AI Code Review
AI Code Review（如何 review AI 生成代码）
核心结论
高效、精准、稳定地 review AI 生成代码，关键不是“让另一个 AI 再看一遍 diff”，而是建立一个 spec-grounded、evidence-driven、independent-verification 的 review membrane：
- 先审规格，再审代码：如果没有可执行/可检查的规格，AI reviewer 容易和 coding agent 从同一分布里犯相关错误。
- 区分证据层级：Seen（仓库里真的看到的事实）、Tested（实际运行过的验证）、Inferred（基于代码路径推断）、Guessed（未证实假设）必须分开。
- 独立验证者不能是原作者：写代码的 agent 不应自证完成；至少需要不同上下文、不同模型、测试/CI 或人工 reviewer 给 verdict。
- review 过程要审计化：记录 review 范围、证据、命令、结果、结论和剩余风险，而不是只留一句“LGTM”。
- 风险分级而非平均用力：AI 代码最危险的不是风格问题，而是幻觉 API、错误机制、绕过测试、过度改动、安全边界和架构约束违反。
为什么普通 code review 不够
AI 生成代码常见失败模式包括：
- 幻觉式补全：引用不存在的类、方法、配置或终端输出。
- 测试通过但机制错误：patch 刚好满足现有测试，却违反架构、错误处理、并发、安全或性能约束。
- 大 diff 认知负载：agent 一次生成大量改动，人类 reviewer 很难逐行保持上下文。
- 相关错误：生成者和 reviewer 都是 LLM 时，若缺少外部 spec/test/ground truth，容易互相确认同一错误。
- 过程不可追溯：不知道 agent 基于哪些证据做判断，也不知道哪些假设没验证。
Review membrane：推荐流程
1. Scope freeze：冻结审查范围
- 明确 base/head 或 MR/PR diff 范围。
- 列出改动文件、改动类型：新增逻辑、重构、测试、配置、依赖、安全敏感路径。
- 大 diff 先按模块/风险分片，不要一次性让 reviewer 看几万行。
2. Spec gate：先验证意图
在看代码前先回答：
- 这次变更要解决什么问题？
- 用户需求/issue/设计文档里哪些是硬约束？
- 哪些行为必须保持不变？
- 哪些约束不能只靠测试覆盖，例如权限、审计、数据兼容、错误处理、性能上限？
没有 spec 的情况下，review 只能降级为“风险扫描”，不能给强通过结论。
3. Evidence map：把证据分层
每个关键判断都标注来源：
| 层级 | 含义 | 可接受用途 |
| Seen | 仓库/文档/日志里实际看到 | 可作为事实 |
| Tested | 命令、测试、CI、复现脚本实际运行 | 可作为 verdict 核心证据 |
| Inferred | 基于控制流/数据流推断 | 需要说明路径 |
| Guessed | 没有验证的猜测 | 不能作为通过依据 |
Surge 对 SWE-bench 失败轨迹的分析说明：coding agent 最容易在缺失信息时把 Guessed 当成 Seen，然后进入 hallucination spiral。
4. Multi-pass review：分工而非一遍看完
建议至少四轮：
- Correctness pass：是否真的满足 spec，是否有边界条件、并发、状态机、兼容性问题。
- Integration pass：是否符合仓库已有架构、错误处理、日志、配置、依赖和扩展点。
- Security pass：secret、注入、权限、路径穿越、反序列化、SSRF、XSS、供应链风险。
- Evidence pass：测试是否覆盖关键路径，是否只测 happy path，是否有伪测试/脆弱测试。
5. Independent verdict：独立结论
最终结论必须包含：
PASS / HOLD / FAIL- 通过依据：哪些测试/命令/静态扫描/人工检查支持结论
- 未覆盖风险：哪些路径没验证
- 阻塞项：哪些问题必须修复
- 非阻塞建议：风格、命名、重构、性能优化
对应 agentops-coding-agent-verification 的原则：No verdict = not done。
对 Hermes / 工作流的落地模板
AI Code Review Verdict
Scope:
- Base/head:
- Files:
- Intent/spec:
Evidence:
- Seen:
- Tested:
- Inferred:
- Guessed / unverified:
Findings:
- Blocker:
- Major:
- Minor:
- Suggestions:
Commands run:
- ... -> result
Verdict: PASS | HOLD | FAIL
Reason:
Residual risk:工具/研究对应关系
- agentops-coding-agent-verification：validation membrane、verdict、ledger。
usetig/sage：实时跟踪 coding agent 每一步，不只 review 最终 diff，而是 review reasoning/plans/responses。sipyourdrink-ltd/bernstein：多 agent orchestration 的 signed audit log、artifact lineage、merge gates。langchain-ai/open-swe：企业内部 coding agent 框架，强调 sandbox、AGENTS.md context、validation middleware。- arXiv
The Specification as Quality Gate：强调 spec 是 AI-assisted review 的外部参照。 - arXiv
The Verification Horizon：提醒 verification 本身会成为瓶颈，任何 verifier 都只是 human intent 的 proxy。 - arXiv
RigorBench：把工程过程纪律也作为 benchmark，而不是只看最终 pass rate。
2026-07-08 补充：从静态 review 到 generate-review-revise loop
| [[swe-review-agentic-code-review | SWE-Review]] 把 AI code review 从“审一次 diff”推进到 generate-review-revise loop：reviewer agent 先独立探索仓库，再给出 accept/reject 与结构化反馈，后续 reviser 根据反馈修复。关键评测不只是 review decision accuracy，还包括 downstream revision usefulness。 |
这强化了本页的 review membrane：review 的最终价值不是评论数量，而是是否让下一版 patch 更接近 spec、更可验证、更少 side effect。对高风险 AI 代码，建议将 author/reviewer/reviser 作为不同阶段，并要求 reviewer 的每条阻塞意见绑定 evidence 层级和可复现检查。
2026-07-11 补充：性能优化 patch 的 review 要求
| [[perfopt-bench-performance-optimization-agents | PERFOPT-Bench]] 提醒：AI 生成的性能优化 patch 不能只看“测试通过 + benchmark 变快”。reviewer 必须审查 measurement protocol、baseline、重复次数、variance、隐藏正确性、是否利用 benchmark-specific shortcut，以及优化是否牺牲可维护性或边界行为。 |
因此 AI Code Review 的 evidence map 对性能类变更应新增一栏：Measured。只有当 speedup 在可复现环境中成立，且 correctness / integration / security 没有退化时，才能给 PASS；否则最多是 HOLD。
2026-07-17 补充：AI code review 必须覆盖 security debt 与人机协作盲区
| [[security-debt-autonomous-coding-agents | Autonomous Coding Agents 的 Security Debt]] 给 review membrane 增加了经验数据：agent-generated PR 中 security smells 并非边缘事件，且 supply-chain integrity、hard-coded credentials、over-privilege execution 等问题很容易被功能导向的 review 忽略。论文还指出现有自动/人工 review 在合入前漏掉大量 credentials，说明“有人 review 过”不是充分证据。 |
因此 AI Code Review 的 Security pass 应从清单项升级为硬门禁：检查依赖 pinning、mutable image/action tags、global install、secret 泄漏、权限扩大、CI/CD 脚本、部署配置和高风险路径。最终 verdict 应说明 security coverage；若未运行 secret scanner 或未审查配置变更，应标为 residual risk，而不是默认 PASS。
2026-07-24 补充：语义 review 规则可以前移为 model-backed lint
| [[alint-model-backed-code-analysis | alint]] 把 AI code review 的一部分前移成可运行规则：像 ESLint 一样输出 diagnostics，但规则内部可以调用模型或工具型 agent 判断语义问题。这个方向的价值在于把反复出现的 AI 生成代码失败模式（虚构 API、上下文遗漏、架构约束违反、测试剧场、文档/实现不一致）沉淀成可版本化 gate，而不是每次依赖 reviewer 从头发现。 |
对 Hermes 来说，review membrane 可以分成三层：传统 deterministic checks（类型、测试、格式、安全扫描）、model-backed semantic lint（项目约束、需求一致性、证据缺口）、independent verdict（fresh reviewer / CI / human gate）。model-backed lint 不能替代 verdict，但能显著降低 reviewer 面对大 diff 时的认知负担。
写入记录
- 2026-07-24 09:01 CST：补充 alint 对 model-backed semantic lint、AI 生成代码预审查和 Hermes review membrane 分层的启发。
- 2026-07-01 09:45 CST：基于 arXiv、HN、GitHub 与博客调研创建 AI Code Review 概念页，总结 review AI 生成代码的 spec/evidence/verdict 流程。
- 2026-07-08 09:00 CST：补充 SWE-Review 的 generate-review-revise 闭环与 downstream revision usefulness 评估。
- 2026-07-11 09:00 CST：补充 PERFOPT-Bench 对性能优化 patch review、measurement protocol 和 Measured 证据层的启发。
- 2026-07-17 09:00 CST：补充 autonomous coding agents security debt 对 AI code review 的启发，强化供应链、secret、权限和 CI/CD 配置的硬门禁。