企业官网建设流程全解析

• 人工智能
• AI 应用
• 开发工具
• CLI
• AI Agent
• dsh-plugin
• DeepSeek

本文聚焦 ccg-workflow 多模型协作开发系统中的归档前审查命令/ccg:spec-review——一条以"双模型交叉验证"为核心的独立代码审查工具。它不依赖其他工作流阶段，随时可调用，用于在 OpenSpec（OPSX）提案归档前，以后端模型 + 前端模型并行审查的方式，从规范符合性、逻辑正确性、安全性、可维护性、集成风险等维度对提案实现做最终把关。读完本文，你将掌握该命令的完整执行流程、双模型并行调用的底层机制（基于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.md）：

• OpenSpec CLI（命令名为openspec，不是opsx），可通过npx @fission-ai/openspec --version校验、npm install -g @fission-ai/openspec@latest安装；Node.js >= 18.x。
• 项目已初始化openspec/目录，.claude/skills/下含openspec-*skills。
• codeagent-wrapper二进制可用：~/.claude/bin/codeagent-wrapper --version。

工作目录（{{WORKDIR}}）的获取有硬性约定：必须通过 Bash 执行pwd（Unix）或cd（Windows 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/目录加载相关规范约束与 PBT（Property-Based Testing）属性。

规范约束的快速检索可用：

rg -n "CONSTRAINT:|MUST|INVARIANT:" openspec/changes/<id>/specs/

Step 3：多模型并行审查（Multi-Model Review，PARALLEL）

这是整个命令的核心环节，约束极其明确：

• 关键：必须在同一条消息里以两个 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）。审查调用中用到的参数含义如下：

之所以用-+ 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.ts）；
• Grok、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；
• 对重叠问题去重；
• 按严重级别分类：

两个模型各自带独立的维度标签：后端模型输出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 问题：

1. 将每个修复任务路由到对应模型（后端问题 →{{BACKEND_PRIMARY}}，前端问题 →{{FRONTEND_PRIMARY}}）；
2. 以unified diff patch格式应用修复（外部模型零写权限，只产出补丁，实际落盘由编排层完成——这与/ccg:spec-impl中"外部模型输出仅作原型参考，必须重写为生产级代码"的守则一致，见 templates/commands/spec-impl.md）；
3. 重新运行受影响的审查维度；
4. 循环直到 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 10（Archive on Completion）执行：当tasks.md中全部任务标记为[x]后，内部调用/opsx:archive，将 spec deltas 合并到openspec/specs/并把 change 移入归档（详见 templates/commands/spec-impl.md）。这保证了"审查通过 → 归档"的时序由流程强制约束：审查是归档的前置关卡，归档是审查通过后的收尾动作。

参考命令速查

小结

/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 应用
• 开发工具
• CLI
• AI Agent
• dsh-plugin
• DeepSeek