Vibe Coding
为什么重要
深度解析
Karpathy 最初的描述故意带着挑衅意味：不用键盘而用语音输入，每一项建议改动都直接按“全部接受”、不读 diff，再把错误消息粘回模型，直到 bug 消失。剥掉挑衅，工作流很简单——描述、生成、运行、反应——人类更像产品经理和测试员，不再是作者。它在 2025 年变得可行，并不是因为 AI 突然会写代码——AI 编程助手早就写了好几年——而是底层大型语言模型已经好到可以在许多轮循环中维持一整个小项目。几个月内，这个词就彻底逃出技术圈，出现在主流媒体和 Collins Dictionary 年度词汇候选名单上，也成了概括“究竟谁可以构建软件”这场真实转变的默认说法。
让它成为可能的工具
编程助手长出智能体模式后，Vibe Coding 才真正实用。Cursor、GitHub Copilot 和 Windsurf 等工具不再一次补全一行，而是能同时编辑多个文件、新建文件、运行 shell 命令、执行程序、读取输出并继续迭代——这正是 Vibe Coder 想要委派的循环。长上下文窗口让模型可以一次在脑中装下一个小项目的代码，更好的指令遵循能力则意味着，即使意图描述松散，通常也能得到可以运行的东西。Devin 等更自主的工具又把同一种想法向前推进：接收任务描述，在极少监督下持续工作很长时间。
Vibe Coding 最闪光的地方
甜点区是有用但可以丢弃的软件：周末项目、个人工具、一次性数据脚本、原型、演示和内部仪表盘。Karpathy 自己说的就是用完即弃的周末项目——手写成本超过回报，因此过去根本懒得动手的东西。对不会编程的人，吸引力更直接：教师、营销人员或小企业主可以描述一个小应用，一个下午就拿到可用版本；过去要么雇开发者，要么亲自学编程。资深工程师则用同一种模式处理样板代码、迁移和胶水代码，这些任务的解法轮廓很清楚，逐行阅读也不会增加多少价值。在所有这些场景中，隐蔽 bug 的代价都不高，所以跳过审查是理性取舍。
审查债与安全债
风险正是同一个选择的另一面。模型可能为并不存在的库函数制造幻觉、选择废弃 API，或错误连接身份验证；如果没人读 diff，这些失误就会直接发布。AI 安全研究人员反复发现，AI 生成代码带有不可忽视的漏洞率——注入缺陷、缺失授权检查、硬编码秘密——2025 年也发生了一连串事故，匆忙 Vibe Coding 出来的应用在生产环境泄露用户数据或 API key。还有一种更慢、更结构性的成本：没人彻底理解的代码库很难调试；等它长到超出模型上下文窗口，连 AI 都会开始作出互相矛盾的修改。批评者把其中最糟的输出统称为AI 垃圾内容——代码看起来像那么回事，大体也能运行，却在暗中腐烂。
它不等于 AI 辅助编程
一个常见误解是，Vibe Coding 只是所有 AI 辅助编程的新名字。不是。这个词特指放弃审查步骤：如果代码由模型编写，但你读过、理解过，也愿意为它负责，那只是工具更好的普通 AI 辅助开发——Simon Willison 等作者很早就清楚而尖锐地划出了这条线。反面的误解是，人类什么也不贡献。实际中，优秀的 Vibe Coding 也是一项技能：精准描述意图、知道下一步该要求什么，并在输出闻起来不对时察觉出来，都很重要；所以这门做法与提示词工程和上下文工程有大量交集。
专业团队实际上怎么用
多数实际工作的团队最终会落在混合模式上。原型用 Vibe Coding 来做——快速、可以丢弃，只看演示效果——任何将进入生产的东西则接受正常审查，由测试和 CI 充当安全网，替代一开始就逐行阅读。常见边界是风险：内部工具与脚本尽可放手，身份验证、支付，以及任何接触用户数据的功能，则无论怎么写成，都要由人类细看。资深开发者往往从这种风格中得到最多，因为直觉会迅速抓住看起来不对的输出；初级开发者若太早依赖它，则可能发布自己无法解释也修不了的代码。把生成代码视为一名速度极快、却粗心大意的初级同事提交的 pull request——有用、欢迎，但永远不能不读就合并——是许多团队最终达成共识的心智模型。