Part 2 開始。前十七天講「為什麼失敗」，接下來七天講「做對了長什麼樣」。

而且這次有數據。

先說清楚這套東西是從哪來的

接下來七天要講的「規格驅動工廠」，不是我原創的。

它的原型來自 Teddysoft 的 ai-coding-exercise 範本專案（Copyright© Teddysoft），我是去上課的時候接觸到的。那個範本專案給的東西包括：.ai/ 與 .dev/ 雙目錄的知識庫結構、規格閉環的概念、L1 檢查腳本的做法、以及把失敗沉澱成資產的制度。

這幾樣是這一整段的地基，而它們不是我的。

我做的事情是三件。

一、把它整理成一份可執行的建置手冊。Phase 0 到 Phase 4，含每個階段的驗收標準與硬性順序。原範本是一個「已經建好的樣子」，不是「怎麼從零建起來」。

二、從它的反面教訓長出護欄。 我分析那個範本的兩個版本時，記下了幾個問題：文件漂移、決策紀錄撞號、威嚇式的 prompt 寫法、以及 schema 驗證被刪掉。後面幾天要講的文件一致性檢查、編號唯一性檢查、以及「不要用驚嘆號要用腳本」那條，都是從這些反面教訓來的。

三、把它套到五個真實專案上，並且量測。 那個 43 次執行、36/37 的數字，是這一步的產物。

所以誠實的說法是：框架是別人的，我加的是建置順序、幾道從踩坑長出來的護欄、以及一份實測紀錄。

（我原本沒有寫這一段。是後來有人提醒我，我才回頭去翻那份 Playbook 的開頭。它自己第一行就標明了來源，而我在寫這個系列的時候沒有把它抄過來。 這是我第三次在引用歸屬上出錯，前兩次在後面會講。）

這個案子

我拿來當範例的，是我們自己公司的薪資系統。

它不是給客戶的交付物，是我們自己在用的東西。每個月算二十幾位同事的薪水、產薪資單、出銀行轉帳檔、寄加密的薪資明細。算錯就是真的算錯。 沒有客戶會幫你抓，只有同事會來問「我這個月怎麼少了三千」。我選它來當「規格驅動工廠」的試點，有三個理由：

一、重複性極高。 勞保、健保、勞退、勞退自提、獎金補充保費、請假扣款⋯⋯每一條薪資規則的形狀都一樣：吃幾個輸入、查一張級距表、算出一個數字、加進薪資單。十幾條規則，長得像同一件事的十幾個變體。

值不值得建一座工廠，判準是重複性。這個案子重複性滿分。

二、對錯是確定的。 勞保費就是那個數字，不是「看起來合理」。可以手算驗證、可以跟法規對、可以跟去年的實際扣款比。

三、風險自負。 出事的是我自己的薪水，不是客戶的系統。這是我認為最重要的一點。你要驗證一套新方法，該拿自己的東西試，不該拿客戶的專案當白老鼠。（這件事後來我覺得應該寫進顧問的職業倫理：新方法先在自己身上跑過，才拿去客戶那裡。）

先講結果

跳過過程，先看數字。這是實際的執行紀錄：

執行次數        43 次（橫跨約兩個半月）
一次通過率      36 / 37
平均耗時        10.9 分鐘 / 個規格
人工修正量      42 / 43 次是 0
測試成長        101 → 350 條全綠
架構決策紀錄    30 份

「一次通過」的定義是他們自己訂的，寫在指標檔開頭：

步驟 4（結構檢查 + 測試）與步驟 5（規格覆蓋率）首輪即綠，且審查無 Critical / Must。

不是「最後有跑通」，是「第一次跑就全綠，沒有人插手」。

而那唯一失敗的一次，紀錄長這樣：

批次替換漏了 1 處編譯錯誤，1 輪修復後 103 條測試全綠

連失敗的細節都記了。

跟 Day 08 那個案子的對照

現在把兩個案子放在一起。這是同一群人、差不多的時期：

這個對照不需要任何虛構化就成立，因為它是同一組人在不同時間點的兩種做法。

而差別的核心，用 Part 1 的語言講就是：

一個案子的規範停在第 0 層，
另一個案子從第一天就把規範推到第 3 層。

建廠的順序

那到底做了什麼？我把流程分成五個階段，而且順序不可以換：

而最重要的一條規定是：

Phase 3（驗證）必須在 Phase 4（自動化）之前完成。

這不是建議，是硬性的。因為如果先把流程自動化、再回頭補驗證，中間那段時間你在做的事情是：

用一條沒有品管的產線，高速產出東西。

自動化的本質是放大器。它放大好的產出，也放大爛的產出。而且因為量大，爛的更難被發現。這也解釋了為什麼那個 36/37 是有意義的：它是在驗證閉環已經建好的前提下量出來的。 如果沒有 L1、L2、覆蓋率檢查，「一次通過」這個詞根本沒有定義。

一個容易被跳過的問題

Phase 0 的結論有可能是「不要建」。

我把三個前提寫成硬性的入場條件：

第二條要特別強調「實際跑一次」。因為「我們有測試」跟「測試現在跑得起來」是兩件事，中間常常隔著三個環境變數和一個過期的相依套件。

我後來在別的案子看過一份指標檔，誠實到讓我印象深刻。它記錄了一次執行的覆蓋率是 100%，然後在旁邊註明：

⚠️ 測試未跑：本機環境跑不起來，mvn test 連編譯都過不了。
這個 100% 是「有測試檔且含對應斷言」的意義，尚未經測試實際通過證實。
CI 跑綠之後才是真的 100%。

他有一個 100%，然後自己在旁邊註明它是假的。

這種紀律比任何方法論都值錢。

接下來的方向

這一段會照建廠的順序走：黃金範例 → 規格格式 → 驗證腳本 → 量測與擴張。中間會穿插幾個我認為最值得單獨講的設計。包括一支我原本以為最難寫、後來發現最有價值的腳本，以及一個只有一行、但防住了整類漂移的閘門。明天先講投報率最高的那一步。如果這一段你只做一件事，我建議是那件。