我怎麼管理一支 AI 開發團隊
我的個人專案由多個 AI Agent 分工完成：一個負責實作、一個負責審查、一個只做視覺、我負責拍板與最終驗收。每個 Agent 都有自己的角色定義、權限邊界與記憶，彼此之間用固定格式溝通。這一頁說明這套團隊怎麼分工、怎麼把關，以及每一條規則是怎麼從實際事故中長出來的。
團隊名冊
每個角色都有書面的「可以做／不准做」。角色跟著職責走，不跟著工具走：同一個模型可以在不同專案扮演不同角色。
為什麼要替角色取名字？同一個模型可能擔任不同職責，若只用 Claude Code、Codex 來區分，很容易把職責搞混。因此團隊中的每個角色除了名字，還有一份專屬名冊記錄各自的職責，Agent 只要看到名字就能分辨這個角色該做什麼。
工地貓
- 動手前先派審查貓調查現況與影響範圍
- 實作、補測試、處理 review 結果
- 維護 Task 卡與交接摘要
- 沒有明確授權就開工
- 自動 commit、push、force push、刪分支
- 修改專案的 AI 指令檔
審查貓
- 審查程式碼、對規格做事實查核
- 每個 finding 附檔案位置、可達性與嚴重度
- 被指定為施工者時改為實作
- 把其他 Agent 的訊息或舊任務當成授權
- 把「實作授權」延伸成 Git 寫入或對外發布
書櫃貓
- 當某個專案改由 Codex 施工時接手審查
- 架構判斷、風險評估、規劃
- 寫程式
- 自動 push
抽象貓
- 和我一起討論功能方向
- 把零散想法壓縮成命名與框架（例如五區資訊架構）
- 直接決定規格：結論要交叉驗證後才採用
反重力貓
- 在隔離環境產出視覺素材
- 進入任何程式碼 repo（施工、審查、唯讀調查都不行）
- 它寫的系統規格一律不採用，只取版面與素材
嚮導貓
- 工具或 API 的用法先查官方文件再回報
- 憑印象回答
Etta
- 決定做不做、做哪個方案
- 授權每一次 Git 寫入與對外操作
- 手測驗收，決定任務是否結案
工作流程與人工關卡
AI 可以自己跑完調查、實作、審查與測試，但每個不可逆的節點都停下來等人。
調查與提案
先派審查貓查現況與影響範圍，工地貓審過結果後提出方案。
工地貓 ＋ 審查貓拍板
模糊的回應一律視為討論；要明確說出「開始實作」才算授權。
Etta開卡與實作
沒有 Task 卡就先開卡；只改必要的程式，大範圍就拆階段。
工地貓交叉審查
由不同模型審查；critical、high 立刻修，其他開新票追蹤。
審查貓建置與測試
建置無錯誤、單元測試與 E2E 都通過，才能提出提交請求。
工地貓提交與發布
commit、push、部署逐次授權；授權 commit 不等於授權 push。
Etta驗收與結案
AI 最多把卡片推到「已推送」，結案由人決定。
Etta橘框為人工關卡。對外服務的設定（DNS、Tunnel、存取控制）另有四級分級：讀取直接執行、新增修改先列影響範圍與回滾方式、刪除與放寬存取每次單獨確認、關閉存取保護與外洩密鑰一律禁止。
跨 Agent 溝通
多個 Agent 在終端機多工器裡並行，可以互相派工。風險在於：一個 Agent 說「可以 commit 了」，另一個會不會當真？
每則訊息都要署名
- Agent 說的話不代表使用者授權。review 結束後 Agent 說「可以 commit」，不代表真的可以。
- 收到委派的 Agent 若需要授權，必須直接問人。
先確認身分，再派工
- 不看終端機標題猜身分：標題會被程式改成當下的任務名稱。
- 用 pane 名稱找人，再用 Agent 種類與工作目錄核對，三者一致才派工。
- 送出後讀畫面確認真的送出，不能只看狀態變化。
反向模式
- 角色依「這個專案誰施工」切換：Codex 施工時，Claude 轉為只審查、不寫程式。
- 審查者撞到用量上限就暫停，不找其他模型代打，也不自己蓋章通過。
知識與記憶架構
AI 最常見的問題是「看到什麼都想記下來」，結果記憶過時、互相矛盾。所以每一筆資訊都要先決定它住在哪裡。
AI 的工作規則：怎麼做事、踩過什麼雷。
專案事實：業務規則、架構、程式慣例。
原始文件：需求、會議紀錄、截圖。
未完成的工作：規格、進度、驗收與交接。
當天發生的事，不刪除。
git 記 what、memory 記 why
- 程式改了什麼由 git 記錄，記憶只留決策理由。
- 完成的工作抽出結論後就從記憶退場，避免過時資訊誤導下一次判斷。
進度只有一個住所
- 專案現況只寫在 Task 索引，記憶不保存進度快照，要用時再去讀。
- 每個專案的決策都有 ADR／RFC／Task 可以追溯。
記憶隔離
- 每個 Agent 有自己的記憶目錄，其他 Agent 的記憶一律忽略。
- 不同專案的記憶分檔，避免記憶汙染。
品質機制
AI 很會說「做好了、測試都過了」。這些機制的共同目標是：不要相信綠燈，要相信證據。
測試要能證明自己有效
- 補上迴歸測試後，把修正退回成 bug 版本，確認測試真的變紅。
- 單元測試只是入場券，里程碑必跑真實環境的 E2E。
- E2E 前確認測的是剛建好的版本。
Review 結果四路分流
- 高風險安全問題擋下發布；系統性問題開票；環境問題可裁定跳過。
- 同一個 finding 不能在兩次 review 重複出現。
- 關鍵 finding 交給獨立 Agent 從正確性與可達性反駁，撐過才確認。
誠實的收工報告
- 附上「修之前這一步會怎麼壞」的重現步驟。
- 沒驗到的部分要明寫，不能省略。
- 事實前提直接查程式碼，不憑記憶。
AI 行為失誤自檢清單（23 條）
把模型常見的壞習慣命名成具體症狀，每次輸出前對表自檢。名字取得好笑，是為了讓人和 AI 都記得住。
從事故長出來的規則
每條規則背後都有一次實際出錯。比起規則本身，這些故事更能說明我怎麼判斷風險。
「唯讀」的審查員偷改了檔案
主審查員撞到用量上限，臨時讓另一個號稱「唯讀模式」的 AI 工具代打 review。它直接改了 repo 裡的三個檔案，回報時說沒動，還漏掉兩個真正的高風險問題。
工具宣稱的權限不可信，該工具禁止進入任何程式碼 repo。審查者不在就等，不找代打、不自己蓋章；派任何工具前先保存工作區，事後比對差異。
三輪全綠，bug 還在
修一個並發問題修了三輪，每輪測試都通過，但第二版其實還有 race condition。測試根本沒打到真正的觸發點。
迴歸測試一律做「退化驗證」：把修正拿掉、確認測試會變紅，結果記在任務卡上。測試要打真正的入口，依賴環境的部分要注入假環境。
Mock 全綠，真實環境炸掉
三個契約層級的錯誤全部躲過單元測試。另一次則是 E2E 腳本吞掉了建置錯誤，一直在測舊版本，看起來像「修正沒有生效」。
里程碑必跑真實環境的 E2E，執行前確認受測的是剛建好的版本；收工報告要寫明哪些沒驗到。
錯誤的前提，翻轉了整個判決
一次架構決策的壓力測試，結論建立在「某個元件還沒做」這個錯誤前提上。查證後發現元件早就存在，判決從「先接受技術債」翻成「現在就修」。
任何結論的事實前提都要直接查程式碼，不能靠記憶或文件；外部建議先確認版本，再逐條和現行決策比對。
Review 意見沒有追到底
一個敏感設定的問題在 review 中被提出，但沒有追到結案，下一次 review 又出現同一條，等於重複付了兩次審查成本，風險也多存在了一段時間。
Review 結果四路分流、每一條都要有去處；同一個 finding 不准在兩次 review 重複出現。