CCG Workflow：给 AI 编程工具装上「协作大脑」

当一个 AI 模型无法准确理解你的需求时，你会怎么做？大多数人可能会反复修改提示词、切换不同的 AI 助手，甚至在多个窗口里来回切换——这种「人在协调，AI 在单打独斗」的模式，正是 CCG Workflow 试图解决的问题。

CCG Workflow 是一个开源的多模型协作工作流引擎，它让 Claude、Codex（OpenAI）和 Gemini 三款主流 AI 模型像团队成员一样协同工作。开发者只需用自然语言描述任务（例如「帮我重构这个模块，加上单元测试」），CCG 就会自动分析意图、选择最优策略、协调多个模型分工执行。项目在 GitHub 已斩获 5400+ stars，npm 周下载量持续增长，是当前 AI Agent 工作流领域最值得关注的项目之一。

背景：AI 工具碎片化之痛

2024 年以来，AI 编程工具呈现「战国时代」格局：Claude Code 擅长深度推理和架构设计，OpenAI Codex（通过 GitHub Copilot）在代码补全和重复任务上效率惊人，Google Gemini 则在多模态和大上下文窗口上独有优势。然而现实是，大多数开发者每天要同时维护多个工具的 API Key、提示词模板和调用逻辑，这种碎片化极大地抵消了 AI 带来的效率提升。

作者 fengshao1227 在开发 CCG 之前，深陷这一困境。他在多个项目中反复在 Claude 和 Codex 之间手动切换，还要处理上下文丢失、API Key 管理、输出格式不统一等一系列问题。2025 年，他决定把「让多个 AI 模型协同工作」这件事做成一个系统性产品——于是 CCG Workflow 诞生了。

类比：像管理开发团队一样调度 AI 模型

如果说传统 AI 工具是「一个人在干活」，那么 CCG 就是一个有明确分工的虚拟开发团队：

• Claude 扮演「架构师」角色，负责理解需求、制定计划、审查代码质量
• Codex 是「执行者」，专注于快速实现功能、处理重复性编码任务
• Gemini 是「多面手」，处理需要超长上下文或多模态理解的任务

而 CCG 本身是这个团队的「项目经理」，它的核心职责是：根据任务类型动态分配角色、管理团队成员之间的上下文传递、在关键节点进行质量把控。你不需要手动切换窗口或复制粘贴上下文——这一切都自动完成。

核心功能：从 29 个命令到一个入口

ccg:go：一个命令替代 29 个操作

v3.0 是项目最重要的里程碑。作者将原来分散在多个配置文件中的 29 个独立命令，浓缩成了一个统一的入口：ccg:go。开发者只需输入自然语言需求，例如：

/ccg:go 帮我分析这个 RESTful API 的设计缺陷，并给出重构方案

CCG 会自动完成：意图分析 → 选择策略 → 编排 Agent Teams → 执行 → 质量审查。

模型路由器（Model Router）

项目内置了智能模型选择机制。根据任务特征（代码复杂度、上下文长度、需要的多模态能力等），CC 动态决定调用哪个模型。配置通过 templates/engine/model-router.md 模板管理，开发者可以自定义路由规则。

Agent Teams 并行执行

支持多个 Agent 同时处理不同子任务。templates/ 目录下的 agents/ 子目录定义了团队成员的职责描述文件（CLAUDE.md 规范），类似于 Multi-Agent System 中的角色定义。

Hook 机制

templates/hooks/ 目录提供了丰富的钩子实现：

• session-start.js：会话初始化钩子
• skill-router.js：技能路由，动态选择最优执行路径
• workflow-state.js：工作流状态追踪，确保长任务不丢失上下文
• subagent-context.js：子 Agent 上下文管理

规范驱动开发（Spec-Driven）

内置了完整的规范驱动开发流程：

• spec-init.md：初始化规范文档
• spec-plan.md：规划阶段
• spec-research.md：调研阶段
• spec-review.md：代码审查阶段

这让 AI 生成代码时始终围绕明确的规格说明，而不是「写到哪算哪」。

技术架构：TypeScript + Node.js 的轻量级实现

项目主体采用 TypeScript 编写，编译后通过 npm 分发（包名 ccg-workflow），入口文件为 bin/ccg.mjs。核心依赖包括：

依赖库	用途
cac	CLI 参数解析框架
inquirer	交互式命令行界面
i18next	多语言国际化支持（内置中英文）
ora	命令行 loading 动画
ansis	彩色终端输出
fs-extra	文件系统操作增强

整体架构采用模块化插件设计：

• src/commands/：各子命令实现（config-mcp、diagnose-mcp、init、menu、update）
• src/utils/：工具函数（安装器、平台检测、配置管理、迁移脚本）
• templates/：可扩展的模板系统，开发者可自定义 prompt 和策略

值得注意的是，项目完全不使用 Docker，也不需要 GPU 环境——这是一个纯 CLI 工具，最轻量的部署方式是直接通过 npm 全局安装。

上手体验：3 分钟安装，即刻使用

安装步骤极其简单：

npm install -g ccg-workflow
# 或者
pnpm add -g ccg-workflow

前提条件仅有 Node.js >= 18，无需配置任何 API Key（模型调用走各自官方 CLI），也无需 GPU 资源。

首次运行时执行 ccg init 初始化配置向导，按提示连接 Claude Code、Codex 和 Gemini 的调用方式。项目内置了 MCP（Model Context Protocol）集成工具，可以诊断和配置 MCP 服务器连接状态。

项目文档站点（ccg.fengshao1227.com）提供了完整的中英文文档，包括从入门到高级定制的全流程指南。

局限与挑战

1. 非原生 Web UI：没有图形界面，完全依赖命令行操作，对非技术用户存在一定门槛。虽然这也保证了工具的轻量和可脚本化。

2. 模型依赖外部 CLI：项目本身不提供 AI 模型调用，而是依赖于 Claude Code CLI、OpenAI Codex CLI 和 Gemini CLI 的可用性。模型成本和可用性完全取决于各平台。

3. 无 Docker 支持：对于习惯容器化部署的团队，需要自行编写 Dockerfile。

4. 文档站依赖外部服务：文档站点托管在作者个人域名，若项目维护中断，文档可访问性可能受影响。

5. 规范复杂度：内置的规范驱动开发流程虽然专业，但也意味着一定的学习成本——对于简单任务可能显得「杀鸡用牛刀」。

行业意义与趋势

CCG 的出现折射出一个更大的趋势：从「用哪个 AI 模型」到「如何让多个 AI 模型协同」。随着 Agent 技术发展，单一模型的局限性越来越明显，而 Multi-Agent 协作正在成为下一代 AI 应用的主流范式。

项目在 GitHub 的增长曲线值得关注：从 v1.0 到 v3.0 的快速迭代、活跃的 Issue 讨论（尤其是中文社区的积极反馈）、以及 413 次 fork 的社区参与度，都说明这个方向确实击中了开发者的真实痛点。

在更宏观的视角下，CC 代表着 AI 开发工具链的「工作流中间层」趋势——不替代底层模型，而是作为协调层让现有模型能力最大化利用。

---

项目信息

| 项目 | 值 |

|------|---|

| GitHub | fengshao1227/ccg-workflow |

| 语言 | TypeScript/Node.js |

| Stars | 5400+ |

| 协议 | MIT |

| 安装 | npm install -g ccg-workflow |

| 文档 | ccg.fengshao1227.com |