逐步指南：如何终结逐行代码审查
内容提要
Aviator Verify 提出“代理验证、人来决策”的 AI 代码审查模式：从 PR 评论、贡献文档和编码会话中提取意图、验收标准与团队不变量，由独立验证代理在预览环境运行场景并附截图、日志等证据，再由人依据证据判断是否合并。不变量可持续积累维护，减少重复审查。
延伸解读
为什么“代理验证、人来决策”更合理
文章指出，当前多数AI代码审查让模型直接判断diff好坏，但模型缺乏团队标准，也无法对决策负责。Aviator Verify主张将验证交给独立代理，由代理运行场景并附截图、日志等证据，人则依据证据判断是否合并。这种分工解决了模型“读每一行但不懂意图”的局限，也让人对最终决策负责。
不变量与验收标准：两层检查缺一不可
文章强调，每次变更需对照两层：验收标准描述本次变更应做什么，不变量是团队始终为真的规则。只有验收标准，标准靠记忆；只有不变量，代码合规但可能偏离目标。两者结合，代理才能既检查行为又守住团队规范，减少重复审查和代理跑偏。
从PR历史中提取不变量，降低启动成本
文章建议从现有PR评论、CONTRIBUTING.md和代理指令文件中提取不变量，也可在PR评论或Slack中标记@aviator invariant即时生成。不变量由确定性脚本或不同代理逐条验证，避免生成与验证同源带来的盲区。团队可先从不变量入手，因为成本最低且PR历史已包含大部分规则。
分阶段落地：从双倍工作到证据审查
文章给出三个月过渡路径：第一个月团队仍逐行审查，同时积累不变量；第二个月不变量开始拦截问题，审查量减少；第三个月审查者主要阅读意图、决策和证据，仅在异常时打开diff。文章提醒不要一次性全开，并指出预览环境并非必需，代码扫描可先处理结构性检查。
Q&A
AI代码审查中“代理验证、人来决策”具体是什么意思？
代理验证指由独立的验证代理在预览环境中运行场景，并附上截图、日志等证据；人来决策指人依据这些证据判断是否合并代码，而不是逐行阅读代码。
为什么不能让写代码的同一个AI模型来审查代码？
因为同一个模型写和审会共享相同的盲点，验证必须与生成在结构上分离，并且要产出证据而非仅仅给出意见。
不变量（invariants）和验收标准（acceptance criteria）有什么区别？
验收标准描述本次变更应该做什么；不变量是团队或工程组织始终为真的规则，无论变更内容是什么。两者结合才能既满足本次需求又符合团队标准。
如何从现有的PR历史中提取不变量？
Verify会读取团队在GitHub上发布的评论，从中发现模式并起草不变量；也会从CONTRIBUTING.md和代理指令文件中起草，或在PR评论/Slack线程中通过@aviator invariant即时生成。
审查者在不逐行读代码的情况下具体看什么？
审查者阅读意图、查看核心变更的热点、过目每个决策以及每条验收标准和不变量的判定结果，并可打开实时预览自行查看变更。
团队应该如何分阶段引入这种审查模式？
不要一次性全部开启。第一个月从不变量开始（成本最低，PR历史中已有），团队仍会审查代码；第二个月不变量能捕获足够多问题，审查量减少；第三个月审查者主要阅读意图、决策和证据，仅在异常时打开diff。
