AI 代码审查与验证税
验证有四档强度，越往下越不依赖模型的自觉：让它自己说、跑测试、对抗式评审、独立复现。 AI 代码高发的坑是 reward hacking（为了让测试通过改测试）、安全缺陷与看似合理的静默错误；产能翻倍后瓶颈换到了审查这一端，验证税是必须付的。
也叫：代码审查 · code review · reward hacking · 测试作弊 · 对抗式评审 · 验证税
再学团队治理与准入
闸二：验证——四档强度，越往下越不依赖模型的自觉出自 T7-2
第 1 档 同一轮里让它自己跑检查并迭代 最省事，但判官就是被告 第 2 档 独立评估器每轮复检 判官换人，但还是模型 第 3 档 确定性钩子，不达标就阻塞回合结束 判官不是模型 ← 分水岭在这 第 4 档 验证子 agent：全新上下文，只看 diff 和验收标准
关键分界在第 3 档：前两档都是「用模型验模型」，模型有动机把自己判过；第 3 档把判断权交给一段确定性代码（跑真测试、跑 lint、跑压测断言），它不会被说服。工程上有个细节值得知道：这类阻塞钩子必须有次数上限，否则模型和钩子会互相僵持——某工具的实现是连续阻塞 8 次后强制收尾。
第 4 档的对抗式评审有一个反直觉的坑，官方文档专门提了：「一个被要求找问题的评审者，通常总能找出些问题，哪怕这份工作本身没毛病」。所以对抗式评审的提示词必须限定范围——只报影响正确性或违反需求的问题。不限定的后果不是「更严格」，是模型开始加没必要的抽象层和防御性分支，代码越审越肿。
AI 代码的高发坑（审查时优先看这几类）：
- 改错对象——同名新旧两套实现，改了不跑的那个（见 T7-1 的故障）。
- 让测试通过而非让代码正确——上面三种具名手法，重点看
conftest.py、测试基类、mock 边界。 - 看起来完整的错误处理——
try/except包住一切然后pass，静默吞异常，日志里什么都没有。 - 幻觉出来的 API 与依赖——调了不存在的方法、引了不存在的包名，本地缓存里恰好有同名包时尤其危险。
- 安全缺省——某安全厂商 2026 年春季对 150 多个模型、80 个任务的评测里，45% 的 AI 生成样本未通过安全测试，两年零改善；按类型拆开更有指向性：日志注入 87%、跨站脚本 85% 的失败率，而 SQL 注入只有 18%。它擅长防你教过它防的，不擅长防没被大量标注过的。
- 重复而不复用——某代码分析平台对 6.23 亿行变更的统计显示，块级重复从 2023 年的每百万行 40.3 处升到 2026 年的 73.0 处（+81%），而「移动代码」这个重构的信号从 21% 掉到 3.8%。AI 倾向于再写一份，不倾向于抽出来。
以上节选自T7-2 AI 协作的工程纪律——规格、验证、回滚、治理这四道闸，读全文能看到前后语境。