为什么AI生成的代码总在同地方挂掉

通过测试并不等于通过评审

UAT 告诉你一个变更做了它该做的事，但它不会告诉你当有人从侧面戳它的时候会发生什么。

AI 构建的应用也是如此。它跑起来了，按钮能点了，这些都不能证明它是安全的。这些只能证明它在你——构建它的人——完全按照预期方式使用它是好用的。

在 vibe coding 的工作流中，没有任何机制强制进行这第二步评审。你必须自己构建这个 CAB 环节。

七个反复出现的问题

我在撰写安全手册时，审查了一批 vibe-coded 应用，从中寻找规律。不同的创始人、不同的想法、不同的技术栈细节，但每次都是同样的七个问题，以某种组合形式出现。

发现这些问题不需要你读一行代码。你只需要知道该问什么问题，以及去哪里找答案。一个仪表盘、一个浏览器面板、一条日志。和你检查交换机配置而不去读厂商源码的方式一样。

我之前在这个账号上已经深入讲过其中两个——key exposure 和 RLS——以及各自的具体修复方法。这篇文章是地图，那篇是地形。

这不是假设

Veracode 的 2025 GenAI 代码安全报告测试了超过 100 个 AI 模型、80 个编码任务。AI 生成的代码有 45% 的概率引入真实漏洞。这里需要如实说明这个数据的含义：它来自精心设计的基准测试任务，而不是对野外 vibe-coded 应用直接研究。这是一个强信号，但不是精确匹配。

现实世界的案例更为具体。2026 年 2 月，一位审计人员在审查一个 Lovable 构建的应用时，发现了一个反转的认证检查——它阻挡真实用户，却让任何人都能直接进入。该漏洞暴露了超过 18000 人的记录。

另一个应用 Moltbook 在上线三天后遭到入侵。数据库配置错误且没有行级安全策略，暴露了 150 万个 API token 和 35000 个电子邮件地址。

你不需要学会编程也能发现这些问题

这部分会让很多人意外，值得直说，因为它与常见的建议相悖。你不需要成为开发者就能发现上述七个问题中的任何一个。

不要去买计算机科学课程。不要以为解决方案是"学会正确地读代码"。这是那个昂贵、时髦的答案，但它并不能真正弥合这个差距。

真正弥合差距的是知道该问 AI 工具要什么，以及知道"正确"在屏幕上长什么样。如果你曾经处理过工单、审查过 ACL、或者参加过 CAB 会议，你就已经有了这种直觉。只不过你还没有把它用在你自己的应用上。

七个问题，同样的形态，每次都是——这意味着发现它们不是个谜。它是一份清单，你跑一次，然后永远复用。

如果这听起来有道理，那这份清单就是我围绕它构建的安全手册的完整主干。七个核心发现，每个都有通俗易懂的检查方法，以及每个问题的 prompt，这样你永远不需要靠读 diff 来获得上线信心。如果你想要完整的体系而不是仅仅一张地图，值得看看。在这里找到它《The Vibe Coders Security Handbook》

经验法则

如果没有人专门问过"这个安全吗？"，默认答案是没有。