58 项实证研究给出的冷水：AI 代码 40-50% 有可利用漏洞

2026 年 10 月发表的一篇系统性综述，梳理了 2024 年到 2026 年初的 58 项实证研究，结论比宣传口径冷得多。

几个关键数字

超过一半的 AI 生成代码在评估后被丢弃。生产力提升最明显的场景是样板代码、文档和单元测试脚手架；在架构决策和企业级调试上收益有限。47 项研究里，自评生产力与客观测量的生产力之间差了 45.6 个百分点。AI 生成代码中存在可利用漏洞的估计比例是 40% 到 50%——这个区间跨任务、工具版本、语言和测量方法差异很大，不能当成某个工具的固定比率，但它足以说明「聚合质量声明需要谨慎测量」。

一个容易被忽略的发现

经验丰富的工程师普遍获得「AI 增益」，而初级工程师面临「AI 拖累」，原因是学习成本被省略了。在一个为期 14 个月的同组对照里，结构化带教把差距缩小了。

这条对团队管理的含义很直接：如果让新人直接拿 AI 出活，短期看似交付变快，两年后你会发现没人能判断产出对不对。

实践上的结论

不是「别用 AI」，而是把工作重心从「写」转到「审」。可以用的一套顺序是：先定验收标准（人审），再给聚焦的上下文（相关测试、回归用例、最近的失败日志），然后保持确定性检查在流水线里（单元、集成、契约、安全、依赖、许可证），最后让 Agent 在最小权限、隔离 runner、写入前需审批的边界内跑。

衡量指标也要换：看变更失败率、逃逸缺陷、flaky 率、评审与修复耗时，而不是看生成了多少行代码。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

四十五点六分的自评与实测差距最能说明问题，大家感觉快了但实际没快。四到五成的漏洞率别当固定比率看，它更像提醒：生成代码必须走同一条评审流水线，不能因为写得快就审得松。

45.6 个百分点的自评与实测差距，比漏洞比例更值得警惕，因为这说明团队对自己交付质量的判断是失真的。我们内部的调整是把 AI 生成部分的评审权重调高，不看行数看改动影响面，涉及鉴权、反序列化和 SQL 拼接的一律双人过，样板代码才允许直接合。

40% 到 50% 这个区间跨度太大，说明测量方法没收敛。我们扫过一批 AI 生成的接口代码，最集中的问题是没做入参校验和权限判断，逻辑本身反而没错。所以关键不在生成环节，在评审和自动化扫描有没有卡住。