昨天講的是 AI 做得太少——很多份讀取程式規格後的需求只有 50 行。

今天講相反的：AI 做得太多。

而且我認為這個問題更難處理，因為做太少你看得出來，做太多看起來很合理。多反而覺得詳盡的錯覺。

我們素材很多，但這些不是規格

先講一件事，因為它決定了這一篇該怪誰：這個案子不缺參照物。

後台設計稿          58 份 HTML
全站設計資產       111 份 HTML、87 份 CSS、46 份 JS、68 張 PNG

每一份 HTML 都是靜態渲染好的完整頁面。表格欄位、按鈕、版面、樣式全部就位。例如主檔列表那一頁，設計稿列出的欄位是 12 個。不多不少，寫得很清楚。

所以這不是一個「沒有東西可以參照」的案子。

而且在主規範文件裡確實有一條「設計稿沒有的欄位不要加」。而那條是我在發現 AI 亂加之後，才補上去的。

也就是說：

AI 產出那些多餘欄位的當下，它沒有違反任何一條寫下來的規則。
它違反的，是一個當時只存在於我腦袋裡的預期。

這件事跟 Day 02 那條時間軸是同一個形狀。那個案子的規範文件，全部出現在第 2 個月，也就是問題冒出來之後。規範不是護欄，是事故報告的副產品。

因為是批次的修改程式，所以當發現問題的時候，應該也是批量的錯誤。
如何讓寫完的當下就有辦法「驗證」？

回到我們探討的議題，當我寫下規則後，為什麼 AI 還是會自己添加東西，這是兩個問題：

1. 它加的時候，我為什麼沒有預料到？
2. 而我補上那條規則之後，它就不加了嗎？

第一個問題是今天的主題。

第二個問題我要老實說：我還沒有仔細估算過。 我手上有那 19 張標題含「多餘」的單，但我沒有把「規則補上去的那一天」當成切點，去比較前後的數量。所以我不知道那條規則到底有沒有效。

而「寫上去了，然後呢」正好是後面整整一個 Part 要處理的問題。這個案子沒有給我答案，它只給了我那個問題。

不過上面那幾個數字，我得先自己打一個折。

「58 份」「111 份」是檔案數，不是覆蓋率。 昨天整篇在講的就是這件事。那份報告寫「全部頁面 100% 完成」，而所謂完成的定義是「只要產出檔案就算完成」。我如果拿檔案數來論證「規格夠用」，等於一天之內犯了同一個錯。

這一篇後半會算出那個折扣有多大：設計稿大概只表達得出三成的規格。 所以準確的說法是：

不缺的是「素材」，缺的是「規格」。
而這兩件事長得很像——像到當時沒有人覺得規格有問題。

第二種失敗：規格沒說，AI 自己補了

實際發生的違規，超過 30 個問題單。舉幾個：

在 187 個問題單裡，有 19 個（10%）的標題直接包含「多餘」兩個字。多餘欄位、多餘按鈕、多餘區塊、多餘查詢條件、多餘返回鍵。那個地址欄位的例子還有一個細節，我覺得很值得記：修復紀錄裡有一條是「移除已註解的 address 程式碼」。

也就是說——**之前有人試圖移除地址欄位，但只註解沒清乾淨；後來 AI 又把它「復活」了一部分。**AI 對「曾經存在過的元素」有保留傾向。註解掉的程式碼對它來說不是垃圾，是線索。

規格說什麼就是什麼，AI 的「合理」反而是違規

想通這件事花了我一段時間。

AI 加的那些東西是什麼？功能說明、統計卡、批次操作、查詢欄、可用餘額、麵包屑、返回鍵。

每一個都是現代後台該有的東西。

先把這句話的帳算清楚，因為它是這一篇最容易被高估的地方。我有證據的是「多做」，不是「太好」：

所以「太好」是我看著那份清單下的詮釋，不是量出來的，也沒有第三方認定過。我仍然相信這個詮釋，但它跟上面那 19 張單不是同一個等級的東西，不該混在一起講。

如果今天是做一個新產品，這些元素全部加分。AI 的訓練資料裡全是這種東西：SaaS dashboard、各種 UI 元件庫範例、設計系統文件。它學到的 prior 是：

• 列表頁該有搜尋、篩選、分頁、排序、批次操作
• 表單該有即時驗證、錯誤提示、麵包屑
• 操作完該有 toast、loading、skeleton

但這個案子要對齊的，是一套跑了十幾年的 Web Forms 後台。它的介面是那個年代的做法：扁平、沒有操作回饋、沒有批次功能。

而那不是缺點，那是規格。 那套系統的使用者已經用它工作了十幾年，每一個欄位擺在哪裡、要按幾下，都是他們的肌肉記憶。

所以真正的難題是：

AI 要做的是「對齊到一份規格」，而那份規格剛好不含那些現代元件——
這違反它的訓練偏差。

規格說什麼就是什麼。AI 的「合理」，在這裡反而是違規。

這句話我覺得是這個案子留下最有用的一句。

反例：地址那四欄，不是這個機制

而我自己這個詮釋，被同一篇裡的一筆紀錄打了一下。

前面提過那條修復紀錄：「移除已註解的 address 程式碼」。如果 AI 加地址欄位是因為「現代後台該有地址」，那它應該是憑空生出來的。但事實不是——**那四欄是它從這個 codebase 裡註解掉的舊程式碼撿回來的。**這是完全不同的機制：

機制一   訓練資料的 prior      →  統計卡、批次操作、麵包屑（現代後台該有的）
機制二   這個 repo 裡的殘留    →  地址四欄（三年前某人註解掉、沒清乾淨的）

**兩者的共同點只有「規格沒說，它自己補了」。至於補進去的東西好不好，兩個機制的答案完全相反。**還有一筆也不該硬歸在「過度生成」底下：「關係人列表缺少 8 欄、多出 5 欄」。那是漏做和多做同時發生，它不是做得太好，它就是做錯了。

所以這一篇真正站得住的結論，比「AI 做太好」更小、但也更有用：

AI 用它手邊「最近的」prior 填補規格沒說的地方。
那個 prior 有時候是最佳實踐，有時候只是別人三年前註解掉的爛主意。

為什麼撐到人工測試才被抓到：UI 的約束是沉默的

那為什麼這種違規會一路撐到人工測試才被抓到？

因為 UI 的約束是沉默的：

API 違反 OpenAPI  →  CI 紅燈
DB  違反 schema   →  寫入失敗
UI  違反設計稿    →  什麼都不會發生

程式編譯通過、頁面渲染正常、沒有 console error。對 AI 來說，一切正常，任務完成。

但人看一眼就知道「咦這欄位多了」。

UI 的約束只存在於使用者的眼睛裡，而 AI 沒有眼睛。這個結構性差異意味著一件事：UI 不能依賴 AI 自我驗證，必須有外部的 ground truth 比對。

愈動態的規格，失敗率愈高

後來我把 UI 失敗按「規格層次」拆開，發現失敗率差距很大。

先講清楚這四個數字的來源，因為它是我後來被抓到的一個問題：它們是我的印象，不是量出來的。

我手上可稽核的只有兩筆。「一個模組的 review 結果是 37 頁裡 14 頁 FAIL」、「187 個問題單裡有 19 個標題含『多餘』」。而下面這張表的百分比沒有分子分母，是我讀完那批問題單之後的估計。

我原本把它寫成「大致失敗率」就交差了。但「~30%」這種寫法借用了量測的權威。它比誠實地說「我沒量過」更糟，因為判斷至少誠實地標示自己是判斷。這正好是後面會講到的那句：寬區間不丟臉，假精確才丟臉。

所以這張表請當成排序讀，不要當成數值讀。我有把握的是那個順序，不是那些數字：

有一個模組的 review 結果是 37 頁裡 14 頁 FAIL。而認證模組四頁全部 PASS。那四頁的問題只有「確認按鈕顏色建議調整」這種等級。**規律很清楚：愈靜態，AI 做得愈好；愈動態、愈跨頁面，失敗率愈高。**原因也不難理解：

• 視覺層——AI 的訓練資料最多，prior 最準
• 版型層——決定依據是業務規格，不是視覺最佳實踐。這頁該不該有地址，是業務問題不是 UX 問題
• 行為層——要串 form / state / handler / API 四個東西，AI 容易做半套：加了欄位沒接驗證、加了按鈕沒接事件、加了送出沒重整列表
• 流程層——規格根本不在設計稿裡。HTML 是靜態的，表達不了「狀態機」「角色 → 視圖」

流程層那個問題後來釀成一份獨立的品質報告：使用者反映「查看按鈕和編輯按鈕行為一樣」，排查之後發現是系統性設計缺陷。所有表單都把「修改」和「查詢」合併處理，沒有區分唯讀模式，影響 8 個以上的表單。

那份報告寫的根本原因是一句話：缺乏統一的程式碼範本與規範。(這句話後面會再出現一次，在 Part 2 講黃金範例的時候。)

設計稿是一個範例渲染，不是完整規格

還有一個結構性問題：HTML 設計稿是「一個範例渲染」，不是「完整規格」。它告訴你：

• ✓ 這頁該有什麼欄位（從表頭推得）
• ✓ 大概的版面排列
• ✓ 樣式類別
• ✗ 互動行為（按下去會發生什麼）
• ✗ 不同狀態的視圖（載入中／空清單／錯誤）
• ✗ 邊界情況（大量資料、權限不足）
• ✗ 跨頁互動（跳過去再回來，帶什麼）

粗估設計稿覆蓋了三成的規格，剩下七成是 AI 在補。這就是開頭那個折扣的大小。58 份檔案，三成規格。而那七成的補空白，全部由 UX 直覺主導。

所以「規格精細度應該與動態程度成正比」。動態的部分不能只給靜態 HTML，要給狀態機或互動規格。

修 5 分鐘、找 30 分鐘——這個不對稱決定了問題會堆在哪

最後講一個成本結構的問題，它解釋了為什麼這類問題會累積成災。

修一個版型 bug：刪掉一個欄位，5 分鐘
找一個版型 bug：人眼看 + 對照設計稿 + 寫問題單，30 分鐘

修復成本低，但發現成本高。

這個不對稱造成的結果是：問題大量堆在測試端。測試員每天從畫面上找出十個「多餘欄位」「位置錯誤」「按鈕沒反應」，每個都立單。這些都是便宜可修但很煩的 bug。

然後 12 輪的修復迴圈，每輪處理五件，連續跑十二輪。用一句話總結那個狀態：

測試員負責看出哪裡不對，AI 負責照著改，中間沒有人負責看出「這幾個其實是同一件事」。

這句話我認為適用於很多正在用 AI 開發的團隊。

明天

今天講的都是規格沒說、AI 自己補。但這個案子還有一種更難處理的情況。規格說了，而且說了兩件互相矛盾的事。

那時候 AI 補的就不是空白了，是在兩個都有權威的答案裡挑一個。明天講那個。

本系列所有案例均經去識別處理，不指涉任何特定客戶、系統或產業。