对抗式代码审查

解决的问题

当 AI 审查自己刚写的代码时，会共享作者的心理模型、假设和盲点，导致对明显有问题的代码给出 “LGTM” 的结果。这是 AI 辅助开发中最令人沮丧的问题之一。

如何工作

通过三种对抗人格强制改变视角。Saboteur 关注生产环境崩溃：未验证输入、状态不一致、并发访问未同步、错误路径吞异常、资源泄漏。New Hire 关注可维护性：命名是否传达意图、是否需要跨多个文件追踪逻辑、魔法数字、函数职责是否单一、类型信息是否缺失、测试是否验证行为而非实现细节。Security Auditor 基于 OWASP 检查注入、认证破坏、数据暴露、不安全默认配置、缺失访问控制、依赖风险、密钥泄露。

审查流程：首先确定审查范围（无参数时检查 git diff，--diff 时使用指定 diff，--file 时读取整个文件）。然后读取每个文件的完整上下文，理解变更目的，识别项目约定。接着按顺序运行三种人格，每种必须至少产生一个发现。最后去重、合并发现，对多个 persona 同时标记的问题提升严重级别，生成结构化输出。

输出格式：每种人格给出发现，去重后按严重程度排序，最终输出 BLOCK（有 CRITICAL 发现）、CONCERNS（无 CRITICAL 但有 2 个以上 WARNING）、CLEAN（只有 NOTE）。

适用边界

这不是自动修复工具，只是审查视角的补充。审查结果需要开发者判断，可能存在误报。适用于 PR 合并前、长时间编码后、安全敏感代码、直觉感觉有问题时。不适合替代全面的安全审计或自动化测试。