Appearance
AI辅助Code Review：能力框架、工具对比与最佳实践
Code Review一直是保障代码质量的核心实践。传统审查的速度无法跟上AI生成代码的规模。AI辅助Code Review不是简单替代人类，而是重新定义审查的粒度、时机和角色分工。
一、四层能力模型
第一层：规格对齐审查（Spec Compliance Review）
验证代码是否实现了预先约定的规格：
- 理解需求文档和设计规范
- 将代码实现与规格条目逐项对应
- 识别遗漏的功能点和偏差
Superpowers 将其作为两阶段审查的第一阶段。
第二层：代码质量审查（Code Quality Review）
关注代码本身的品质：
| 维度 | 说明 |
|---|---|
| 代码风格一致性 | 格式、缩进、注释风格 |
| 命名规范与可读性 | 变量、函数、类命名 |
| 错误处理和边界条件 | 异常捕获、边界值处理 |
| 性能考虑 | 算法效率、资源使用 |
| 安全漏洞检测 | OWASP Top 10 等 |
第三层：架构与设计审查（Architecture Review）
更高维度的审查：
- 模块边界是否清晰
- 依赖关系是否合理
- 是否遵循 SOLID 等设计原则
- 是否有过度设计或设计不足
第四层：上下文感知审查（Context-Aware Review）
最前沿的能力：
- 理解业务背景和用户场景
- 评估代码对系统其他部分的影响
- 识别潜在的回归风险
- 提供项目特定的定制化建议
二、审查时机的新范式
| 时机 | 目的 | 代表框架 |
|---|---|---|
| 任务开始前 | 验证规格清晰度 | OpenSpec |
| 子任务完成后 | 及时发现偏差 | Superpowers |
| 代码编写中 | 实时反馈 | gstack /review |
| 合并前 | 全面质量把关 | Compound Engineering |
| 部署后 | 监控实际运行 | gstack /canary |
三、四种方法论对比
Superpowers：两阶段递进审查
流程：
任务分配 → 子Agent执行 → 第一阶段：规格对齐审查 →
[如不通过：返回修复] → 第二阶段：代码质量审查 →
[如不通过：返回修复] → 任务完成关键洞察：两阶段分离确保审查逻辑顺序，避免代码质量层面讨论掩盖更根本的规格偏差问题。
OpenSpec：规格驱动的前置对齐
流程：
/opsx:propose → AI生成proposal.md和specs/ →
人类审核确认 → AI执行tasks/ → 人类确认完成核心创新：引入 Artifact（制品）概念——proposal.md、specs/、design.md、tasks.md。
审查时机前移：代码审查变成验证「实现是否遵循了已批准的规格」。
Compound Engineering：80%在规划与审查
公式：80%的工作在规划与审查，20%在执行。
流程：
/ce-brainstorm → /ce-plan → /ce-work →
/ce-code-review → /ce-compound → 循环迭代核心创新：/ce-compound 要求将审查发现的模式、教训沉淀为可复用知识。
gstack：角色扮演的专职审查
| 技能 | 角色 | 审查焦点 |
|---|---|---|
| /review | Staff Engineer | 通过CI但生产环境可能爆炸的bug |
| /cso | Chief Security Officer | OWASP Top 10 + STRIDE威胁模型 |
| /plan-eng-review | Eng Manager | 架构、数据流、状态机 |
| /plan-design-review | Senior Designer | AI Slop检测、设计质量评分 |
/cso 安全审查特点：
- 17个已知误报排除规则
- 8/10以上置信度阈值
- 独立验证每个发现
流程对比总结
| 维度 | Superpowers | OpenSpec | Compound Engineering | gstack |
|---|---|---|---|---|
| 审查阶段 | 任务后两阶段 | 规格前置 | 规划-执行-审查循环 | 多角色按需触发 |
| 审查粒度 | 规格→质量 | 规格→实现 | 多Agent并行 | 角色分工 |
| 知识沉淀 | 无 | 可选 | /ce-compound强制 | /retro可选 |
| 适用规模 | 中小型 | 中大型 | 中大型 | 各种规模 |
四、最佳实践
何时引入
- 代码生成量已超出人工审查能力
- 审查质量不稳定，存在遗漏
- 需要标准化审查标准
- 团队成员审查能力参差不齐
审查质量保障
| 方法 | 说明 |
|---|---|
| 设定置信度阈值 | 只报告高置信度发现 |
| 分层处理发现 | Blocker / Major / Minor |
| 建立反馈闭环 | 驳回时记录原因，优化提示词 |
人机协作边界
| AI擅长 | 人类擅长 |
|---|---|
| 模式识别、大范围扫描 | 业务上下文理解 |
| 标准化检查（风格、格式） | 创新性和设计决策 |
| 快速反馈（秒级响应） | 团队约定和文化判断 |
工具选择建议
| 团队规模 | 推荐 |
|---|---|
| 小型团队（<5人） | gstack 或 Superpowers |
| 中型团队（5-20人） | OpenSpec 或 Compound Engineering |
| 大型团队（>20人） | Compound Engineering |
五、未来发展趋势
| 趋势 | 说明 |
|---|---|
| 审查前移 | 从代码审查到设计审查 |
| 多模态审查 | UI/视觉、API契约、配置审查 |
| 自适应审查规则 | 根据项目历史调整审查标准 |
| 跨仓库知识共享 | 项目级别知识沉淀 |
| CI/CD深度集成 | PR→合并→部署全程审查 |
总结
核心洞察：在AI时代，Code Review的目的不是「找出坏代码」，而是「确保好代码持续产生」。
AI不是来取代人类审查者，而是让人类能够专注于更高价值的决策。
关键词：AI Code Review, Superpowers, OpenSpec, Compound Engineering, gstack, 规格对齐审查
