四模型串联审查vibe-coded代码安全

代码如今用大白话就能写。你描述需求，模型交出一个成品应用，运行起来，一切看起来都正常。但"能用"和"安全"是两个词，中间隔着别人的钱和泄露的数据。最近的统计显示，近一半 AI 生成的代码存在漏洞，三分之一的这类项目上线时就带着一个谁顺着链接就能钻进去的洞。

原因很简单：模型写代码时，生成的是概率上最可能出现的下一个片段，而不是最正确的那一个。它看不见自己的错误——因为它看代码的眼光和写出这些代码时一模一样。发现这些错误需要一个外部视角。更好的做法是，同时拥有多个视角，每个都有各自的盲区。

于是我构建了这样一套流程：让代码依次流经四个不同的模型，每个都从零开始、各司其职。第一个制定计划，捕捉粗制滥造的部分。第二个，下手狠的那个，深挖——哪里会崩，哪里有副作用，哪些边界情况。第三个接起前两个踩过去的东西，审视边界和安全。第四个汇总拍板：干净，还是打回重修。这套方法论已经公开发表，带 DOI——不是噱头，是工程流程。

为了演示这套流程怎么跑，我从 GitHub 上抓了一个现成的开源项目——一个 Python + Flask 的任务管理应用，约 2700 行代码，有注册、登录、角色、邮件和 Telegram 通知。就是这类人们现在花几个晚上就能上线的产品。我故意不提作者名字：重点不是要羞辱某个人，而是要展示几乎每个人都会踩的典型坑。以下是这套流程在一小时内发现的问题。

发现一：一把主钥匙直接写死在源码里

应用里有一把密钥，用来给每个用户的入场凭证签名。代码里写的是：从环境变量读取密钥，如果没有——就 fallback 到 super-secret-key。

听起来无害。实际上意味着：如果发布者忘了在启动时设置自己的密钥——他们几乎总是忘掉，因为"反正也能跑"——应用会悄无声息地使用这个 fallback。它对所有下载了这份代码的人来说是一样的，而且就明晃晃躺在公开仓库里。知道它的人可以给自己签一张管理员凭证，以主人身份登堂入室。门上有锁，但备用钥匙就挂在门边的一颗钉子上，而那颗钉子在街上就能看见。

同样的问题在隔壁：管理员和管理员角色的密码码也直接写死在源码里带着 fallback——admin*123* 和 manage*159*。读过代码的人都知道管理员密码。

发现二：一张可以伪造的凭证

应用给已登录用户发一张数字凭证（JWT），之后靠它辨认用户。签名校验本身做得挺仔细——没什么好挑剔的。但有一个细节，几乎总被一个模型漏掉，而狠角色二号能抓住它。

验凭证的时候，代码相信凭证本身声称的签名方式。就像一个保安用凭证上印着的方法去校验凭证上的印章。如果伪造者在上面写"无需校验印章"——保安就乖乖地不校验了。这是自制凭证校验里一个老掉牙的、众人皆知的漏洞，而这里的校验恰恰就是手写的，不是从成熟库里搬过来的。

发现三：一个随机导致校验失败的小东西

在解码凭证的同一处代码里，补位计算有一个算术错误——那种不到撞上就看不见的错误。大多数时候能过，但在特定数据长度下数学结果会出错，解码不知从哪里就崩了。用户看不到明确的错误，只看到"登录无缘无故地用不了"。这类 bug 后面要找上好几天，因为它们不是每次都复现。

这算什么级别的审查

这三个发现没有一个会在正常运行中露出来。应用启动正常，注册正常，登录正常——"能用"。漏洞正好藏在单个模型不会去看的地方，因为它自己写的代码，它信得过。二号、三号、四号视角——正是它们把这些揪了出来。

而且这不是含糊的"我觉得有点弱"。每个发现都附上代码里的精确位置、风险解释和修复方法。报告做成可以原样丢给同一个 AI 说"修这个"——然后拿到修复方案。

说个真实的数字：之前我用同一套流程跑过自己的请求路由库——1211 行，124 个通过的测试，严格类型。我以为已经完工了。四个声音一小时内找出了 8 个缺陷。所以外部视角不只是为了别人的 vibe-code——对任何代码都适用，包括我自己的。

如果你也有这样一个项目

用 Cursor、Lovable、Bolt、Replit，或者直接在 AI 对话里做了一个产品，准备给真实用户上线了？在做之前，让代码过一遍这样的审查。我提供这项服务：你发来仓库链接或压缩包——一天内你收到工时估算、时间线和报价。小项目 48 小时内出报告。而且我在每个档位都恪守一条规则：审查如果没有发现任何一个有价值的问题，你不付费。

服务页面含定价和详情——quantareon.com/audit.html 直接联系我——Telegram @quantareon

第一反应是噪音。第二反应是信号。