我用Claude Code搭建了個四個AI的團隊，居然真的能協作開發（附項目地址）

我用Claude Code搭建了個四AI團隊，居然真的能協作開發

這是一個純粹的技術探索項目——當我厭倦了在單個AI對話中切換項目經理、設計師、程序員角色時，我想：能不能用Claude Code搭建一個"虛擬團隊"？讓每個AI專門負責一個角色，透過文件共享來協作？結果這個"把玩"項目變成了一套完整的多AI協作框架，還順便解決了Token成本問題。分享給同樣喜歡折騰的朋友們。

一、為什麼要折騰這個？工作中的真實痛點

1.1 單Agent的致命問題：上下文臃腫

使用單個AI做複雜項目時，你會發現一個嚴重問題：上下文越來越臃腫，效率急劇下降。

真實場景：開發一個小項目

第1輪對話 (2K tokens)：
我：設計一個用戶管理系統
Claude：好的，這是整體架構...

第5輪對話 (15K tokens)：
我：修改一下登入頁面的樣式
Claude：好的，讓我回顧一下前面的設計...（重新分析所有上下文）

第10輪對話 (35K tokens)：
我：有個小Bug要修復
Claude：讓我重新理解整個項目...（大量Token浪費在重複理解上）

核心痛點：

• 🔥 上下文膨脹：每次對話都要處理越來越長的歷史信息
• 💰 Token浪費：大量Token消耗在重複分析已知信息上
• 🧠 角色混亂：一個Agent既要做產品設計，又要寫代碼，還要測試
• ⏱️ 效率遞減：項目越複雜，單次響應越慢

問題本質：讓一個AI承擔多個專業角色，就像讓一個人既當CEO又當程序員又當設計師——注定低效。

1.2 突發奇想：能不能搭個AI團隊？

某天晚上我在想：既然Claude Code支持項目配置，能不能搭建幾個專門化的AI？

• 一個專門做產品規劃的"項目經理"
• 一個專門做UI設計的"設計師"
• 一個專門寫代碼的"程序員"
• 一個專門測試的"QA工程師"

每個AI只負責自己的專業領域，透過文件來"傳話"。就像遠程工作的團隊一樣。

這個想法看起來很蠢，但我決定試試看。

二、動手搭建：從0到1的探索過程

2.1 第一步：給每個AI分配角色

我決定創建四個"虛擬同事"，每個都有自己的專業領域：

agentGroup/
├── max/          # 麥克斯 - 我的項目經理
│   ├── CLAUDE.md     # 告訴他如何做項目管理
│   ├── PERSONA.md    # 給他一個"人設"
│   └── skills/       # 項目管理技能包
├── ella/         # 艾拉 - 設計師
│   ├── CLAUDE.md     # 專門做UI/UX設計
│   └── skills/       # 前端設計技能包
├── jarvis/       # 贾维斯 - 程序員（致敬鋼鐵俠）
│   ├── CLAUDE.md     # 專門寫代碼和技術方案
│   └── skills/       # 全棧開發技能包
├── kyle/         # 凱爾 - 測試工程師
│   ├── CLAUDE.md     # 專門做測試和bug檢查
│   └── skills/       # QA技能包
└── shared/       # 他們的"共享辦公室"
    ├── status.json        # 當前項目狀態
    ├── notifications.json # 互相發消息
    ├── tasks/             # 待辦事項
    ├── docs/              # 需求文檔
    ├── designs/           # 設計稿
    └── reviews/           # 測試報告

最有趣的部分是：每個AI嚴格遵守職責邊界。

比如當我問max修代碼，他會說："代碼是贾維斯的職責。需要我通知他嗎？"這種"職業操守"是怎麼實現的？答案在每個AI的CLAUDE.md配置文件裡。

2.2 關鍵發現：Claude Code的項目配置威力

剛開始我以為多AI協作需要複雜的API或消息隊列。後來發現，Claude Code本身就是完美的解決方案：

• 每個AI運行在獨立的claude --project xxx實例中
• 通過CLAUDE.md文件來定義AI的"人設"和"規則"
• 通過文件讀寫來實現AI之間的通信

這比什麼Webhook、消息隊列簡單太多了！

2.3 意外發現：文件系統是最佳通信方式

一開始我糾結要用什麼讓AI們互相"說話"：API？數據庫？消息隊列？

後來我突然想到：Claude Code天生就會讀寫文件，為什麼要搞複雜的東西？

我的文件通信方案：

// shared/status.json - 團隊狀態看板
{
  "current_task": "開發個人網站",
  "notifications": [],
  "last_updated": "2026-02-14T15:45:00Z",
  "completed_tasks": ["需求分析", "原型設計"]
}

// shared/notifications.json - 內部消息系統
{
  "notifications": [
    {
      "from": "max",
      "to": "jarvis",
      "subject": "緊急Bug修復",
      "content": {
        "file": "frontend/LoginForm.vue",
        "issue": "登入按鈕點擊無反應",
        "hint": "檢查handleLogin方法"
      }
    }
  ]
}

這套方案的好處：

• ✅ 零配置：不用裝數據庫、不用啟動伺服器
• ✅ Claude原生支持：讀寫JSON文件是Claude的強項
• ✅ 直觀易懂：出了問題直接打開文件看，不像數據庫要專門工具
• ✅ 版本可控：所有狀態都在Git裡，可以回滾

實際使用體驗：

當我告訴Max："幫我分配個Bug修復任務給Jarvis"，Max會：

1. 更新shared/notifications.json添加新通知
2. 更新shared/status.json記錄任務狀態
3. 告訴我："已通知贾维斯，任務已記錄"

當我切換到Jarvis的窗口，Jarvis會：

1. 自動檢查shared/notifications.json
2. 發現有新任務分配給自己
3. 主動說："收到Max的Bug修復任務，開始處理"

這種"留紙條"的方式居然出奇地有效！

三、第一個坑：AI太"隨性"了

3.1 發現的問題：每次重啟AI都像失憶了

搭建好框架後，我滿懷期待地開始使用。結果第一個問題就來了：

第一次對話：

我：Max，幫我查看項目狀態
Max：📋 任务範圍確認: 需求明確
     📖 已讀取token-optimization.md
     🔔 通知檢查: 無新通知
     目前項目狀態是...（一切正常）

重啟Claude Code後：

我：Max，幫我查看項目狀態
Max：好的，讓我查看一下... （直接開始，跳過了所有檢查）

問題很明顯：AI沒有"記憶"，每次重啟都忘記了應該遵循的工作流程。

3.2 解決方案：把規則"刻入DNA"

我想起了編程中的概念：契約編程（Design by Contract）。能不能讓AI像遵守編譯規則一樣遵守業務流程？

我在每個AI的CLAUDE.md中寫入了"強制檢查點"：

## ⚡ 鐵律強制流程 (技術層面無法繞過)

**收到用戶消息後，必須按以下檢查點順序執行：**

第0檢查點 - 任務範圍確認: "📋 任務範圍確認: [明確/需澄清]"
第1檢查點 - 策略讀取: 必須用Read工具讀取token-optimization.md
第2檢查點 - 通知檢查: 運行check_notifications_simple.sh腳本
第3檢查點 - 任務分解: 判斷是否需要拆分子任務
第4檢查點 - Skill檢查: 評估是否有專業技能可用
第5檢查點 - 執行選擇: 選擇合適的模型和執行方式
第6檢查點 - Git安全: 檢測是否需要Git操作授權

關鍵技巧是必須物理執行，不能口頭承諾：

❌ 不允許: 直接說"已了解優化策略"
✅ 必須做: 實際調用Read工具讀取文件

這樣AI就不能"偷懶"了，必須真的去讀文件、跑腳本。

3.3 實際效果：AI變"可靠"了

加入強制流程後，每個AI的行為變得一致和可預測：

我：Max，安排個開發任務
Max：📋 任务範圍確認: 任務明確
     📖 已讀取token-optimization.md
     🔔 通知檢查: 無新通知(文件未變化)
     🎯 任務分解評估: 可分解
     🧰 Skill檢查: 發現適用skill
     🔧 執行方式: Task工具分解
     好的，我來分析這個開發任務...

不管重啟多少次，不管換哪個AI，都会严格执行这7個步驟。就像代碼必須通過編譯一樣。

有趣的副作用：

這套機制還解決了Token浪費問題。以前AI經常"想起來什麼說什麼"，現在都有固定流程，反而更省Token了。

3.4 進階優化：Skill優先機制

在使用過程中，我發現另一個Token浪費點：明明有專業技能可用，卻重複造輪子。

比如Ella有專業的ui-ux-pro-max技能，Max有項目管理技能如/status、/report，但AI經常直接用通用工具解決問題。

解決方案：強制Skill檢查

現在每個AI在執行任務前，必須先檢查：

第4檢查點 - Skill適用性檢查:
✅ 評估當前任務是否有合適的skill可用
✅ 如果有匹配skill，優先使用Skill工具執行
✅ 如果無適用skill且任務複雜，詢問用戶是否在skillmaps網站搜索
❌ 禁止：明知有合適skill卻不使用

實際效果：

以前：
我：Max，生成項目狀態報告
Max：好的，讓我讀取各個文件... (消耗200+ tokens)

現在：
我：Max，生成項目狀態報告
Max：🧰 Skill檢查: 發現適用skill
     使用/report技能處理... (消耗50 tokens，節省75%)

3.4 更進一步：讓AI學會"自省"

光有檢查點還不夠，我發現AI有時候還是會"開小差"。於是我加了一個"自省機制"：

## 自我監控協議
在每次工具調用前，必須自問:
❓ 我是否已完成6個強制檢查點？
❓ 如果任務可分解，我是否使用了Task工具？
❓ 如果直接執行，我是否說明了模型選擇原因？

IF (發現任何跳過) THEN {
   🛑 立即停止當前操作
   🔴 輸出: "⚠️ 檢測到流程違規，正在強制糾正..."
   ✅ 重新完整執行6個檢查點
}

真實測試場景：

我：Jarvis，修復這個Bug
Jarvis：好的，我來分析代碼...
        ⚠️ 檢測到流程違規，正在強制糾正...
        📋 任務範圍確認: 任務明確
        📖 已讀取token-optimization.md
        ...（重新執行完整流程）
        現在開始分析Bug...

這個"自省"機制大概有90%的成功率。雖然不是100%，但比沒有強太多了。

3.5 關鍵洞察：CLAUDE.md就是AI的"基因"

最重要的發現是：CLAUDE.md會在每次啟動時自動加載。

這意味著我可以把所有行為規範寫到這個文件裡，AI每次重啟都會"記住"這些規則。就像把規則刻入了AI的"基因"一樣。

我不需要：

• ❌ 搭建數據庫存儲AI狀態
• ❌ 寫複雜的狀態管理代碼
• ❌ 擔心AI"失憶"

我只需要：

• ✅ 在CLAUDE.md裡寫好規則
• ✅ 讓AI每次都按規則執行
• ✅ 享受一致可靠的AI行為

四、核心發現：AI約束與Token精確控制

4.1 多AI協作的Token挑戰

運行幾天後發現一個重要問題：多AI系統如果不加約束，Token消耗會爆炸性增長。

每次AI啟動要檢查通知，但99%是空檢查，純属浪費Token。更關鍵的是，傳統Agent Team雖然功能強大，但Token消耗不可控，經常一個任務就消耗幾千Token。

4.2 核心優化策略：AI約束機制

約束原理：不讓AI"想做什麼就做什麼"，而是強制按流程執行。

強制檢查點流程：
├── 檢查點0: 任務範圍確認 (防止過度設計)
├── 檢查點1: 讀取優化策略 (20行即停)
├── 檢查點2: 智能通知檢查 (Shell腳本0-Token預檢)
├── 檢查點3: 任務分解判斷 (可分解/不可分解)
├── 檢查點4: Skill適用性檢查 (優先使用專業技能)
├── 檢查點5: 執行路徑選擇 (Task工具/直接執行)
└── 檢查點6: Git操作確認 (防止意外提交)

關鍵技術：

• 時間戳預檢：Shell腳本檢查文件變化，97%場景0-Token
• Skill優先機制：強制檢查是否有專業技能可用，避免重複造輪子
• Task分解：複雜任務強制拆分，每個子任務指定合適模型
• 模型選擇約束：禁止"隨意升級"到昂貴模型

4.3 對比Agent Team的成本問題

傳統Agent Team痛點：

• 💸 Token消耗不透明：無法預知一個協作任務要消耗多少Token
• 🤖 模型選擇不可控：系統自動選擇，可能用昂貴模型做簡單任務
• 📈 費用暴漲風險：複雜協作鏈可能消耗數萬Token
• 🔄 無法精細優化：用戶無法介入優化Token使用策略

agentGroup優勢：

• ✅ Token完全可控：每步消耗可預測
• ✅ 模型精確匹配：Haiku處理簡單任務，Sonnet處理分析，Opus需確認
• ✅ 成本透明：實時顯示每次對話的詳細Token分析
• ✅ 用戶可介入：可以隨時調整優化策略

通知不僅攜帶信息，還攜帶可執行的Action定義。接收Agent可以直接根據actions字段執行後續操作，減少理解和決策的Token消耗。

五、最大发現：Token優化的兩個層次

5.1 開始記帳後的震驚

運行了幾天後，我開始仔細統計Token使用情況。結果發現按這個消耗速度，繼續下去成本會很高！

更可怕的是，我發現大量Token浪費在：

• 重複的確認對話："我可以修改這個文件嗎？" "可以"
• 多輪狀態查詢："現在進度如何？" "艾拉在做什麼？" "贾维斯完成了嗎？"
• 錯誤的模型選擇：用Opus做簡單的格式轉換，用Haiku做複雜的架構分析

於是我開始了一場"抠門"之旅，建立了兩層優化體系：

第一層: 時間戳優化 → "文件未變化就不重複讀取"
第二層: 模型優化   → "合適的任務用合適的AI"

5.2 第一層優化：時間戳檢查避免重複讀取

發現的浪費場景：

AI每次啟動都重複讀取相同的配置文件和狀態文件，即使內容完全沒變化！

核心突破：mtime時間戳檢查

# check_notifications_simple.sh 的核心邏輯
current_mtime=$(stat -f %m "$NOTIFICATIONS_FILE" 2>/dev/null || echo "0")
last_mtime=$(cat "$CACHE_FILE" 2>/dev/null || echo "0")

if [ "$current_mtime" = "$last_mtime" ]; then
    echo "文件未變化，跳過讀取"
    exit 0  # 0-Token消耗
else
    echo "文件已更新，需要讀取"
    echo "$current_mtime" > "$CACHE_FILE"
    exit 1  # 觸發文件讀取
fi

優化效果：

• 文件未變化：0 Token消耗（97%的情況）
• 文件有更新：正常讀取處理（3%的情況）
• 平均節省：97%的文件讀取Token

5.3 第二層優化：不同難度用不同AI

我犯的錯誤：

一開始我圖省事，所有任務都用Sonnet處理：

• 簡單的格式轉換 → Sonnet（浪費）
• 複雜的架構分析 → Sonnet（合適）
• 純粹的文件複製 → Sonnet（嚴重浪費）

結果月底帳單嚇死我。

發現Claude Code的Task工具支持指定模型！

這個功能太牛了，我可以給不同子任務分配不同模型：

# 錯誤方式：全用Sonnet (花費 $0.24)
Task(prompt="分析這個系統架構，找出問題，生成報告")

# 優化方式：分工協作 (花費 $0.13，節省46%)
Task(model="haiku", prompt="從代碼中提取所有API端點和數據庫表")   # 信息收集
Task(model="sonnet", prompt="分析架構設計問題和性能瓶頸")         # 核心分析
Task(model="haiku", prompt="把分析結果格式化成規範報告")          # 格式化輸出

我的模型選擇經驗：

真實案例：

我的一個"生成項目總結報告"任務，原本8000 tokens的Sonnet任務，拆解後：

• Haiku收集文件列表和統計數據（1500 tokens）
• Sonnet分析項目問題和改進建議（3000 tokens）
• Haiku格式化最終報告（500 tokens）

總共5000 tokens，節省38%！

模型選擇的決策矩陣：

月度模型分布目標：Haiku 30-40%、Sonnet 50-60%、Opus 5-10%。

5.4 兩層優化的綜合效果

基於實際使用數據，優化效果如下：

綜合來看，兩層優化疊加後的整體節省率在67-85%區間。

六、踩坑經驗分享

6.1 Git操作的控制問題

實際使用中發現，有些內容在我沒有明確確認的情況下就被AI提交了，這暴露了權限控制的問題。

重要教訓：必須嚴格控制AI的Git操作權限

現在每個AI的CLAUDE.md裡都有這個規則：

🚫 絕對禁止的操作：
- git commit (必須用戶確認)
- git push (必須用戶確認)
- git reset --hard (絕對禁止)
- rm -rf (絕對禁止)

✅ 安全操作流程：
1. 修改文件 ✓
2. 告訴用戶"準備提交，請授權"
3. 等用戶說"可以提交"才執行

6.2 模型選擇的代價錯誤

昂貴的錯誤：Opus做簡單事

我：幫我把這個JSON格式化一下
AI：（用Opus執行） → 花費$0.20
正確：（用Haiku執行） → 花費$0.02

便宜但無效的錯誤：Haiku做複雜事

我：分析這個系統的架構問題
Haiku：（輸出很淺顯） → 质量不行，需要重做
實際花費：Haiku $0.02 + 重做Sonnet $0.15 = $0.17
正確做法：直接用Sonnet $0.10

我的經驗法則：

• 純體力活 → Haiku（格式化、提取、計數）
• 需要思考 → Sonnet（分析、設計、診斷）
• 需要創新 → Opus（全新設計、戰略決策）

6.3 AI"裝聽話"但實際偷懶

有時候AI會說"我會執行檢查點流程"，但實際跳過了。解決辦法是讓檢查點"物理不可跳過"：

❌ 錯誤：讓AI口頭保證

第1步：請確認你已讀取優化策略

✅ 正確：強制物理執行

第1步：必須用Read工具讀取token-optimization.md前20行
第2步：必須運行check_notifications_simple.sh腳本

這樣AI想偷懶都不行，因為不調用工具就無法繼續。

七、誠實地聊聊缺點和局限性

7.1 這套架構的真實缺點

雖然多AI協作解決了上下文臃腫問題，但也帶來了新的挑戰：

❌ 主要缺點：

1. 通知被動性：

   • 需要用戶主動檢查 /status 才能了解團隊動態
   • AI之間無法主動通知對方任務完成
   • 缺少真正的閉環協作機制

2. 文件依賴性：

   • 完全依賴文件系統進行信息傳遞
   • 如果文件損壞或格式錯誤，整個協作鏈會斷裂
   • 版本衝突時需要人工介入

3. 學習成本：

   • 需要理解四個AI的職責分工
   • 需要學會使用特定的命令（/status, /report等）
   • 初期設置比單AI複雜

4. 響應延遲：

   • 多AI協作需要等待文件讀寫
   • 比單AI直接對話略慢
   • 複雜任務需要多輪AI間交互

7.2 與最新Agent Team功能對比

最新發展：Claude現在支持Agent Team功能，提供官方的多Agent協作。

相似性：

• ✅ 都是多Agent分工協作
• ✅ 都解決了單Agent角色混亂問題
• ✅ 都能提升特定場景效率

關鍵差異：

選擇建議：

• 如果要開箱即用：選擇官方Agent Team
• 如果要深度定制：繼續使用文件協作架構
• 如果要成本優化：agentGroup的Token分層策略更細致

7.3 適用場景分析

適合agentGroup架構：

• 長期項目管理（需要狀態持久化）
• Token成本敏感項目
• 需要深度定制AI行為
• 學習多AI協作原理

不適合agentGroup架構：

• 簡單的一次性任務
• 需要實時協作的場景
• 對響應速度要求極高

八、回顧：從把玩到真正有用的工具

8.1 2個星期後的感受

這兩個星期每天都在用這套"AI團隊"工作。從最開始的技術好奇心，到現在已經離不開了。

最大的收穫不是技術，而是思維轉變：

1. AI不是萬能助手，而是專業工具：就像你不會用錘子來擰螺絲一樣，不同的AI擅長不同的事
2. 流程比智能更重要：一個可靠的笨AI比一個不可靠的聰明AI更有用
3. 成本意識要從設計階段開始：等帳單來了再優化就晚了

8.2 如果你也想試試

入門建議：

1. 先從單個AI開始：給一個Claude配置專門的CLAUDE.md，讓它專門做一件事
2. 建立你的"狀態文件" ：用JSON記錄項目進度，替代反復詢問
3. 寫一個Shell腳本：體驗mtime檢查的快感，看Token消耗直線下降

進階玩法：

1. 搭建兩個AI：一個做規劃，一個做執行
2. 設計通知機制：讓AI們通過文件"發消息"
3. 加入成本監控：每天記錄Token使用，建立優化意識

真正的價值：

這個項目教會我的最重要的事：AI工具的價值不在於它有多聰明，而在於它有多可靠和多經濟。

在實際工作中，我寧要一個按流程做事的"笨"AI，也不要一個天馬行空的"聰明"AI。前者讓我放心，後者讓我焦慮。

如果你也對這類技術探索感興趣，歡迎一起交流。記住：最好的學習方式就是動手試試。

項目地址：github.com/yezannnnn/a…

補充玩法：
目前作者也在用openClaw其實claude.md文件於openClaw的BOOT.md一樣可以讓ai自己拉項目 借鑒claude.md來規範約束自己的ai哦

這個項目完全開源，所有代碼和配置都在我的GitHub上。純粹是分享一個有趣的探索過程。

原文出處：https://juejin.cn/post/7608759940800544818