okooooooo/ccg-workflow

0 Fork 0

Files

T

li c74c8c927b feat: 新增 MCP 动态选择系统 v1.3.0

## 主要更新

### 1. MCP 动态选择
- ✨ 支持安装时选择 MCP 提供商（ace-tool 或 auggie）
- 🔧 自动生成 ~/.ccg/config.toml 配置文件
- 🔄 命令模板根据配置动态路由 MCP 工具

### 2. 命令模板简化
- 📝 移除外部文档引用（memorys/MCP_USAGE.md）
- 🎯 自包含配置读取说明，减少 50% 提示词长度
- 🔍 统一模式：读取 config → 获取 provider → 调用对应工具

### 3. 配置驱动架构
- 🗂️ 新增 [mcp.tools] 工具名称映射
- 🏷️ 参数名映射（query vs information_request）
- 🚫 优雅处理缺失功能（auggie 无 prompt enhancement）

### 4. 文件更改
- 修改: install.py（新增 MCP 选择逻辑）
- 修改: config.json（operation: install_mcp）
- 修改: 12 个命令模板（dev, enhance, code, analyze, etc.）
- 删除: SLASH_COMMAND_FORMAT.md, UPDATES.md（已合并到文档）
- 更新: CHANGELOG.md, README.md, CLAUDE.md

### 5. 兼容性
- ✅ 向后兼容：默认使用 ace-tool
- ✅ 支持跳过 MCP 安装
- ✅ 配置不存在时使用默认值

Breaking Changes: 无

2026-01-05 19:42:44 +08:00

4.9 KiB

Raw Blame History

description

description
多模型代码生成（智能路由：前端→Gemini，后端→Codex）

/ccg:code - 多模型代码生成

Usage

/ccg:code <功能描述>

Context

功能描述: $ARGUMENTS
智能检测任务类型，自动路由到合适的模型
生成的原型经 Claude 重构为生产级代码

工作流程

注意: 本命令使用 MCP 代码检索工具。请先读取 ~/.ccg/config.toml 确定 MCP 提供商（ace-tool 或 auggie），然后使用对应的工具。

Phase 1: 需求分析

调用代码检索工具:
- 根据 ~/.ccg/config.toml 中 [mcp.tools] code_search_{provider} 调用对应工具
- 参数：project_root_path（项目根目录）, 查询内容为功能需求相关的代码
- 查询参数名使用 query_param_{provider} 的值（"query" 或 "information_request"）
分析检索结果：
- 相关模块和文件结构
- 现有代码模式和风格
- 依赖和接口定义
分析任务类型：
- 前端: UI 组件、样式、用户交互
- 后端: API、业务逻辑、数据库操作
- 全栈: 同时涉及前后端

Phase 2: 智能路由

注意：调用前先读取对应角色提示词文件，将内容注入到 <ROLE> 标签中。

Route A: 前端任务 → Gemini

codeagent-wrapper --backend gemini - $PROJECT_DIR <<'EOF'
<ROLE>
读取 prompts/gemini/frontend.md 的内容并注入
</ROLE>

<TASK>
Implement: <功能描述>

Context:
<相关代码>
<设计系统/组件库信息>
</TASK>

OUTPUT: Unified Diff Patch ONLY.
EOF

Route B: 后端任务 → Codex

codeagent-wrapper --backend codex - $PROJECT_DIR <<'EOF'
<ROLE>
读取 prompts/codex/architect.md 的内容并注入
</ROLE>

<TASK>
Implement: <功能描述>

Context:
<相关代码>
<API 规范/数据模型>
</TASK>

OUTPUT: Unified Diff Patch ONLY.
EOF

Route C: 全栈任务 → 并行生成

同时启动（run_in_background: true）：

Codex: 使用 prompts/codex/architect.md 角色，生成后端 API + 数据层
Gemini: 使用 prompts/gemini/frontend.md 角色，生成前端组件 + UI 交互

定义清晰的接口契约：

API Contract:
- Endpoint: POST /api/xxx
- Request: { field1: string, field2: number }
- Response: { data: T, error?: string }

Phase 3: 原型整合

收集模型输出（使用 TaskOutput）
将 Unified Diff 视为"脏原型"
Claude 重构：
- 统一代码风格
- 确保前后端接口一致
- 优化实现细节
- 移除冗余代码

Phase 4: 代码实施

应用重构后的代码
确保不破坏现有功能
验证编译/类型检查通过

Phase 5: 双模型审查

并行启动审查（run_in_background: true）：

注意：调用前先读取对应角色提示词文件（reviewer），将内容注入到 <ROLE> 标签中。

# Codex 审查
codeagent-wrapper --backend codex - $PROJECT_DIR <<'EOF'
<ROLE>
读取 prompts/codex/reviewer.md 的内容并注入
</ROLE>

<TASK>
Review the implementation for: <功能描述>

Changes:
<实施的代码变更>
</TASK>

OUTPUT: Review comments with specific line references.
EOF

# Gemini 审查
codeagent-wrapper --backend gemini - $PROJECT_DIR <<'EOF'
<ROLE>
读取 prompts/gemini/reviewer.md 的内容并注入
</ROLE>

<TASK>
Review the implementation for: <功能描述>

Changes:
<实施的代码变更>
</TASK>

OUTPUT: Review comments with specific line references.
EOF

Phase 6: 修正与交付

综合双模型审查意见
修正发现的问题
最终交付

输出格式

## 🚀 Code: <功能描述>

### Phase 1: 需求分析
- 任务类型: [前端/后端/全栈]
- 相关文件: <文件列表>
- 现有模式: <识别的模式>

### Phase 2: 代码生成
#### [Codex/Gemini] 原型
<Unified Diff 摘要>

### Phase 3: 整合重构
<重构说明>

### Phase 4: 实施
<变更文件列表>

### Phase 5: 审查
#### Codex 审查
- <审查意见 1>
- <审查意见 2>

#### Gemini 审查
- <审查意见 1>
- <审查意见 2>

### Phase 6: 交付
✅ 实施完成
- 新增文件: X
- 修改文件: Y
- 代码行数: +N / -M

任务类型检测

关键词	类型	路由
component, UI, style, CSS, React, Vue	前端	Gemini
API, endpoint, database, auth, backend	后端	Codex
full-stack, 全栈, 页面+接口	全栈	并行

代码质量标准

前端代码 (Gemini)

TypeScript 类型完整
响应式设计
无障碍属性
加载/错误状态
遵循设计系统

后端代码 (Codex)

输入验证
错误处理
安全检查
查询优化
API 一致性

关键原则

智能路由 - 根据任务自动选择最合适的模型
接口优先 - 全栈任务先定义 API 契约
原型重构 - 外部模型输出需要 Claude 重构
双重审查 - 代码必须经过双模型审查