Vibe Coding（氛围编程）
Vibe Coding（氛围编程） 是由 Andrej Karpathy 提出的编程范式描述：开发者不再严格规划每一步，而是凭直觉（“vibe”）给 AI 描述意图，让 AI 快速生成代码，再根据报错或不满意之处反复修改，通过高速迭代逼近目标。
这种方式的核心依赖是 Loop Engineering（循环工程）——AI 生成代码 → 运行验证 → 把报错/失败反馈给 AI → AI 再改 → 循环，直到通过。
为什么 Vibe Coding 非常消耗 Token
每一次循环迭代都会累积历史上下文：第一轮的对话 + 代码 + 报错，会全部进入第二轮的输入；第二轮再加上新代码和报错，进入第三轮。修一个 Bug 循环十次，Token 消耗以指数级增长。
这完美契合了 AI 公司按 Token 计费的商业逻辑——越难搞定的问题、越混乱的代码库，产生的 Token 消耗越多。
前提：必须是封闭性任务
Vibe Coding 能运作的核心前提，是编程属于 Closed vs Open Tasks（封闭性任务与开放性任务）：代码对不对有明确的机器验证标准（测试通过/失败、编译报错与否）。AI 不需要每次都对——只要验证环境能给出清晰的失败信号，AI 就能在下一轮修正。
在没有客观验证标准的开放性任务（写报告、做决策）里，同样的试错循环会因为无法判断"对不对"而失效。
风险
- Comprehension Debt（理解债）：代码跑起来了，但开发者不理解它为什么能跑；下次出问题更难排查。
- Cognitive Surrender（认知投降）：循环跑得太顺，开发者停止主动思考设计，完全被动接受 AI 的方案。
- 质量债：快速试错容易绕过架构问题，而非解决它；技术债以隐蔽的方式积累。
- Goodhart’s Law（古德哈特定律）陷阱：以"测试通过"为验收标准，AI 可能删测试而不是修 Bug。
适用场景
| 适合 | 不适合 |
|---|---|
| 原型验证、一次性脚本 | 核心业务逻辑、需长期维护的代码 |
| 有完整测试覆盖的项目 | 测试覆盖率低、难以验证的场景 |
| 开发者熟悉领域能快速鉴别输出质量 | 陌生领域、无法判断 AI 方案好坏 |
相关概念
- Loop Engineering（循环工程） — Vibe Coding 依赖的底层工程范式
- Closed vs Open Tasks（封闭性任务与开放性任务） — 封闭性任务是 Vibe Coding 能运作的前提
- Comprehension Debt（理解债） — Vibe Coding 的主要认知成本
- Harness Engineering（驾驭工程） — 为 Vibe Coding 提供约束，防止 AI 钻规则漏洞