从测试角度审视氛围编程的价值

现在，围绕 vibe coding 的讨论非常喧嚣。

人们凭着感觉就能生成完整的应用，借助 LLM 在几分钟内把想法变成代码。我承认，这确实令人惊叹。但从事测试工作 20 多年后，我忍不住注意到：这里似乎缺少了某些东西。

这种能量是真实的。这种速度让人上瘾。但稳定性呢？可靠性呢？往往无处可寻。

这正是我能发挥作用的地方。

我的职业生涯大部分时间都在做测试。我的工作始终是确保产品能够兑现承诺——不只是在理想化的演示中，更要在真实场景下做到这一点。

各种测试我都经历过：自动化测试、探索式测试、性能测试、安全测试、混沌测试。当 vibe coding 进入大家的视野时，我很好奇。

我开始用它构建项目。

我开始测试它。

然后，我开始破坏它——轻而易举。

纯靠感觉的问题

Vibe coding 缺少支柱，也缺少明确的意图。AI 可以生成代码，但它能验证代码吗？能自我纠正吗？能知道自己什么时候出了问题吗？

除非我们为它提供相应的工具，否则不能。

这时，我的测试人员思维开始发挥作用。我创建了一个名为 vibe-todo 的项目，用它来证明：只要有结构和测试的引导，vibe coding 完全可以切实可行。

真正带来改变的是这些：

• 将 Hypothesis 测试作为自我纠正的检查点
• 使用 .windsurfrules 文件告诉 AI 应该如何行动
• 通过基准测试强制执行 SLA（每次操作最长 10ms）
• 使用结构化日志，让 LLM 能够观察并作出反应
• 使用 Grammatical Evolution 引擎动态生成边界情况

没错，我甚至使用 DEAP 接入了一套基于 GE 的进化测试套件，让输入随时间不断演化。它真的会对 payload 进行变异，找出那些被单元测试遗漏的故障。

就这样，LLM 生成的代码从纯靠感觉，变成了经过验证的代码。

说点实际的：没有测试会发生什么？

举个例子。

LLM 曾经生成过一个非常漂亮的 CRUD API，看起来无可挑剔。

但发送包含空字符串的 POST 请求时，并不会触发验证。更糟糕的是，当时没有任何单元测试能够捕获这个问题。直到 Hypothesis 测试开始快速失败，我才发现它。

这不是什么边界情况，而是一个实实在在的缺口。

没有测试，LLM 就会对代码的正确性产生幻觉。

结构化日志 = LLM 的可观测性

每次操作，我都会输出结构化的 JSON 日志：

{
  "operation": "add_task",
  "duration_ms": 8,
  "sla_pass": true,
  "timestamp": 1713040000.01
}

这样，Windsurf Agent 就能监控输出、检查是否符合 SLA，甚至根据违规模式提出修复建议。

这就像把 Grafana 装进了 LLM 的脑子里。

每个 Vibe Coder 都应该加入什么

你不需要拥有 20 年的测试经验，也能让自己的 vibe 更可靠。可以从这里开始：

最小测试宣言

• .windsurfrules（你与 AI 之间的编码契约）
• 用于验证行为的 Hypothesis 测试
• 针对已知失败状态的回归测试
• 强制执行 SLA 的基准测试
• 使用 Grammatical Evolution（GE）进行 fuzzing 和边界情况探索
• 用于 Agent 反馈的结构化日志

即使你只做到了其中一半，也已经走在前面了。

我对社区的呼吁

不要放弃 vibe coding。

让你的 vibe 可以被测试。添加规则。使用基准测试。像测试人员一样思考。

然后呢？让 LLM 靠自己的表现赢得那个绿色对勾。

我测试软件已经有几十年了。可以明确告诉你：

感觉良好的代码，并不一定真的好。

但结构清晰、经过测试、跑过基准测试，同时感觉依然良好的代码呢？

Vibe coding 并不一定意味着风险，它也可以很有韧性。

它可以带着明确的意图。

凭 vibe 构建。由测试验证。随时可以投入生产。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。