AI 提速附带一张安全账单

两个数字出自同一份 Gartner 研究， 却几乎从不被一起引用。第一个：90% 的工程负责人反馈 AI 编码工具带来了改进，净生产力提升约 19%。 第二个：未经审查的 AI 生成代码缺陷密度高出 23%，且 14.3% 的 AI 代码片段含有安全漏洞， 而人写代码这一比例为 9.1%。

第一个数字上了头条。第二个数字六个月后写进了事故报告。它们本该出现在同一句话里。

提速是真的——债务也是真的

我不是来抹掉这 19% 的。它是真的，是被测量过的，而且指挥智能体带来的生产力提升正是我之所以这样工作的全部原因。 但一项收益若被引用时不带它的代价，那就不是测量——而是一场推销。诚实的版本是这样写的：AI 让我们快了约 19%，并交付了缺陷率和漏洞率明显更高的代码。

两半都是真的。提速和安全账单由同一件事产出——快速生成大量看似合理的代码——所以你无法只要其一而不为另一项预留预算。

「未经审查」才是承重的那个词

注意缺陷密度那个数字住在哪里：住在未经审查的 AI 代码里。这就是线索。缺陷并非模型愚蠢的固有属性； 而是当生成速度跑到验证前面时，你会得到的东西。快速写代码却没有相应增加的检查，不过是在快速堆积没人看过的风险。

这正是我一再得出的那个结论：当智能体写下大部分代码时，你的杠杆就转移到了审查上。提速是毛收益。 净收益是毛收益减去那些未经审查的缺陷日后让你付出的代价——而「日后」正是漏洞最昂贵的地方。

如何既保住速度又把账单还清

这不是靠放慢速度来解决的。而是靠让检查与写代码同步扩展来解决的：

• 让审查变得审慎而可衡量。 不是扫一眼——而是一道真正的关卡，在代码合并前产出一个信号。你生成得越快， 这一点就越重要。
• 加入专门针对安全的检查。 漏洞率是更高而非更低，所以请依靠 SAST 以及用第二个模型对 diff 做红队演练。 别因为代码能跑起来就假定它是安全的。
• 有意地写出可审查的代码。 SOLID、DRY、KISS 这类原则在这里不是美学；干净、有结构的代码才是人或智能体真正 能验证的代码。糊弄的烂代码会藏住缺陷。
• 把缺陷率和速度并排追踪。 如果你只衡量提速，你就会去优化那个奉承你的数字，而忽略那个给你开账单的数字。

底线

AI 编码带来的生产力胜利是真实的。它同时也带来了可衡量的缺陷与漏洞增长，而那个欢庆版本恰好把这部分略过了。

+19% 的速度和 +14% 的漏洞率是同一个故事——所以把它们一起引用，并用审查来还清这笔账单。 让你的检查扩展得和你的生成一样快，狠狠依靠安全审查，并把代码保持得足够干净以便检视。提速是真的。账单也是真的。