多模型协作（Multi-Model Collaboration）

概述

多模型协作是一套利用多个 AI 模型（Codex、Gemini、Claude）各自优势进行分工协作的高级工作流体系。通过智能路由（前端任务交给 Gemini、后端任务交给 Codex、Claude 负责编排和最终执行），实现从规划到实施再到审计的全流程多模型协同，同时严格保证"代码主权"——所有文件修改仅由 Claude 执行。

---|-------|--------| | 分析 | ~/.claude/.ccg/prompts/codex/analyzer.md | ~/.claude/.ccg/prompts/gemini/analyzer.md | | 规划 | ~/.claude/.ccg/prompts/codex/architect.md | ~/.claude/.ccg/prompts/gemini/architect.md |

会话复用（Session Reuse）：每次调用返回 SESSION_ID: xxx，必须保存以供后续 /ccg:execute 使用。

等待后台任务（最大超时 600000ms = 10 分钟）：

TaskOutput({ task_id: "<task_id>", block: true, timeout: 600000 })

重要提示：

• 必须指定 timeout: 600000，否则默认 30 秒会导致过早超时
• 10 分钟后仍未完成，继续用 TaskOutput 轮询，绝不终止进程
• 如因超时跳过等待，必须使用 AskUserQuestion 询问用户是否继续等待或终止任务

执行工作流

阶段 1：完整上下文检索

[模式：研究]

1.1 提示词增强（必须首先执行）

必须调用 mcp__ace-tool__enhance_prompt 工具：

mcp__ace-tool__enhance_prompt({
  prompt: "$ARGUMENTS",
  conversation_history: "<最近 5-10 轮对话>",
  project_root_path: "$PWD"
})

等待增强后的提示词，用增强结果替换原始 $ARGUMENTS 用于所有后续阶段。

1.2 上下文检索

调用 mcp__ace-tool__search_context 工具：

mcp__ace-tool__search_context({
  query: "<基于增强需求的语义查询>",
  project_root_path: "$PWD"
})

• 使用自然语言构建语义查询（Where/What/How）
• 绝不基于假设回答
• 如 MCP 不可用：退化为使用 Glob + Grep 进行文件发现和关键符号定位

1.3 完整性检查

• 必须获取相关类、函数、变量的完整定义和签名
• 上下文不足时触发递归检索
• 优先输出：入口文件 + 行号 + 关键符号名；仅在需要消除歧义时添加最少代码片段

1.4 需求对齐

• 如需求仍有歧义，必须向用户输出引导性问题
• 直到需求边界清晰（无遗漏、无冗余）

阶段 2：多模型协作分析

[模式：分析]

2.1 分发输入

并行调用 Codex 和 Gemini（run_in_background: true）：

将原始需求（不含预设观点）分发给两个模型：

1. Codex 后端分析：

   • ROLE_FILE：~/.claude/.ccg/prompts/codex/analyzer.md
   • 聚焦：技术可行性、架构影响、性能考量、潜在风险
   • 输出：多角度解决方案 + 优劣分析

2. Gemini 前端分析：

   • ROLE_FILE：~/.claude/.ccg/prompts/gemini/analyzer.md
   • 聚焦：UI/UX 影响、用户体验、视觉设计
   • 输出：多角度解决方案 + 优劣分析

使用 TaskOutput 等待两个模型的完整结果。保存 SESSION_ID（CODEX_SESSION 和 GEMINI_SESSION）。

2.2 交叉验证

整合视角并迭代优化：

1. 识别共识（强信号）
2. 识别分歧（需要权衡）
3. 互补优势：后端逻辑遵循 Codex，前端设计遵循 Gemini
4. 逻辑推理：消除方案中的逻辑缺口

2.3（可选但推荐）双模型计划草案

为降低 Claude 综合计划时的遗漏风险，可并行让两个模型输出"计划草案"（仍然不允许修改文件）：

1. Codex 计划草案（后端权威）：

   • ROLE_FILE：~/.claude/.ccg/prompts/codex/architect.md
   • 输出：分步计划 + 伪代码（聚焦：数据流/边界情况/错误处理/测试策略）

2. Gemini 计划草案（前端权威）：

   • ROLE_FILE：~/.claude/.ccg/prompts/gemini/architect.md
   • 输出：分步计划 + 伪代码（聚焦：信息架构/交互/可访问性/视觉一致性）

使用 TaskOutput 等待两个模型的完整结果，记录其建议中的关键差异。

2.4 生成实施计划（Claude 最终版）

综合两方分析，生成分步实施计划：

## 实施计划：<任务名称>

### 任务类型
- [ ] 前端（-> Gemini）
- [ ] 后端（-> Codex）
- [ ] 全栈（-> 并行）

### 技术方案
<综合 Codex + Gemini 分析得出的最优方案>

### 实施步骤
1. <步骤 1> - 预期交付物
2. <步骤 2> - 预期交付物
...

### 关键文件
| 文件 | 操作 | 描述 |
|------|------|------|
| path/to/file.ts:L10-L50 | 修改 | 描述 |

### 风险与缓解
| 风险 | 缓解措施 |
|------|----------|

### SESSION_ID（供 /ccg:execute 使用）
- CODEX_SESSION: <session_id>
- GEMINI_SESSION: <session_id>

阶段 2 结束：计划交付（非执行）

/ccg:plan 职责到此结束，必须执行以下操作：

1. 向用户展示完整实施计划（包含伪代码）

2. 将计划保存到 .claude/plan/<feature-name>.md

3. 以粗体文本输出提示（必须使用实际保存的文件路径）：

   ---

   计划已生成并保存到 .claude/plan/actual-feature-name.md

   请审查上述计划。您可以：

   • 修改计划：告诉我需要调整的内容，我会更新计划
   • 执行计划：将以下命令复制到新会话中

   /ccg:execute .claude/plan/actual-feature-name.md
   

   ---

4. 立即终止当前响应（到此为止。不再有工具调用。）

绝对禁止：

• 询问用户 "Y/N" 后自动执行（执行是 /ccg:execute 的职责）
• 对生产代码的任何写操作
• 自动调用 /ccg:execute 或任何实施操作
• 在用户未明确请求修改时继续触发模型调用

计划保存

• 首次规划：.claude/plan/<feature-name>.md
• 迭代版本：.claude/plan/<feature-name>-v2.md、.claude/plan/<feature-name>-v3.md...

计划修改流程

如果用户请求修改计划：

1. 根据用户反馈调整计划内容
2. 更新 .claude/plan/<feature-name>.md 文件
3. 重新展示修改后的计划
4. 再次提示用户审查或执行

第二部分：多模型协作执行（/ccg:execute）

核心协议

• 语言协议：与工具/模型交互时使用英语，与用户交流时使用用户的语言
• 代码主权：外部模型拥有零文件系统写权限，所有修改由 Claude 执行
• 脏原型重构（Dirty Prototype Refactoring）：将 Codex/Gemini 的 Unified Diff 视为"脏原型"，必须重构为生产级代码
• 止损机制：当前阶段输出未经验证前，不得进入下一阶段
• 前置条件：仅在用户明确回复 "Y" 确认 /ccg:plan 输出后执行（如缺失，必须先确认）

执行工作流

阶段 0：读取计划

[模式：准备]

1. 识别输入类型：计划文件路径或直接任务描述

2. 读取计划内容：解析并提取任务类型、实施步骤、关键文件、SESSION_ID

3. 执行前确认：确保用户已批准计划

4. 任务类型路由：

   任务类型	检测依据	路由
   前端	页面、组件、UI、样式、布局	Gemini
   后端	API、接口、数据库、逻辑、算法	Codex
   全栈	同时包含前端和后端	Codex 与 Gemini 并行

阶段 1：快速上下文检索

[模式：检索]

必须使用 MCP 工具进行快速上下文检索，不要逐个手动读取文件

基于计划中的"关键文件"列表，调用 mcp__ace-tool__search_context：

• 从计划的"关键文件"表中提取目标路径
• 构建覆盖入口文件、依赖模块、相关类型定义的语义查询
• 结果不足时追加 1-2 次递归检索

阶段 3：原型获取

[模式：原型]

按任务类型路由：

路线 A：前端/UI/样式 -> Gemini

• 调用 Gemini（使用 ~/.claude/.ccg/prompts/gemini/frontend.md）
• 输入：计划内容 + 检索到的上下文 + 目标文件
• 输出：仅 Unified Diff 补丁。严禁任何实际修改。
• Gemini 是前端设计权威，其 CSS/React/Vue 原型是最终的视觉基线
• 警告：忽略 Gemini 的后端逻辑建议

路线 B：后端/逻辑/算法 -> Codex

• 调用 Codex（使用 ~/.claude/.ccg/prompts/codex/architect.md）
• 输入：计划内容 + 检索到的上下文 + 目标文件
• 输出：仅 Unified Diff 补丁。严禁任何实际修改。
• Codex 是后端逻辑权威，利用其逻辑推理和调试能力

路线 C：全栈 -> 并行调用

• 并行调用（run_in_background: true）：
  • Gemini：处理前端部分
  • Codex：处理后端部分
• 使用 TaskOutput 等待两个模型的完整结果

阶段 4：代码实施

[模式：实施]

Claude 作为代码主权者执行以下步骤：

1. 读取 Diff：解析 Codex/Gemini 返回的 Unified Diff 补丁
2. 心智沙盒（Mental Sandbox）：
   • 模拟将 Diff 应用到目标文件
   • 检查逻辑一致性
   • 识别潜在冲突或副作用
3. 重构与清理：
   • 将"脏原型"重构为高可读性、可维护、企业级代码
   • 移除冗余代码
   • 确保符合项目现有代码标准
   • 除非必要，不生成注释/文档，代码应自解释
4. 最小范围：
   • 变更仅限需求范围
   • 强制审查副作用
   • 进行精准修正
5. 应用变更：
   • 使用 Edit/Write 工具执行实际修改
   • 仅修改必要代码，绝不影响用户其他现有功能
6. 自我验证（强烈推荐）：
   • 运行项目现有的 lint / typecheck / tests（优先最小相关范围）
   • 如失败：先修复回归，再进入阶段 5

阶段 5：审计与交付

[模式：审计]

5.1 自动审计

变更生效后，必须立即并行调用 Codex 和 Gemini 进行代码评审（Code Review）：

1. Codex 评审（run_in_background: true）：

   • ROLE_FILE：~/.claude/.ccg/prompts/codex/reviewer.md
   • 输入：变更 Diff + 目标文件
   • 聚焦：安全、性能、错误处理、逻辑正确性

2. Gemini 评审（run_in_background: true）：

   • ROLE_FILE：~/.claude/.ccg/prompts/gemini/reviewer.md
   • 输入：变更 Diff + 目标文件
   • 聚焦：可访问性（Accessibility）、设计一致性、用户体验

5.2 整合与修复

1. 综合 Codex + Gemini 评审反馈
2. 按信任规则权衡：后端遵循 Codex，前端遵循 Gemini
3. 执行必要修复
4. 必要时重复阶段 5.1（直到风险可接受）

5.3 交付确认

审计通过后，向用户报告：

## 执行完成

### 变更摘要
| 文件 | 操作 | 描述 |
|------|------|------|
| path/to/file.ts | 修改 | 描述 |

### 审计结果
- Codex：<通过/发现 N 个问题>
- Gemini：<通过/发现 N 个问题>

### 建议
1. [ ] <建议的测试步骤>
2. [ ] <建议的验证步骤>

第三部分：多模型协作工作流（/ccg:workflow）

概述

完整的六阶段结构化开发工作流，带质量门禁（Quality Gates）和多模型协作：

研究 -> 构思 -> 规划 -> 执行 -> 优化 -> 评审

用法

/workflow <任务描述>

角色定义

你是编排者（Orchestrator），协调多模型协作系统。面向资深开发者，沟通简洁专业。

协作模型：

• ace-tool MCP — 代码检索 + 提示词增强
• Codex — 后端逻辑、算法、调试（后端权威，可信赖）
• Gemini — 前端 UI/UX、视觉设计（前端专家，后端意见仅供参考）
• Claude（自身） — 编排、规划、执行、交付

六阶段工作流

阶段 1：研究与分析

[模式：研究] — 理解需求和收集上下文：

1. 提示词增强：调用 mcp__ace-tool__enhance_prompt
2. 上下文检索：调用 mcp__ace-tool__search_context
3. 需求完整性评分（0-10）：
   • 目标清晰度（0-3）、预期结果（0-3）、范围边界（0-2）、约束条件（0-2）

   • = 7：继续 | < 7：停止，提出澄清问题

阶段 2：方案构思

[模式：构思] — 多模型并行分析：

并行调用（run_in_background: true）：

• Codex：使用 analyzer 提示词，输出技术可行性、方案、风险
• Gemini：使用 analyzer 提示词，输出 UI 可行性、方案、UX 评估

保存 SESSION_ID（CODEX_SESSION 和 GEMINI_SESSION）。

综合两方分析，输出方案对比（至少 2 个选项），等待用户选择。

阶段 3：详细规划

[模式：规划] — 多模型协作规划：

并行调用（使用 resume <SESSION_ID> 复用会话）：

• Codex：使用 architect 提示词，输出后端架构
• Gemini：使用 architect 提示词，输出前端架构

Claude 综合：采纳 Codex 后端方案 + Gemini 前端方案，用户批准后保存到 .claude/plan/task-name.md。

阶段 4：实施

[模式：执行] — 代码开发：

• 严格遵循已批准的计划
• 遵循现有项目代码标准
• 在关键里程碑请求反馈

阶段 5：代码优化

[模式：优化] — 多模型并行评审：

并行调用：

• Codex：使用 reviewer 提示词，聚焦安全、性能、错误处理
• Gemini：使用 reviewer 提示词，聚焦可访问性、设计一致性

整合评审反馈，用户确认后执行优化。

阶段 6：质量评审

[模式：评审] — 最终评估：

• 对照计划检查完成情况
• 运行测试验证功能
• 报告问题和建议
• 请求用户最终确认

关键规则

1. 阶段顺序不可跳过（除非用户明确指示）
2. 外部模型拥有零文件系统写权限，所有修改由 Claude 执行
3. 评分 < 7 或用户不批准时强制停止

第四部分：后端专项工作流（/ccg:backend）

概述

以 Codex 为主导的后端专项开发工作流，适用于：API 设计、算法实现、数据库优化、业务逻辑。

用法

/backend <后端任务描述>

角色定义

你是后端编排者（Backend Orchestrator），协调多模型协作处理服务端任务。

协作模型：

• Codex — 后端逻辑、算法（后端权威，可信赖）
• Gemini — 前端视角（后端意见仅供参考）
• Claude（自身） — 编排、规划、执行、交付

核心工作流

1. 阶段 0：提示词增强（可选）— 如 ace-tool MCP 可用，增强需求描述
2. 阶段 1：研究 — 理解需求，检索现有 API、数据模型、服务架构
3. 阶段 2：构思 — 必须调用 Codex 进行技术可行性分析，保存 CODEX_SESSION
4. 阶段 3：规划 — 必须调用 Codex（复用会话），输出文件结构、函数/类设计、依赖关系
5. 阶段 4：实施 — 严格遵循计划，确保错误处理、安全、性能优化
6. 阶段 5：优化 — 必须调用 Codex 进行代码评审，聚焦安全、性能、错误处理、API 合规
7. 阶段 6：质量评审 — 最终评估，运行测试验证

关键规则

1. Codex 后端意见可信赖
2. Gemini 后端意见仅供参考
3. 外部模型拥有零文件系统写权限
4. Claude 处理所有代码写入和文件操作

第五部分：前端专项工作流（/ccg:frontend）

概述

以 Gemini 为主导的前端专项开发工作流，适用于：组件设计、响应式布局、UI 动画、样式优化。

用法

/frontend <UI 任务描述>

角色定义

你是前端编排者（Frontend Orchestrator），协调多模型协作处理 UI/UX 任务。

协作模型：

• Gemini — 前端 UI/UX（前端权威，可信赖）
• Codex — 后端视角（前端意见仅供参考）
• Claude（自身） — 编排、规划、执行、交付

核心工作流

1. 阶段 0：提示词增强（可选）— 如 ace-tool MCP 可用，增强需求描述
2. 阶段 1：研究 — 理解需求，检索现有组件、样式、设计系统
3. 阶段 2：构思 — 必须调用 Gemini 进行 UI 可行性分析，保存 GEMINI_SESSION
4. 阶段 3：规划 — 必须调用 Gemini（复用会话），输出组件结构、UI 流程、样式方案
5. 阶段 4：实施 — 严格遵循计划，遵循现有设计系统和代码标准，确保响应式和可访问性
6. 阶段 5：优化 — 必须调用 Gemini 进行代码评审，聚焦可访问性、响应式、性能、设计一致性
7. 阶段 6：质量评审 — 最终评估，验证响应式和可访问性

关键规则

1. Gemini 前端意见可信赖
2. Codex 前端意见仅供参考
3. 外部模型拥有零文件系统写权限
4. Claude 处理所有代码写入和文件操作

总结：多模型信任规则

核心原则：代码主权归 Claude，前端信 Gemini，后端信 Codex。