「AI 又做了一件很奇怪的事，我要不要把這條規則寫進 CLAUDE.md，以後就不會再發生了？」
這個反射動作很自然——這個系列從 Day 16 開始，一直在講怎麼把踩坑經驗收斂成規則、寫進記憶、提煉成 skill。但這裡有一個容易被忽略的分岔：有些問題是「這個專案的規則沒講清楚」，有些問題是「AI coding agent 這個工具本身的行為有毛病」。前者該寫進專案的規則系統，後者寫進去也沒用——因為下一個專案、下一個 agent 版本，同樣的問題還是會發生，因為根本原因不在專案裡，而在工具本身。今天是第三部（AI Agent 的長期記憶與團隊協作）的最後一篇，來講怎麼分辨這兩者，以及怎麼把後者回報得有用。
判斷標準其實不複雜：如果這個問題只在「這個專案的規矩」被違反時才會發生，換一個沒有這條規矩的專案就不成問題，那它屬於專案規則，該寫進 CLAUDE.md 或 skill。如果這個問題不管在哪個專案、換誰跟 agent 互動都會發生，那它是工具本身的行為問題，寫進專案規則治標不治本。
舉例來說，「這個專案的資料庫存取一律要經過 Repository」是專案規則——別的專案可能根本沒有 Repository 這一層，這條規則對它們毫無意義。但如果 AI agent 有一種傾向，是「查證一件事時只確認了最容易查到的那個角落，就用很有自信的語氣回報『已確認』」——這種傾向不是任何一個專案的規則能解決的，它是 agent 本身推理習慣的問題，換到任何專案都可能重演。前面 22 天講的大部分內容，其實都是在幫這第二類問題「打補丁」：用流程、用檢查清單、用獨立 review，去彌補工具本身還沒解決的傾向。打補丁不是壞事，但打補丁跟回報問題,是兩件該同時做的事，不是二選一。
「AI 有時候會亂改東西」「AI 太自信了」——這種抱怨完全可以理解，但對工具改善幾乎沒有幫助，因為它沒有給出任何可以被驗證、可以被重現的具體資訊。工具開發者拿到這種回報，沒有辦法判斷是哪一類情境觸發的、觸發頻率有多高、跟哪個版本有關。
一份有用的 bug report，需要包含四個要素：
用一組對照來看這個差異：
❌ 模糊的抱怨：
「AI 常常太快下結論，查一半就說已經確認完了，這樣不太好。」
→ 對方不知道是哪一類任務、什麼情境下發生、
發生頻率如何、是不是每次都這樣
✅ 結構化的 bug report：
「觀察到的行為：agent 在查證『這批項目是否還有真實資料』時，
只查詢了預設範圍就回報『已確認都沒有』。
預期行為：查詢範圍如果只涵蓋預設情境，
應該在回報時明確標注查詢邊界，而不是講成確定性結論。
重現步驟：給定一個查詢邏輯涉及跨表關聯、且預設篩選條件會排除掉部分資料的情境，
重現率高。
證據：具體發生的對話紀錄、涉及的查詢邏輯片段。
懷疑根因：agent 傾向把『目前查詢範圍內沒找到』
跟『這件事不存在』兩者的語氣混在一起表達，沒有區分查詢邊界。」
→ 對方可以判斷這是不是一類已知模式、
能不能在類似情境下重現，甚至可能修正這種語氣混淆的傾向
一份好的 bug report 本身，就是這個系列反覆講的那個原則的實踐：不要只給結論，要給出「觀察到什麼」跟「查證範圍是什麼」,讓對方能自己判斷可信度，而不是要求對方直接相信你的判斷。
第三部從 Day 16 走到今天，講的是一整套「怎麼讓 AI 記住這個專案的規矩、並且知道什麼時候該用哪條規矩」的機制：CLAUDE.md 跟 skill 怎麼分工、skill 怎麼從一次性經驗提煉出來、記憶系統的四種類型、feedback 記憶怎麼記住「為什麼」而不只是「使用者不喜歡什麼」、記憶會過期怎麼辦、什麼情境該委派給獨立 agent、以及怎麼設計 code review 流程避免 AI 審查自己的盲點。今天這篇算是收尾：當你發現問題根本不在任何規則能解決的範圍內，記得把它區分出來,回報給工具本身，而不是徒勞地想用專案規則去治一個工具層級的病。
回想你上一次抱怨「AI 又做了什麼奇怪的事」的經驗：那次抱怨有沒有具體到「觀察到的行為 vs 預期行為」「重現步驟」這種程度？如果拿去回報給工具開發者，對方看得懂你在講什麼嗎？
第三部到此結束，明天正式進入第四部：實戰案例與總結。第一個案例是一次「以為是非同步問題，其實是重複鍵設計錯誤」的除錯過程——表面症狀很像一類常見問題，追查後發現完全是另一回事。
iThome鐵人賽
看影片追技術