用 Lovable、Cursor、Claude Code 或 Replit 做出的 AI 原型,能在一个周末把你带到一个能跑的 demo。它带不了你到生产环境。"在我屏幕上能跑" 和 "扛得住真实用户、真实负载和一次安全审查" 之间的那道缝,正是 AI 生成代码悄悄失效的地方。这是我们对 AI 辅助构建在上线前所跑的 QA 流程,以及我们最常见到的失效模式。
这些都不是反对用 AI 来构建。我们自己也用 AI 构建。这是在说:要像测试任何即将触碰真实金钱、真实数据和真实用户的代码那样,去测试它的产出。
上线了一个 AI 原型?
预约一次生产就绪评审AI 编码工具只优化一件事:产出一个能跑、且符合 prompt 的东西。它们不优化那些决定软件能否在用户接触下存活的东西。模型看不到你的威胁模型、你的数据量、你的边界情况,也看不到你的合规义务。它把 happy path 写得不错,几乎跳过其余一切,因为没人去问。
结果就是:demo 干净、出错可预测的代码。这些故障不是随机的。它们每次都聚在同样的地方,而这正是它们可被测试的原因。
这是我们在每个 AI 辅助构建上逐项过的清单,按出问题的频率排序。

"AI 不是故意写出不安全的代码。它写的是你要求的代码,以及你忘了要求的那些都没写。生产环境,就是你忘了要求的一切之和。"
这是一次 Wavect 评审的结构。在你打电话给任何人之前,可以自己先跑一遍。
这是我们软件 QA 服务的核心。交付的不是一份满是抱怨的 PDF,而是一个修好、测过的代码库,以及让它一直保持修好的测试套件。
部分可以。你一指到位置,AI 工具就会乐意加上一个校验检查,或把一个调用包进错误处理。它做不到的,是决定该去哪里看。它没有你的技术债模型,不记得各部分是按什么顺序搭起来的,也没有那种直觉去预判真实用户第二天会撞上的边界情况。找出这些漏洞是人的活。补上它们,越来越是人机共担的活。我们正是这样推进这类合作的。
对一个典型的 vibe-coded MVP,一轮聚焦的评审加加固跑下来是一到三周。波动由两件事决定:产品触碰多少真实金钱或敏感数据,以及 AI 在无人监督下跑了多远。一个处理支付和个人数据的周末原型,需要的 QA 不止一个周末。一个只读的内部工具则少得多。我们在先看一眼之后再定范围,而不是在那之前。
少见,但确实会发生。如果数据模型从根上就错了,或同一个坏模式被复制到了上百个文件里,那重建核心比打补丁更便宜。我们会在第一通电话里就告诉你这一点,而不是收你一个月的钱去修一个本该重新浇筑的地基。在这件事上诚实,对所有人都更便宜。
AI 生成的代码不是更差的代码。它是没被审过的代码。那个花了一个周末的原型,跳过了每个生产系统都需要的那几周加固,而这几周的账单不会因为第一稿是模型写的就消失。它只是挪到了上线那天,在那时它最贵。
在你把真实用户放到一个 AI 辅助构建面前之前,先把清单过一遍。如果授权、输入和失败路径那几节让你心里发慌,那就是信号:在上线前、而不是事故后,找第二双眼睛来看一看。
上线了一个 AI 原型?
预约一次生产就绪评审