Part 0 倒數第二天。
先回答昨天那個問題：哪一個案子先發生？
是昨天那個。
這系列裡我一直用「第一個案子」稱呼設計稿那個、用「第二個案子」稱呼昨天那個開發規範的。那是我講的順序，不是它們發生的順序。真實的順序剛好相反：
發生的順序 第二個案子（開發規範） ──→ 第一個案子（設計稿）
我講的順序 第一個案子 ──→ 第二個案子
而這個反轉要講出來，是因為中間有一段東西一直沒被看見。
第二個案子收尾的時候，我們得到的結論是：「規範要寫清楚。」
下一個案子——也就是第一個案子——我們真的照做了。那份 591 行的規範文件就是這樣來的（後面講第 0 層那一篇會用到它）：四個方框級的絕對禁止事項、六項欄位檢查清單。格式清楚、位置顯眼、語氣強烈。
然後它還是垮了。而且不是垮在規範上。
用昨天那條線，可以直接指出兩個案子各斷在哪：
需求 →（翻譯一）→ 規格 →（翻譯二）→ 程式碼
↑ ↑
第一個案子 第二個案子
翻譯一沒有人做 翻譯二的依據是錯的
我補好了這條線的一端，然後掉進了另一端。
那為什麼要倒著講？
因為照時序講，它會讀成一個勵志故事：撞牆、學到教訓、繼續前進。那個版本會讓你以為問題是「教訓還不夠多」，於是你回頭再多寫幾條規範。
倒著講才看得出形狀：這不是兩個坑，是同一條線上的兩個斷點。
我當時以為我在補一個洞。其實我補的是線上的一個點——而線有兩端。
所以今天要說明的是：為什麼我認為它們是同一件事。
我把三件事並排，是因為分開看的時候，每一件都像是那個當下的意外。
場景一：寫前端 UI（第一個案子）
AI 加了設計稿上沒有的功能說明、統計卡、批次操作、查詢欄、可用餘額。
為什麼會這樣？因為現代的後台管理系統，確實該有這些東西。
場景二：寫後端程式碼（第二個案子）
AI 在每一支 Controller 裡包 try-catch、把讀寫混在同一個 Service、手寫 DTO 映射。
為什麼會這樣？因為一般的 .NET 專案，確實是這樣寫的。
場景三：除錯（另一個進行中的案子）
這一個最近才發生，而它讓我確定前面兩個不是巧合——因為這一次，AI 一行程式都沒有寫。它只是在判斷「問題出在哪」。
狀況是：後端明明處理成功了，前端卻顯示失敗。
AI 的診斷是：後端回傳的資料太大，在傳輸途中被截斷了，所以前端拿到半截東西才解析失敗。解法是去設定檔裡，把單次傳輸的容量上限調大。
為什麼會這樣？因為在一般的 Spring 專案裡，這個診斷是對的——而且它就是最常見的那個原因。
但這個專案有一個細節它不知道：負責發出這個請求的元件，是團隊自己手寫的，不是交給框架自動產生的。而設定檔裡那一行，只有框架自動產生的那一種會去讀。
所以那個建議照做之後——設定改了、服務重啟了、沒有跳出任何錯誤——問題原封不動。它不是改錯了，是那一行設定從頭到尾沒有人在看。
寫 UI、寫後端、除錯。三個階段，三次同一件事：
AI 拿它已知的知識，去填這個專案沒有講的空白。
這裡有一個很反直覺的地方，我想講清楚。
AI 補的空白，補的不是垃圾。
它補的是「一般情況下的最佳實踐」。現代後台該有的元素、標準的 .NET 錯誤處理、一般 Spring 專案的設定方式。這些東西在大多數情境下都是對的，這正是它們會出現在訓練資料裡的原因。
所以問題不是「AI 亂寫」。問題是：
AI 的先驗是「一般 best practice」，
你的專案要的是「這個案子的規範」。
當兩者不一致的時候，AI 會選前者。而且它產出的東西會看起來很專業，因為它確實是專業的。只是專業在錯的方向。這也解釋了為什麼這類問題特別難被發現：
而對照規格是有成本的。然而，修復問題的成本結構：修一個版型 bug 五分鐘，找到它三十分鐘。
當一個 Bug 被植入後，需要花六倍的時間成本來找出問題。
再往前推一層：那些空白為什麼會存在？
第一個案子的空白：設計稿只覆蓋了三成的規格，剩下七成沒有人寫。動態行為、狀態變化、邊界情況。這些不在 HTML 裡。第二個案子的空白：客戶的開發規範是存在的，是一份正式文件。但它沒有出現在 AI 產碼當下的視野裡，也沒有任何機制在違反時發出訊號。
第三個場景的空白：這個專案的 HTTP client 是手動建的。這個事實寫在某個設定類別裡，但沒有人在除錯的時候把它端到檯面上。
所以空白有兩種：
第二種更讓人難受，因為文件明明就在那裡。
「填空白的人」這件事，在 AI 進來之前有一個標準答案，只是沒有人講出來過。
那個人是工程師，而他是在寫程式的過程中順手做掉的。
一個工程師拿到那份 Prototype，他會自然地想：「這個欄位應該要必填吧？」→ 去看舊系統；「手機格式要不要擋？」→ 去問 PM。那個「補齊規格」的動作，隱含在他寫程式的過程裡。 沒有人把它當成一項工作，也沒有人為它估工時。因為它是免費的。
而 AI 不會做那件事。 你給它 Prototype，它就照 Prototype 做。它不會停下來問「那驗證呢」。它沒有那個焦慮。
以前：規格不全 → 工程師邊做邊補 → 補齊了（而且沒人注意到這件事發生過）
現在：規格不全 → AI 照規格做 → 就是不全
所以那個案子留給我最重要的一句是：
「定義要做什麼」，在 AI 開發的時代，變成了一項獨立而且關鍵的工作。
它以前不是。以前它散落在寫程式的過程裡，沒有名字、沒有工時、沒有交付物。而現在它必須有名字、有工時、有交付物。
而「補齊規格」這件事有三層難度，一層比一層難。這三層講的是同一件事：第一個環節為什麼會斷。
| 層次 | 為什麼補不齊 | 這個案子的狀況 |
|---|---|---|
| 一 | 我們指定的規格，本身就不完整 | Prototype 沒有檢核邏輯 |
| 二 | 答案藏在舊系統裡，萃取不出 100% | 散落在事件處理、隱藏欄位、預存程序 |
| 三 | 連客戶都沒有標準答案 | 沒有驗證程序，規則的理由已流失 |
第二層我們試過——想把舊系統的檢核邏輯萃取出來補到 Prototype 上，結果無法 100% 正確，因為那些邏輯有些是刻意設計的、有些是當年臨時補的，而沒有人能判斷哪些該保留。
往下追就撞到第三層：客戶自己也沒有一套標準的驗證程序。 規則跑了十幾年，但沒有一份文件說「這個欄位為什麼必填」，當初知道的人早就不在了。
所以「正確答案」根本不存在，而不是藏起來了。
這意味著：**規格不是「找出來」的，是「決定出來」的。**那是需要有人拍板的工作，不屬於技術範疇。而如果沒有人拍板，它就會用最貴的方式被決定。在測試階段，一輪一輪地吵出來。
第二個案子有一份客戶的開發規範文件。正式、完整、有版號。
它在整個開發過程中發揮的作用是：零。
不是因為沒人讀，而是因為它從頭到尾都只是一份要靠人記得的文件。沒有腳本檢查它、沒有 CI 擋它、沒有 hook 在寫檔時提醒。
而人（包括 AI）在趕進度的時候，會記得的東西非常有限。
我後來在另一個專案看到同一份規範被用得完全不同。它被放進了程式碼庫裡，而且是兩個版本並存（因為規範自己也會改版）。那個案子的狀況好很多。
同一份規範、同一個客戶、兩種做法、兩種結果。
(那個對照是 Part 2 的主題。)
如果要用一句話總結 Part 0 這六天，我會說：
兩個案子的失敗，都不是因為 AI 能力不足。
是因為「這個案子的規範」從來沒有變成 AI 做不到違反的東西。
其中一個案子後來自己做了歸因，結論是：
我認同這個比例。而且那 5% 裡面，大部分還是「它不知道」而不是「它做不到」。那個案子的回顧裡有一句話，我覺得是整個 Part 0 最好的收尾：
不是「AI 不行」，是「AI 沒被告知要做這個」。
而「沒被告知」在兩個案子裡是兩種不同的斷法，值得分開：
案子一 缺的是「規格」 沒有人說得出這個系統應該怎麼運作
案子二 缺的是「開發規範」 給了兩三百頁文件，而他真正在意的不在裡面
兩件事的層次不一樣：一個是「要做什麼」沒有答案，一個是「要怎麼寫」的答案寫錯了地方。
但它們的斷點是同一個。都不是 AI 做不出來，是沒有人把那件事交到 AI 手上。第一種要有人先去決定出來，第二種要有人先問出來。兩個動作都不是技術，也都不是 AI 做得到的。
而它們的共同點還有一個，我認為更重要：在 AI 進來之前，這兩個洞都可以靠工程師邊做邊補，補完沒有人會發現。
這就是後面要回答的問題，而且答案比「寫清楚一點」複雜得多。
先講一個會讓人不太舒服的事實：**第二個案子其實有寫。**那份客戶的開發規範寫了。第一個案子的主規範文件裡也寫了「設計稿沒有的欄位不要加」。兩邊都寫了，都用了很強的語氣。
而且有一個差別要標出來：第一個案子那條，是在問題發生之後才補上去的。 所以它連「寫了但沒攔住」都算不上。它在該攔的時候還不存在。 這兩種失效等一下會分開算。
然後 AI 還是違反了。
所以「告知」不是寫下來就算數。
但在進到「怎麼讓規則有效」之前，明天還有一件更根本的事要處理。**因為那張表上的第一種失敗，我一直還沒真正拆開。**回去看 Day 02 那張表：第二種是「多做」，你會看到一個很專業的東西；第三種是「錯維度」，你會看到一個綠燈。而第一種是「漏做」。你什麼都看不到。
它是三種裡最安靜的一種，而且它跟「規則有沒有效」無關。規則再強，也擋不住一件從來沒有被要求過的事。 明天是 Part 0 的最後一天，把三種合起來看。
本系列所有案例均經去識別處理，不指涉任何特定客戶、系統或產業。
iThome鐵人賽
看影片追技術