警惕AI代码引入的依赖风险

AI 编程助手的确能让代码出炉的速度快上好几倍，但它顺手把新依赖扔进项目里，往往会让团队在后面吃到苦头。想象一下，咱们在写一个小工具，AI 推荐了一个看起来功能强大的库，结果这个库的许可证是 GPL‑3.0，项目本身是 MIT，合并后就可能触碰到版权冲突，甚至导致整个产品必须开源。于是本来省下的时间，最后得花更多时间去审查许可证、替换库或重新谈合规。

除了许可证，依赖本身的维护成本也不容小觑。一个只为实现单一功能而引入的第三方包，往往会带来额外的升级、漏洞修复和兼容性检查。若项目里已经有内部封装的类似功能，直接使用外部库就等于是“重复造轮子”，后期升级时可能要在两个实现之间来回迁移。更糟的是，很多依赖的来源不明，供应链风险随时可能暴露——比如某个库被恶意注入后门，代码审查时只看到实现逻辑，根本发现不了背后的安全隐患。

评审时，除了看代码是否跑通，还得把依赖检查列进清单：① 这个库是否已经在项目白名单里？② 许可证是否兼容当前发布策略？③ 版本是否锁定，是否有已知的安全漏洞？④ 是否真的解决了问题，还是可以用已有的工具替代？如果答案里有“不确定”，最好先暂停合并，等把风险澄清再继续。

最后，AI 生成的代码往往伴随自动化测试，但测试覆盖的往往是“happy path”。真正的风险点——异常处理、边界条件、权限校验——常常被忽视。团队在接受 AI 代码时，应该把“依赖风险”与“异常路径”一起放到评审清单里，确保每一行新引入的 import 都有明确的业务 justification，且对应的错误处理已经在测试里得到验证。把这些细节写进提交说明，大家一起对照检查，才能把 AI 的便利转化为安全可靠的产出。