知乎热榜这两天挂着一个问题：技术团队引入 AI 编程工具后，用什么方法保证代码质量？高赞回答绕来绕去，其实都在说同一件事——AI 把"写代码"变得便宜之后，"验代码"成了新的稀缺品。
我翻了最近一周的几篇报道，有三个数字放在一起看，特别扎眼。
**第一个数字：7%。**谷歌在官方博客里提到，AI 代码扫描的"真阳率"——也就是报出来的漏洞里真实存在的比例——可能低于 7%。换句话说，AI 一口气列 100 个可疑点，真能复现的可能不到 7 个，剩下九十几个是编的。谷歌为此开源了一套叫 Mantis 的验证流程：AI 报的每条漏洞都要写出 PoC 复现脚本，扔进断网的沙箱里真跑一遍，跑通了才允许生成补丁，最后再打 1 到 10 的风险分。它不多找一个漏洞，只负责让每个漏洞都有证据。
**第二个数字：6157 对 516。**Anthropic 披露，截至 10 月 2 日，Claude 已帮助发现并披露 6157 个开源软件漏洞，经人类专家审查的候选里 92.7% 被确认有效——但真正打上补丁的只有 516 个。发现能力早就溢出了，卡住的是人工审查和修复的速度。用那篇报道的话说：人类正在成为软件安全处理的瓶颈。
**第三个数字：4。**国际上的合规框架也在跟进这件事。NIST 的 AI 风险管理框架把要求归纳为 Govern、Map、Measure、Manage 四部分，欧盟 AI 法案要求高风险 AI 有记录保存和有效人工监督。这意味着"我们会认真审核 AI 的输出"这句口头承诺，以后不够用了，你得拿得出流程证据。
三个数字指向同一个结论：**质量问题的性质变了。**过去代码是人写的，写得慢，但每一行都经过脑子；现在 AI 写得飞快，产出量上去了，可"正确、安全、符合最初意图"这三件事，没有任何一件会随产量自动提升。验收跟不上，产能越大，风险敞口越大。
那普通团队怎么办？这周掘金上一篇拆 Matt Pocock 开源 skills 工具库的文章，给了很实在的思路——不指望模型"自觉清醒"，而是在流程上设硬性关卡：
- **动手前先质询需求。**让 AI 把需求整理成决策树，逐层盘问边界条件、异常分支，关键分支没确认前禁止直接写代码。大部分跑偏，其实在纸面推演阶段就能拦住。
- **用测试当裁判。**强制 TDD：先写一个能稳定复现预期行为的失败测试，再写最简实现让它通过。测试跑不跑得通由机器判决，这是最客观的红线，AI 没法靠"嘴上说完成了"蒙混过关。
- **验收看状态，不看汇报。**AI 说"已完成全部步骤"不算数，要去查它留下的实际结果：文件在不在、内容对不对、系统里记录更新了没有。执行和验收必须是两道独立的工序。
把这三条串起来你会发现，它们和谷歌 Mantis 是同一个哲学：**凡是 AI 的产出，都要有一个不依赖 AI 自述的验证环节。**机器能判的交给测试和沙箱，机器判不了的才留给人。人的时间最贵，就该花在刀刃上。
如果你也在日常工作里用 AI 写脚本、做工具，这套"先立规矩、再要证据"的习惯同样适用——哪怕你不懂代码，让 AI 交付前自己列出"怎么证明它做对了"，也能过滤掉一大半糊弄。我在 spark1.cn 的工具链页面（/toolchains）整理过一批带验证环节的工作流模板，写作、数据处理这类非编程场景也能套用，欢迎去翻翻。
AI 时代真正的工程能力，不是让 AI 写得更多，而是让每一份产出都经得起检查。这件事，你从今天就能开始练。
评论