AI依赖审查的实战案例

上个月我让 AI 帮手重构了一段订单状态流转的逻辑，它交回来的代码看起来非常完整：函数齐全、异常分支也写了、注释甚至比我自己写的还勤快。我差点就点合并了，但临门一脚多看了一眼需求，才发现它把“仅限已支付订单可发起退款”理解成了“所有订单都可发起退款”。从那天起，我对 AI 生成代码的态度就变了——不是不信它，而是审查方式必须跟着变。

我的第一个习惯，是要求提交者在合并请求里说清楚 AI 到底干了什么。它生成了哪些模块、有没有改写已有的逻辑、开发者自己验证过哪些关键路径。这不是给代码贴标签，也不是想把责任推给工具，纯粹是为了让审查的人能快速找到真正需要动脑子的地方。尤其是大范围重构、权限处理、数据写入这类高影响改动，没有这段说明，审查基本等于大海捞针。我见过太多次“看起来能运行”的代码，实际处理的和需求根本不是同一个问题。

依赖变更是我现在最警惕的部分。AI 为了快速完成任务，特别喜欢引入新的第三方库，或者顺手帮你“统一替换”原有的调用方式。这类改动在代码差异里往往不显眼，但后患无穷。我现在的原则是：新增依赖必须单独审，不藏在代码差异里一带而过。先问它是不是真的有必要，现有能力能不能实现同样的事；再看这个依赖的用途和引入范围匹不匹配。为一个小问题引入一个大型依赖，或者只在某个角落用到却影响了全局构建，这种改动我都会打回去重新评估。依赖是项目资产的一部分，不是生成代码的附带物。

测试这块也踩过坑。AI 生成测试代码的能力很强，但测试数量多不代表验证质量高。我后来学到的办法是从业务规则反推测试：需求里有边界条件，就分别构造边界两侧和边界本身的输入；接口涉及失败处理，就确认失败后会不会产生错误的数据写入或重复操作。尤其是修改已有逻辑的提交，一定要补回归测试，不然新代码只能证明“新增功能可用”，证明不了“原有功能仍然正确”。还有一点，测试里过度模拟内部细节也很要命——实现稍一调整测试就挂，却根本发现不了真实的集成问题。

敏感信息检查现在被我从“靠经验临场发现”改成了明确的审查关口。AI 生成示例代码时，真的会把密钥、口令、访问令牌、内部地址直接写进代码和配置文件。哪怕只是测试用途，一旦进了版本库，后续清理追踪都麻烦得要死。我每次都会明确检查：有没有硬编码的认证信息，日志和异常信息有没有暴露个人数据，配置有没有区分环境，新接口有没有扩大不必要的数据访问范围。涉及身份认证和权限控制的改动，光看“代码看起来正常”是远远不够的。

回滚方案是我最近才加进高影响改动必填项的。AI 能快速生成大范围改动，意味着一次提交可能同时触及多个模块。除了看“如何上线”，我更关心“失败后怎么退出”。回滚不一定要保留一套复杂的备用代码，它可以是一个明确的开关策略、可逆的数据处理方案、或者出现异常时的人工处置步骤。关键在于，团队要能判断触发回滚的信号是什么、谁来决策、回退后会不会遗留数据或兼容性问题。如果一项改动无法被安全撤回，那审查重点就应该前移到更充分的验证和更小的发布范围上，而不是寄希望于上线后“先观察”。

说到底，代码审查的核心一直没变：对合并到共同代码库的结果负责。AI 带来的变化，只是让“理解需求、识别影响、验证结果、准备退出”这个过程变得更不能省略。我现在不再问“这段代码对不对”，而是问“这段代码到底理解了需求没有、引入了什么隐性变化、出了问题能不能安全撤回”。这三个问题，替我省下的返工时间，远比多看一眼代码多得多。