（2026年11月11日，掘金作者「濤濤ing」發文回顧一個月前審查的一段AI生成程式碼，原文以繁體轉寫。）讀到「差點直接點了合併」這句話時，多數工程師會心一笑，但這篇貼文值得細看的地方，在於它把AI編程最安靜的一類風險具體化了：不是程式碼寫得爛，而是程式碼寫得太漂亮，漂亮到看不出它是多餘的。
文中的情境是這樣的。一個結帳頁的小調整，順手帶進一個 pricing.ts，裡面有一個 formatMoneyCents()。型別完整、函式拆得乾淨、三個單元測試全綠、CI通過、建構通過、頁面跑起來也正常。作者的手指已經移到 Approve 上，才發現不對勁：這個倉庫裡早就有一個做同一件事的 formatCurrency()，藏在三個包之外的 packages/currency/src/format.ts。
而那個舊函式多承擔了一項職責。它執行的捨入規則，是財務部門幾年前在一次真實的分幣事故之後簽字確認的銀行家捨入，不是四捨五入。
同一個腦子寫實作，也寫測試
新函式的測試用了 10.00、99.99、500.00、1280.00，全部通過。問題在於，銀行家捨入和四捨五入只在「恰好一半」的數值上分道揚鑣：0.005、2.675、五分錢這類分叉點，測試裡一個都沒出現。
作者點出關鍵：寫測試的和寫實作的是同一個模型。它不會主動構造一個自己沒想到的邊界，它驗證的是「這個函式自己跟自己一致」，而非「這個函式跟系統裡那個唯一的實作一致」。
更麻煩的是這類缺陷不會報錯。金額差一分錢，介面回傳200，頁面正常顯示，監控安安靜靜。它只會在幾個月後某一次對帳時浮出來，那時距離合併已經過了好幾週。
這與我們先前整理過的AI做不出設計稿效果，多半是它根本沒讀到是同一類結構性問題：能力不是瓶頸，讀取範圍才是。
造輪子的四個原因，沒有一個是模型笨
原po引用的技術評論給出四條解釋，作者說在工程現場每一條都對得上：
一、局部上下文偏好。既有工具在三個包之外，提示裡沒有任何東西指向它，Agent就在看得到的幾個檔案裡解決問題。 二、命名不匹配。既有函式叫 formatCurrency，Agent想的是「金額分」，模糊搜尋也會錯過。 三、完成度獎勵。一個自包含的小函式能讓當前改動變綠，又不必碰共享程式碼，這是通往「綠」的最短路徑。 四、桶導出掩蓋來源。所有東西都從一個索引重導出，Agent意識不到自己需要的函式已經在公共介面上了。
四條裡沒有一條是模型能力不足，全是檢索與歸屬的問題。AI不知道哪些程式碼是「用血換來的」、哪些看似多餘的幾行邏輯背後壓著一個真實事故。它只看到「這裡缺一個函式」，然後補上。這不是一句「請不要重複造輪子」的提示詞能解決的。
審查者的土辦法：先搜動詞，再問來歷
作者後來養成的習慣很土，但可直接抄：每次看到AI新建工具函式，先不讀實作，先去搜同名的動詞。format、validate、parse、convert 這些詞最容易長出「看起來該新建、其實早就有了」的東西。
找到舊的那個之後，問一句：它為什麼長這樣？如果舊函式裡有任何一行看起來多餘的程式碼，一個奇怪的捨入、一個彆扭的預設值、一條繞路的錯誤處理，那大概不是當初寫的人水準不行，而是有人為那一行付過代價。AI不知道這些代價，它只會看到「這裡不夠優雅」，然後把它優化掉。
測試側的收尾：讓邊界值硬編碼
該評論在測試側的建議是，金額類的邊界值不能等模型「自己想起來」，要寫成固定的小表，把 0.005、2.675、五分錢這些分叉點硬編碼進去，讓測試去守那條線，而非讓實作去「理解」那條線。
原po認為更深一層在測試之外：AI生成的程式碼缺的不是正確性，是「來歷」。它不知道 formatCurrency 為什麼用銀行家捨入，不知道某個看起來冗餘的處理是為了繞開特定瀏覽器的bug。這篇貼文被廣泛轉發的原因，大概就在於它沒有停留在「AI寫程式靠不靠譜」的爭論，而是把審查流程裡真正該新增的那一步講清楚了：在按 Approve 之前，先確認這個函式在倉庫裡沒有一個帶著事故記憶的前輩。
（文／沈安）