Termdock先把工作分清楚
兩個 CLI 合作的重點不是各開一個視窗，而是讓下一個 agent 拿到足夠的需求、檔案位置與驗證結果。本文用 Gemini CLI 探索、Claude Code 實作、再交回審查的方式示範；你也可以換成已能使用的其他 CLI。
先確認存取資格。 Google 的 2026 年 5 月公告表示，6 月 18 日起 Gemini CLI 不再服務 Gemini Code Assist 個人免費使用者和 Google AI Pro／Ultra 使用者；Code Assist Standard／Enterprise 和付費 Gemini、Gemini Enterprise Agent Platform API key 仍獲支援。Google 引導受影響的個人使用者轉向 Antigravity CLI，但它不是 Gemini CLI 的完全替代品。另一方面，Gemini CLI 驗證文件與額度文件仍列個人帳號與免費額度。這些官方來源有衝突，本文沒有實測所有帳號；先看最新資訊並用自己的資格驗證，不要假設每天 1,000 次免費請求。
判斷框架：什麼任務用什麼工具
先按責任切分，而不是假設特定模型一定較好：探索 session 找現況和疑點，實作 session 修改授權的檔案，審查 session 比對需求與 diff。另一個 session 不會自動知道之前的對話；每次交接都要帶上必要上下文。
設定雙工具 workflow
- 依 Gemini CLI 安裝文件和 Claude Code 設定文件安裝並確認登入、方案和用量。各工具的帳號及費用分開計算。
- 在 Termdock 開啟專案工作區，新增兩個終端，分別啟動已可使用的 CLI。確認兩邊指向預期的專案與分支。
- 給兩個 session 不同職責。若要同時寫入，先劃分檔案所有權，或自行建立 worktree；Termdock 不會自動替每個 agent 建立 worktree。
實戰範例：完整開發一個功能
以下用 API rate limiting 當示意，不預設專案已安裝任何套件，也不宣稱已跑過範例。
第一步：探索，不修改
在 Gemini CLI session 提出：
請唯讀檢查這個專案的 API 入口、中介層及現有測試。
列出檔案路徑、目前處理方式，以及加入 rate limiting 前需要確認的問題。
不要修改檔案或安裝套件。
搭配工具提供的權限限制；文字要求本身不是 sandbox。確認列出的路徑確實存在，並人工決定限制策略及是否需要新增依賴。
第二步：把決策交給實作 session
把需求、確認過的路徑、允許修改的檔案和測試命令交給 Claude Code：
依照已確認的方案，替指定 API 加入 rate limiting。
僅修改以下授權的檔案：[填入路徑]。
完成後列出 diff、測試命令與結果；不要提交或部署。
不要把 [填入路徑] 當成實際路徑。測試失敗或條件不足時，先回報，不要假裝完成。
第三步：交回審查，再由人確認
讓另一個 session 取得需求和 diff 位置，請它唯讀檢查錯誤回應、邊界情況和測試缺口，並附上檔案位置。檢查回覆是否有證據，將有效意見交回實作 session，再跑相關測試。最後由人看 diff 和結果，決定後續處理。
選用：讓 Agent 透過 Termdock 交接
在 macOS 的 Termdock「設定 > Skills > Command Line Tool」安裝 termdock CLI，確認兩個 CLI 都已安裝並登入後，可以請 Claude Code 使用內建終端操作 skill 開啟審查 session、送出需求與 diff 位置、讀取回覆。也可以由人手動操作。Termdock 連接終端，不會自動共享對話，也不保證審查完成或正確。Windows 可用桌面與 HTTP Terminal API；一鍵 CLI 安裝目前限 macOS。操作細節見 Agent 交接教學與 CLI 文件。
費用計算
先記錄實際訂閱與 API 帳單、各自模型和用量，再比較原流程與雙工具流程的總成本。不要把個人免費額度、固定比例的節省，或能降級訂閱當成保證；是否省錢取決於你能使用的方案與任務量。
這個策略什麼時候不適用
單一小修改可能不值得新增交接；機密資料也不一定適合送到第二個供應商。權限敏感的任務應先限制操作、審查資料政策，且由人決定是否執行或發布。
開始行動清單
確認登入與預算，選一個低風險任務，寫明輸入、輸出與禁止事項。完成探索、實作、複查後，保存實際測試結果，觀察交接是否真的有幫助。較完整的存取與成本比較見 Claude Code 與 Gemini CLI。