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 方案好坏 |
门槛降低与领域专家构建
Vibe Coding 的下游效果是：编程能力不再是构建软件的前置门槛——只要领域里有客观的验证信号，非程序员也能把多年专业技能编译成可运行工具。2025 OpenAI Build Week 是这一趋势的集中展示：
- 一位 61 岁、无编码背景的兽医把几十年的临床与运营判断做成分诊工具 veTriage，已在她的诊所试运行
- 一位开罗心脏病专家在医院轮班间隙，把心脏骤停响应的复苏流程做成研究原型 Pulse
- 一位自认“不够技术”的设计师孤身在河内做出越南语声调教练 Dấu，进入决赛
这些案例的共同点不是“AI 直接给了正确代码”，而是领域专家提供判断标准、AI 承担实现与试错。这恰好放大了 Vibe Coding 的边界：它更适合封闭性任务（有客观验证信号）的场景。医疗、音频这些领域之所以能成立，是因为发明者本身就能鉴别 AI 输出的对错、设定确定性验证层——这正是 AI 受限层与确定性系统分工 的前提：AI 只做事后有保障的辅助层，关键决策仍由人或确定性系统把关。
相关概念
- Loop Engineering（循环工程） — Vibe Coding 依赖的底层工程范式
- Closed vs Open Tasks（封闭性任务与开放性任务） — 封闭性任务是 Vibe Coding 能运作的前提
- Comprehension Debt（理解债） — Vibe Coding 的主要认知成本
- Harness Engineering（驾驭工程） — 为 Vibe Coding 提供约束，防止 AI 钻规则漏洞
- AI 受限层与确定性系统分工 — 领域专家要能鉴别 AI 输出，就得让关键路径保持确定性