人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeek【免费下载链接】ccg-workflow多模型协作开发系统 - Claude 编排 Codex 后端 Gemini 前端28 个命令覆盖开发全流程一键安装零配置项目地址https://gitcode.com/fengshao1227/ccg-workflow点击查看免费下载本文聚焦 ccg-workflow 多模型协作开发系统中的归档前审查命令/ccg:spec-review——一条以双模型交叉验证为核心的独立代码审查工具。它不依赖其他工作流阶段随时可调用用于在 OpenSpecOPSX提案归档前以后端模型 前端模型并行审查的方式从规范符合性、逻辑正确性、安全性、可维护性、集成风险等维度对提案实现做最终把关。读完本文你将掌握该命令的完整执行流程、双模型并行调用的底层机制基于codeagent-wrapper、JSON 结构化发现格式、严重级别分级与决策门规则以及如何将其与/ccg:spec-impl归档流程衔接。命令定位独立可用的归档前审查工具在 ccg-workflow 的 Spec 系列命令体系中/ccg:spec-review是一个特殊存在它不属于研究 → 规划 → 实现的流水线阶段而是独立工具、随时可用。命令注册表中对其的定位是双模型交叉审查 → Critical 必须修复 → 允许归档见 src/utils/installer-data.ts安装时归类于spec类别、排序号为 34属于 V3 Core commands随核心安装始终可用。在菜单系统中它同样以/ccg:spec-review形式注册见 src/commands/menu.ts。在 templates/commands/spec-init.md 的Standalone Tools清单里/ccg:spec-review被明确标注为唯一一条独立审查工具Code Review:/ccg:spec-review(Independent dual-model review)——也就是说它既可以在 spec-impl 流程的归档步骤之前使用也可以脱离整个流水线、单独对任意一个 OpenSpec 提案的实现进行审查。核心哲学与守则Guardrails命令模板开篇定义了四条核心理念双模型交叉验证能捕获单模型审查遗漏的盲区Dual-model cross-validation catches blind spots single-model review would miss——后端模型擅长规范符合性与逻辑正确性前端模型擅长模式一致性与集成风险两者视角互补。Critical 级别发现必须在继续推进前解决Critical findings SHOULD be addressed before proceeding——审查不是走过场关键问题必须闭环。审查同时验证实现符合规范约束与代码质量两个维度。这是一条独立工具——随时可用不绑定归档工作流。命令守则方面有三条硬性要求强制{{BACKEND_PRIMARY}}后端主模型与{{FRONTEND_PRIMARY}}前端主模型必须都完成审查才能进入结果综合synthesis阶段。审查范围严格限定在提案自身的变更内禁止范围蔓延no scope creep。审查 OpenSpec 提案时须参照openspec/config.yaml了解项目约定。关于占位符{{BACKEND_PRIMARY}}、{{FRONTEND_PRIMARY}}等是模板变量安装时由injectConfigVariables()替换为用户配置值。从源码看后端主模型默认值为codex、前端主模型默认值为antigravity见 src/utils/installer-template.ts实际取值取决于用户安装时的 routing 配置。前置条件OpenSpec 环境与工作目录约定/ccg:spec-review的审查对象是 OpenSpec 提案因此其环境依赖由/ccg:spec-init阶段保障见 templates/commands/spec-init.mdOpenSpec CLI命令名为openspec不是opsx可通过npx fission-ai/openspec --version校验、npm install -g fission-ai/openspeclatest安装Node.js 18.x。项目已初始化openspec/目录.claude/skills/下含openspec-*skills。codeagent-wrapper二进制可用~/.claude/bin/codeagent-wrapper --version。工作目录{{WORKDIR}}的获取有硬性约定必须通过 Bash 执行pwdUnix或cdWindows CMD获取当前工作目录的绝对路径禁止从$HOME或环境变量推断。如果用户通过/add-dir添加了多个工作区应先确定与任务相关的工作区。这一约定同样贯穿 spec-research、spec-plan、spec-impl 全部命令是为了保证多模型子代理在正确的代码库上下文中执行。审查执行全流程8 个步骤详解Step 1选择提案Select Proposal# 列出全部 Active Changes openspec list --json与用户确认要审查的提案 ID 后加载该提案的规范与任务清单openspec status --change proposal_id --json--json输出便于程序化解析提案状态、任务完成度等信息。Step 2收集实现产物Collect Implementation Artifacts识别该提案修改过的所有文件用git diff获取变更摘要从openspec/changes/id/specs/目录加载相关规范约束与 PBTProperty-Based Testing属性。规范约束的快速检索可用rg -n CONSTRAINT:|MUST|INVARIANT: openspec/changes/id/specs/Step 3多模型并行审查Multi-Model ReviewPARALLEL这是整个命令的核心环节约束极其明确关键必须在同一条消息里以两个 Bash 工具调用同时启动{{BACKEND_PRIMARY}}和{{FRONTEND_PRIMARY}}禁止先调用一个模型并等待其完成必须同时以run_in_background: true启动两者。第一个 Bash 调用{{BACKEND_PRIMARY}}后端/逻辑审查标准载荷如下Bash({ command: ~/.claude/bin/codeagent-wrapper --progress --backend {{BACKEND_PRIMARY}} {{GEMINI_MODEL_FLAG}}{{GROK_MODEL_FLAG}}{{KIMI_MODEL_FLAG}}{{OPENCODE_MODEL_FLAG}}- \{{WORKDIR}}\ EOF\nReview proposal proposal_id implementation:\n\n## {{BACKEND_PRIMARY}} Review Dimensions\n1. **Spec Compliance**: Verify ALL constraints from spec are satisfied\n2. **PBT Properties**: Check invariants, idempotency, bounds are correctly implemented\n3. **Logic Correctness**: Edge cases, error handling, algorithm correctness\n4. **Backend Security**: Injection vulnerabilities, auth checks, input validation\n5. **Regression Risk**: Interface compatibility, type safety, breaking changes\n\n## Output Format (JSON)\n{\n \findings\: [\n {\n \severity\: \Critical|Warning|Info\,\n \dimension\: \spec_compliance|pbt|logic|security|regression\,\n \file\: \path/to/file.ts\,\n \line\: 42,\n \description\: \What is wrong\,\n \constraint_violated\: \Constraint ID from spec (if applicable)\,\n \fix_suggestion\: \How to fix\\n }\n ],\n \passed_checks\: [\List of verified constraints/properties\],\n \summary\: \Overall assessment\\n}\nEOF, run_in_background: true, timeout: 300000, description: {{BACKEND_PRIMARY}}: backend/logic review })第二个 Bash 调用{{FRONTEND_PRIMARY}}模式/集成审查必须与第一个在同一消息中发出Bash({ command: ~/.claude/bin/codeagent-wrapper --progress --backend {{FRONTEND_PRIMARY}} {{GEMINI_MODEL_FLAG}}{{GROK_MODEL_FLAG}}{{KIMI_MODEL_FLAG}}{{OPENCODE_MODEL_FLAG}}- \{{WORKDIR}}\ EOF\nReview proposal proposal_id implementation:\n\n## {{FRONTEND_PRIMARY}} Review Dimensions\n1. **Pattern Consistency**: Naming conventions, code style, project patterns\n2. **Maintainability**: Readability, complexity, documentation adequacy\n3. **Integration Risk**: Dependency changes, cross-module impacts\n4. **Frontend Security**: XSS, CSRF, sensitive data exposure\n5. **Spec Alignment**: Implementation matches spec intent (not just letter)\n\n## Output Format (JSON)\n{\n \findings\: [\n {\n \severity\: \Critical|Warning|Info\,\n \dimension\: \patterns|maintainability|integration|security|alignment\,\n \file\: \path/to/file.ts\,\n \line\: 42,\n \description\: \What is wrong\,\n \spec_reference\: \Spec section (if applicable)\,\n \fix_suggestion\: \How to fix\\n }\n ],\n \passed_checks\: [\List of verified aspects\],\n \summary\: \Overall assessment\\n}\nEOF, run_in_background: true, timeout: 300000, description: {{FRONTEND_PRIMARY}}: patterns/integration review })底层执行器codeagent-wrapper上述调用中的codeagent-wrapper是 ccg-workflow 的 Go 编写的跨平台 CLI 包装器源码见 codeagent-wrapper/main.go它通过Backend接口 backendRegistry工厂将 Codex / Gemini / Claude / Grok / Kimi / OpenCode / Antigravity 等 AI CLI 后端统一成一个标准接口详见 codeagent-wrapper/CLAUDE.md。审查调用中用到的参数含义如下Flag作用说明--backend name指定后端模型审查场景下由{{BACKEND_PRIMARY}}/{{FRONTEND_PRIMARY}}模板变量决定--progress向 stderr 输出紧凑进度行便于在长时间审查中观察任务是否存活--gemini-model name指定 Gemini 型号仅 gemini 后端有效由{{GEMINI_MODEL_FLAG}}注入-从 stdin 读取任务文本配合 heredocEOF传递含换行/特殊字符的多行审查载荷{{WORKDIR}}子代理工作目录必须为绝对路径之所以用- heredoc 而非直接传参是因为任务文本包含换行、引号等特殊字符时 wrapper 会自动切换 stdin 模式见 codeagent-wrapper/main.go 的 stdin 传递协议。模板变量在运行时如何展开命令模板中的{{GEMINI_MODEL_FLAG}}{{GROK_MODEL_FLAG}}{{KIMI_MODEL_FLAG}}{{OPENCODE_MODEL_FLAG}}是按行感知的模型标志注入机制line-aware substitution由安装期的 src/utils/installer-template.ts 处理属于 issue #130 的修复方案若前端/后端主模型都不是 gemini则{{GEMINI_MODEL_FLAG}}全局替换为空串该 flag 完全无意义不应输出死参数若某行硬编码了非 gemini 的--backend name如--backend codex则该行上的{{GEMINI_MODEL_FLAG}}被剥离若某行是条件表达式如--backend codex|gemini或硬编码 gemini则保留 flag 并替换为--gemini-model model默认型号gemini-3.1-pro-preview见 src/utils/installer-template.tsGrok、Kimi 同理{{GROK_MODEL_FLAG}}默认--grok-model grok-4.5{{KIMI_MODEL_FLAG}}仅在配置了 kimiModel 且角色用到 kimi 时才输出见 src/utils/installer-template.ts。这一逻辑有完整测试覆盖见 src/utils/tests/injectConfigVariables.test.ts如--backend gemini {{GEMINI_MODEL_FLAG}}- /workdir应保留 flag、--backend codex {{GEMINI_MODEL_FLAG}}应剥离 flag 等用例。等待结果的并行 TaskOutput两个 Bash 调用返回任务 ID 后Step 3.2用两次 TaskOutput 调用同时阻塞等待TaskOutput({ task_id: codex_task_id, block: true, timeout: 600000 }) TaskOutput({ task_id: gemini_task_id, block: true, timeout: 600000 })失败与超时规则硬性红线⛔前端模型失败必须重试若前端模型调用失败最多重试 2 次间隔 5 秒。3 次全败才允许跳过。⛔后端模型结果必须等待后端模型执行 5–15 分钟属正常现象超时后继续轮询禁止跳过。这一规则反映了两模型的职责权重后端审查承载规范符合性与安全性判定是归档决策的关键依据不可缺失前端审查虽重要但极端情况下可降级。Step 4综合发现Synthesize Findings合并两个模型的 findings对重叠问题去重按严重级别分类级别判定标准处理要求Critical规范违反Spec violation、安全漏洞security vulnerability、破坏性变更breaking change必须修复MUST fixWarning模式偏离pattern deviation、可维护性隐患maintainability concern应当修复SHOULD fixInfo轻微改进建议可以修复MAY fix两个模型各自带独立的维度标签后端模型输出spec_compliance|pbt|logic|security|regression前端模型输出patterns|maintainability|integration|security|alignment综合时可据此追溯每条 finding 的来源视角。Step 5呈现审查报告Present Review Report按严重级别分组展示模板如下## Review Report: proposal_id ### Critical (X issues) - MUST FIX - [ ] [SPEC] file.ts:42 - Constraint X violated: description - [ ] [SEC] api.ts:15 - SQL injection vulnerability ### Warning (Y issues) - SHOULD FIX - [ ] [PATTERN] utils.ts:88 - Inconsistent naming convention ### Info (Z issues) - MAY FIX - [ ] [MAINT] helper.ts:20 - Consider extracting to separate function ### Passed Checks - ✅ PBT: Idempotency property verified - ✅ Security: No XSS vulnerabilities found报告格式要点每条 finding 带[维度标签]SPEC / SEC / PATTERN / MAINT 等、文件:行号、问题描述Passed Checks列出已验证通过的约束/属性让通过项与问题项同样可见便于归档时展示完整证据链。Step 6决策门Decision Gate若 Critical 0向用户呈现 findings询问现在修复还是返回/ccg:spec-impl处理Fix now or return to/ccg:spec-implto address?不允许归档。若 Critical 0询问用户所有关键检查已通过是否继续归档All critical checks passed. Proceed to archive?若 Warning 0建议在归档前先处理。决策门是整个命令的价值核心它将审查与归档强制解耦任何未解决的 Critical 问题都会卡住归档动作从流程上杜绝带病合入。Step 7可选内联修复模式Inline Fix Mode若用户选择立即修复 Critical 问题将每个修复任务路由到对应模型后端问题 →{{BACKEND_PRIMARY}}前端问题 →{{FRONTEND_PRIMARY}}以unified diff patch格式应用修复外部模型零写权限只产出补丁实际落盘由编排层完成——这与/ccg:spec-impl中外部模型输出仅作原型参考必须重写为生产级代码的守则一致见 templates/commands/spec-impl.md重新运行受影响的审查维度循环直到 Critical 0。Step 8上下文检查点Context Checkpoint报告当前上下文占用。若接近 80K tokens建议用户运行/clear后继续/ccg:spec-review或/ccg:spec-impl。这是整个 Spec 系列共用的上下文管理惯例spec-research、spec-plan、spec-impl 均以 80K 为阈值提示清理目的是防止长任务中上下文溢出导致审查质量下降。退出标准Exit Criteria审查完成的判据为以下四项全部满足{{BACKEND_PRIMARY}}与{{FRONTEND_PRIMARY}}的审查均已完成所有 findings 已综合并分类零 Critical 问题残留已修复或用户已确认用户决策已被记录归档 / 返回实现 / 推迟。与归档流程的衔接审查通过后归档动作不在本命令内完成而是回到/ccg:spec-impl的 Step 10Archive on Completion执行当tasks.md中全部任务标记为[x]后内部调用/opsx:archive将 spec deltas 合并到openspec/specs/并把 change 移入归档详见 templates/commands/spec-impl.md。这保证了审查通过 → 归档的时序由流程强制约束审查是归档的前置关卡归档是审查通过后的收尾动作。参考命令速查用途命令查看提案状态openspec status --change id --json列出 Active Changesopenspec list --json检查规范约束rg -n CONSTRAINT:\|MUST\|INVARIANT: openspec/changes/id/specs/查看实现 diffgit diff审查后归档通过后/ccg:spec-impl→ Step 10小结/ccg:spec-review通过同一消息双 Bash 并行 结构化 JSON 输出 严重级别决策门三件套把双模型交叉审查变成了可重复、可判定、可追溯的工程环节后端模型兜底规范符合性、逻辑正确性与安全漏洞前端模型兜底模式一致性、可维护性与集成风险任何 Critical 发现都必须在归档前闭环。结合codeagent-wrapper的统一后端抽象与模板变量注入机制{{BACKEND_PRIMARY}}/{{FRONTEND_PRIMARY}}/ 各类模型 flag它可以在用户配置的任何模型组合下开箱即用——这也是它与 ccg-workflow 中其他 27 条命令共享的多模型协作底座详见 src/CLAUDE.md 的模板变量系统说明与 codeagent-wrapper/CLAUDE.md 的 wrapper 文档。赞分享人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeek【免费下载链接】ccg-workflow多模型协作开发系统 - Claude 编排 Codex 后端 Gemini 前端28 个命令覆盖开发全流程一键安装零配置项目地址https://gitcode.com/fengshao1227/ccg-workflow点击查看免费下载相关推荐Create React App Kitchensink E2E 测试套件实战指南从 Docker 运行到编写 env/syntax/webpack 测试Create React App Kitchensink E2E 测试套件实战指南从 Docker 运行到编写 env/syntax/webpack 测试 C人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeekccg-workflow 后端专项工作流/backend 命令的六阶段多模型协作实战指南ccg workflow 后端专项工作流/backend 命令的六阶段多模型协作实战指南 ccg workflow 是一套以 Claude 为编排中枢、Cod人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeekRyujinx 模拟器教程免费在电脑上玩 Switch 游戏的完整上手指南Ryujinx 模拟器教程免费在电脑上玩 Switch 游戏的完整上手指南 Ryujinx 是一个用 C 编写的开源任天堂 Switch 模拟器目前由活跃的人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeek上一篇FIESTA快速增量欧几里得距离场 - 无人机实时运动规划的终极解决方案下一篇image库性能基准测试与其他语言图像库对比分析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考