多模型协作的理念在很多项目中都有提及，但真正能够落地实施的却不多。难点从来不是简单地把 Claude、Codex、Gemini 这几个模型摆在一起，而是需要明确三件事：谁来编排任务，谁来负责编写，以及出了问题谁来兜底。 如果这三个角色没有厘清，所谓的多模型协作最终往往会退化成开发者手动在不同模型间来回切换的繁琐操作。
开源项目 fengshao1227/ccg-workflow 正是为了系统性地解决这一问题而生。
它的设计思路非常直接：由 Claude 负责总体的编排与协调，Codex 专攻后端开发任务，Gemini 则专注于前端开发。 表面上它像一个智能的模型路由器，但深入研究其 README、CLAUDE.md 和更新日志后你会发现，它正在向一个“完整的开发系统”演进：涵盖了命令体系、补丁审核、安全隔离、OPSX 规范、智能体团队以及技能注册表等模块。
项目概览
- 项目名称：CCG Workflow
- GitHub 地址：https://github.com/fengshao1227/ccg-workflow
- 发展状态：当前版本已迭代至
2.1.11，近期持续更新了模型路由配置、技能注册表、智能体团队、MCP（模型上下文协议）以及安装体验，开发活跃度很高。
- 核心价值：如果你已经不满足于仅用 Claude 单个模型“一把梭”，而是希望根据不同模型的强项进行分工与协作，那么 CCG 是目前中文开源社区中一套非常成体系的解决方案。
核心理念：分工与编排，而非简单并列
CCG 项目 README 中的架构图清晰地阐释了其核心思路：
- Claude Code：作为总调度员
- Codex：负责后端任务
- Gemini：负责前端任务
- 最终输出：统一的代码补丁
这背后蕴含着一个关键的产品判断。许多人理解的多模型协作，仍然是“哪个模型不行就换另一个”。但 CCG 并非如此，它的目标是将模型能力与任务类型进行强绑定：前端类任务默认路由给 Gemini，后端类任务默认交给 Codex，再由 Claude 统一负责任务编排、代码审查和最终的应用落地。这样做的好处在于，开发者无需在每次任务开始时都重新做一次“模型选择题”。
安全边界的协作，而非无保护的切换
个人认为，CCG 最值得关注的地方不在于它集成了多少模型，而在于它为这套协作系统引入了安全边界。
其 README 明确写道：外部模型（Codex、Gemini）不具备直接写入代码库的权限，它们只返回修改建议（patch），必须经过 Claude 的审核后才能被应用。
这一点至关重要。因为多模型协作最容易出现问题的环节，往往不是模型之间意见相左，而是多个智能体直接对代码库进行读写操作，导致相互覆盖和污染。CCG 的做法相当于将 Codex 和 Gemini 放置在“只读”的工作环境中：它们负责分析问题、生成补丁、提出修改建议；而真正将代码写回仓库的关键一步，必须通过 Claude 这一层的把关。
这种结构更像是一种“审稿制”，而非“多人同时在线编辑同一份文档”，极大地提升了协作的可靠性和代码质量。这种对流程和安全性的思考，正是现代 AIGC 应用走向工程化所必需的。
工作流如何运转？
CCG 已经构建了一套相当完整的命令体系。README 中列举了超过 29 个斜杠命令，而从更新日志和 CLAUDE.md 文件来看，其功能仍在持续扩展。如果抓取主线，其核心工作流大致可以分为四个层次。
1. 日常开发层：plan / execute / feat / frontend / backend
这是最直观、最易用的一层。
/ccg:plan：启动多模型协同规划任务。/ccg:execute：执行多模型协同开发。/ccg:feat：进行智能功能特性开发。/ccg:frontend：开启前端开发快车道。/ccg:backend：开启后端开发快车道。
这一层的重点不在于命令数量多，而在于它已经按照职责将常见的开发任务入口进行了清晰的拆分。开发者无需每次都从自由对话开始，可以直接根据任务类型，将指令“路由”到最擅长的模型。
2. 规范驱动层：用 OPSX 将模糊需求转化为明确约束
很明显，CCG 的野心不止于做一个路由外壳。它引入了 OPSX 规范，直接提供了一套 /ccg:spec-* 工作流：
/ccg:spec-init/ccg:spec-research/ccg:spec-plan/ccg:spec-impl/ccg:spec-review
README 对这层的解释非常精准：将模糊的需求转化为可验证的约束，从而减少 AI 的即兴发挥。这实际上是在填补 AI 编程中最常见的坑：看似理解了需求，实则缺乏边界约束；计划写得满满当当，关键决策点却未能锁定。CCG 借助 OPSX 所做的，正是将“AI 是否会过度发挥”这个问题在流程前端就予以解决。
3. 智能体团队层：从小队并行，而非简单对话
从 v1.7.60 版本开始，CCG 便着手开发 Team 系列命令，后来进一步整合为统一的 /ccg:team 工作流。它现在的方向很明确：不再是让 Codex 和 Gemini 各说一句话那么简单，而是让 Claude Code 作为核心 Agent，组建包含多个“建造者”队友的团队进行并行工作。
一旦这一层架构成立，CCG 的定位就与普通的提示词套件截然不同了。它不再仅仅是“帮你更好地调用模型”，而是在尝试将多模型、多智能体、文件状态和流程阶段融合成一个工程化的系统。
4. 技能注册表层：将能力扩展化为可安装资产
CCG 在 2.0.0 版本之后引入了一个非常有意思的概念：技能注册表。
简而言之，就是利用 SKILL.md 文件的前置元数据自动生成命令，使得新技能的添加不再依赖于手工编写命令、提示词和模板。这次加入的不是一两个小功能，而是成体系的能力包，例如：领域知识库、Impeccable 工具集、Scrapling、Override-Refusal、输出风格包等。你能清晰地感受到，作者已经不满足于“仅仅维护一套命令模板”，而是希望将 CCG 打造成一个可扩展的开发工作台。
项目的核心吸引力何在？
CCG 真正吸引人的地方，并非“Claude + Codex + Gemini”这个明星阵容，而是它试图回答一个非常现实的问题：如果不同的 AI 模型真的各有所长，我们如何才能将这种差异性转化为稳定的、自动化的流程，而不是成为手工切换的负担？
它给出的答案框架大致如下：
- 用 Claude 担任总控，确保流程不偏离主线。
- 用 Codex / Gemini 进行专长分工，避免优势浪费。
- 用补丁审核和“只读”权限隔离，防止协作演变为生产事故。
- 用规范、团队、技能和 MCP 等模块，将系统从“能够使用”推向“能够长期、稳定地使用”。
这条技术路线是成立的，至少比“直接多开几个模型聊天窗口”要先进和系统得多。
一些保留意见与思考
当然，任何系统都有其权衡。对于 CCG，我有以下几点考量：
- 系统复杂性在快速增加：命令、技能、输出风格、MCP、团队、OPSX、注册表等模块都在不断叠加。对于重度用户而言这是强大的能力，但对于新用户来说，这也意味着不小的学习成本。
- 路由策略的局限性：模型路由听起来很合理，但现实开发任务并非总是严格的前后端分离。很多功能特性是前后端高度耦合的，过于固定的路由策略需要谨慎处理，避免将问题“切坏”。
- 依赖与环境成本：系统功能越强大，其依赖的组件也越多，例如 Claude Code、Codex CLI、Gemini CLI、jq、MCP 工具链等。所谓的“一键安装零配置”，更像是将复杂度封装进了安装程序，而非复杂度本身消失了。
然而，这些保留意见并不会让人低估这个项目的价值。因为 CCG 至少没有停留在“想法很棒”的层面，它已经把多模型协作中最难的部分——路由决策、安全边界、状态管理、命令入口——做成了可以安装、可以运行、并且能够持续迭代更新的具体实现。
总结
如果你只是偶尔想让 AI 帮你补充几行代码，CCG 可能会显得有些“重”。
但如果你已经开始认真思考：Claude 擅长编排，Codex 擅长后端，Gemini 擅长前端，那么我该如何将这套分工理论真正转化为高效、可靠的工作流？那么这个 开源 仓库就非常值得深入研究。
它并非简单地将三个模型并列放置，而是尝试将三种不同的 AI 能力“熔铸”成一条完整的开发流水线。对于希望探索 AI 编程边界，并将其应用于实际工程实践的开发者而言，CCG Workflow 提供了一个颇具前瞻性和实践价值的范本。如果你想持续追踪这类能将前沿 AI 能力工程化的开源项目，不妨关注像云栈社区这样的技术论坛，那里常有深度的一手分析和实践分享。
发表于 3 天前
|
查看: 17|
回复: 0
