前言：為什麼要花 30 天講「怎麼跟 AI 協作」這件事本身

決定寫這個系列時，其實猶豫過。市面上不缺「AI 工具怎麼用」的分享，但大多數停在功能介紹的層次——這支工具能做什麼、那個設定怎麼開。這對第一次接觸的人或許夠用，但沒有回答一個更根本的問題：當你已經在用 AI agent 處理日常工作一段時間之後，那些反覆出現的規則文件、記憶檔案、委派給多個 agent 平行工作的習慣，到底該怎麼設計，才不會自己先亂成一團。

這個念頭在寫這個鐵人賽系列的過程裡變得非常具體——因為這 30 天的寫作過程本身，就是一次活生生的示範：CLAUDE.md 從幾行規則長成一份分層的規範，一支去識別化掃描 skill 從一次人工漏抓的教訓誕生，好幾次同時派出的 agent 互相寫壞對方的檔案、逾越了原本只指派給它們的範圍。與其把這些經驗留在對話紀錄裡自生自滅，不如藉這個系列把它們收斂成一套可以分享、也可以被檢驗的紀律。

第一部回顧：為什麼「怎麼跟 AI 協作」本身值得被設計

第一部（Day 1-7）從「CLAUDE.md 不就是寫一份文件嗎，有什麼好設計的」這個疑問出發，一路拆解 CLAUDE.md 該放什麼、Skill 的本質是什麼、Reference 型跟 Task 型 skill 怎麼選、skill 的「定位」段落為什麼比規則本身重要。這幾天想釐清的核心是一件容易被忽略的事：規則文件、skill、記憶系統，表面上是「寫給 AI 看的說明」，本質上是一套需要被設計的系統——跟軟體開發裡「把所有邏輯塞進同一支函式」是同一種失誤，只是換了一個載體。

現在回頭看，這一部最重要的不是任何一條具體規則，而是建立了「工具要分層、要有邊界」這個貫穿全系列的視角。後面 23 天不管講的是記憶系統、多 agent 協作還是事實查核，骨子裡都是同一個判斷在不同情境下的變形。

第二部回顧：記憶系統怎麼設計

第二部（Day 8-16）走得最細，從持久記憶系統的四種類型（user/feedback/project/reference），講到 feedback 記憶要記「為什麼」而不是只記「不喜歡什麼」、記憶會過期怎麼設計「引用前先驗證」的紀律，一路到 CLAUDE.md／Skill／Memory 三層分工怎麼不互相打架、以及某類規則怎麼從「人工複查總是漏」寫成自動化檢查工具。這幾天累積的案例，想傳達的是同一件事的不同樣貌：記憶系統如果沒有分類、沒有時效性標注，會退化成一堆混在一起、沒人知道哪些還有效的筆記——這跟第一部講的「規則文件沒有分層會失控」是同一個根本問題，只是這次換成了「時間」這個維度。

三層分工模型是這一部最值得記住的一件事：CLAUDE.md 回答「現在的規矩是什麼」，Skill 回答「這個情境該怎麼做」，Memory 回答「過去發生過什麼、為什麼、還適不適用」。分不清楚這三層職責，最常見的下場就是同一條規則被寫進兩個地方，之後只改了其中一份。

第三部回顧：多 Agent 協作的坑

第三部（Day 17-23）從「為什麼要委派給獨立 agent、不只是分工這麼簡單」開始，講到一個 agent 逾越指派範圍自己動手做了別人的工作、兩個 agent 同時寫同一個檔案事後怎麼比對取捨、為什麼要限制 agent「只讀不寫」、一個違反只讀不寫指示但改的內容剛好是對的案例、委派範圍限制的具體 prompt 寫法，最後收在發現真的有其他並行工作階段在同一個專案裡工作這件事。這一部是全系列踩坑密度最高的一段，因為多 agent 協作把前兩部講的「工具需要邊界」這件事，從「文件層面的邊界」升級成「行為層面的邊界」——一份寫得再清楚的規則文件，如果沒有具體的範圍限制去堵住 agent 逾越管道的每一個可能路徑，還是會在實際委派時失控。

這一部讓我更確定一件事：委派的紀律不能只講一個抽象原則就結束，要具體到「只寫這一個檔案」「不要委派子任務」「完成後立刻結束回報」這種明確到不能再誤解的措辭——這些措辭不是憑空想出來的，是從真的發生過的逾越案例反推出來的。

第四部回顧：實戰總結

第四部（Day 24-30）用幾個具體案例，把前面 23 天的原則放回真實情境裡檢驗：事實查核抓到的真實錯誤有哪些型態（歸屬錯誤、跨篇引用錯誤、方向相反的錯誤、失真但不算捏造的錯誤）、技術主張的歸屬錯誤連 AI 自己都會張冠李戴、CLAUDE.md 規則怎麼被一次次糾正逐漸長成現在的樣子、AI 協作的授權邊界哪些決定不該讓 AI 自己拍板、這套雜記的寫作方式本身也要去識別化、以及這整套方法論解決不了什麼問題。這幾篇合起來想證明一件事：這一路講的原則不是憑空想像出來的方法論，是從真實犯過的錯裡一條一條長出來的，而且這個「提煉」的過程本身，也適用系列反覆講的同一套紀律——查核跟修正要分開、判斷空間大的地方要留給人決定。

一個誠實的失敗經驗

寫到這裡，如果只講「照著這套紀律做就萬事順利」，那就違背了系列一直在強調的立場——任何結論都該誠實標注它的邊界，這句話對我自己寫的東西也一樣適用。

我自己也不是一開始就把委派範圍限制寫對。第一批派出去的委派指令，只講了「請處理這一天的內容」這種籠統的範圍描述，沒有明講「只寫這一個檔案」「不要委派子任務」。結果就是好幾次收到回報時，才發現被指派的 agent 因為工具限制或自己的判斷，擴大範圍去做了根本沒被要求的事，跟其他被正常指派處理相鄰任務的 agent 互相覆蓋了對方的產出。

事後回頭看，這個教訓很直接：一句「請處理這件事」聽起來已經夠清楚了，但清楚的程度要用「這句話能不能被誤解成更大的範圍」來檢驗,不是靠寫的人自己覺得夠不夠明確。 我後來把委派指令改成明確列出「只寫這一個檔案，檔名照指定路徑」「不要委派其他 agent」「完成後立刻結束回報」這幾條具體限制之後，同類問題才明顯減少——但不是完全消失，中間還是有幾次意外，這也讓我更相信，這套紀律是一直在修正、不是一次到位的東西。

回到系列主題句

系列一開始立下的主題句是：AI 開發工具本身（skill、CLAUDE.md、memory、多 agent 協作）也需要被當成軟體來設計——沒有清楚的分工跟驗證機制，這些工具會用最省事的方式退化成一堆互相矛盾、逾越範圍的雜訊。

30 天寫完，我更確定這句話，但也更確定它背後真正的意涵不是「AI 協作工具很難搞」，而是這些工具跟你平常寫的軟體遵守同一套設計原則：職責要分清楚、狀態要有時效性、行為要有邊界、產出要能被驗證。CLAUDE.md 太長會失控，跟一支函式塞太多邏輯會失控，是同一個道理；agent 逾越範圍，跟一個服務沒有明確權限邊界會越權操作，也是同一個道理。理解這件事之後，判斷「這裡該怎麼設計」就不再需要每次從零想起，可以直接套用你已經很熟悉的軟體設計直覺。

給讀者的實用建議

如果你也想把這套紀律套進自己跟 AI 協作的流程，幾個立即可行的第一步：

• 先問一句「這份規則文件，現在有多長、有沒有互相矛盾的規則」——這是整個系列成本最低、效益最高的單一檢查，不需要任何工具，找個時間通讀一次就知道答案。
• 下次委派任務給獨立 agent 時，把「請處理這件事」換成具體到不能再誤解的範圍描述：只寫哪個檔案、不要做哪些事、完成後怎麼回報，寧可寫得囉唆一點，也不要留模糊空間。
• 記憶不要記「不喜歡什麼」，記「原始判斷邏輯、否決理由、適用邊界」：這個練習比想像中更快能訓練出判斷力，也是整套記憶系統裡投資報酬率最高的一個習慣。

漸進式的技能發展路徑：先從「CLAUDE.md 該放什麼」這個最基礎的分界練起；等規則文件穩定了，再往記憶系統的分類跟時效性推進；最後才是多 agent 協作的範圍限制，這個層次的坑通常要親自踩過幾次才會真正記住,不用急著一次到位。

結語

回到 Day 01 那個疑問：CLAUDE.md、Skill、記憶系統，講白了不就是幾份給 AI 讀的說明文件嗎，有什麼好設計的？寫完這 30 天，我的答案沒有變得更複雜，但變得更具體了——它們值得被設計，正是因為它們會被反覆讀、反覆套用、反覆委派出去執行，而任何會被反覆使用的東西，一旦沒有清楚的分工跟驗證機制，都會用最省事的方式退化成雜訊,不管那個東西是一份規則文件、一套記憶系統，還是一個 AI agent。

這套紀律還在持續演化，我自己也還在修正委派指令的措辭、還在調整記憶系統的分類方式。如果你在自己的專案裡也踩過類似的坑，或是找到了更好的做法，很樂意聽聽你的版本長什麼樣。謝謝你陪我走完這 30 天。