AI代码如何做依赖审查?

AI生成的代码进入仓库的速度越来越快，依赖审查也随之成为评审环节里最容易被低估的一环。很多团队把注意力放在“项目能不能安装、测试能不能通过”上，却忽略了一个更关键的问题：这段代码引入的依赖，是否真的有必要、来源是否可信、是否会悄悄扩大系统的维护边界和安全暴露面。

依赖审查的第一步，是对比变更前后的依赖清单。AI在生成实现时，往往倾向于“解决问题就引入新东西”，而不是优先复用仓库里已有的能力。评审者需要追问三个问题：这个依赖为什么必须加入？项目中是否已经有能够完成同样工作的组件？它的许可证、维护状态和使用范围是否符合团队规范？如果一段代码只是为了处理简单的数据转换，却新增了一个功能庞大的库，这就不是“多装一个包”的小事，而是需要提交者说明理由、或者改用已有模块的信号。一个典型的反面案例是：AI为日期格式转换引入了新的工具包，而仓库原本已经有统一的日期处理模块。此时即使代码运行完全正常，也不应直接合并，正确的处理是删除新增依赖、复用现有模块，并在评审记录中写明依赖选择的依据。

依赖审查真正要防的风险，不是“装不上”，而是“装得太随意”。一个依赖一旦进入代码库，就意味着团队要长期承担它的安全更新、许可证合规和兼容性维护成本。评审时要把依赖当作一笔长期负债来评估，而不是当作一次性的安装动作。对于功能简单、但体积庞大或维护不活跃的依赖，尤其要谨慎；如果AI生成代码引入的依赖只是为了绕过几行手写逻辑，那更值得怀疑它的必要性。依赖清单的每一次变化，都应该有明确的业务理由，而不是“模型觉得这样方便”。

落到实际操作上，团队可以把依赖审查嵌入现有的拉取请求流程，不必单独建立一套繁重的审批机制。在评审清单中增加“依赖变更是否有明确理由”“是否复用了已有组件”“许可证与维护状态是否合规”这几项检查即可。低风险的展示层调整可以快速确认，涉及核心业务或数据权限的改动则要求更完整的说明。依赖审查的目的不是阻止引入新库，而是确保每一次引入都经过有意识的判断，而不是让AI在不知不觉中替团队做了技术选型。