前言：把工具做好了，是不是就萬無一失？

「講了 28 天怎麼設計 skill、怎麼分層 CLAUDE.md、怎麼管理記憶、怎麼委派 agent——把這些都做對，AI 協作是不是就不會出錯了？」

如果讀到這裡有這種期待,那正好違反了這系列從 Day 01 就立下的主題句:AI 開發工具本身也需要被當成軟體來設計——沒有清楚的分工跟驗證機制，這些工具會用最省事的方式退化成一堆互相矛盾、逾越範圍的雜訊。 這句話講的是「工具設計得好，出錯的機率會降低」，不是「工具設計得好，就不會出錯」。今天要誠實面對後半句——這套方法論解決不了什麼。

今日目標

• 認識三類這套方法論明確解決不了的問題
• 理解「降低出錯機率」跟「消除決定的後果」是兩個不同層次
• 看清楚「工具設計得再好」也不能取代人親自審過內容的責任
• 建立一套判斷「這件事該不該靠工具解決」的分界

第一類：工具管不到「這件事本身該不該做」

Skill、CLAUDE.md、Memory 三層分工（Day 13 講過）能確保 AI 記得規矩、能按需載入正確的細節、能引用還沒過期的資訊——但這一切的前提是「這件事本身是該做的」。如果一開始的任務方向就錯了（例如要解決的其實不是真正的問題，或者這個時間點根本不該動這段程式碼），再完美的委派流程、再嚴謹的查核機制，也只會把一個錯誤的方向執行得又快又乾淨。

工具能保證「照著規矩做」，不能保證「這個規矩該不該用在這裡」。 這個判斷需要對當下的情境有理解，理解沒辦法寫成一條放進 CLAUDE.md 就能自動套用的規則。

第二類：工具管不到團隊裡人跟人之間沒對齊的目標

多 agent 協作的坑（第三部講的那些逾越範圍、重複檔案、只讀不寫）都是「執行層面」的問題——只要委派的 prompt 寫得夠精確、範圍限制夠具體，這類問題可以大幅降低。但如果一開始委派任務的人，跟審核產出的人，對「這個任務到底要達成什麼」有不同的理解，再精確的執行也只會讓這個落差被放大：agent 完美地執行了一個雙方理解不一致的指令，產出看起來合規，卻不是任何一方真正想要的東西。

用一組對照來看這個差異：

❌ 只靠工具流程解決分歧：
「委派範圍寫得很精確，agent 也完全照做了，
 但產出出來雙方才發現彼此對『這個任務要做到什麼程度』
 的理解完全不一樣，得整個重來。」
→ 執行完美不代表理解一致，工具流程管不到
  委派前雙方腦中的畫面對不對得上

✅ 先確認理解一致，再靠工具流程精確執行：
「委派前先用一兩句話互相確認『我理解的任務範圍是這樣』，
 對上了才開始寫精確的委派 prompt。」
→ 工具流程負責讓「已經對齊的理解」被精確執行，
  不負責幫你確認理解本身對不對齊

第三類：工具不能取代人親自審過內容的責任

這系列反覆講「客觀錯誤直接修正，判斷空間大的跟使用者討論」這條分工——但這條規則本身依賴一個前提：有人真的讀過查核結果、真的判斷過哪些屬於客觀錯誤、哪些屬於需要討論的判斷空間。如果協調者把這個判斷也外包出去（例如看到查核 agent 說「已修正」就直接信任，不核對修正內容對不對），那整套「查核跟修正分開」的設計就變成一個形式上的步驟，沒有實質的把關效果。

工具能降低出錯的機率，不能替使用者承擔決定的後果。 一份查核清單、一支自動化 script、一套委派範圍限制的寫法，做的都是「讓正確的事更容易發生、讓錯誤更容易被抓到」，但最終「這個內容能不能發布」「這個修正該不該接受」的責任，還是落在按下確認鍵的那個人身上，不會因為工具設計得好就轉移出去。

這三類問題的共同點

這三類工具解決不了的問題，共同點是它們都不是「執行層面」的問題，是「判斷層面」的問題。 工具設計（skill、CLAUDE.md、memory、委派範圍限制）處理的是「怎麼讓已經確定要做的事，被正確、一致、可驗證地執行」；但「要不要做這件事」「雙方理解對不對齊」「這個結果能不能接受」這三種判斷，工具只能提供輔助資訊，不能替代判斷本身。

今日思考題

回想你設計過的某個 AI 協作流程：那個流程解決的是「執行得對不對」的問題，還是「方向對不對」的問題？如果你發現流程設計得再好，某次還是出了問題,那個問題屬於今天講的哪一類？

今日重點回顧

• 第一類邊界：工具管不到「這件事本身該不該做」，這需要對情境的理解，理解沒辦法寫成規則自動套用
• 第二類邊界：工具管不到人跟人之間對任務理解沒對齊，執行完美不代表理解一致
• 第三類邊界：工具不能取代人親自審過內容的責任，最終決定的後果不會因為工具好就轉移出去
• 這三類問題的共同點：都是「判斷層面」而非「執行層面」的問題，工具只能輔助判斷，不能取代判斷

明日預告

明天是這個系列最後一篇：如果重來一次，這整套 AI 開發工作流會怎麼被重新設計——30 天的總結與回顧。