CCG 是什麼？
先講結論。CCG 就是讓三個 AI 分工合作：
Claude Code 當指揮官，Codex CLI 跑後端，Gemini CLI 跑前端。
裝完之後，你在 Claude Code 裡面打一行斜線指令（slash command），Claude 就會自動把任務拆開丟給 Codex 跟 Gemini 去做，做完回傳差異檔（Patch），Claude 審核通過才寫進你的專案。
重點：外部模型沒有寫入權限。代碼主權從頭到尾在 Claude 手上，不會有哪個 AI 自己亂改你的檔案。
前置要求
動手之前，先確認你手上有這些東西：
| 工具 | 說明 | 狀態 |
|---|---|---|
| Claude Code CLI | 主控端，需要 Claude MAX 訂閱 | 必要 |
| Node.js 20+ | v18 會噴 SyntaxError，別問我怎麼知道的。務必升到 20 以上 | 必要 |
| Codex CLI | ChatGPT Go ($50) 以上訂閱 安裝： npm i -g @openai/codex |
選配 |
| Gemini CLI | Google One AI Ultra 訂閱 安裝： npx https://github.com/nicholasgriffintn/gemini-cli |
選配 |
安裝步驟
六步，照著走就對了。
1. 打開終端機，貼這行
npx ccg-workflow2. 選「初始化工作流」 — 跳出選單，選第一個。
3. 選語言 — 中文或 English，看你習慣。
4. 選命令預設 — 不知道選什麼就選標準。
| 預設 | 命令數 | 適合誰 |
|---|---|---|
| 最小化 | 3 個 | 只要 dev / code / commit，極簡派 |
| 標準（推薦） | 12 個 | 日常開發 + Git 工具，大多數人選這個 |
| 完整 | 17+ 個 | 全功能，含 team 協作，重度使用者 |
5. 配置 MCP（可跳過） — ace-tool MCP 是可選的上下文增強工具。不懂就先跳過，之後再回來設也行。
6. 重啟終端機 — 關掉 Claude Code 再重開。新指令要重啟才會生效，這步忘了就白裝了。
裝完長這樣
~/.claude/
├── commands/ccg/ # 你打的斜線指令放這
├── agents/ccg/ # 子 agent 定義
├── skills/ccg/ # 品質檢查 + 多模型協調邏輯
├── bin/codeagent-wrapper # CLI 包裝器
└── .ccg/
├── config.toml # CCG 主設定檔
└── prompts/
├── codex/ # 6 個 Codex 專家提示詞
└── gemini/ # 7 個 Gemini 專家提示詞/ccg:dev 完整 6 階段怎麼跑、所有指令速查表、實戰範例，還有怎麼真的把 Token 帳單壓下來。
核心指令——記這三個就夠
指令很多，但日常真的在用的就三個。其他的後面再說。
| 指令 | 用途 | 白話翻譯 |
|---|---|---|
/ccg:feat | 新功能開發 | 從零開始蓋一個新功能，自動幫你規劃架構 |
/ccg:dev | 複雜任務 / 重構 | 最完整的 6 階段工作流，大改動用這個 |
/ccg:code | 快速寫 code | 小任務直接上，系統自動判斷要丟給誰 |
日常好用的指令
除了上面三個核心指令，這幾個你遲早會用到：
前端 / 後端專屬指令
有時候你很明確知道這個任務是前端還是後端，不需要系統幫你判斷。直接指定丟給誰，更快。
| 指令 | 什麼時候用 |
|---|---|
/ccg:frontend | 純前端的活，直接丟 Gemini 跑，不經過智能路由 |
/ccg:backend | 純後端的活，直接丟 Codex 跑，一樣不走路由 |
開發輔助
寫 code 之外，分析、除錯、測試、審查這些事 CCG 也包了。
| 指令 | 什麼時候用 |
|---|---|
/ccg:analyze | 分析現有程式碼，搞懂架構跟相依關係 |
/ccg:debug | 抓 bug 用，多模型一起幫你查 |
/ccg:test | 自動生成測試 |
/ccg:review | 程式碼審查，讓 AI 幫你 code review |
/ccg:optimize | 效能優化，找出可以改進的地方 |
/ccg:dev 的 6 階段流程
這是 CCG 最完整的工作流。你打一句 /ccg:dev 實現用戶登入功能，後面六步全自動。拆開來看：
階段 0 — Prompt 增強
你隨便寫一句話，Claude 幫你展開成完整的需求規格。懶人福音。
階段 1 — 代碼檢索
掃你現有的 codebase，找出相關的檔案跟程式碼模式。不會從零開始亂寫，會先看你已經有什麼。
階段 2 — 多模型並行分析
同時把需求丟給 Codex 跟 Gemini 分析，交叉比對兩邊的方案。這步花的是 Codex 跟 Gemini 的額度，不扣你 Claude 的。
階段 3 — 原型生成（智能路由）
前端的東西 → Gemini 生成。後端的邏輯 → Codex 生成。各司其職。外部模型只回傳 Patch，不直接動你的檔案。
階段 4 — 代碼實施
Claude 審核所有 Patch，整合重構，然後才寫入檔案。整個流程只有這步花 Claude Token。
階段 5 — 審計交付
最後來個交叉驗證：Codex 去 review 前端的 code，Gemini 去 review 後端的 code。讓寫前端的去抓後端的漏，反過來也是。互相抓漏，比你自己 review 還狠。
完整指令速查
前面記三個就能活。但如果你想把 CCG 的能力榨乾，這邊是完整的指令表。
開發工作流
| 指令 | 什麼時候用 |
|---|---|
/ccg:dev | 完整 6 階段，大改動、複雜重構用這個 |
/ccg:feat | 從零蓋一個新功能 |
/ccg:code | 小事情直接寫，系統自動路由 |
/ccg:enhance | 先把需求一次講清楚，減少後面來回改 |
Plan + Execute——規劃跟執行拆開
大任務建議先規劃再執行。規劃的時候你可以看計畫書，覺得不對再改，確認了才動手。
| 指令 | 什麼時候用 |
|---|---|
/ccg:plan | 先生成實施計畫，存成 .md 檔給你看 |
/ccg:execute | Claude 照著計畫跑（你可以精細控制） |
/ccg:codex-exec | Codex 全權跑計畫，最省 Token 的做法 |
Team 協作——需要先開實驗功能
這組適合可以拆成三個以上獨立模組的大任務。每步之間用 /clear 清掉上下文，避免 context 爆炸。
| 指令 | 什麼時候用 |
|---|---|
/ccg:team-research | 先做需求研究，產出約束集 |
/ccg:team-plan | 規劃出可並行的零決策計畫 |
/ccg:team-exec | 多個 Builder 同時開工 |
/ccg:team-review | 雙模型交叉審查，互相抓漏 |
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1。沒加的話指令會找不到。
Git 工具
| 指令 | 什麼時候用 |
|---|---|
/ccg:commit | 自動分析你改了什麼 → 幫你寫 commit message → 本地 commit |
/ccg:pr | 自動生成 PR 描述 |
/ccg:rollback | 改壞了想退回去，安全地 rollback |
/ccg:clean-branches | 清掉已合併或廢棄的分支，保持 repo 乾淨 |
/ccg:worktree | Git worktree 管理，同時在多個分支上工作 |
/ccg:commit 只做本地 git commit，不會幫你推到 GitHub。要推上去還是得自己打 git push origin main，要拉下來就 git pull origin main。別 commit 完就以為上線了。
Spec 工作流——規格驅動開發
這組是給比較嚴謹的開發流程用的。先寫規格，再照規格實作，最後對著規格驗收。四個階段一路走下來，適合你要交付給團隊或客戶的正式功能。
| 指令 | 什麼時候用 |
|---|---|
/ccg:spec-init | 初始化規格文件，定義要做什麼 |
/ccg:spec-research | 研究階段，收集技術可行性跟限制條件 |
/ccg:spec-plan | 根據研究結果，規劃具體實施方案 |
/ccg:spec-impl | 按照計畫實作 |
/ccg:spec-review | 對著規格做最終審查，確認沒有遺漏 |
Smart Routing 與專家提示詞系統
CCG 不是隨便把任務丟給外部模型。背後有兩套機制在運作：
智能路由（Smart Routing）
裝完 CCG 之後，~/.claude/.ccg/config.toml 裡面有路由設定：
[routing]
mode = "smart"
[routing.frontend]
models = ["gemini"] # 前端任務丟 Gemini
primary = "gemini"
strategy = "fallback" # Gemini 掛了就 Claude 接手
[routing.backend]
models = ["codex"] # 後端任務丟 Codex
primary = "codex"
strategy = "fallback"
[routing.review]
models = ["gemini", "codex"]
strategy = "parallel" # 審查階段兩個同時跑，交叉比對fallback 策略代表主模型掛了會自動降級，不會卡住。parallel 代表兩個模型同時跑，適合需要交叉驗證的場景。
三套專家提示詞
每個模型都配了一組角色專屬的提示詞，不是用同一套 prompt 打天下：
| 角色 | Claude | Codex | Gemini |
|---|---|---|---|
| Analyzer（分析） | ✓ | ✓ | ✓ |
| Architect（架構） | ✓ | ✓ | ✓ |
| Debugger（除錯） | ✓ | ✓ | ✓ |
| Optimizer（優化） | ✓ | ✓ | ✓ |
| Reviewer（審查） | ✓ | ✓ | ✓ |
| Tester（測試） | ✓ | ✓ | ✓ |
| Frontend（前端） | — | — | ✓ |
Gemini 多了一個 Frontend 專屬角色，因為它主要負責前端生成。這些提示詞放在 ~/.claude/.ccg/prompts/ 底下，你可以自己改。
效能設定
config.toml 裡面有兩個效能開關：
[performance]
liteMode = false # 開啟後跳過部分分析步驟，跑更快
skipImpeccable = false # 開啟後跳過品質檢查，省時間趕時間的時候可以暫時打開，但日常建議關著。品質檢查跳過去，省的是幾十秒，賠的可能是幾小時的 debug。
省 Token 三招
用 CCG 本身就省了，但如果你想再壓更低，這三招學起來：
第一招：/ccg:codex-exec
整個任務讓 Codex 全權跑，Claude 只在最後審一次。後端 API、邏輯計算、Debug 這類任務特別適合。Token 省最多的就是這招。
第二招：每步 /clear
做完一步就清掉上下文，context 不會越滾越大。跑 Team 系列或大型任務的時候一定要養成這個習慣，不然 context 爆了效果會直線下降。
第三招：/ccg:enhance
動工之前先用這個把需求展開講清楚。一開始多花三分鐘描述需求，後面少來回五次修改。划算。
實戰範例：村花弄囍訂單系統
講理論沒感覺，直接拿我自己公司的案子示範。
場景：幫村花弄囍新增一個場地方案比較頁
# 方法一：懶人全自動，一句話搞定
/ccg:dev 新增場地方案比較頁，前端 React 卡片排版支援篩選，後端 Next.js API route 撈資料庫
# 方法二：先規劃再執行（大任務推薦這樣做）
/ccg:plan 新增場地方案比較頁
# → 打開 .claude/plan/venue-compare.md 看一下計畫
# → 覺得沒問題，再讓 Codex 去跑：
/ccg:codex-exec .claude/plan/venue-compare.md
# 方法三：Team 模式（任務夠大、能拆模組的時候用）
/ccg:team-research 場地方案比較頁面
/clear
/ccg:team-plan venue-compare
/clear
/ccg:team-exec
/clear
/ccg:team-review三種方法選哪個？小改動用方法一，中型任務用方法二，大到可以拆三個以上模組的用方法三。不確定就從方法二開始，最穩。
更新與卸載
# 更新到最新版
npx ccg-workflow@latest
# 如果你當初是 npm 全域安裝的
npm install -g ccg-workflow@latest
# 不想用了，卸載
npx ccg-workflow # 選「卸載工作流」就好常見問題
底下這幾個是被問最多的，先看完再動手可以少踩很多坑。
Q：只裝 Claude Code，不裝 Codex 跟 Gemini 能用嗎？
能。系統自動降級，所有任務 Claude 自己扛。只是少了分工的好處，Token 省不到那麼多。
Q：Codex 跟 Gemini 會直接改我的檔案嗎？
不會。外部模型只回傳 Patch（差異檔），Claude 審核通過才寫入。你的程式碼從頭到尾只有 Claude 能動。
Q：Node.js 18 可以嗎？
不行，會噴 SyntaxError。乖乖升到 20 以上。
Q：/ccg:commit 會推到 GitHub 嗎？
不會。它只做本地 git commit，幫你自動生成 commit message。要推上去還是得自己 git push。