Vibe Coding：速度不是省略验证的理由

这个词原本没有那么宏大

2025 年 2 月，Andrej Karpathy 用“Vibe Coding”形容一种很具体的状态：完全顺着感觉走，不再仔细阅读代码，把报错复制给模型，反复要求修改，直到程序看起来能够运行。

这段话很快被解释成一种新的编程范式，甚至被赋予“代码已经不再重要”的意义。但 Karpathy 在原文里给出的场景，是一个可以随手丢掉的周末项目。

这层限定很重要。做一个今晚用完就算的小游戏，和修改支付系统、用户权限或数据库结构，显然不该采用同一种工程方法。

AI 让代码生成变得便宜。过去需要查文档、拼接口和写样板代码的工作，现在几轮对话就能完成。人不必亲手敲下每一行，也可以做出有用的软件。

但代码由谁生成，与谁对结果负责，是两个问题。

如果我接受一段自己没有读过的代码，我其实做了一个选择：用理解成本换取速度，并承担里面可能存在的错误。这个交换并不总是坏事。关键在于，错误发生以后是否容易发现、是否可以撤销、会伤害谁。

Vibe Coding 不是对或错的身份标签，而是一种风险偏好。

目前的证据没有给出一个适用于所有人的答案。

GitHub 曾在一项受控实验中，让 202 名开发者完成一个 API 端点任务。使用 Copilot 的参与者在部分功能性、可读性和代码质量指标上表现更好。这个结果说明 AI 在边界清楚的任务里可以提供帮助，但它来自供应商研究，也只覆盖了一类任务。

METR 在另一项随机对照研究中，观察 16 名熟悉大型开源项目的开发者完成真实任务。使用 2025 年初 AI 工具的参与者平均反而多花了 19% 的时间，而且他们主观上仍认为自己变快了。

两项结果并不矛盾。陌生的小任务、熟悉的大型代码库，新手、资深维护者，生成代码、理解上下文，本来就有不同的成本。把其中任何一个数字推广成“AI 必然提效”或“AI 只会拖慢”，都走得太远。

AI 的价值取决于任务，也取决于验证生成结果要花多少力气。

我越来越少问“这段代码是不是我亲手写的”，而更常问：我有什么证据相信它可以工作？

一个足够简单的流程是：

这些步骤不会消除错误，人工编写也做不到。但它们把“感觉能用”变成一组可以重复检查的证据。

AI 编程工具自己也在朝这个方向发展：代码生成之后自动运行测试、静态分析和安全检查。真正成熟的 AI 辅助工程，不是让人永远盯着每一个字符，而是让生成和验证共同自动化。

Vibe Coding 最吸引人的地方，是它让想法第一次离成品这么近。一个不熟悉编程的人，也可以在几小时里做出能够操作的东西。这种自由值得珍惜。

但自由不等于所有软件都可以按照周末项目的标准交付。原型的任务是证明想法，生产系统的任务是长期兑现承诺。前者允许我们不知道代码为什么有效，后者迟早会要求有人回答这个问题。

代码可以越来越多地由 AI 生成，工程责任却不会因此消失。

速度来自减少无价值的手工劳动，不该来自省略必要的验证。