Part 0 最後一天。

前六天講的是「哪裡出錯了」。今天要問一個更難的問題，而且我到現在都還沒有完整的答案：

當一條指令要 AI 同時處理很多不同維度的事情時，我們該怎麼進行驗收的確認？

這是那個案子事後反省下來，我認為最核心的一條。

回到第一種失敗：那些「沒有做」的東西

測試階段冒出大量的問題，而其中最集中的一類是前端驗證沒有被實踐：

• 必填欄位沒填，不會顯示紅字提示
• 手機、日期這類欄位，格式錯了不會擋
• 長度超過資料庫限制，前端不會提醒
• 修改密碼那個彈窗，七個驗證情境全部失效

Day 03 講過那七張問題單其實是同一個 bug。但今天要看的是另一個問題：為什麼它們一路活到測試階段。

真正的原因：我們把一份 Prototype 當成了規格

先回答「為什麼一路活到測試階段」。這一類東西真正的原因，既不是深度不夠，也不是規範沒寫：

是規格定義的問題。

具體是這樣的。

舊系統是 Web Forms。它上面有檢核邏輯。必填、格式、長度、各種業務規則，全部都在，跑了十幾年。

而新系統的起點是一份 Prototype。Prototype 上面有版面、有欄位、有按鈕。但它沒有檢核邏輯。

然後我們跟 AI 說：這個 Prototype 就是規格。

於是 AI 做出來的東西，沒有檢核邏輯。

而它完全照規格做了。

一開始我把這件事歸類成「AI 漏做了」。但這個說法不對——AI 沒有做錯任何事。 我們給它的規格裡就沒有那些東西，它照著做，產出跟規格一致。要說有誰失職，那是定義規格的人。

這裡有一個很容易被忽略的類別錯誤：

Prototype 表達的是「長什麼樣」，不是「怎麼行為」。
它天生就不是完整的規格。

版面、欄位、按鈕位置。這些它表達得很好。而「這個欄位不填會怎樣」「輸入格式錯了要顯示什麼」「超過長度要不要擋」，它一個字都沒說。

我們卻把它當成規格的全部。

「做錯」有訊號，「沒做」沒有

先講一個我覺得很關鍵的區分。

如果 AI 把驗證做錯了。例如手機格式的規則寫錯、擋了不該擋的。那你會看到一個錯的東西。你輸入正確的資料被擋下來，馬上就發現了。

但這些不是做錯，是沒有做。

而「沒有做」有一個很麻煩的性質：

你什麼都看不到。

頁面打得開、欄位填得進去、按送出會存檔、資料進資料庫。看起來完全正常。要發現那些驗證不存在，你必須故意去輸入錯的東西。

那是測試員的工作，不是開發驗收的工作。

後面會講到一個概念叫「缺漏的沉默」。程式碼寫錯了測試會紅，放錯目錄檢查會擋，而「該做的事沒做」什麼都不會發生。

前端驗證就是這一類。

一條指令，十三個維度

那為什麼會沒做？

因為我們給 AI 的那條指令，實際上同時涵蓋了十幾件不同的事。「實作會員資料維護頁面」——這九個字裡面藏著：

 1. 版型結構      有哪些區塊、怎麼排
 2. 欄位清單      有哪幾個欄位
 3. 欄位型別      文字、數字、日期、下拉
 4. 必填規則      哪些必填
 5. 格式驗證      手機、日期、身分證的格式
 6. 長度限制      每個欄位的上限（而且要對得上資料庫）
 7. 錯誤訊息      怎麼顯示？紅字？位置在哪？文案是什麼？
 8. 送出行為      按下去做什麼
 9. API 串接      打哪支、參數怎麼組
10. 成功之後      跳轉？重整列表？顯示提示？
11. 失敗之後      錯誤怎麼呈現、要不要保留已填的資料
12. 權限控制      誰能看、誰能改
13. 查看 vs 編輯   兩種模式的差異

**十三個維度。而它們彼此獨立——任何一個做不好，都不影響其他十二個。**這件事很重要，因為它意味著：版型對了，不代表驗證對了。 兩者之間沒有任何連動關係。

13 / 4 / 6-8 / 1

現在把整條鏈路上的維度數量攤開來看：

指令涵蓋   13 個維度
規格寫了    4 個      ← 業務目標、欄位、資料表、大致的驗證提示
AI 做了     6-8 個    ← 它認為重要的那幾個
驗收驗了    1 個      ← 「打開來看看能不能用」

中間那些沒被寫下、也沒被驗到的維度，就是後來那 187 張問題單的來源。

而且注意這四個數字的落差是逐段擴大的：

• 規格比指令少，是因為寫規格的人也沒把維度想全
• AI 做的比規格多一點，是因為它會用先驗補（Day 09 講的）——但補得不完整、也不一定對
• 驗收比 AI 做的少很多，是因為人的驗收天生就是整體印象

人的注意力是序列的，而指令是扇形的

這一點我想講清楚，因為它不是「驗收的人不認真」。

你打開一個頁面，得到的是一個整體的感覺。版面看起來對、欄位好像都在、填了資料能存。

你不會自動產生十三個獨立的判斷。

這是認知的限制。人腦處理視覺場景的方式就是整體優先，細節要刻意去看才會看到。而「刻意去看十三次」需要一份清單，不能靠記憶。

所以問題不是「驗收要更仔細」。再仔細也還是一維的。

問題是：驗收的維度必須被外部化成一份清單，而那份清單要從哪裡來？

規格的職責是列出「有哪些維度需要被驗收」

我們的直覺是：規格要寫得更詳細。

但「更詳細」是一個沒有終點的要求。你可以把那十三個維度全部寫成散文，寫成三頁，然後。驗收的人還是只會看一眼。真正的轉變是這個：

規格的職責，不是描述「要做什麼」，
是列出「有哪些維度需要被驗收」。

差別在哪？

描述式的規格（那個案子當時的樣子）：

會員資料維護作業：提供會員基本資料的新增、修改、查詢功能。
欄位包含姓名、手機、生日、地址等。需依規定進行必要欄位檢核。

讀起來沒問題。但你沒辦法拿它去驗收。「需依規定進行必要欄位檢核」，是哪些欄位？檢核什麼？沒過的時候要顯示什麼？可驗收的規格：

postconditions:
  - 必填欄位未填時，該欄位下方顯示紅字提示
  - 手機格式不符時，顯示「手機格式錯誤」並阻擋送出
  - 姓名超過 10 字時，輸入被截斷且顯示上限提示
  - 查看模式下，所有欄位為唯讀且不顯示送出按鈕
  - 送出成功後，回到列表並重新載入
errorCases:
  - 當 API 回傳 409 → 顯示「資料已被他人修改」並保留已填內容

每一條都是一個維度，而且每一條都可以被單獨驗收。

這就是為什麼後面 Part 2 會花整整一篇講「規格要描述可驗證的行為，不是實作步驟」。它的真正動機就在這裡。

四個層次的做法

我把目前試過的做法排成四層，由淺到深：第一層：把維度列出來（規格層）最基本的一步。每個功能的規格，強制列出後置條件與錯誤情境，而且至少各一條。這條規則的作用是強迫寫規格的人把維度想過一遍，不是湊數。第二層：要求 AI 回報它涵蓋了哪些維度（產出層）

這個做法很便宜，效果不錯：在指令裡要求 AI 產出之後，附一份「本次涵蓋的維度清單」，以及明確標示沒有處理的部分。它不會讓 AI 變得更完整，但它會讓「漏掉的東西」從隱形變成一行字。

(後面會講到同一個原則的另一個版本：拍不到的東西，要嘛補工具、要嘛人工驗證、要嘛在報告中誠實標示未涵蓋。沒有第四種。)第三層：分維度驗收（驗收層）

拿著規格的那份清單逐條打勾，不是「打開來看看」。

這裡有一個實務上的關鍵：清單必須跟規格是同一份。如果驗收清單是另外寫的，它就會跟規格漂移。然後你有兩份不一致的維度清單，而且不知道哪份是對的。**第四層：讓機器驗維度（自動化層）**最後一步是把可以自動驗的維度變成測試。每一條後置條件對應一個斷言。

那樣「這個維度有沒有被實作」就變成 CI 會回答的問題，不是人要記得檢查的事。

這正好是整個 Part 2 在講的東西。

一個判準：你的驗收方式是「打開來看看」嗎

如果你只想帶走一句話，我建議這句：

如果你的驗收方式是「打開來看看」，那你只驗了一個維度。

你的指令涵蓋了幾個？

但「怎麼知道維度列全了」，我沒有答案

這一篇跟其他篇不一樣，我想誠實說明：這個問題我還沒解決。上面那四層做法我都試過，但每一層都有代價：

還有一個更根本的問題：你怎麼知道維度列全了？

我列的那十三項，是事後回頭數出來的。而在事前，沒有人會想到「查看模式和編輯模式的差異」也是一個維度。直到它出事，影響了八個表單。

而 Day 01 講的那第三層難度，在這裡會再咬你一次：**當客戶自己也沒有標準的驗證程序時，那個維度的「正確答案」不是被找出來的，是被決定出來的。**這代表列維度清單這件事，不能只靠翻舊系統、也不能只靠問客戶。它需要有人拍板。

如果沒有人拍板，它就會用最貴的方式被決定。在測試階段，一輪一輪地吵出來。

所以老實說，我目前的做法比較像是：

• 從已經出過事的維度開始列（那 187 張問題單就是一份現成的清單）
• 每次漏掉一個新維度，就把它補進清單
• 而且優先把它變成機器可以驗的（後面會講為什麼要往這個方向）

這是一個逐次逼近的過程，不是一次做對的事。

Part 0 的總表

第一天給了一張骨架。七天過完，可以把它填滿了。

產出要「對」，三個環節必須同時成立：規格說了 → 產出做了 → 驗收驗了。

而第二天和第三天講的，是三種失敗的共同下游：當失效沒有訊號，它們會全部堆到測試階段。九輪人工測試、187 張問題單、12 輪修復迴圈，以及那個 34 倍的深度落差。

三種失敗的共同結構

把三列壓成一句話：

規格沒說的，AI 不會停下來問。
它要嘛不做（一），要嘛照它的先驗做（二）。
而這兩種驗收都看不到——因為驗收只驗它想得到的那一個維度（三）。

這就是為什麼那張漏斗有意義：十三個維度、規格表達四個、AI 做六到八個、驗收驗一個。 三種失敗全部發生在那些沒有交集的格子裡。

而它們之所以都沒有訊號，是因為約束的可見性不同

這是 Part 0 的第二條軸，Day 06 給過一半，現在補完：

上面三列有訊號，下面三列沒有。而這一年咬到我的，全部在下半部。

所以 Part 0 收斂下來只有一句：

問題不在 AI 產出的品質。
在於「對錯」這件事，有一大半根本沒有被表達成機器判斷得出來的形式。

規範與規格，沒有變成「可以被檢查的東西」。

明天開始 Part 1，講一個框架來處理這件事。它把規則放在一條光譜上：

希望 AI 別做 → 告訴 AI 別做 → 提醒 AI 別做 → 讓 AI 做不到

那兩個案子的規則，幾乎全部卡在第二格。

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