AI 代码审查还不够：工程负责人如何为 AI 生成的代码设置关卡
最容易通过的 Pull Request，往往也是最需要仔细审查的。AI 生成的代码通常格式工整、注释齐全，还附带一段像模像样的改动说明。
但这些表象并不能告诉你：实现是否安全？新引入的依赖是否存在风险？代码行为是否真的符合需求？这些问题需要独立的关卡来把关。剩下的问题就是：这些关卡应该设在哪里，它们应该检查什么，以及为什么仅靠 AI 审查远远不够。
为什么 AI 生成的代码看起来像是生产就绪，实际上却不是
想象一下，开发者让 AI 助手添加一个“个人资料编辑”接口，方便用户更新自己的显示名称和个人简介。AI 助手返回了一条新路由、一个数据库迁移脚本、一个用来渲染个人简介的 React 组件，外加一堆通过测试的单元测试。
代码差异看起来没什么异常，构建是绿色的，PR 描述也像是细心工程师写出来的。但在同一份改动里，可能藏着一条渲染路径：它在写入 DOM 之前从未对用户输入做转义处理；或者引入了一个 Markdown 解析依赖，而该依赖存在一个没人检查过的公开安全告警。
这个现象值得直接说清楚：现代大语言模型（LLM）通常能生成功能正确的代码，但安全的代码生成仍然是一个难度大得多的课题。
最近，针对真实软件仓库进行的独立基准测试一致发现：模型能生成功能正确的实现，同时仍会引入安全漏洞，而且那些提升功能正确性的技术，并不能可靠地改善安全效果。
这意味着，一次改动可能看起来像生产就绪，通过了测试，却仍然需要确定性的安全检查之后才能安全合并。