人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeek【免费下载链接】ccg-workflow多模型协作开发系统 - Claude 编排 Codex 后端 Gemini 前端28 个命令覆盖开发全流程一键安装零配置项目地址https://gitcode.com/fengshao1227/ccg-workflow点击查看免费下载本文档对应仓库 templates/engine/strategies/guided-develop.md是 CCG Workflow 引擎在中等复杂度M 级功能开发场景下的核心执行策略。它以「Claude 编排 外部模型分析/实施」为主线定义了需求增强 → 上下文检索 → 双模型分析 → 计划审批 → 实施 → 迭代审查的完整状态机并强制在计划阶段设置 HARD STOP 让用户掌控执行模式。读完本文你将掌握 Guided Develop 策略的完整阶段流转、双模型并行调用模板、Ralph Loop 迭代审查协议与 Spec Evolution 经验归档机制并能直接依据仓库中的真实命令与配置投入实战。一、策略定位它解决什么问题Guided Develop引导式开发是 CCG Workflow 引擎在策略选择矩阵中专门承接feature 类 M 级复杂度任务的执行策略。根据 templates/commands/go.md 中的决策矩阵/ccg:go智能入口在完成意图分析、复杂度评估、风险评估后按下表选择策略类型 \ 复杂度SML / XLbug-fixdirect-fixdebug-investigatedebug-investigatefeaturequick-implementguided-developfull-collaboraterefactordirect-fixrefactor-safelyrefactor-safelyresearchdeep-researchdeep-researchdeep-researchoptimizeoptimize-measureoptimize-measureoptimize-measurereviewreview-auditreview-auditreview-auditgitgit-actiongit-actiongit-action也就是说当用户描述的是一个「新增/开发/实现」类功能复杂度评估为 M2-5 个文件、单模块内、路径明确风险为 low 或 medium 时引擎自动加载 Guided Develop 策略。同时比它轻量的 quick-implement.mdS 级在遇到「涉及 3 文件或需要架构决策」「涉及认证/数据库等高风险领域」时也会升级到此策略而 Guided Develop 自身在执行中发现「涉及 5 文件或需要跨模块协调」「架构级变更」「外部模型分析发现重大风险」时则升级到更重的 full-collaborate.md完整多模型协作。适用条件速览复杂度 M2-5 个文件单模块需要一定规划但不需要完整的多模型协作风险 low 或 medium这一档位设计使它成为整个 CCG 引擎中使用频率最高的「中间档」策略——比 quick-implement 多了一层规划与双模型分析又比 full-collaborate 少了多模型构思、评分门槛等重型环节。二、工作流状态机六阶段流转与 Gate 控制Guided Develop 定义了 6 个阶段的显式状态机每个阶段通过[phase-state:N]块声明「当前阶段 Gate 下一步动作」并在阶段完成后通过 workflow-state Hook 注入ccg-state面包屑实现状态追踪详见 templates/hooks/workflow-state.js阶段名称Gate 条件Next 动作1需求增强—需求结构化后进入上下文检索2上下文检索需求已增强 ✓上下文收集完毕后判断是否需要外部模型分析3领域分析可选外部模型上下文已收集 ✓分析完成后进入规划阶段4规划分析已完成 ✓用户确认计划后进入实施5实施用户已确认计划 ✓HARD STOP实施完成后进入验证6验证实施已完成 ✓验证通过后报告结果这套状态机与 templates/engine/phase-guide.md 中定义的通用阶段规范呼应每完成一个阶段回顾对应的[phase-state:N]块确认 Gate 条件已满足输出 Next: [具体动作]告知用户下一步任何标记为[required]的阶段不可跳过。状态机背后有 Hook 的自动追踪支撑workflow-state.js在每一轮用户消息时读取.ccg/tasks/{task-name}/task.json将Task / Strategy / Phase / Gate / Next注入面包屑trackTurn维护最近 10 轮滚动缓冲连续 3 轮phase nextAction完全相同即判定死循环触发⚠️ LOOP DETECTED警告并提示执行 Break-Loop Protocol见 phase-guide.md §9。这也是为什么策略文件要求每阶段都同步更新task.json——它是整个状态追踪与循环检测的数据源。三、Phase 1-2需求增强与上下文检索Phase 1: 需求增强 [required]分析用户的$ARGUMENTS即/ccg:go或直接加载策略时传入的自然语言描述补全为四要素结构化需求目标要实现什么约束不能改什么、需要兼容什么范围哪些文件/模块会受影响验收标准怎样算完成增强后的需求必须展示给用户确认或调整——这是需求对齐的第一次用户交互点。Phase 2: 上下文检索 [required]按固定顺序收集项目上下文用 MCP 搜索工具搜索相关代码CCG 模板中的{{MCP_SEARCH_TOOL}}占位符安装时由installer-template.ts替换为实际 provider支持 ace-tool / contextweaver / fast-context配置为skip时降级为 Glob Grep读取目标模块的核心文件识别依赖关系和可能的影响范围了解现有的测试覆盖情况四、Phase 3: 双模型并行分析——多模型协作的核心价值这是 Guided Develop 与 quick-implement 最本质的区别。M 复杂度必须调用双模型{{FRONTEND_PRIMARY}}{{BACKEND_PRIMARY}}并行分析不可只调一个不可跳过。两个模型从不同角度分析同一个问题交叉验证弥补单模型盲区——这是多模型协作的核心价值。CHANGELOG.md 记录了该阶段的历史演进早期版本曾允许「可选单模型」后改为强制双模型并行以对齐纯 Claude 模式与 Codex 模式的统一规则「M 双模型都必须调用」。4.1 模型选择与模板变量{{FRONTEND_PRIMARY}}和{{BACKEND_PRIMARY}}是模板变量安装时由src/utils/installer-template.ts的injectConfigVariables()替换为用户配置templates/CLAUDE.md 中有完整占位符表占位符默认值说明{{FRONTEND_PRIMARY}}gemini前端主模型可配置为codex/claude/grok/kimi/opencode/antigravity{{BACKEND_PRIMARY}}codex后端主模型可选同上{{GEMINI_MODEL_FLAG}}--gemini-model gemini-3.1-pro-preview使用 gemini 时传给 wrapper否则为空字符串{{LITE_MODE_FLAG}}轻量模式时为--lite模型路由细节由 templates/engine/model-router.md 定义从~/.claude/.ccg/config.toml的[routing]区块读取frontend.primary/backend.primary以及geminiModel、grokModel、kimiModel、opencodeModel等型号配置。分析/研究阶段按任务领域选择后端/架构/安全用 backend 模型 $BACKEND/analyzer.md前端/UI 用 frontend 模型 $FRONTEND/analyzer.md全栈则双模型并行。注意若frontend.primary和backend.primary都是claude则项目运行在纯 Claude Code 模式——不调用 codeagent-wrapper改用 Agent Teams 子代理完成各阶段model-router.md §1bGuided Develop 中所有--backend调用模板均不适用。4.2 并行调用模板原文命令完整保留执行步骤确定工作目录WORKDIR$(pwd)并行调用双模型run_in_background: true两个同时启动Backend 模型Bash({ command: ~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--progress --backend {{BACKEND_PRIMARY}} {{GEMINI_MODEL_FLAG}}{{GROK_MODEL_FLAG}}{{KIMI_MODEL_FLAG}}{{OPENCODE_MODEL_FLAG}}- \$WORKDIR\ CODEAGENT_EOF\nROLE_FILE: ~/.claude/.ccg/prompts/{{BACKEND_PRIMARY}}/analyzer.md\nTASK\n需求{增强后的需求}\n上下文{Phase 2 收集的项目上下文、相关代码摘要}\n/TASK\nOUTPUT: 技术分析报告可行性、架构建议、风险评估、实施方案对比\nCODEAGENT_EOF, run_in_background: true, timeout: 3600000, description: Backend 模型分析 })Frontend 模型必须同时启动不是如果是全栈才调Bash({ command: ~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--progress --backend {{FRONTEND_PRIMARY}} {{GEMINI_MODEL_FLAG}}{{GROK_MODEL_FLAG}}{{KIMI_MODEL_FLAG}}{{OPENCODE_MODEL_FLAG}}- \$WORKDIR\ CODEAGENT_EOF\nROLE_FILE: ~/.claude/.ccg/prompts/{{FRONTEND_PRIMARY}}/analyzer.md\nTASK\n需求{增强后的需求}\n上下文{Phase 2 收集的项目上下文}\n/TASK\nOUTPUT: 从不同视角的分析报告可行性、设计建议、风险评估\nCODEAGENT_EOF, run_in_background: true, timeout: 3600000, description: Frontend 模型分析 })等待结果必须等不可跳过TaskOutput({ task_id: id, block: true, timeout: 600000 })综合模型分析结果提取关键建议用于 Phase 4 规划同时更新 Task 状态currentPhase → 3-analysis、nextAction → 等待模型分析返回。4.3 调用背后的底层实现上述命令调用的codeagent-wrapper是仓库 codeagent-wrapper/ 中描述的 Go 编写的跨平台 CLI 包装器它将 7 种 AI CLI 后端Codex / Gemini / Claude / Grok / Kimi / OpenCode / Antigravity统一成一个标准接口通过Backend接口backend.go的Name() / Command() / BuildArgs()三方法backendRegistry工厂config.go选择后端任务文本含换行/特殊字符或超长800 字符时自动切换 stdin 模式main.go--progress向 stderr 输出紧凑进度行--lite关闭 Web UI 加快响应后端执行完成后返回SESSION_ID后续可用resume session_id复用会话model-router.md §5重试规则frontend 模型失败重试最多 2 次间隔 5sbackend 模型运行中可能需 5-15 分钟保持轮询永不终止3 次全败降级为单模型模式并告知用户五、Phase 4: 规划——HARD STOP 前的关键产出5.1 实施计划格式撰写实施计划输出格式如下原文完整保留 实施计划 ## 需求 [增强后的需求摘要] ## 方案 [选定方案及理由] ## 步骤 1. [文件路径] — [具体变更] 2. [文件路径] — [具体变更] ... ## 影响范围 - 修改: [文件列表] - 新增: [文件列表]如有 - 测试: [需要更新/新增的测试]将计划持久化到.ccg/tasks/{task-name}/plan.md。5.2 Task 状态更新更新 .ccg/tasks/{task-name}/task.json: currentPhase → 4-plan gate → user_approval_required nextAction → 等待用户审批计划5.3 ⛔ HARD STOP —— 计划审批 执行模式选择这是本策略最关键的强制交互点不可跳过、不可默认选择。必须原样输出以下内容并等待用户回复⛔计划审批 执行模式选择请审批以上计划并选择谁来写代码Claude 自己写— 精细控制逐步实施外部模型写{{BACKEND_PRIMARY}}— 更快、省 Claude 额度Claude 监控审查请回复 1 或 2或直接点名模型如用codex/用grok/用kimi — 点名时用该模型替换默认 backend。在用户回复之前你不可以执行任何文件写入操作。违反 流程失控。用户确认后更新task.json: gate → null, currentPhase → 5-implement。这一 HARD STOP 与 templates/commands/go.md 铁律第 7 条完全一致「写代码前必须让用户选择执行模式——必须明确向用户展示选项并等待回复不可默认选择任何模式」。CHANGELOG.md 显示该设计历经演进早期硬编码模型名--backend codex/--backend gemini后替换为{{BACKEND_PRIMARY}}/{{FRONTEND_PRIMARY}}模板变量并支持用户点名覆盖用grok/用codex。六、Phase 5: 实施——两种执行模式与并行分解模式 A: Claude 自己写用户选 [1]严格按计划执行遵循项目现有代码规范每完成一个主要步骤简要报告进度遇到计划外的问题时告知用户不自行扩大范围模式 B: 外部模型实施用户选 [2]Claude 作为编排者调用外部模型写代码。默认用{{BACKEND_PRIMARY}}用户点名其他模型codex / grok / kimi / antigravity则将--backend和 ROLE_FILE 路径替换为该模型。Step 1: 从 plan.md 按文件归属拆分子任务Layer 1— 无依赖的任务底层模块model/util/storeLayer 2— 依赖 Layer 1 的任务上层route/middleware/component每个子任务标注文件范围、实施步骤、验证命令Step 2: 生成并行任务配置调用 codeagent-wrapper--parallel模式Bash({ command: ~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--progress --parallel --backend {{BACKEND_PRIMARY}} {{GEMINI_MODEL_FLAG}}{{GROK_MODEL_FLAG}}{{KIMI_MODEL_FLAG}}{{OPENCODE_MODEL_FLAG}}- \$WORKDIR\ PARALLEL_EOF\n---TASK---\nid: layer1-{name1}\nworkdir: $WORKDIR\n---CONTENT---\nROLE_FILE: ~/.claude/.ccg/prompts/{{BACKEND_PRIMARY}}/builder.md\nTASK\n## 文件范围⛔ 只改这些文件\n{file1, file2}\n\n## 实施步骤\n{steps from plan.md}\n/TASK\n---TASK---\nid: layer1-{name2}\nworkdir: $WORKDIR\n---CONTENT---\nROLE_FILE: ~/.claude/.ccg/prompts/{{BACKEND_PRIMARY}}/builder.md\nTASK\n## 文件范围\n{file3, file4}\n\n## 实施步骤\n{steps}\n/TASK\n---TASK---\nid: layer2-{name3}\nworkdir: $WORKDIR\ndependencies: layer1-{name1},layer1-{name2}\n---CONTENT---\nROLE_FILE: ~/.claude/.ccg/prompts/{{BACKEND_PRIMARY}}/builder.md\nTASK\n## 文件范围\n{file5}\n\n## 实施步骤\n{steps}\n/TASK\nPARALLEL_EOF, run_in_background: true, timeout: 3600000, description: Parallel Builder: {task count} 个子任务 })也可以用 Codex 原生 spawn 模式如果项目.codex/已配置 multi_agent_v2发送编排指令让 Codex 读 AGENTS.md 的 §5 Parallel Spawn 模式由 Codex 自行 spawn ccg-implement 子代理并行写。Step 3: 等待完成读取汇总报告wrapper 自动合并所有子任务结果。Step 4: Claude 审查git diff确认变更在 plan 范围内小问题 Claude 直接修复大问题再调外部模型或切换模式 A降级外部模型失败/超时 → 切换到模式 A。Task 更新currentPhase → 5-implement、nextAction → 按计划执行实施。这里的--parallel模式底层由 wrapper 的并行任务配置格式config.go支撑---TASK---块声明id / workdir / backend / dependenciesexecutor.go的topologicalSort()实现依赖拓扑排序——同层无依赖任务并行、跨层串行每个任务独立 session 互不干扰codeagent-wrapper/CLAUDE.md。七、Phase 6: 迭代审查 [Ralph Loop]——审查不是一次性动作Phase 6 采用 phase-guide.md §10 定义的Ralph Loop 迭代审查协议每轮 spawn 全新 Agent干净上下文读取磁盘最新状态重新验证循环自修复最多 3 轮变更 30 行时触发。Round N 流程⛔ 双模型交叉审查每轮 spawn 新调用干净上下文并行调用双模型run_in_background: true使用 templates/engine/model-router.md 模板backend 模型 reviewer 角色 — 安全、性能、错误处理frontend 模型 reviewer 角色 — 设计一致性如涉及前端综合审查意见⛔ 质量关卡必须逐个调用 Skill不可跳过3. 调用 Skillverify-quality— 等待报告 4. 调用 Skillverify-security— 等待报告涉及 auth/input/crypto 时 5. 调用 Skillverify-change— 等待报告这三个质量关卡 Skill 均有仓库实体。例如 templates/skills/tools/verify-quality/SKILL.md 定义圈复杂度 ≤10、函数长度 ≤50 行、文件长度 ≤500 行、参数 ≤5 个、嵌套深度 ≤4、行长度 ≤120 等指标以及重复代码、过长参数列表、魔法数字、死代码、注释代码等异味检测通过node scripts/quality_checker.js 扫描路径运行verify-security 在涉及认证/输入/加密时强制调用verify-change 在变更 30 行时分析文档同步状态。用户决定⛔ 必须等待有 Critical →发现 N 个 Critical 问题。修复后再审一轮[Y/n]无 Critical →审查通过。需要再审一轮[y/N]用户选择继续 → 修复 Critical 后回到 Round N1用户选择停止 → 退出审查循环追加进度到.ccg/tasks/{task-name}/fix-log.jsonl每轮一行 JSON格式见 phase-guide.md §10{round: 1, critical: 2, warning: 5, fixed: [file1:issue, file2:issue], ts: ISO}Ralph Loop 的关键规则phase-guide.md §10每轮审查必须新 Agent不复用上一轮上下文以避免上下文污染越修越烂fix-dev 也是新 Agent从磁盘读取最新代码状态超过 3 轮说明问题根深应回退到规划阶段用户始终有决定权不自动循环。结果输出检查是否满足验收标准输出结果✅ 开发完成 变更: [N] 文件[M] 行 实现: [摘要] 测试: [通过/跳过/失败情况] 审查: [N] 轮[Critical: N, Warning: N, Info: N] Next: 可以用 /ccg:commit 提交Spec Evolution归档前必须执行参考 templates/engine/phase-guide.md §8 Spec Evolution Protocol 执行分析本次git diff 审查结果提炼可复用的编码约定如有值得记录的经验 → 草拟 Spec 条目展示给用户确认后追加到.ccg/spec/{domain}/index.md后端 →backend/index.md前端 →frontend/index.md跨模块 →guides/index.md无值得提炼的经验 → 跳过不强行凑条目Spec 条目质量标准具体引用真实文件路径和 API 签名、说明 Why、可验证拒绝空泛条目。Task 更新status → archived随后归档任务mkdir -p .ccg/tasks/archive/$(date %Y-%m) mv .ccg/tasks/{task-name} .ccg/tasks/archive/$(date %Y-%m)/ git add .ccg/tasks/ git commit -m chore: archive ccg task八、升级规则执行中发现复杂度超出当前策略能力时按 phase-guide.md §4 的策略升级规则处理明确告知用户「当前策略为 guided-develop但发现 [原因]建议升级到 full-collaborate」等待用户确认后Read目标策略并从其 Phase 1 开始已完成的分析工作可复用。只能升级不能降级除非用户明确要求。Guided Develop 的升级触发条件发现涉及 5 文件或需要跨模块协调 → 升级到full-collaborate发现涉及架构级变更 → 升级到full-collaborate外部模型分析发现重大风险 → 升级到full-collaborate九、铁律MUST NOTPhase 4 计划必须用户确认— HARD STOP不可自动跳过外部模型仅提供建议— Claude 执行所有文件修改不扩大范围— 只做计划内的变更计划外的报告但不自行处理增量实施— 多文件变更时逐文件执行便于追踪这些铁律与 phase-guide.md 的错误恢复表配套使用外部模型调用失败按模型路由器重试规则处理测试失败分析原因修复后重跑用户要求中止立即停止并报告已完成工作意外文件冲突报告冲突等待用户决策。十、实战要点与适用边界综合来看使用 Guided Develop 时有几个关键实践建议从/ccg:go进入用户只需描述自然语言需求引擎自动完成意图分类与复杂度评估并加载本策略go.md中 M 复杂度且非 git-action 的任务会先创建.ccg/tasks/{task-name}/目录与task.json含strategy / currentPhase / nextAction / gate / branch字段再加载策略——没有task.json就没有 Hook 面包屑注入等于丢失状态追踪。双模型分析不可省略M 复杂度强制双模型并行这不是可选项即使任务看起来简单[required]标记的阶段也不可跳过go.md 铁律第 5 条。HARD STOP 是流程安全的锚点Phase 4 的计划审批 执行模式选择是用户控制权的核心表达跳过它即流程失控。审查闭环完整执行Ralph Loop 的双模型交叉审查 verify-quality / verify-security / verify-change 三个质量关卡 用户决定权构成完整闭环fix-log.jsonl 与 review 记录保证过程可追溯。边界清晰S 级简单任务走 quick-implement 更轻量L/XL 级复杂任务应直接或升级到 full-collaborate其差异在于多模型构思、需求评分 ≥7 门槛、Agent Teams 并行等重型机制。相关资源索引策略本体templates/engine/strategies/guided-develop.md相邻策略templates/engine/strategies/quick-implement.mdS 级入口、templates/engine/strategies/full-collaborate.mdL/XL 级阶段通用规范templates/engine/phase-guide.mdGate Check、Ralph Loop、Spec Evolution、Loop Detection模型路由templates/engine/model-router.md智能入口与决策矩阵templates/commands/go.md执行载体codeagent-wrapper/CLAUDE.mdGo CLI wrapper 与并行模式状态追踪 Hooktemplates/hooks/workflow-state.js质量关卡templates/skills/tools/verify-quality/SKILL.md赞分享人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeek【免费下载链接】ccg-workflow多模型协作开发系统 - Claude 编排 Codex 后端 Gemini 前端28 个命令覆盖开发全流程一键安装零配置项目地址https://gitcode.com/fengshao1227/ccg-workflow点击查看免费下载相关推荐ECC 多模型协作开发工作流/multi-workflowCodex Gemini Claude 六阶段编排实战指南ECC 多模型协作开发工作流/multi workflowCodex Gemini Claude 六阶段编排实战指南 本文以 docs/ja JP人工智能AI 技能AI 插件AI 评测Agent 评测MCP Clients开发工具Front-End-Checklist 无障碍规则精讲ARIA 复合组件必含子角色aria-required-childrenFront End Checklist 无障碍规则精讲ARIA 复合组件必含子角色aria required children 本指南以 Front En人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeekCANN Runtime 新增 aclrt 接口开发全流程从需求澄清到代码检视的六阶段实践指南CANN Runtime 新增 aclrt 接口开发全流程从需求澄清到代码检视的六阶段实践指南 本文是面向 CANN Runtime 开发者的接口开发实战指南CANNAscend人工智能性能剖析系统编程上一篇Eralchemy vs 传统ER图工具为什么开发者更爱这款开源神器下一篇ComfyUI 使用教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考