我如何讓 Claude 擔任專案經理，Gemini 擔任執行者，打造一個更懂我的 AI 團隊
最近，我花了不少時間在尋找 Gemini CLI 之外的另一個備用 CLI 工具。
這個過程讓我密集測試了市面上許多主流的 AI 助手。繞了一圈後，我得出的結論是：Gemini CLI 確實是目前在 Windows 上整合體驗最好的選擇。
不過，這次探索最大的收穫，是讓我遇見了 Claude Code。
它的體驗真的非常驚艷，尤其是在命令列（CLI）的互動設計上，遠遠超過了其他競爭者。我完全能理解為什麼它會是目前評價最高的 AI CLI 工具。
在深度使用 Claude 的過程中，我發現它有一個非常突出的優點：極其擅長做詳細的任務規劃和流程設計。
這恰好觸發了我一個擱置已久的想法——之前在網路上看到有人分享如何讓不同的 AI 模型進行協作。既然 Claude 擅長「規劃」，而我慣用的 Gemini 擅長「執行」，為什麼不把它們組成一個團隊呢？
於是，我開始著手實踐，最終打造出一個由 Claude、Gemini 和 Obsidian (我的筆記軟體) 構成的協作系統。
我的 AI 團隊是如何分工的？
這個系統的核心理念很簡單，就是進行明確的分工：
Claude 扮演「大腦」/「專案經理」：負責理解需求、思考和規劃。
Gemini 扮演「雙手」/「執行者」：負責快速、平行地執行具體任務。
Obsidian 扮演「記憶體」：存儲背景知識、歷史記錄，並協助我進行後續的文章創作。
三天，從想法到實踐
這個系統的搭建過程比想像中要快，大概只花了三天時間：
Day 1：完成藍圖
我與AI先設計了整個系統的架構，明確了 Claude 和 Gemini 之間如何溝通、如何分工，以及數據如何在它們之間透過MCP流動。Day 2：基礎建設
我為這個系統建立了一套「工作手冊」（我稱之為 Playbook）。例如，有一個專門的diary-update手冊，詳細定義了更新日記的每一步流程。這樣 Gemini 在執行任務時，就能像查閱 SOP 一樣，精準地完成工作。Day 3：首次測試與修正
我進行了第一次端到端測試，場景是「更新日記的遊戲進度」。流程是這樣的：
我向 Claude (專案經理) 下達指令。
Claude 將指令轉化為計畫，交給 Gemini (執行者)。
Gemini 根據工作手冊，生成了日記草稿。
結果：成功！ 這是第一次實現了 Claude → Gemini → Obsidian 的完整工作流。
測試中發現的問題（以及為什麼這很重要）
首次測試雖然成功了，但也暴露了一個關鍵問題：Claude 在審查完 Gemini 的草稿後，直接就想把內容寫入檔案，跳過了我的確認環節。
這違反了我的核心原則：人類必須在關鍵節點上擁有最終決定權。
我立刻修正了系統的規則，要求 AI 在執行任何寫入操作前，必須先展示完整的草稿給我，並等待我明確說「OK」。
這個修正看似微小，卻是整個協作系統的靈魂。它確保了 AI 始終是「輔助」我的角色，而不是「代替」我做決定。這也是讓 AI 越來越懂我的關鍵。
結語：真正的樂趣，在於「我能用 AI 做什麼」
對我來說，這次從想法到實踐的整個過程，帶來的是一種純粹的興奮感。看著自己的一個念頭，被 AI 轉化為細緻的計畫，再一步步搭建完成，並成功跑通第一個流程——那種「哇，AI 真的太好玩了」的感覺，遠比單純生成一段文字要強烈得多。
這也再次印證了我一直以來的想法：AI 的價值，不在於它第一次能幫你生成什麼，而在於它能多好地理解你的意圖，遵循你的指令，並最終實現你預期的結果。
我一直在尋求的，是 AI 如何更好地「輔-助」我完成想做的事，而不是「取代」我。
我認為，這正是探索 AI 用法時一個巨大的思想分歧點。你可以問：「AI 能幫我做什麼？」，這會讓你傾向於把主導權交給 AI。
但我更喜歡問：「我可以用 AI 做什麼？」
當你從這個角度出發，AI 就從一個指令的執行者，變成了你思想的延伸、一個強大的協作者。無數的可能性，正是在這個問題下被探索出來的。
目前，這個協作系統還只是一個開始，內部還有很多細節等待我去填充。但我非常期待，在它完全體之後，我到底能用它來把目前手上的各種事情，玩出多大的效果。
作者：Roland Zhong