Vibe Coding必须补上QA验证环节

现在人人都在 vibe coding。提示词、发布、重复。我的信息流里满是有人花一个周末就做出完整产品的帖子，说实话——我也是其中之一。

但有一个对话没人愿意聊，而它上周差点让我错失一次发布机会：谁来验证 AI 产出的代码？

我是一名独立创始人。快速开发，快速发布——几周前，在让真实的房产经纪人试用之前，我让一个 AI agent 对 VayReach 做了一次完整的 QA 审查。VayReach 是我为房产团队开发的 WhatsApp 跟进 CRM。

它返回了一份缺陷日志，让我心惊肉跳：几十个问题，每个都有 ID（DEF-019、DEF-020……）、严重级别、精确的复现步骤，以及"修复后"应该是什么样子。

Vibe coding 同样以更快速度交付 bug

那些"AI 让我的效率提升 10 倍"的帖子往往省略了一个关键细节：用 coding AI 批量修复问题后，agent 会在部署的构建版本上重新测试每处修复。不是问"部署成功了吗"，而是"bug 真的死了吗"。

最新一轮：17 个缺陷重新测试，12 个通过，5 个仍然失败。结论：未准备好发布。

而一个不断重演的模式——我认为每个 vibe coder 都需要了解的是——几个"已修复"的缺陷以另一种故障形式重新出现了。一个 SKU 唯一性校验不再抛出 500 错误，但却开始拒绝合法的 SKU。修复没有解决问题，只是改变了它出问题的形式。

"已修复"是一个声明，不是事实。在有东西对实际构建进行对抗性检查之前，它只是你在看着绿色部署日志时产生的一种感觉。

AI 构建软件的不舒服的数学题

以前我每行代码都自己写，速度很慢——但大致知道问题藏在哪里。现在 AI 写得快，我审得也快，而 bug 反而更有底气了。它们看起来不像是坏的，更像是已经发布的。

这就是改变的地方：现代独立开发的失败模式不再是"我造不出来"，而是"我造出来了，能部署，但我不知道有什么东西在悄悄出错"。

作为唯一的开发者，我天生无法对自己的工作进行对抗性测试——无论代码是不是 AI 写的。我知道代码应该做什么，所以我测的是我预期的，而不是实际写出来的。agent 不会对我的意图产生这种忠诚，它只是检查。

agent 做不到的事（诚实的清单）

因为"AI 做我的 QA"听起来比实际更神奇：

它不写修复代码。我的 coding AI 负责那块。agent 的工作是发现问题、界定问题和验证——这是 QA 中最不体面的三分之二工作。

它无法判断产品是否足够好。"暂停发布"是我的决定，基于它的结论。agent 负责报告，我来承担后果。

它在勤勉的意义上很慢。一批一批来，不能跳过。有时候晚上我就是想发布，但它不在乎我的晚上。

那么人类的工作现在是什么？

关于 vibe coding 的讨论一直在问开发者是否已经过时。问题本身就错了。代码从来都不是最难的部分——确认它是对的才是。

如果你发布的 AI 生成代码没有经过对抗性验证步骤，你不是在快速前进，而是在以机器速度积累 bug，然后把它叫做"velocity"。

所以这是我真正的问题：如果你用 AI 开发，谁来检查工作——真的？一份检查清单？你自己写的测试（测的是你预期的，而不是实际写出来的）？还是像我以前一样，发布然后祈祷？我很好奇什么真正有效，因为"不信任我的东西"是第一个有用的。

我在 Vayqube Technologies 开发产品——AI 产品、SaaS 平台，偶尔还有面向房产经纪人的 WhatsApp CRM。VayReach 还没有发布。缺陷日志说了算。