AI 写的代码，我从来不逐行 review：我只看它能炸多大 - 编程一生
内容提要
AI生成的代码不应逐行审查，而应关注其影响范围。机器负责验证代码正确性，通过实际启动、集成测试和证据检查确保可运行；人则评估改动可能波及的代码、数据和运行中的系统，考虑引用范围、旧数据兼容性和发布风险。核心是风险不取决于改动多少，而取决于影响范围。AI缺乏公司记忆，审查时需转换视角。
延伸解读
为什么逐行审查在AI时代失效
文章指出，AI生成的代码语法正确、命名规范，但错误往往隐藏在未写的部分或假设中。逐行审查不仅效率低下，而且容易陷入“看过”的错觉。真正的风险在于改动的影响范围，而非改动本身。因此，审查重点应从代码细节转向影响评估，这是AI无法替代的人类判断。
如何有效验证AI代码的正确性
文章强调，验证AI代码不能依赖编译或单元测试，因为AI倾向于构建理想化的测试环境。必须要求真实启动服务、连接真实数据库、运行集成测试，并让AI提供具体证据。同时，应要求先写一个会失败的测试，并明确指定异常场景，以迫使AI证明代码可能出错，而非仅仅证明其正确。
评估改动影响的三圈模型
文章提出评估改动影响的三圈模型：代码引用范围、数据兼容性、时间维度。第一圈关注代码被多少地方引用，第二圈检查新代码与旧数据的兼容性，第三圈考虑发版时正在运行的系统状态。通过这三圈评估，可以更全面地识别潜在风险，避免仅关注diff本身而忽略隐藏的连锁反应。
Q&A
AI生成的代码应该如何进行代码审查？
不应该逐行审查，而应该关注改动的影响范围。代码正确性交给机器验证，人负责评估改动可能波及的代码、数据和运行中的系统。
为什么逐行审查AI代码行不通？
因为速度不匹配（AI写代码快，人看代码慢），AI的bug不像bug（语法正确但逻辑错误），且炸点常常不在diff里（改动本身没问题，但影响其他未修改的部分）。
如何验证AI写的代码是否正确？
必须真正启动服务，运行集成测试，连接真实数据库和接口。要给出明确的验收标准，要求提供证据（日志、返回内容），让AI先写一个会失败的测试，并点名容易出问题的情况。
为什么编译通过和单元测试全绿不代表代码能跑？
因为编译可能不做类型检查（如前端构建工具默认忽略类型错误），单元测试可能使用假数据，导致真实环境中的问题（如空指针、数据格式不符）无法被发现。
如何评估AI代码改动的影响范围？
从三个圈评估：代码（有多少人用）、数据（新代码能否兼容老数据）、时间（发版时正在运行的系统）。还要问三个问题：最多能炸到谁、多久能发现、能否一键回滚。
AI代码审查中，人应该关注什么？
人应该关注改动的影响范围，而不是代码细节。因为AI缺乏公司记忆，不知道哪些目录被共用、哪些数据有历史问题、哪些流程正在运行。
AI代码审查的放行清单是什么？
根据改动类型分级：纯文案/样式/独立新页面（小范围）AI自测即可；改业务逻辑（中范围）需真启动跑主流程和异常情况；改公共组件/工具类（大范围）需看引用；动表结构/字段类型（最大范围）需检查老数据并准备回滚；动流程/状态机（最大范围）需考虑正在运行的数据。
为什么AI写的bug长得像正确答案？
因为AI生成的代码语法正确、命名规范、有注释，错误往往在未写的部分或假设中，比如依赖的接口返回格式、数据的历史状态等，这些在代码中看不出来。
