Part 2 最後一天。講一個看起來很小、但決定工廠會不會垮掉的判斷：

什麼時候可以擴張到第二種任務類型？

那條規定

薪資工廠的指標檔，第二行就寫著這句：

一次通過率穩定 > 80% 後，才擴張第二種任務類型（基礎設施全部共用）。

而擴張準則那一節寫得更死：

試點的一次通過率穩定 > 80%（建議連續 ≥5 次）後，才擴張。
未達標就擴張 = 規格格式發散、範例品質撐不住。

注意「穩定」和「連續 ≥5 次」。不是某一次剛好，是一段時間都是。

為什麼要等

因為如果第一條產線的通過率只有 50%，那代表你的規格格式、範例、或驗證有結構性的問題。這時候擴張，只是把同一個問題複製到第二個地方。然後你要在兩個地方同時修。

而更糟的是，第二條產線的問題會被歸因錯：你會以為是「第二種任務比較難」，而不是「地基本來就有洞」。

不等會發生什麼

我把「一開始就想涵蓋全專案」列為工廠的三大死法之一，因為它的破壞方式很隱蔽。假設你一開始就選了五種任務類型：查詢 API、表單頁面、報表、批次、整合介面。

第一件會發生的事：規格格式發散。

五種任務的形狀完全不同。要讓同一個格式裝下全部，就得：

• 把欄位改成選填
• 把約束放寬
• 加上一堆「視情況而定」的說明

最後那個格式退化成一個有結構的自由文字。它有 JSON 的外表，但實質上什麼都不強制。

而 Day 23 講過那條「後置條件與錯誤情境至少各一條」的規則一旦鬆掉，規格覆蓋率就算不出來了。地基就這樣沒了。

第二件會發生的事：黃金範例撐不住。

五種任務要準備十個範例（每種兩個），每一個都要「修到完美」。實際會發生的是：前兩個修得很仔細，第三個開始敷衍，到第十個直接複製既有檔案就上了。

而 Day 21 講過：範例品質是產出品質的上限。 十個範例裡有八個是敷衍的，那八條產線的天花板就在那裡。

先窄後寬在數學上是划算的

我知道「只做一種」很反直覺，尤其當你剛把工廠建起來、正興奮的時候。

但擴張的成本結構是這樣的：

第一條產線很貴，因為它要付掉：

• 知識庫的目錄骨架
• 編碼規範
• 三支驗證腳本
• hook 設定
• 審查清單的骨架
• 規格 schema 的核心欄位

第二條產線只要付：

• 規格格式的一個分支
• 兩個新的黃金範例
• 一個新的執行流程

基礎設施全部共用。

所以第二條的成本大概是第一條的三分之一。而如果你一開始就做五條，你付的是五條的錢，卻沒有任何一條的品質是達標的。

先窄後寬划算的前提是：第一條真的做紮實了。

那個工廠實際怎麼擴張的

看紀錄可以看到擴張的痕跡。試點是「薪資計算規則」，後來陸續出現：

use-case 首例          ← 第二種：業務流程
首個 I/O adapter       ← 第三種：外部介接
新 spec 模組 cli/      ← 第四種：命令列介面

而且擴張的方式很保守。每次只多一種，而且都是在前一種已經穩定之後。

另外一個案子的紀錄裡也看得到同樣的模式，他們的迭代日誌寫著：

Spec 工廠擴張第 4 種任務類型（補某項需求）
補該類型的黃金範例（完成前一條的後續）
Spec 工廠擴張第 5 種任務類型

注意中間那一條。 擴張了第 4 種之後，下一個動作不是擴張第 5 種，是回頭補第 4 種的黃金範例。

補完了才擴張第 5 種。

這個節奏我覺得很值得學：擴張 → 補範例 → 確認穩定 → 再擴張。 不是一路往前衝。

擴張的時候什麼該共用，什麼不該

這裡有一個容易做錯的地方。

該共用的：

不該共用的：

最容易做錯的是第一項。「反正都是範例，放在一起」。然後 AI 讀了兩個不同類型的範例，產出一個混合體。

範例要分目錄放，而且流程要明確指定「這次讀哪一個」。

一個誠實的補充

要說清楚：**那個 36/37 是「一種任務類型」的數字。**擴張之後的通過率，紀錄裡沒有分開統計。所以我不能說「這套方法在五種任務上都是 97%」。我只能說「試點那種任務是」。這也是 Day 25 講的限制之一。分開統計每種任務類型的通過率，是我認為那份指標檔可以再改進的地方。

Part 2 小結

七天下來，工廠的樣子大概是這樣：

Phase 0  體檢     → 三個前提，結論可能是「不要建」
Phase 1  範例     → 兩個修到完美的範例 + 從範例反推的規範
Phase 2  規格     → 描述可驗證的行為 + schema 強制
Phase 3  驗證     → 三支腳本 + 勾稽閘門
Phase 4  自動化   → 一鍵執行 + 量測

而貫穿其中的原則，用 Part 1 的語言講就是：

每一條規範，都在建廠當下就被推到第 3 層。

Day 08 那個案子的規範停在第 0 層，事後才寫改善計畫。這個案子的規範一開始就是腳本、是 schema、是 hook。

同一組人、同樣的技術能力，差別只在規則落在哪一層。

明天開始 Part 3。前面講的都是「怎麼建」，接下來要講一個更難的問題：

建好之後，怎麼讓它持續變好？

那一段的素材是另一個案子。它有一份日誌，記錄了每一次調整規則的動作，而且要求七天內回填「這個調整到底有沒有效」。