尧图网站建设 
人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeek【免费下载链接】ccg-workflow多模型协作开发系统 - Claude 编排 Codex 后端 Gemini 前端28 个命令覆盖开发全流程一键安装零配置项目地址https://gitcode.com/fengshao1227/ccg-workflow点击查看免费下载导读本文围绕 ccg-workflow 仓库中的 templates/commands-legacy/team-review.md 展开系统讲解 Agent Teams 模式下双模型交叉审查的完整执行流程如何并行调用后端/前端两个外部模型对team-exec的产出进行分级审查、如何综合去重、如何通过 Critical 门禁决策放行或修复。读完本文你将掌握 ccg-workflow 中/ccg:team-review的完整运行机制、codeagent-wrapper的底层调用协议、Critical/Warning/Info 三级发现的分级标准与输出格式以及审查阶段允许 Lead 直接修复代码的边界规则。一、定位审查阶段在多模型协作流水线中的位置1.1 前置阶段计划与执行在 ccg-workflow 的 Agent Teams 工作流中team-review不是孤立命令它承接上游两个阶段规划阶段templates/commands-legacy/team-plan.mdLead 同时调用{{BACKEND_PRIMARY}}后端权威与{{FRONTEND_PRIMARY}}前端权威做并行分析产出零决策并行实施计划写入.claude/team-plan/任务名.md每个子任务的文件范围强制隔离。执行阶段templates/commands-legacy/team-exec.md读取计划文件后通过TeamCreate创建团队并行 spawn 多个 Builder teammatesSonnet实施编码Lead 只协调不写码。team-review正是这两个阶段的质量收口——审查范围严格限于 team-exec 产生的变更不扩大到整个代码库。1.2 统一工作流中的 Phase 6在 8 阶段企业级统一工作流 templates/commands-legacy/team.md 中审查对应Phase 6: REVIEW{{BACKEND_PRIMARY}} ∥ {{FRONTEND_PRIMARY}}并行审查 Reviewer teammate 综合判决随后进入 Phase 7最多 2 轮 Critical 修复循环与 Phase 8集成验证。team-review.md描述的即这一阶段在独立命令形态下的完整执行规范。1.3 核心哲学原文档开篇即明确三条原则是整个审查流程的设计基石双模型交叉验证捕获单模型审查遗漏的盲区。Critical 问题必须修复后才能结束。审查范围严格限于 team-exec 的变更不扩大范围。见 templates/commands-legacy/team-review.md二、Guardrails审查阶段的硬性约束team-review.md定义了三道不可逾越的护栏原文档 L10-L13约束说明违反后果双模型必须都完成{{BACKEND_PRIMARY}}与{{FRONTEND_PRIMARY}}都必须完成审查后才能综合禁止只等一个模型综合结论不完整丢失单一视角盲区范围不蔓延审查范围限于git diff的变更不做范围蔓延引入与本次变更无关的噪音稀释审查焦点Lead 可修复 Critical审查阶段允许写代码——Lead 可直接修复 Critical 问题若禁止则修复路径被阻塞门禁无法收敛第三点与 team-exec 阶段Lead 绝不直接修改产品代码形成鲜明对比见 templates/commands-legacy/team-exec.md实施阶段 Lead 是纯协调者审查阶段 Lead 被明确授权动手修 Critical。这是流程设计上有意为之的角色切换也是审查阶段区别于执行阶段的标志性特征。三、Step 1收集变更产物审查的第一步是建立审查基准原文档给出三个动作L16-L19运行git diff获取变更摘要——这是审查范围的唯一事实来源读取.claude/team-plan/下的计划文件——提取约束和成功判据作为审查基准即按计划验收列出所有被修改的文件——形成待审文件清单。这一步对应统一工作流 Phase 6 的起点templates/commands-legacy/team.mdLead 先Bash: git diff获取完整变更内容再决定如何分发给两个外部模型。计划文件之所以重要是因为 team-plan 阶段产出的每个子任务都带有验收标准见 templates/commands-legacy/team-plan.md审查不仅要看代码对不对还要看是否兑现了计划的验收承诺。四、Step 2多模型并行审查PARALLEL这是team-review.md的技术核心也是全仓库多模型协作范式的标准样板。4.1 硬性要求CRITICAL两条 Bash 调用必须在同一条消息中同时发起即真正的并行而非先后串行工作目录{{WORKDIR}}必须通过 Bash 执行pwdUnix或cdWindows CMD获取当前工作目录的绝对路径禁止从$HOME或环境变量推断。工作目录约束在多处重复出现team-plan.md、templates/commands-legacy/workflow.md原因是路径推断错误会导致外部模型在错误目录下审查产生系统性误报。4.2 两条并行调用后端与前端视角分工第一条 Bash 调用{{BACKEND_PRIMARY}} 后端审查原文档 L25-L33Bash({ 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}}\ EOF\nROLE_FILE: ~/.claude/.ccg/prompts/{{BACKEND_PRIMARY}}/reviewer.md\nTASK\n审查以下变更\ngit diff 输出或变更文件列表\n/TASK\nOUTPUT (JSON):\n{\n \findings\: [\n {\n \severity\: \Critical|Warning|Info\,\n \dimension\: \logic|security|performance|error_handling\,\n \file\: \path/to/file\,\n \line\: 42,\n \description\: \问题描述\,\n \fix_suggestion\: \修复建议\\n }\n ],\n \passed_checks\: [\已验证的检查项\],\n \summary\: \总体评估\\n}\nEOF, run_in_background: true, timeout: 3600000, description: {{BACKEND_PRIMARY}} 后端审查 })第二条 Bash 调用{{FRONTEND_PRIMARY}} 前端审查——必须与第一条在同一条消息中原文档 L35-L42Bash({ 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}}\ EOF\nROLE_FILE: ~/.claude/.ccg/prompts/{{FRONTEND_PRIMARY}}/reviewer.md\nTASK\n审查以下变更\ngit diff 输出或变更文件列表\n/TASK\nOUTPUT (JSON):\n{\n \findings\: [\n {\n \severity\: \Critical|Warning|Info\,\n \dimension\: \patterns|maintainability|accessibility|ux|frontend_security\,\n \file\: \path/to/file\,\n \line\: 42,\n \description\: \问题描述\,\n \fix_suggestion\: \修复建议\\n }\n ],\n \passed_checks\: [\已验证的检查项\],\n \summary\: \总体评估\\n}\nEOF, run_in_background: true, timeout: 3600000, description: {{FRONTEND_PRIMARY}} 前端审查 })两条调用的审查维度刻意错开这是双模型交叉验证能捕获盲区的关键模型审查维度关注点{{BACKEND_PRIMARY}}logic、security、performance、error_handling逻辑错误、安全漏洞、性能瓶颈、错误处理{{FRONTEND_PRIMARY}}patterns、maintainability、accessibility、ux、frontend_security模式一致性、可维护性、可访问性、UX、前端安全后端模型不审 UX、前端模型不审 SQL 注入——各自聚焦专业领域再由 Lead 综合去重这正是文档所谓双模型交叉验证捕获单模型审查遗漏的盲区的落地形态。4.3 底层调用链codeagent-wrapper两条调用都指向~/.claude/bin/codeagent-wrapper这是 ccg-workflow 的跨平台 Go CLI 包装器见 codeagent-wrapper/CLAUDE.md。其关键机制后端抽象通过Backend接口backend.go统一 Codex / Gemini / Claude / Grok / Kimi / OpenCode / Antigravity 七种 AI CLI 后端selectBackend()工厂负责路由stdin 模式命令中的-表示从 stdin 读取任务文本当任务包含换行、反斜杠、引号、反引号、$等特殊字符或长度超过 800 字符时自动切换main.go--progress向 stderr 输出紧凑进度行{{LITE_MODE_FLAG}}对应--lite精简模式关闭 Web UI 加快响应可通过CODEAGENT_LITE_MODEtrue环境变量开启main.go{{GEMINI_MODEL_FLAG}}等占位符由安装器按用户配置注入用于指定 Gemini/Grok/Kimi/OpenCode 的型号ROLE_FILE~/.claude/.ccg/prompts/backend/reviewer.md即该后端专属的审查角色提示词安装时由安装器生成到用户目录。4.4 等待结果与失败重试策略两条调用启动后用TaskOutput阻塞等待原文档 L45-L49TaskOutput({ task_id: codex_task_id, block: true, timeout: 600000 }) TaskOutput({ task_id: gemini_task_id, block: true, timeout: 600000 })两条铁律原文档 L51-L52⛔前端模型失败必须重试调用失败非零退出码或输出含错误信息最多重试 2 次、间隔 5 秒3 次全败才允许跳过前端审查用单模型结果继续。⛔后端模型结果必须等待后端模型执行 5-15 分钟属于正常TaskOutput超时后必须继续轮询禁止跳过。已启动的后端任务被跳过 浪费 token 丢失结果。这与 templates/commands-legacy/workflow.md 中多模型调用规范的全局约定一致timeout: 60000010 分钟必须显式指定否则默认 30 秒会提前超时10 分钟后未完成继续轮询绝对不要 Kill 进程。若必须中断等待需用AskUserQuestion询问用户禁止直接 Kill Task。4.5 退出码参考审查调用结束后可通过退出码判断结果见 codeagent-wrapper/CLAUDE.md码含义0成功1通用错误参数缺失、无输出124超时127后端命令不在 PATH130用户中断CtrlC其他后端进程退出码透传五、Step 3综合发现与分级两个模型的 JSON 结果返回后进入综合阶段原文档 L54-L60合并两个模型的发现去重重叠问题——多源指出同一问题时保留最详细的描述按严重性分级级别定义处置Critical安全漏洞、逻辑错误、数据丢失风险必须修复Warning模式偏离、可维护性问题建议修复Info小改进建议可选修复分级标准与 Reviewer teammate 角色定义完全一致templates/commands/agents/team-reviewer.mdCritical 覆盖安全漏洞、逻辑错误、数据丢失风险、构建失败并阻塞发布Warning 覆盖模式偏离、性能隐患、可维护性问题但不阻塞Info 为风格建议与微优化。此外综合时若多源意见矛盾以代码事实为准team-reviewer.md。六、Step 4输出审查报告原文档给出了可直接套用的 Markdown 报告模板L62-L79## 审查报告 ### Critical (X issues) - 必须修复 - [ ] [安全] file.ts:42 - 描述 - [ ] [逻辑] api.ts:15 - 描述 ### Warning (Y issues) - 建议修复 - [ ] [模式] utils.ts:88 - 描述 ### Info (Z issues) - 可选 - [ ] [维护] helper.ts:20 - 描述 ### ✅ 已通过检查 - ✅ 无 XSS 漏洞 - ✅ 错误处理完整报告规范要点每个 finding 必须指向具体的文件和行号且必须包含可操作的修复建议事实依据 可操作两条硬性约束同样出现在 team-reviewer.md 中。6.1 Reviewer 角色的扩展报告格式在统一工作流中输出报告的职责由Reviewer teammate承担templates/commands/agents/team-reviewer.md。其报告在分级清单之外增加了审查范围头部与判决尾部并标注每个 finding 的来源自身 / Codex / Gemini# 代码审查报告 ## 审查范围 - **变更文件数**: N - **变更行数**: X / -Y - **审查来源**: 自身审查 Codex 后端审查 Gemini 前端审查 ## Critical (N issues) — 必须修复 ### [C-1] [安全] SQL 注入风险 - **文件**: src/api/users.ts:42 - **描述**: 用户输入直接拼接 SQL 查询 - **来源**: 自身 Codex - **修复建议**: 使用参数化查询 db.query(SELECT * FROM users WHERE id $1, [userId]) ## ✅ 已通过检查 - ✅ 无硬编码密钥 - ✅ 错误处理完整 ## 判决 - **Critical**: N → [BLOCKED / PASS] - **总体**: ❌ 需要修复 Critical 后重审 / ✅ 审查通过Reviewer 的独立审查覆盖 5 个维度正确性逻辑错误、off-by-one、null/undefined 处理、类型安全、安全性注入、XSS、CSRF、硬编码密钥、权限绕过、路径遍历、性能N1 查询、不必要重渲染、内存泄漏、阻塞操作、模式一致性项目规范、命名、目录结构、API 风格、可维护性复杂度、重复代码、耦合度、文档team-reviewer.md。6.2 后端/前端角色提示词的审查清单两个外部模型的审查行为由各自的 reviewer 角色提示词约束Codex 后端审查templates/prompts/codex/reviewer.md安全输入校验、SQL/命令注入、硬编码密钥、鉴权、日志脱敏、代码质量错误处理、去重、命名、单一职责、性能N1、索引、缓存、可靠性竞态、边界情况、优雅恢复、幂等。同时要求零文件系统写权限只读沙箱——外部模型对文件系统零写入所有修改由 Claude/Lead 执行。Gemini 前端审查templates/prompts/gemini/reviewer.md可访问性语义 HTML、ARIA、键盘导航、焦点管理、颜色对比、设计一致性design tokens、无硬编码颜色/尺寸、间距排版一致、代码质量TS 类型、Props 接口、可复用组件、性能重渲染、memoization、懒加载、响应式移动/平板/桌面。同样要求零写权限。两个角色提示词还要求.context感知若项目存在.context/目录需读取prefs/coding-style.md作为审查标准、读取workflow.md验证开发流程是否被完整遵循并对照history/commits.jsonl检查当前变更是否与既往架构决策冲突codex/reviewer.md、gemini/reviewer.md。七、Step 5决策门Decision Gate分级完成后进入门禁决策原文档 L81-L88分支一Critical 0展示发现用AskUserQuestion询问用户立即修复 / 跳过选择修复 →Lead 直接修复审查阶段允许写代码后端问题参考{{BACKEND_PRIMARY}}建议前端问题参考{{FRONTEND_PRIMARY}}建议修复后重新运行受影响的审查维度重复循环直到 Critical 0。分支二Critical 0报告通过建议提交代码。在统一工作流中该循环被形式化为Phase 7 修复循环Evaluator-Optimizer Loop最多 2 轮按 finding 归属文件分配给对应 Dev teammate多 finding 同文件则合并为一个修复任务每轮修复后由 Lead 运行测试轻量验证templates/commands-legacy/team.md。2 轮后仍有 Critical 则用AskUserQuestion报告让用户选择继续手动修复或跳过提交。八、Step 6上下文检查点与退出标准8.1 上下文检查点报告当前上下文使用量原文档 L90-L91。这条约定贯穿整个工作流team-plan 阶段也要求如果接近 80K建议/clear后运行/ccg:team-execteam-plan.md。原因是 Agent Teams 工作流要连续承载规划、执行、审查多个长阶段上下文管理直接决定流程能否走完。8.2 Exit Criteria退出标准审查阶段必须全部满足以下条件才可宣告完成原文档 L93-L97{{BACKEND_PRIMARY}}{{FRONTEND_PRIMARY}}审查完成所有发现已综合分级Critical 0已修复或用户确认跳过审查报告已输出这四项退出标准与统一工作流 Phase 6/7/8 的衔接完全对应审查完成后进入集成验证全量测试 lint typecheckteam.md最终报告写入.claude/team-plan/任务名-report.md。九、从源码看审查机制的工程保障9.1 模板是可执行规范team-review.md是带 CCG 标记的指令模板!-- CCG:TEAM:REVIEW:START --至!-- CCG:TEAM:REVIEW:END --由安装器渲染后注入用户的 Claude 配置。其中的{{BACKEND_PRIMARY}}、{{FRONTEND_PRIMARY}}、{{WORKDIR}}、{{LITE_MODE_FLAG}}等占位符在安装时被替换为用户的真实后端选择与工作目录。{{GEMINI_MODEL_FLAG}}、{{GROK_MODEL_FLAG}}、{{KIMI_MODEL_FLAG}}、{{OPENCODE_MODEL_FLAG}}的存在说明前端权威模型并不固定为 Gemini而是一个可配置的多选占位——审查的第二只眼睛可以是 Gemini/Grok/Kimi/OpenCode 中的任意一个或多选组合。9.2 wrapper 的并行与等待保障codeagent-wrapper对长任务审查有专门设计见 codeagent-wrapper/CLAUDE.md非--lite模式下启动本地 HTTP 服务通过 SSE 实时推送后端输出到浏览器方便观察 5-15 分钟的长审查任务进度--lite则跳过该机制以换取速度。审查任务通常以run_in_background: true启动配合TaskOutput轮询这与 wrapper 的并发执行引擎executor.go和默认 7200 秒超时main.go匹配。9.3 测试保障仓库为 wrapper 提供了覆盖完善的测试矩阵codeagent-wrapper/CLAUDE.md与审查链路直接相关的包括parser_token_too_long_test.go超长 JSON 行处理、parser_unknown_event_test.go未知事件降级、main_integration_test.gostdin 模式与后端切换端到端验证、concurrent_stress_test.go高并发调度稳定性——这些保障了双模型并行审查调用时的输出解析与并发可靠性。十、常见问题与实战要点前端模型失败怎么处理最多重试 2 次间隔 5 秒3 次全败才可跳过前端审查以单模型结果继续——但此时需意识到盲区风险建议在报告中标注仅后端审查。后端模型迟迟不返回5-15 分钟属正常超时后继续TaskOutput轮询禁止 Kill 进程、禁止跳过——跳过等于浪费 token 且丢失审查结果。如何避免审查范围蔓延始终以git diff的变更文件为边界计划文件中的文件清单为补充基准不审查整个代码库。Critical 修完要不要重审必须重新运行受影响的审查维度直到 Critical 0 才能通过门禁。工作目录如何确定通过 Bash 执行pwdUnix或cdWindows CMD获取绝对路径禁止从$HOME或环境变量推断。结语team-review是 ccg-workflow 多模型协作体系的质量闸门它以双模型并行、维度错开、JSON 结构化输出、三级分级、Critical 门禁为核心配合codeagent-wrapper的统一后端抽象与TaskOutput轮询机制将交叉验证防盲区从理念落成了可重复执行的流程。理解本文的六步执行规范收集产物 → 并行审查 → 综合分级 → 输出报告 → 决策门 → 上下文检查点即可在生产中复现这套双模型交叉审查机制并借助仓库中的 team-reviewer.md、codex/reviewer.md、gemini/reviewer.md 与 codeagent-wrapper/CLAUDE.md 继续深挖实现细节。赞分享人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeek【免费下载链接】ccg-workflow多模型协作开发系统 - Claude 编排 Codex 后端 Gemini 前端28 个命令覆盖开发全流程一键安装零配置项目地址https://gitcode.com/fengshao1227/ccg-workflow点击查看免费下载相关推荐CCG Workflow 的 /review 命令解析双模型并行审查与交叉验证机制CCG Workflow 的 /review 命令解析双模型并行审查与交叉验证机制 导读 review 是 ccg workflow 多模型协作开发系统中的代人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeekCCG Workflow 双模型交叉审查指南/ccg:spec-review 命令全流程实战CCG Workflow 双模型交叉审查指南/ccg:spec review 命令全流程实战 本文聚焦 ccg workflow 多模型协作开发系统中的 归档人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeekCCG-Workflow /debug 多模型调试命令全解析双模型并行诊断与交叉验证实战指南CCG Workflow /debug 多模型调试命令全解析双模型并行诊断与交叉验证实战指南 导读 本文围绕 CCG Workflow多模型协作开发系统中人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeek上一篇Metabase Full App Embedding 深度实战iframe 嵌入、SSO/JWT 认证、SameSite 跨域与安全加固下一篇deepagents 系统提示快照解析远程沙箱默认后端下的 Shell paths vs. virtual paths 路由段创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CCG Workflow 多模型交叉审查实战：Agent Teams 双后端并行审查与 Critical 门禁机制全解
人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeek【免费下载链接】ccg-workflow多模型协作开发系统 - Claude 编排 Codex 后端 Gemini 前端28 个命令覆盖开发全流程一键安装零配置项目地址https://gitcode.com/fengshao1227/ccg-workflow点击查看免费下载导读本文围绕 ccg-workflow 仓库中的 templates/commands-legacy/team-review.md 展开系统讲解 Agent Teams 模式下双模型交叉审查的完整执行流程如何并行调用后端/前端两个外部模型对team-exec的产出进行分级审查、如何综合去重、如何通过 Critical 门禁决策放行或修复。读完本文你将掌握 ccg-workflow 中/ccg:team-review的完整运行机制、codeagent-wrapper的底层调用协议、Critical/Warning/Info 三级发现的分级标准与输出格式以及审查阶段允许 Lead 直接修复代码的边界规则。一、定位审查阶段在多模型协作流水线中的位置1.1 前置阶段计划与执行在 ccg-workflow 的 Agent Teams 工作流中team-review不是孤立命令它承接上游两个阶段规划阶段templates/commands-legacy/team-plan.mdLead 同时调用{{BACKEND_PRIMARY}}后端权威与{{FRONTEND_PRIMARY}}前端权威做并行分析产出零决策并行实施计划写入.claude/team-plan/任务名.md每个子任务的文件范围强制隔离。执行阶段templates/commands-legacy/team-exec.md读取计划文件后通过TeamCreate创建团队并行 spawn 多个 Builder teammatesSonnet实施编码Lead 只协调不写码。team-review正是这两个阶段的质量收口——审查范围严格限于 team-exec 产生的变更不扩大到整个代码库。1.2 统一工作流中的 Phase 6在 8 阶段企业级统一工作流 templates/commands-legacy/team.md 中审查对应Phase 6: REVIEW{{BACKEND_PRIMARY}} ∥ {{FRONTEND_PRIMARY}}并行审查 Reviewer teammate 综合判决随后进入 Phase 7最多 2 轮 Critical 修复循环与 Phase 8集成验证。team-review.md描述的即这一阶段在独立命令形态下的完整执行规范。1.3 核心哲学原文档开篇即明确三条原则是整个审查流程的设计基石双模型交叉验证捕获单模型审查遗漏的盲区。Critical 问题必须修复后才能结束。审查范围严格限于 team-exec 的变更不扩大范围。见 templates/commands-legacy/team-review.md二、Guardrails审查阶段的硬性约束team-review.md定义了三道不可逾越的护栏原文档 L10-L13约束说明违反后果双模型必须都完成{{BACKEND_PRIMARY}}与{{FRONTEND_PRIMARY}}都必须完成审查后才能综合禁止只等一个模型综合结论不完整丢失单一视角盲区范围不蔓延审查范围限于git diff的变更不做范围蔓延引入与本次变更无关的噪音稀释审查焦点Lead 可修复 Critical审查阶段允许写代码——Lead 可直接修复 Critical 问题若禁止则修复路径被阻塞门禁无法收敛第三点与 team-exec 阶段Lead 绝不直接修改产品代码形成鲜明对比见 templates/commands-legacy/team-exec.md实施阶段 Lead 是纯协调者审查阶段 Lead 被明确授权动手修 Critical。这是流程设计上有意为之的角色切换也是审查阶段区别于执行阶段的标志性特征。三、Step 1收集变更产物审查的第一步是建立审查基准原文档给出三个动作L16-L19运行git diff获取变更摘要——这是审查范围的唯一事实来源读取.claude/team-plan/下的计划文件——提取约束和成功判据作为审查基准即按计划验收列出所有被修改的文件——形成待审文件清单。这一步对应统一工作流 Phase 6 的起点templates/commands-legacy/team.mdLead 先Bash: git diff获取完整变更内容再决定如何分发给两个外部模型。计划文件之所以重要是因为 team-plan 阶段产出的每个子任务都带有验收标准见 templates/commands-legacy/team-plan.md审查不仅要看代码对不对还要看是否兑现了计划的验收承诺。四、Step 2多模型并行审查PARALLEL这是team-review.md的技术核心也是全仓库多模型协作范式的标准样板。4.1 硬性要求CRITICAL两条 Bash 调用必须在同一条消息中同时发起即真正的并行而非先后串行工作目录{{WORKDIR}}必须通过 Bash 执行pwdUnix或cdWindows CMD获取当前工作目录的绝对路径禁止从$HOME或环境变量推断。工作目录约束在多处重复出现team-plan.md、templates/commands-legacy/workflow.md原因是路径推断错误会导致外部模型在错误目录下审查产生系统性误报。4.2 两条并行调用后端与前端视角分工第一条 Bash 调用{{BACKEND_PRIMARY}} 后端审查原文档 L25-L33Bash({ 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}}\ EOF\nROLE_FILE: ~/.claude/.ccg/prompts/{{BACKEND_PRIMARY}}/reviewer.md\nTASK\n审查以下变更\ngit diff 输出或变更文件列表\n/TASK\nOUTPUT (JSON):\n{\n \findings\: [\n {\n \severity\: \Critical|Warning|Info\,\n \dimension\: \logic|security|performance|error_handling\,\n \file\: \path/to/file\,\n \line\: 42,\n \description\: \问题描述\,\n \fix_suggestion\: \修复建议\\n }\n ],\n \passed_checks\: [\已验证的检查项\],\n \summary\: \总体评估\\n}\nEOF, run_in_background: true, timeout: 3600000, description: {{BACKEND_PRIMARY}} 后端审查 })第二条 Bash 调用{{FRONTEND_PRIMARY}} 前端审查——必须与第一条在同一条消息中原文档 L35-L42Bash({ 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}}\ EOF\nROLE_FILE: ~/.claude/.ccg/prompts/{{FRONTEND_PRIMARY}}/reviewer.md\nTASK\n审查以下变更\ngit diff 输出或变更文件列表\n/TASK\nOUTPUT (JSON):\n{\n \findings\: [\n {\n \severity\: \Critical|Warning|Info\,\n \dimension\: \patterns|maintainability|accessibility|ux|frontend_security\,\n \file\: \path/to/file\,\n \line\: 42,\n \description\: \问题描述\,\n \fix_suggestion\: \修复建议\\n }\n ],\n \passed_checks\: [\已验证的检查项\],\n \summary\: \总体评估\\n}\nEOF, run_in_background: true, timeout: 3600000, description: {{FRONTEND_PRIMARY}} 前端审查 })两条调用的审查维度刻意错开这是双模型交叉验证能捕获盲区的关键模型审查维度关注点{{BACKEND_PRIMARY}}logic、security、performance、error_handling逻辑错误、安全漏洞、性能瓶颈、错误处理{{FRONTEND_PRIMARY}}patterns、maintainability、accessibility、ux、frontend_security模式一致性、可维护性、可访问性、UX、前端安全后端模型不审 UX、前端模型不审 SQL 注入——各自聚焦专业领域再由 Lead 综合去重这正是文档所谓双模型交叉验证捕获单模型审查遗漏的盲区的落地形态。4.3 底层调用链codeagent-wrapper两条调用都指向~/.claude/bin/codeagent-wrapper这是 ccg-workflow 的跨平台 Go CLI 包装器见 codeagent-wrapper/CLAUDE.md。其关键机制后端抽象通过Backend接口backend.go统一 Codex / Gemini / Claude / Grok / Kimi / OpenCode / Antigravity 七种 AI CLI 后端selectBackend()工厂负责路由stdin 模式命令中的-表示从 stdin 读取任务文本当任务包含换行、反斜杠、引号、反引号、$等特殊字符或长度超过 800 字符时自动切换main.go--progress向 stderr 输出紧凑进度行{{LITE_MODE_FLAG}}对应--lite精简模式关闭 Web UI 加快响应可通过CODEAGENT_LITE_MODEtrue环境变量开启main.go{{GEMINI_MODEL_FLAG}}等占位符由安装器按用户配置注入用于指定 Gemini/Grok/Kimi/OpenCode 的型号ROLE_FILE~/.claude/.ccg/prompts/backend/reviewer.md即该后端专属的审查角色提示词安装时由安装器生成到用户目录。4.4 等待结果与失败重试策略两条调用启动后用TaskOutput阻塞等待原文档 L45-L49TaskOutput({ task_id: codex_task_id, block: true, timeout: 600000 }) TaskOutput({ task_id: gemini_task_id, block: true, timeout: 600000 })两条铁律原文档 L51-L52⛔前端模型失败必须重试调用失败非零退出码或输出含错误信息最多重试 2 次、间隔 5 秒3 次全败才允许跳过前端审查用单模型结果继续。⛔后端模型结果必须等待后端模型执行 5-15 分钟属于正常TaskOutput超时后必须继续轮询禁止跳过。已启动的后端任务被跳过 浪费 token 丢失结果。这与 templates/commands-legacy/workflow.md 中多模型调用规范的全局约定一致timeout: 60000010 分钟必须显式指定否则默认 30 秒会提前超时10 分钟后未完成继续轮询绝对不要 Kill 进程。若必须中断等待需用AskUserQuestion询问用户禁止直接 Kill Task。4.5 退出码参考审查调用结束后可通过退出码判断结果见 codeagent-wrapper/CLAUDE.md码含义0成功1通用错误参数缺失、无输出124超时127后端命令不在 PATH130用户中断CtrlC其他后端进程退出码透传五、Step 3综合发现与分级两个模型的 JSON 结果返回后进入综合阶段原文档 L54-L60合并两个模型的发现去重重叠问题——多源指出同一问题时保留最详细的描述按严重性分级级别定义处置Critical安全漏洞、逻辑错误、数据丢失风险必须修复Warning模式偏离、可维护性问题建议修复Info小改进建议可选修复分级标准与 Reviewer teammate 角色定义完全一致templates/commands/agents/team-reviewer.mdCritical 覆盖安全漏洞、逻辑错误、数据丢失风险、构建失败并阻塞发布Warning 覆盖模式偏离、性能隐患、可维护性问题但不阻塞Info 为风格建议与微优化。此外综合时若多源意见矛盾以代码事实为准team-reviewer.md。六、Step 4输出审查报告原文档给出了可直接套用的 Markdown 报告模板L62-L79## 审查报告 ### Critical (X issues) - 必须修复 - [ ] [安全] file.ts:42 - 描述 - [ ] [逻辑] api.ts:15 - 描述 ### Warning (Y issues) - 建议修复 - [ ] [模式] utils.ts:88 - 描述 ### Info (Z issues) - 可选 - [ ] [维护] helper.ts:20 - 描述 ### ✅ 已通过检查 - ✅ 无 XSS 漏洞 - ✅ 错误处理完整报告规范要点每个 finding 必须指向具体的文件和行号且必须包含可操作的修复建议事实依据 可操作两条硬性约束同样出现在 team-reviewer.md 中。6.1 Reviewer 角色的扩展报告格式在统一工作流中输出报告的职责由Reviewer teammate承担templates/commands/agents/team-reviewer.md。其报告在分级清单之外增加了审查范围头部与判决尾部并标注每个 finding 的来源自身 / Codex / Gemini# 代码审查报告 ## 审查范围 - **变更文件数**: N - **变更行数**: X / -Y - **审查来源**: 自身审查 Codex 后端审查 Gemini 前端审查 ## Critical (N issues) — 必须修复 ### [C-1] [安全] SQL 注入风险 - **文件**: src/api/users.ts:42 - **描述**: 用户输入直接拼接 SQL 查询 - **来源**: 自身 Codex - **修复建议**: 使用参数化查询 db.query(SELECT * FROM users WHERE id $1, [userId]) ## ✅ 已通过检查 - ✅ 无硬编码密钥 - ✅ 错误处理完整 ## 判决 - **Critical**: N → [BLOCKED / PASS] - **总体**: ❌ 需要修复 Critical 后重审 / ✅ 审查通过Reviewer 的独立审查覆盖 5 个维度正确性逻辑错误、off-by-one、null/undefined 处理、类型安全、安全性注入、XSS、CSRF、硬编码密钥、权限绕过、路径遍历、性能N1 查询、不必要重渲染、内存泄漏、阻塞操作、模式一致性项目规范、命名、目录结构、API 风格、可维护性复杂度、重复代码、耦合度、文档team-reviewer.md。6.2 后端/前端角色提示词的审查清单两个外部模型的审查行为由各自的 reviewer 角色提示词约束Codex 后端审查templates/prompts/codex/reviewer.md安全输入校验、SQL/命令注入、硬编码密钥、鉴权、日志脱敏、代码质量错误处理、去重、命名、单一职责、性能N1、索引、缓存、可靠性竞态、边界情况、优雅恢复、幂等。同时要求零文件系统写权限只读沙箱——外部模型对文件系统零写入所有修改由 Claude/Lead 执行。Gemini 前端审查templates/prompts/gemini/reviewer.md可访问性语义 HTML、ARIA、键盘导航、焦点管理、颜色对比、设计一致性design tokens、无硬编码颜色/尺寸、间距排版一致、代码质量TS 类型、Props 接口、可复用组件、性能重渲染、memoization、懒加载、响应式移动/平板/桌面。同样要求零写权限。两个角色提示词还要求.context感知若项目存在.context/目录需读取prefs/coding-style.md作为审查标准、读取workflow.md验证开发流程是否被完整遵循并对照history/commits.jsonl检查当前变更是否与既往架构决策冲突codex/reviewer.md、gemini/reviewer.md。七、Step 5决策门Decision Gate分级完成后进入门禁决策原文档 L81-L88分支一Critical 0展示发现用AskUserQuestion询问用户立即修复 / 跳过选择修复 →Lead 直接修复审查阶段允许写代码后端问题参考{{BACKEND_PRIMARY}}建议前端问题参考{{FRONTEND_PRIMARY}}建议修复后重新运行受影响的审查维度重复循环直到 Critical 0。分支二Critical 0报告通过建议提交代码。在统一工作流中该循环被形式化为Phase 7 修复循环Evaluator-Optimizer Loop最多 2 轮按 finding 归属文件分配给对应 Dev teammate多 finding 同文件则合并为一个修复任务每轮修复后由 Lead 运行测试轻量验证templates/commands-legacy/team.md。2 轮后仍有 Critical 则用AskUserQuestion报告让用户选择继续手动修复或跳过提交。八、Step 6上下文检查点与退出标准8.1 上下文检查点报告当前上下文使用量原文档 L90-L91。这条约定贯穿整个工作流team-plan 阶段也要求如果接近 80K建议/clear后运行/ccg:team-execteam-plan.md。原因是 Agent Teams 工作流要连续承载规划、执行、审查多个长阶段上下文管理直接决定流程能否走完。8.2 Exit Criteria退出标准审查阶段必须全部满足以下条件才可宣告完成原文档 L93-L97{{BACKEND_PRIMARY}}{{FRONTEND_PRIMARY}}审查完成所有发现已综合分级Critical 0已修复或用户确认跳过审查报告已输出这四项退出标准与统一工作流 Phase 6/7/8 的衔接完全对应审查完成后进入集成验证全量测试 lint typecheckteam.md最终报告写入.claude/team-plan/任务名-report.md。九、从源码看审查机制的工程保障9.1 模板是可执行规范team-review.md是带 CCG 标记的指令模板!-- CCG:TEAM:REVIEW:START --至!-- CCG:TEAM:REVIEW:END --由安装器渲染后注入用户的 Claude 配置。其中的{{BACKEND_PRIMARY}}、{{FRONTEND_PRIMARY}}、{{WORKDIR}}、{{LITE_MODE_FLAG}}等占位符在安装时被替换为用户的真实后端选择与工作目录。{{GEMINI_MODEL_FLAG}}、{{GROK_MODEL_FLAG}}、{{KIMI_MODEL_FLAG}}、{{OPENCODE_MODEL_FLAG}}的存在说明前端权威模型并不固定为 Gemini而是一个可配置的多选占位——审查的第二只眼睛可以是 Gemini/Grok/Kimi/OpenCode 中的任意一个或多选组合。9.2 wrapper 的并行与等待保障codeagent-wrapper对长任务审查有专门设计见 codeagent-wrapper/CLAUDE.md非--lite模式下启动本地 HTTP 服务通过 SSE 实时推送后端输出到浏览器方便观察 5-15 分钟的长审查任务进度--lite则跳过该机制以换取速度。审查任务通常以run_in_background: true启动配合TaskOutput轮询这与 wrapper 的并发执行引擎executor.go和默认 7200 秒超时main.go匹配。9.3 测试保障仓库为 wrapper 提供了覆盖完善的测试矩阵codeagent-wrapper/CLAUDE.md与审查链路直接相关的包括parser_token_too_long_test.go超长 JSON 行处理、parser_unknown_event_test.go未知事件降级、main_integration_test.gostdin 模式与后端切换端到端验证、concurrent_stress_test.go高并发调度稳定性——这些保障了双模型并行审查调用时的输出解析与并发可靠性。十、常见问题与实战要点前端模型失败怎么处理最多重试 2 次间隔 5 秒3 次全败才可跳过前端审查以单模型结果继续——但此时需意识到盲区风险建议在报告中标注仅后端审查。后端模型迟迟不返回5-15 分钟属正常超时后继续TaskOutput轮询禁止 Kill 进程、禁止跳过——跳过等于浪费 token 且丢失审查结果。如何避免审查范围蔓延始终以git diff的变更文件为边界计划文件中的文件清单为补充基准不审查整个代码库。Critical 修完要不要重审必须重新运行受影响的审查维度直到 Critical 0 才能通过门禁。工作目录如何确定通过 Bash 执行pwdUnix或cdWindows CMD获取绝对路径禁止从$HOME或环境变量推断。结语team-review是 ccg-workflow 多模型协作体系的质量闸门它以双模型并行、维度错开、JSON 结构化输出、三级分级、Critical 门禁为核心配合codeagent-wrapper的统一后端抽象与TaskOutput轮询机制将交叉验证防盲区从理念落成了可重复执行的流程。理解本文的六步执行规范收集产物 → 并行审查 → 综合分级 → 输出报告 → 决策门 → 上下文检查点即可在生产中复现这套双模型交叉审查机制并借助仓库中的 team-reviewer.md、codex/reviewer.md、gemini/reviewer.md 与 codeagent-wrapper/CLAUDE.md 继续深挖实现细节。赞分享人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeek【免费下载链接】ccg-workflow多模型协作开发系统 - Claude 编排 Codex 后端 Gemini 前端28 个命令覆盖开发全流程一键安装零配置项目地址https://gitcode.com/fengshao1227/ccg-workflow点击查看免费下载相关推荐CCG Workflow 的 /review 命令解析双模型并行审查与交叉验证机制CCG Workflow 的 /review 命令解析双模型并行审查与交叉验证机制 导读 review 是 ccg workflow 多模型协作开发系统中的代人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeekCCG Workflow 双模型交叉审查指南/ccg:spec-review 命令全流程实战CCG Workflow 双模型交叉审查指南/ccg:spec review 命令全流程实战 本文聚焦 ccg workflow 多模型协作开发系统中的 归档人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeekCCG-Workflow /debug 多模型调试命令全解析双模型并行诊断与交叉验证实战指南CCG Workflow /debug 多模型调试命令全解析双模型并行诊断与交叉验证实战指南 导读 本文围绕 CCG Workflow多模型协作开发系统中人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeek上一篇Metabase Full App Embedding 深度实战iframe 嵌入、SSO/JWT 认证、SameSite 跨域与安全加固下一篇deepagents 系统提示快照解析远程沙箱默认后端下的 Shell paths vs. virtual paths 路由段创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考