用多个 AI 模型自动化代码审查 — 告别单一视角
AI 代码审查已经不新鲜了。但你有没有想过：一个 AI 模型审查代码，和两个 AI 模型独立审查再合并，效果差多少？
答案是：差很多。就像人类 code review 需要多个 reviewer 一样，AI 审查也需要多视角。
单模型审查的盲区
Section titled “单模型审查的盲区”单个模型做 code review 的典型问题：
- 偏好一致性：同一个模型倾向于用同样的模式思考，容易漏掉它不熟悉领域的问题
- 前后端割裂：擅长后端的模型可能忽略前端 XSS 风险，反之亦然
- 确认偏误：模型可能对自己生成的代码过于宽容
双模型交叉审查
Section titled “双模型交叉审查”CCG Workflow 的 review-audit 策略实现了真正的交叉审查：
> /ccg:go review 最近的代码改动执行流程：
- 自动获取 git diff
- Codex 独立审查 — 关注后端逻辑、API 安全、数据一致性
- Gemini 独立审查 — 关注前端交互、XSS 风险、可访问性
- Claude 合并两份 findings，去重分级
输出格式：
## Review Report
### Critical- [Codex] SQL injection risk in user query (line 42)- [Gemini] Unsanitized innerHTML usage (line 158)
### Warning- [Codex] Missing transaction rollback on error path- [Gemini] Button missing aria-label for accessibility
### Info- [Codex] Consider indexing the `created_at` column- [Gemini] Component could be memoized for performance关键：两个模型是独立审查，不知道对方的 findings。这避免了锚定效应——一个模型的结论不会影响另一个。
实际效果对比
Section titled “实际效果对比”以一个典型的全栈 PR（认证模块改动）为例：
| 发现类型 | 只用 Claude | CCG 双模型审查 |
|---|---|---|
| SQL 注入风险 | ✅ 发现 | ✅ 发现（Codex） |
| XSS 风险 | ❌ 遗漏 | ✅ 发现（Gemini） |
| 竞态条件 | ✅ 发现 | ✅ 发现（Codex） |
| 可访问性问题 | ❌ 遗漏 | ✅ 发现（Gemini） |
| 缺失事务回滚 | ⚠️ 可能发现 | ✅ 发现（Codex） |
| CSS 性能问题 | ❌ 遗漏 | ✅ 发现（Gemini） |
双模型覆盖率显著更高，尤其在跨领域问题上。
其他审查场景
Section titled “其他审查场景”> /ccg:go 审查这次重构是否保持了行为等价引擎使用 refactor-safely 策略：
- 一个模型审查重构前代码的行为语义
- 另一个模型验证重构后代码是否一致
- 确保重构没有偷偷改变行为
OPSX 规格审查
Section titled “OPSX 规格审查”/ccg:spec-review在 OpenSpec 流程中，代码实现完成后触发双模型审查，验证实现是否满足所有约束。
> /ccg:go review this PR against the requirements结合需求文档和代码 diff，双模型从不同角度验证实现完整性。
质量关卡自动化
Section titled “质量关卡自动化”除了人工触发的审查，CCG 在复杂任务的策略流程中自动运行质量关卡：
- verify-security — 扫描安全漏洞（注入、越权、硬编码密钥等）
- verify-quality — 检查复杂度、命名规范、函数长度等
- verify-change — 分析变更影响范围，检查文档是否同步
这些关卡在 full-collaborate 和 guided-develop 策略的验证阶段自动执行，不需要手动触发。
npx ccg-workflow安装后，在 Claude Code 中用自然语言触发审查：
> /ccg:go review the changes on this branch> /ccg:go 审查最近 3 个 commit 的代码质量> /ccg:go security review the auth module引擎自动选择最合适的审查策略。