昨天談的是 AI 總是一個口令一個動作的處理 Bug，沒有累積，不會隨著經驗變多而增長。

今天往上游走，走到它們(Bugs)被種下去的那一刻。

Day 02 的時間軸裡有一行，當時看起來完全是好消息：

第 1 個月：一週掃完舊系統的全部頁面，十天產出全部需求文件。

那個速度確實很快，快到當時所有人都覺得 AI 真好用。今天要講那份「快」的代價。而代價不在速度本身，在它掩蓋掉的東西。

先講結論，因為它跟標題那句話有關。

那批文件打開來看，前面幾份寫得很認真，後面八十幾份是樣板。當時我們的解釋很自然：AI 做到後面累了嘛，context 塞滿了嘛。

這個解釋讓我們錯過了真正的問題，而且錯過了大概兩個月。

深度落差 34 倍：四份將近兩千行，八十幾份五十幾行

那九十幾份需求文件，深度長這樣：

四個「示範頁面」      七百多行 ~ 三千六百多行
其餘八十幾個頁面      全部落在 50–70 行

四份的平均，是其餘八十幾份平均的 34 倍。

那 50 行裡面有什麼？我抽了其中一份看全文：六個一級標題、三行業務目標、一行功能需求、一行資料表名稱、一行驗證提示，最後加一段套版的「Clean Architecture 實作 / CQRS 模式 / 驗證框架」共通建議。

這不是需求，這是樣板。

前置工程的不均衡，會在後期以測試疲勞的形式還回來

後來把測試問題的分布跟這份深度落差對照，結果非常整齊：

• 被深度分析的那四個功能 → 後期測試問題相對少
• 被淺分析的功能（附屬明細、關係人、文件、簡訊、報表）→ 成為測試 bug 的主產區

這不是巧合。50 行的樣板裡沒有寫「這個欄位是必填」「這個日期是民國年」「這個狀態轉換的條件是什麼」，AI 產碼的時候當然只能猜。而猜出來的東西，就是後面測試員一張一張抓出來的問題單。

所以我後來把它寫成一句話：

前置工程的不均衡，會在後期以測試疲勞的形式還回來。

你在前期省下的那八十份深度分析，會在後期變成一百多張問題單、九輪人工測試、和一個做不完的收斂。

「完成」的定義是「產出了檔案」，不是「產出夠用」

這件事最值得警惕的地方，不是「有些頁面分析得比較淺」。任何專案的資源分配都不均勻，這很正常。

真正的問題是：沒有任何環節發現這件事。

那份分析總結報告寫的是「全部頁面 100% 完成」。而所謂完成，定義是只要產出檔案就算完成。沒有人去檢查：一份 50 行的樣板和一份 3,600 行的深度分析，該不該被同一個 ✅ 認定為「已完成」。

我後來把這條寫進團隊規範，因為它不只發生在這個案子：

AI 報告完成度時，是按「執行了任務」算，不是按「產出夠用」算。

AI 收到的任務是「為每一頁產出一份分析」。它做到了——每一頁都有，一份不少。它不會自己意識到「我這份寫得太淺」，因為「夠不夠深」不在它的任務定義裡。

而人也沒有發現，因為進度報表上那一欄是綠的。

能被統計發現的異常，就不要靠人讀出來

答案沒有很聰明，但有效：抽樣審核。

具體做法：

• 每個模組隨機抽一個頁面做深度檢查，不過就整批退回
• 要檢查的是「這份產出能不能直接拿去產碼」，而非「有沒有產出」
• 訂一個最低門檻——例如「每個頁面至少要列出所有欄位的必填/格式/長度」——達不到就不算完成

還有一個更便宜的做法，是我後來才想到的：看行數分布。如果那九十幾份文件的行數畫出來是雙峰。四份幾千行、八十幾份五十行。那不用讀內容就知道有問題。這種檢查可以寫成三行腳本，掛在產出之後跑。

能被統計發現的異常，就不要靠人讀出來。

AI 報完成度是按「執行了任務」算

再往回推一層，這個案子的需求工程還有另一個問題，我覺得也值得講。這個專案同時有兩套需求文件並行：

• 一套以舊系統頁面為單位，描述「業務目標 + 功能需求 + 資料表 + 驗證」
• 一套以功能模組為單位編號，描述「新系統要做什麼」

兩套並存，內容大量重疊。而且——

兩套都不是真正的需求。

前者是「舊系統長什麼樣」（逆向產出的現況），後者是「我們要做哪些工項」（工作清單）。

真正的需求——業務流程、邊界條件、例外處理、狀態轉換。一份都沒有。它們要等到停擺重啟之後，2 月底才開始系統地寫，最後成為那 149 份 Use Case。

所以前面那句話可以講得更精確一點：重啟做的第一件事，不只是「把需求重寫」，而是「第一次真的寫需求」。

那個頭重腳輕，是模型的問題，還是我們的問題？

這一節是我後來才想清楚的，而它可能是這一整篇最有用的部分。

那四份寫得很認真的，是最先做的。 而八十幾份樣板，是後面批次跑出來的。

當時我的直覺解釋是：AI 累了。 context 愈填愈滿、token 愈用愈多，於是後面的產出愈來愈簡略——就像一個人寫到第五十份會開始複製貼上。

這個解釋不能說錯，但它含糊。所以先把「累」這個字拆開，因為它其實混了三件不一樣的事：

第一列要先劃掉。AI 不會累——它沒有意志力這個東西，第八十份的產出品質不會因為「它已經做了七十九份」而下降。

第二列是真的，而且它正是「工作量大小」在 AI 開發裡的意義：你一次交出去的量，會直接決定每一份能分到多少注意力。 八十份需求擠在同一個 context 裡，每一份能被「認真對待」的份額就是八十分之一。這不是它偷懶，是你把它的注意力稀釋了。

而第三列才是最貴的那個。

因為那四份「示範頁面」之所以認真，不只是因為它們在前面——是因為做那四份的時候，我們是一份一份看的。有人讀了、有人回饋了、有人說「這裡不夠」。

而後面八十幾份，是一次丟出去、一次收回來的。

前四份    一次一份  →  做完 → 有人看 → 給回饋 → 再做下一份
後八十份  一次全部  →  做完 → 沒有人一份一份看 → 直接進下一階段

所以真正變了的不是模型的狀態，是我們的工作方式。

那個雙峰分布的中間為什麼是空的？因為沒有任何一份是在「有回饋」的情況下產出、然後又被放進批次的。它不是一條逐漸下滑的曲線——是兩種工作模式，各自產出一群。

而這正好是 Day 03 那件事的另一個版本：一次做完的代價，不是做得比較差，是沒有中間的修正點。

所以什麼是「適當的窗格」

這個問題我沒有標準答案，但我有一個判準，而且它比「一次做幾份」具體：

一批的大小，應該由「你打算看多細」決定，不是由「AI 一次能吃多少」決定。

這裡有三個上限，而我們當時只看了第一個：

技術上限是最不重要的那一個，而它是唯一會出現在工具介面上的數字。

另外兩個都不會有人提醒你：context window 顯示還有空間，不代表塞進去的東西還能被「認真處理」；而你自己讀得完幾份，更是沒有任何工具會告訴你。

那個案子的錯誤，就是用第一個上限決定了批次大小。

實務上我後來的做法是這樣：

三列的重點都在中間那欄。批次可以變大，前提是驗收方式跟著換——從「逐份讀」換成「抽樣讀」，再換成「看分布」。

那個案子的問題是批次放大了，而驗收方式沒有跟著換。 它從第一階段的「逐份讀」，直接跳到「產出了檔案就算完成」——中間那兩格是空的。

（後面講那條產線的時候會看到相反的做法：每一批都小到可以跑完一輪完整驗證，而不是大到只能看檔案數。）

小結

今天這篇的七個重點：

1. 深度不均衡會延後爆發，而且爆發的形式是測試疲勞，不是「需求寫得不好」——所以很難歸因回去
2. AI 的「100% 完成」是任務完成度，不是產出充分度，這兩者需要不同的檢查
3. 描述舊系統現況 ≠ 需求，描述工項清單也不是；需求是流程、邊界與例外
4. AI 不會累——把「累」拆開來看是三件事：模型疲勞（不存在）、注意力被稀釋（工作量的問題）、沒有人給回饋（工作方式的問題）
5. 你一次交出去的量，會直接決定每一份能分到多少注意力——八十份擠在同一個 context 裡，每一份就是八十分之一
6. 那個頭重腳輕不是模型累了，是我們的工作方式換了——前四份一次一份、有人看有人回饋；後八十份一次丟出去一次收回來。雙峰分布的中間之所以是空的，因為那是兩種工作模式各自產出一群，不是一條下滑的曲線
7. 一批的大小，應該由「你打算看多細」決定，不是由「AI 一次能吃多少」決定——批次可以放大，前提是驗收方式跟著換（逐份讀 → 抽樣讀 → 看分布）

明天

明天講一個方向相反的問題。今天講的是「AI 做得太少」，明天講「AI 做得太多」——而且做得太多，比做得太少更難發現。

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