如何在不阅读代码的情况下审查AI代码
内容提要
文章指出，AI已接管大部分代码审查，但团队通过审查讨论决策、建立系统认知的部分被忽视。作者提出“智能体验证、人来决策”的五层框架，强调应记录并辩论AI生成代码中的关键决策，由具名负责人最终拍板，而非逐行读代码。
延伸解读
AI审查的盲区：决策不在代码差异中
文章指出，AI代码审查擅长机械性工作，如查找缺陷、保持标准一致，但它看不到开发过程中做出的关键决策。这些决策——例如选择令牌桶还是滑动窗口、故障时放行还是关闭——往往不会出现在代码差异里。因此，即使AI审查覆盖了大部分PR，团队仍可能丢失对“为什么这样改”的理解。这提醒我们，AI审查不能替代团队对决策的讨论和记录。
从逐行审查到决策辩论：新五层框架
作者提出“智能体验证、人来决策”的五层框架，前三层由机器完成，后两层“辩论”和“拥有”由人负责。辩论层要求团队在AI生成的代码中识别关键决策，并在讨论线程中辩论；拥有层则要求每个决策由具名负责人最终拍板。这一框架旨在解决两种极端：逐行审查成为瓶颈，或橡皮图章式通过导致失控。
决策记录优于规格文档：事后捕获更实际
文章对比了审查规格文档和审查决策记录。规格文档写在前头，容易脱离实际，且实现一开始就会漂移；而决策是在工作中实时产生的，简短且具体。因此，作者建议在编码会话结束后捕获意图和验收标准，而不是要求事先写规格。这样，审查者无需逐行读代码，只需围绕决策进行辩论，就能理解变更并建立系统认知。
问责不可少：每个决策需有具名负责人
文章强调，模型没有声誉，也无法被追问“为什么”，因此每个经过辩论的决策都必须由一位具名的人同意并负责。这解决了AI审查无法问责的问题。作者建议团队自问：“上周我们决定了什么，谁同意的？”如果答不上来，说明决策记录和问责机制缺失。这提醒团队，在依赖AI审查的同时，必须保留人类对关键决策的最终责任。
Q&A
为什么说工程师已经不读代码了？
Faros AI 报告显示，自上次报告以来，未经审查就合并的拉取请求增加了 76.3%，许多公司现在对 50% 到 80% 的 PR 运行 AI 审查。AI 审查接管了找 bug 的工作，因此工程师不再逐行阅读代码。
AI 代码审查有哪些局限性？
AI 审查擅长机械性工作（如找 bug），但它没有参与决策过程，不会告诉你不要构建某个东西，也无法对结果负责。它读取的是错误的工件（代码差异），而不是决策记录。
什么是“智能体验证、人来决策”框架？
该框架有五层：前三层（如捕获、验证等）由机器完成，工具已存在；后两层“辩论”和“拥有”由人完成。原则是智能体负责验证，人类负责决策，因为人更擅长判断变更是否正确、权衡取舍并承担责任。
如何在不逐行读代码的情况下审查 AI 生成的代码？
审查者应关注决策而非代码行。每个决策有独立线程，人类和智能体分开标注，审查者可以同意、质疑、覆盖或将决策转为后续任务。审查者只需三步：理解意图、查看决策线程、参与辩论，无需逐行阅读。
为什么审查决策比审查规格说明更好？
规格说明写起来耗时，在工作带来任何学习之前就写好了，且实现一开始就会偏离。决策来自工作本身，是实时产生的、简短的，每个决策都因为变更可能走向另一条路而存在。
在决策审查中，谁对最终结果负责？
每个经过辩论的决策最终都由一个具名的人同意并负责。模型没有声誉，也无法被追问原因，因此“辩论”层之后会移交给“拥有”层，由人来签字确认。
