现状：用数据与来源说话
到 2026 年，多项独立研究不再谈论印象，而是开始测量。被引用最多的结论可以浓缩为一句话：根据实证评估，AI 生成的后端代码中只有约 35% 同时既安全又正确。换言之，在多数情况下，所生成的代码要么错误，要么脆弱，要么两者兼有，哪怕它「看起来」能运行。
含有至少一个漏洞的代码占比，依研究不同被估计在 62% 至 92% 之间。这是一个很宽的区间，也应当如此看待：各方法学彼此不同（所测试的语言、漏洞的定义、所采纳的严重度、提示语料库）。这一区间中的任何单一数字，都不应在未注明研究及其方法的情况下被孤立引用；诚实的信息是这个区间，而非某一个点。
风险并非理论上的。Georgia Tech 的「Vibe Security Radar」记录到与 AI 生成代码相关的 CVE 在 2026 年第一季度急剧攀升：一月 6 个、二月 15 个、三月 35 个，也就是说，仅这三个月就超过了整个 2025 年的总和。
在观感层面，不信任与数字同步：87% 的开发者表示怀疑 AI 生成代码的可靠性。用得最多的人，往往最先不会盲目信任它。
出于诚实，须做一点方法上的说明：这一语料主要是产业界的安全研究——安全公司的报告、审计、基准测试——而非一批经过同行评审的学术文献。其中真正称得上学术的仅有一项（一篇 arXiv 论文）；其余皆出自产业界。这并不使这些数字失真，但要求我们按其本来面目来读它们：相互印证的独立测量，而非已成定论的科学共识。
其中一项工作值得点名，因为它恰好界定了这场争论：独立基准 Vibe-Eval（2026）以应用安全的标准，编目了若干主流生成器——Lovable、Bolt、Cursor、Replit、v0——的失败模式。这正是一个发布注明日期的运行时校验的引擎可以正面较量的场域，而不必退回到信任。
- AI 生成的后端代码中约 35% 同时既安全又正确（实证评估）。
- 62% 至 92% 的生成代码含有漏洞——区间很宽，方法各异。
- 相关 CVE：每月 6 → 15 → 35（2026 年 1 月 → 3 月，Vibe Security Radar，Georgia Tech）。
- 87% 的开发者怀疑 AI 生成代码的可靠性。
为什么：概率式模型产出的是貌似合理的代码，而非有保证的代码
原因是结构性的，而非一时的。大型语言模型在给定上下文下产出最可能的 token。应用到代码上，这给出的是最像样的后续，而未必是正确的、也未必是安全的。模型没有「这个 schema 能编译」「这个查询已参数化」「这个访问控制存在」这类内在概念；它有的是「这类代码看起来是什么样」的概念。
这恰恰使问题变得阴险：幻觉出来的代码貌似合理。它读起来通顺，有时能编译，能部署，却在使用中失败——或更糟，表面上能运行，却留下一个 SQL 注入、一个明文的密钥、一处缺失的授权校验。各项研究记录的反复出现的缺陷类别（注入、密钥管理不当、缺少输入校验、访问控制失效），正是模型会复现的那些，因为它们在其训练数据中比比皆是。
在提示中加一句指令（「写安全的代码」）会挪动概率，却不改变对象的本质：没有什么能保证结果，因为没有什么去校验它。一句指令不是一份证明。
改变一切的区分：AI 撰写规格，构建器编译代码
Blueprint Maker 从这一认识出发，拒绝让模型来写代码。流水线把两个本无须混同的角色分开。AI 做它最擅长的事：理解一个业务领域，并产出一份结构化的规格——一份以 JSON 表示的实体、关系与规则的 schema。它做设计，而不写代码。
接着，确定性的构建器——只写一次、经过测试、有版本管理——把这份规格转化为代码：数据库 schema、页面、路由、仪表盘。因此代码从不由 LLM「幻觉」而来：它由一个行为已知的程序产出。组件的属性不是被猜出来的，而是按固定规则从规格推导而来。同一份规格输入，永远产出同一份代码输出。
这种分离并不会神奇地消除一切风险，但它把问题挪到可处理之处：与其寄望一个概率式模型没有在数千行独一无二的代码里埋下缺陷，不如以构造方式保证代码的范式（查询、表单、控件）都出自唯一的、可审计的生成器，并可一劳永逸地修正。
- AI → 理解领域 → 产出一份规格（而非代码）。
- 确定性构建器 → 编译规格 → 产出代码。
- 代码不是由模型逐行推断而来：它由一个已知的程序生成。
可被追责的防线：一份公开发布的运行时校验（K-15 / Health Score）
以更安全的方法来写代码，在被证明之前始终只是一个承诺。决定性的区别不在于宣称「我们的代码可靠」，而在于测量它并公布测量结果。Blueprint Maker 产出的每一个应用都要经过一道自动化的运行时校验，名为 K-15：代码被编译，应用被真正启动，随后由一个自动化浏览器逐屏走查。判据是二元的：它能跑，或者不能跑。
聚合结果——在七天滑动窗口内通过全部这些检查的应用占比——以 Health Score 为名公开发布并注明日期。这是一项可被追责的可靠性指标：可核验、非自我声明、由一个自动裁判而非营销说辞产出。
这恰恰是任何纯概率式生成器都不会公布的，而且有一个根本原因：产出这样一项测量，需要一种确定性、可复现的方式在真实条件下测试每一份输出。一条让模型写代码并原样交付的流水线，没有可展示的系统性运行时关卡。唯有当可靠性被构建为可测量时，关于可靠性的透明才成为可能。
我们的局限，坦诚而言
运行时校验证明一个应用能够构建、启动并被正确走查；它大幅减少了「貌似合理却已损坏的代码」这一类错误。它并不取代一次完整的应用安全审计、一次渗透测试，或一次合规审查。Blueprint Maker 迄今并不声称拥有 SOC 2 或 ISO 认证：我们宁愿公布一项真实、注明日期的指标，也不要一个对所交付产品毫无说明的标识。
正确的读法是这样：AI 生成的代码存在一个被测量的可靠性问题；唯一可信的回答不是承诺，而是一份公开发布的核验；把设计（AI）与制造（确定性构建器）分开，使这种核验成为可能且可复现。这是一个基础，而非一张空白支票——它胜过一个你不肯拿出来的数字。
来源
Cloud Security Alliance, Vibe Coding / AI Governance Gap：https://labs.cloudsecurityalliance.org/research/csa-research-note-vibe-coding-ai-governance-gap-20260602-csa/
The Security Crisis in AI-Generated Code (2026)：https://blog.vibecoder.me/security-crisis-ai-generated-code-2026
IOActive, The Security Gap in AI-Generated Code：https://www.ioactive.com/wp-content/uploads/2026/05/IOA-The-Security-Gap-in-AI-Generated-Code.pdf
AppStuck, AI-Generated App Security Risks (2026)：https://www.appstuck.com/blog/ai-generated-app-security-risks
Vibe-Eval, AI App Security Benchmark 2026：https://vibe-eval.com/data-studies/ai-app-security-benchmark-2026/
Sherlock Forensics, AI Code Security Report 2026：https://www.sherlockforensics.com/pages/ai-code-security-report-2026.html
OX Security, Vibe Coding Security：https://www.ox.security/blog/vibe-coding-security/
arXiv, Coding With AI：https://arxiv.org/pdf/2512.23982