Journal
AI 協作系列｜第 0 篇：一整天的脈絡
這篇是系列的入口。如果你想直接跳進某個主題，每個段落結尾都有對應的文章連結。
文中對 Agent 行為的觀察，受模型版本、工具選擇與我自己的工作脈絡影響，不一定出現在每一位使用者身上。把它當作一個觀察紀錄，而不是通用結論。
文中「AI」泛指工具或模型，「Agent」則特指它在接任務、規劃與執行時的運作角色。兩者偶爾交替出現，但後者更強調「自主執行某件事的那個狀態」。
起點：原本只是要大掃除
今年八月，我決定整理一套已經用了好幾個月的 AI 協作規則系統。
這套系統叫做 AGENT.HQ，位於各 AI 工具配置目錄的上層，同步給我用的三個工具：Claude Code、Codex CLI、Antigravity CLI（原Gemini CLI）。裡面有操作規範、按需載入的規則、各種 skill。大概念是：把「怎麼和 AI 一起工作」寫成可執行的規則，讓每次新的對話不用重新說明偏好。
大掃除的理由很現實：模型比以前強了，很多以前要再三叮嚀才做到的事，現在只要提點一下就好了；工具使用的方式也在變；我自己的標準也不一樣了（有些進化?）。所以想清一清過期的東西，補上缺的。
開始執行之後，事情的走向出乎我意料。
清垃圾花了不到二十分鐘。但接下來問的那個問題——「你真正需要改的是什麼」——把我帶進了一個不太一樣的思考地帶。
問題比我以為的更根本
整理規則的過程裡，聊到了我實際的開發流程。我描述了自己怎麼接任務、怎麼跟 Agent 互動、怎麼驗收成果。
說出口之後，我意識到一件事：整個流程裡，真正在做判斷和決策的幾乎都是 Agent。我更像是在等待結果，確認能跑、有問題就回去修。
這不是我想要的協作方式。但我沒有明確意識到這件事，直到被問到。
這個發現讓整天的焦點從「整理規則」轉移到「我到底想要什麼樣的協作」。
→ 關於這個角色問題，我在第 1 篇深入說明。
然後我們看了一個讓我很推崇的專案
談到「什麼是好的工程文化」，我提到了一個我有加入其中的公司專案，主要維護人被我在心中標籤成一位匠人，非常用心的一包。
把它打開來看，試著說出「我推崇的是什麼」的時候，我才發現自己說不清楚的是：程式碼規範、目錄結構、review checklist——這些東西我很喜歡，但在我其他的專案裡幾乎都是空的。
更重要的是，這些東西存在於那個專案本身，而不是在我的全局規則系統裡。一個新專案開起來，不會自動繼承這些。
這個觀察後來影響了規則系統的整個結構調整方向：全域層只放原則和偏好，專案層自己維護具體規範，兩者之間有一個「專案啟動前置」機制來填補缺口。
→ 關於規則系統的設計，我在第 2 篇說明。
最大的工程：從頭設計一套 review 框架
那天最耗時的工作，是重新設計一套叫 delivery-review 的交付檢查框架。
這個框架花了很長時間討論，不是因為技術難，而是因為每一條規則背後都有一個「為什麼這樣、不那樣」的判斷。
最核心的一個決定：review 不是核對清單，而是判斷後果。 同一個問題，在不同情境下可能是 blocking，也可能是建議，取決於那個問題實際上會造成什麼影響，而不是「命中了哪條規則」。
這個原則影響了整個框架的設計，從 Must Fix 和 Should Review 的分類方式、到 Agent 被告知「不要因為 pattern 命中就自動修改」。
框架本身的範圍後來也擴到了四個面向：Application、Data、Runtime、Delivery，每個面向有自己的 context detection，只有在相關的變更存在時才載入對應的規則。
→ 關於 delivery-review 的設計思考，我在第 3 篇說明。
最後討論的：複雜度問題
討論到比較後期，refactor 這個詞出現在我眼前，我意識到一個問題：AI 協作開發會不會讓 codebase 越來越複雜？
不是因為需求複雜，而是 Agent 本身沒有人工 coding 時的那種「摩擦成本」——對人來說多做一層是有代價的，對 Agent 來說多做和不多做差不多，所以它傾向做得更多。
這個問題後來長出了一個設計原則，但同時也讓我意識到規則介入的是哪個環節、又管不到哪裡。
→ 關於 AI 協作開發的複雜度問題，我在第 4 篇說明。
這一天走到哪裡
清了過期的備份、重組了規則系統的結構、建了新的框架、寫進去了幾個新原則。有形的改動很多。
但對我來說，比這些更重要的是那個起初沒有預料到的問題。
「你在這段協作裡，到底扮演什麼角色？」
這個問題我花了一整天才說清楚——不是因為它很難，而是因為我沒有在對的時候問自己。
後面四篇文章，是我對這個問題的各個面向的回答。