如果 AI 能在幾分鐘內寫完原本需要半天的功能，為什麼不少團隊反而更不敢修改自己的系統？

問題通常不在生成速度，而在決策速度超過驗證速度。需求還沒對齊，AI 已經選好資料結構；測試邊界還沒決定，它已經替實作補上一組會通過的斷言；模組責任還沒釐清，程式碼已散落到更多檔案。產出變快了，但人類理解、驗證與修正的能力沒有同步增加。

Matt Pocock 的 Skills for Real Engineers 提供了一個值得研究的答案：不要期待一個更長、更神奇的 prompt 一次解決所有問題，而是把需求對齊、規格、任務拆解、測試、審查與架構改善，做成可單獨組合的工程技能。

本文的核心論點是：

AI 協作的品質，不取決於人類是否把每個微觀決策都親手做完，而取決於團隊是否建立了可追溯的決策邊界與足夠短的回饋迴圈。

這不是「把決策權從 AI 手中全部搶回來」那麼簡單。真正需要掌握的，是哪些決策必須由人類確認、哪些事實能從程式庫直接查出，以及什麼證據足以讓工作進入下一階段。

先釐清：這不是一條不能跳步的生產線

Pocock 在專案首頁直接批評了另一種做法：用大型流程接管整段開發，雖然看似完整，卻會讓使用者失去控制，也讓流程本身的錯誤難以修正。他提出的替代方案是小型、可調整、可組合的 skills。

這個差異很重要。

重型流程把品質寄託在「每次都走完所有步驟」；模組化技能則把品質寄託在「眼前的風險由正確的回饋機制處理」。修正文案不需要完整架構審查；跨模組資料遷移也不能只靠一輪需求訪談。流程應該跟著風險改變，而不是反過來讓工作配合儀式。

因此，以下六個階段比較適合被理解成一組工具箱，而不是不可違反的關卡。

第一階段：用 /grill-me 暴露尚未做出的決策

AI agent 常見的失敗，不是完全聽不懂需求，而是在模糊處自行補完。一句「幫我做登入」背後至少還有帳號來源、失敗狀態、session 期限、登出範圍與既有資料相容性等決策。若沒有明確停損點，agent 會選一條能繼續產生程式碼的路。

目前的 /grill-me 是一個很薄的入口：它要求執行 /grilling session。真正的訪談規則由共用技能負責，包括逐一追問決策樹、一次處理一個問題、附上建議答案，以及能從 codebase 查到的問題就直接查證。

這套設計改變的不是問句格式，而是責任分配：

問題類型	處理方式
可從程式庫確認的現況	Agent 查證，不把查資料變成人類問答題
產品取捨與可接受風險	Agent 提供選項，人類拍板
尚未看清的連鎖影響	Agent 沿決策依賴繼續追問
需要畫面或可執行行為才能判斷	先做低成本 prototype，再回來決策

這也指出「達成 100% 共識前不准動工」的限制。對低擬真度的決策，例如 URL、權限規則或資料保留政策，訪談很有效；對互動手感、複雜狀態機或未知技術限制，只靠文字追問會產生假共識。此時 prototype 不是違規，而是提高決策所需的證據品質。

第二階段：讓規格保存決策，不要假裝保存整個實作

對話中的共識會消失，程式碼中的理由也不一定能被未來的維護者還原。規格的任務，是把「為何這樣做、外部行為是什麼、哪些事情不做」留下來。

現行 /to-spec 會從既有對話與 codebase 理解合成規格，內容包括：

• 使用者面對的問題與解法；
• 完整的 user stories；
• 模組、介面、schema、API contract 等實作決策；
• 測試 seam 與驗證方式；
• 明確的 out of scope。

它確實要求不要放入特定檔案路徑或程式碼片段，理由是這些細節很快會過時。但它也保留一個合理例外：若 prototype 產生的 state machine、schema 或 type shape 比文字更能精確保存決策，可以留下經過修剪的片段。

所以「規格嚴禁任何程式碼」太絕對。更準確的原則是：

規格不應複製可由 repository 取得的實作；只有能保存決策、且比文字更精確的最小表示，才值得進入規格。

這種區分能避免兩種極端：一種是把規格寫成第二份會過期的 source code，另一種是只寫產品願景，完全沒有 API contract、測試邊界與失敗條件。

從訪談走向共同語言

/grill-with-docs 把 /grilling 與 domain modeling 組合起來，過程中同步整理 glossary 與 Architecture Decision Records（ADR）。

價值不只是「讓 AI 記得更多」，而是建立團隊可重複使用的壓縮語言。當「materialization cascade」已經在專案詞彙表中有精確定義，未來的人類與 agent 就不必每次用一整段話重新描述同一個現象。命名一致也會反過來改善函式、檔案與測試的可導航性。

第三階段：/to-tickets 不是把工作切碎，而是切出可驗證閉環

按資料庫、API、UI 分工的水平切片很容易排程，卻把風險推到最後：資料庫完成時，還不知道使用者流程是否走得通；UI 完成時，才第一次驗證整合。

現行工具名稱是 /to-tickets，不是「2tickets」。它要求把工作拆成 tracer-bullet vertical slices：每個 ticket 都穿過完成該能力所需的 schema、API、UI 與 tests，而且完成後能獨立展示或驗證。

水平切片	垂直切片
建完所有 schema	完成一條最窄、可用的使用者流程
建完所有 API	只建該流程真正需要的 contract
最後才串 UI 與測試	每個 slice 都帶著驗證方式
整合風險延後出現	風險隨第一條路徑提早暴露

好的 ticket 不是「越小越好」。若把「建立按鈕」、「新增 endpoint」、「補測試」分成三張票，依舊只是把水平切片包裝成更細的待辦事項。完成標準必須是可觀察行為，而不是完成某一技術層。

平行開發不是免費加速

垂直切片能讓無阻塞關係的 tickets 同時開始，/to-tickets 也要求每張票標出 blocking edges。但「可以平行」不等於「速度呈指數成長」。

**這是分析：**當兩個 slices 共用 schema、權限模型、design system 或部署管線時，平行工作會增加合併、同步與返工成本。只有介面先穩定、ownership 清楚、驗證環境彼此隔離時，平行 agent 才真正縮短交付時間。否則只是把等待時間換成整合衝突。

第四階段：TDD 的作用是建立外部真相，不是把 agent 分成兩個人

「AI 會作弊」是一個好記的比喻，但不是可驗證的心理描述。更精確地說，語言模型會沿著當前上下文尋找容易滿足目標的輸出；如果測試與實作共享同一套錯誤假設，兩者可以一致通過，卻仍然違反需求。

/tdd 的防線有三層：

1. 先確認要測試的 public seam；
2. 測試外部行為，不綁定內部實作；
3. 以「一個失敗測試 → 最小實作 → 重構」循環前進。

其中「紅燈」不只是儀式。它證明新測試在功能不存在或行為錯誤時確實會失敗，避免永遠為真的 assertion、沒有執行到的 test case，或只驗證 mock 呼叫的假安全感。

但素材中「嚴禁讓 AI 同時生成功能與測試」也過度延伸。現行 skill 明確反對一次寫完所有測試、再一次寫完所有實作；它要求的是垂直的短循環，而不是一定要由不同 agent 或不同 session 分工。真正需要獨立的是預期值的來源：它應來自規格、已知範例或外部 contract，不能只是用同一段演算法重新計算一次答案。

TDD 也不是唯一防線。型別檢查、lint、真實瀏覽器、integration test、production telemetry 與人工驗收，各自捕捉不同錯誤。把所有品質責任交給 unit tests，只是換一種形式的黑盒。

第五階段：Code review 必須同時回答「寫得對不對」與「做的是不是對的」

不少 review 只檢查命名、重複程式碼與效能，最後得到一份漂亮但無法回答需求是否完成的報告。另一種 review 只對照 ticket，卻忽略程式碼正在製造新的維護成本。

現行 /code-review 把審查拆成兩條軸線：

• Standards：是否符合 repository 規範與 code-smell baseline；
• Spec：是否忠實實現原始 issue、PRD 或 spec。

兩條軸線分開取得上下文，再把結果並列，目的是降低彼此污染。這比籠統要求「幫我仔細 review」更可稽核：每個 finding 都必須說明它違反哪個標準，或偏離哪一條規格。

Shotgun Surgery、Feature Envy、Data Clumps 等術語可以作為高壓縮的搜尋提示，但不能當成自動判決。Skill 本身也把 smell 定位為 heuristic：repository 已明文接受的設計優先，而且每個 smell 都需要依變更情境判斷。

另外，「一定要開全新 session 才客觀」也不是充分條件。新 session 能減少實作者對自己方案的辯護傾向，卻也可能丟失關鍵歷史。更穩健的做法是替 reviewer 提供固定 diff、明確 spec 與 repository standards，讓它少讀開發過程的辯解，多讀可驗證的輸入。

第六階段：深模組不是檔案越少，而是介面替呼叫者承擔了多少複雜度

John Ousterhout 將好的模組描述為：以簡單介面提供大量功能。Pocock 的 codebase-design 與 /improve-codebase-architecture 把這套語彙帶進 agent 工作流，目標是提高 testability 與 AI navigability。

可以用一個比率理解模組深度：

模組深度 ≈ 被隱藏的行為與決策複雜度 ÷ 呼叫者必須理解的介面複雜度

processCheckout() 並不會因為只有一個函式名稱就自動成為深模組。若呼叫者仍要先決定折扣順序、庫存鎖定、付款重試與補償交易，再把十幾個旗標傳進去，它只是一扇寫著「大門」的薄牆。

反過來說，把折扣、庫存、付款與通知放在不同檔案，也不必然是淺模組。只要它們被一個穩定 seam 協調，內部責任清楚，呼叫者不必知道流程細節，檔案數量就不是問題。

刪除測試真正測的是什麼？

架構 skill 使用 deletion test 檢查可疑模組：想像移除它之後，複雜度是被集中暴露，還是只被搬到隔壁。

• 若刪除後，原本被封裝的政策、錯誤處理與狀態轉換全部洩漏給 caller，這個模組確實隱藏了複雜度。
• 若刪除後只少一次轉呼叫與一次檔案跳轉，原模組沒有提供足夠 leverage。

這仍是設計推理，不是可以單靠 dependency graph 自動證明的真理。視覺化 HTML 報告能幫助人類找到熱點，無法替人類決定 domain seam 是否正確。

把六個技能串成可執行的 AI 協作 SOP

真正有價值的不是記住六個 slash commands，而是替每次狀態轉換設定證據門檻。

階段	主要產物	進入下一階段前的證據
需求對齊	決策與未決問題	產品取捨已由人類確認；repo 現況已查證
規格	問題、行為、contract、out of scope	每項驗收可被觀察；關鍵 seam 已確認
Tickets	垂直 slices 與 blocking edges	每張票可獨立展示或驗證
TDD 實作	小步 red-green-refactor	紅燈曾出現；綠燈來自最小行為變更
Code review	Standards 與 Spec findings	高風險問題已處理或被明確接受
架構保養	Deepening candidates	重構對應真實 hot spot，而非抽象潔癖

這套流程還需要兩個常被忽略的守門條件。

第一，可追溯性。Ticket 應能回到 spec，測試應能回到可觀察行為，review finding 應能回到 diff 與標準。沒有這條鏈，團隊只是在累積更多 AI 產生的文件。

第二，停止規則。訪談不是問到沒有問題，而是問到剩餘不確定性已低於動工門檻；重構不是做到完美，而是改善當前 hot spot，並以測試證明外部行為沒有改變。沒有完成標準，再模組化的 skills 也會變成儀式性負擔。

哪些團隊適合採用？哪些不適合？

這套方法最適合已經有 repository 規範、issue tracker、可執行測試與 code review 習慣的團隊。Skills 能把既有工程判斷變成 agent 可重複遵循的路徑。

若團隊沒有產品決策者、沒有可觀察的驗收條件，也沒有人願意處理 agent 提出的衝突，再多訪談只會製造文件；若系統沒有可靠的執行環境，TDD skill 也無法憑空建立回饋。

對探索性 prototype 而言，完整 SOP 更可能拖慢學習。此時應先用 disposable prototype 回答一個高不確定性問題，得到證據後，再決定哪些部分值得規格化與生產化。

結論：人類要掌握的不是每一行程式碼，而是證據門檻

回到開頭的矛盾：AI 讓程式碼產出變快，卻可能讓軟體更難改。真正的原因不是 AI 天生只能寫出壞架構，也不是人類必須重新手工控制每一行程式碼，而是產出速度超過了團隊建立共識、驗證行為與修正結構的速度。

/grill-me 延後未經確認的決策，/to-spec 保存可追溯的共識，/to-tickets 把風險切成可驗證閉環，/tdd 縮短行為回饋，/code-review 分離規格與品質判斷，architecture skills 則定期償還結構熵。

這些 skills 不是「馴服黑盒子」的魔法。它們比較像一組工程護欄：不保證車永遠不會出事，但能讓偏離更早被看見，讓每次繼續前進都有證據。

AI 時代真正稀缺的能力，也因此不是把 prompt 寫得更有氣勢，而是知道：現在缺的是哪一個決策、哪一種回饋，以及什麼證據足以讓團隊安全地往下一步走。

---

參考資料與查證邊界

• Matt Pocock：Skills for Real Engineers
• /grill-me 原始 skill
• /to-spec 原始 skill
• /to-tickets 原始 skill
• /tdd 原始 skill
• /code-review 原始 skill
• /improve-codebase-architecture 原始 skill
• 使用者提供的影片素材

本文以 2026 年 7 月 24 日讀取到的原始 repository 內容為準。影片頁面未能在本次工作環境中獨立擷取，因此沒有採用筆記中無法由原始 repository 交叉驗證的下載量、固定行數與效率成長數字。文中標示「這是分析」的段落，是根據上述機制做出的工程判斷，不是專案作者的原話。