我怎么重新理解 Vibe Coding

我第一次认真看 vibe coding 这个词的时候，其实有点抗拒。它听起来太像一个会被迅速消费掉的流行语，像那种你在社交平台上刷三天就会开始疲劳的说法。可后来我把几篇平台文章、教程和批评性文章连起来看了一遍，反而觉得这个词虽然悬，但它背后描述的变化是真的。

真正让我改观的，不是有人说它会颠覆软件开发，而是我发现越来越多产品、教程和实践，确实在把开发重新组织成一种“人说目标，AI 产出实现，再一起迭代”的流程。问题不在于这个词准不准确，而在于我们是不是已经需要一套新语言，去描述这种工作方式。读完这篇文章，你会看到我现在怎么理解 vibe coding，它为什么会火，它真实的工作流到底长什么样，以及我为什么觉得它最值得警惕的地方，不是生成代码本身。

一句话先说结论：vibe coding 最有价值的地方，是把原型阶段压缩得足够短；最危险的地方，是它也会顺手压缩你对风险的感知。

它为什么突然火了

我后来觉得，vibe coding 之所以会在这么短时间里爆开，不只是因为名字抓耳，而是因为它刚好命中了一个老问题，也就是从“我有一个想法”到“我手上有一个能跑的东西”，中间那段路一直太长。

如果你本来就是工程师，这段路虽然麻烦，但大多还能走。你知道怎么起项目，怎么选框架，怎么配环境，怎么 debug。可如果你是创业者、设计师、学生，或者只是一个业务侧的人，这条路经常不是长，而是根本进不去。

我觉得 vibe coding 最厉害的地方，是它把开发入口从“先掌握实现”改成了“先把意图说清楚”。这听起来像一句市场文案，但它确实改变了很多人的第一步。你不再必须先会写每一行代码，才配开始做产品。你可以先描述目标、界面、流程、限制，然后让 AI 帮你铺出第一版实现。

我现在回头看，很多人第一次被它震住，不是因为 AI 写代码这件事多神奇，而是因为“原来我脑子里的东西，真的可以这么快变成一个能点、能看、能试的东西”。这一点一旦成立，传播速度就会非常快。

💡 我后来意识到：很多人追的并不是“AI 写代码”，而是“我终于能直接推动软件成形”。这两件事很像，但不是一回事。

它到底是什么

不过我后来也发现，很多争论从一开始就没对齐，因为大家说的根本不是同一个东西。有人把 vibe coding 理解成 AI 写代码，有人把它理解成无代码开发的升级版，还有人把它当成一种产品原型方法。

对我来说，比较准确的定义是，vibe coding 不是单个工具，也不是某个模型能力，而是一种人机协作工作流。人类主要负责意图、约束、判断和取舍，AI 负责把这些意图往实现层推进，比如生成代码、改结构、补细节、修错误，甚至顺手帮你把配置和环境也带过去。

我一开始最容易混淆的地方，是把它和传统自动补全放在一起。后来再看，差别其实很大。自动补全是在你已经知道要写什么时，帮你把输入变快。vibe coding 则更像是你先说“我要一个什么东西”，再让 AI 帮你把实现路径展开。

Figure 1: 在 vibe coding 里，人负责目标和判断，AI 负责把实现往前推。

这也是为什么我现在不太愿意把它叫“更聪明的代码助手”。那个说法太轻了。更接近现实的说法是，开发活动的重心正在被重新分配。你可能不再亲手写出绝大多数实现细节，但你要对方向负责，对结果负责，也要对风险负责。

理解到这里之后，下一步才真正重要，也就是它在现实里到底是怎么跑起来的。

真实流程长什么样

如果只看短视频或者营销 demo，你很容易以为 vibe coding 是一句 prompt 出结果。说一句需求，等几十秒，项目就长出来了。可我把教程和实操文章串起来看以后，最大的感受反而是，真正可用的 vibe coding 一点也不省判断。

它更像一个循环。通常从一个模糊想法开始，然后进入 prompt 阶段，把产品目标、页面结构、技术偏好和限制条件尽量讲清楚。接着 AI 生成第一版，你开始 review，看方向对不对，哪里像样，哪里跑偏。然后一定会进到 debug 和 refine，也就是继续补上下文、贴报错、缩小范围、加约束、再生成一轮。

我以前会误以为这套流程的核心是 prompt。后来才意识到，真正决定质量的常常不是第一次 prompt，而是后面的反馈密度。你有没有指出问题的能力，有没有拆任务的耐心，有没有在系统开始跑偏时及时收手，这些都比“会不会写一句很炫的提示词”更关键。

Figure 2: Vibe coding 的真实形态是一条反馈回路。

还有一个我后来很认同的点是，好的 vibe coding 其实很像项目管理。你要会拆任务，知道什么时候该停，什么时候该回滚，什么时候该换一种描述方式。很多实战教程都在强调 checkpoint，我以前觉得这只是平台功能包装。后来想想，它背后其实是在承认一件事，AI 会把项目一路带歪，如果你没有稳定节点，后面会修得越来越乱。

这也是我现在最认同的判断：vibe coding 不是省掉判断，而是把判断从“怎么写”挪到了“往哪走、哪里错、能不能收”。

所以现在如果有人问我 vibe coding 的本质是什么，我不会说“AI 替你开发”。我更愿意说，它把开发变成了一条更高频的人机反馈回路，而这条回路里，人的判断并没有消失，只是从敲代码转移到了提目标、查偏差和做取舍。

它为什么这么上头

我自己现在能理解，为什么很多人一碰到 vibe coding 就会迅速上头。不是因为它让一切都变简单了，而是因为它把反馈变快了。

你说一句，界面出来了。你改一句，流程变了。你贴一个报错，系统又往前走了一步。这个节奏很容易让人产生一种强烈的创作感，尤其当你以前已经习惯了漫长的起项目、找依赖、调样式、补脚手架流程之后。

更重要的是，它不是只对工程师有吸引力。对不同角色来说，它解决的是不同问题。

Figure 3: 不同角色迷上 vibe coding 的原因不一样，但都和反馈提速有关。

我现在会把它理解成一种“压缩表达延迟”的工具。你脑子里有个产品感觉，不需要先翻译成一堆技术步骤，再慢慢实现。你可以直接把那个感觉往前推。这对独立开发者是提速，对创业者是提前验证，对非工程角色则是第一次真正碰到“我说的话可以直接长成一个可运行界面”的体验。

但也正因为这个过程太顺，人才特别容易把顺滑感误认成可靠性。这个误判，几乎就是所有后续问题的起点。

最危险的误解

如果让我只选一个最该反复提醒的点，我会选这个，vibe coding 最危险的地方，不是 AI 会不会写错，而是它太容易让人觉得“现在已经差不多了”。

我后来越来越认同一种批评，就是 demo 成功和工程可信之间，隔着一整个世界。一个东西能跑、能点、能部署出链接，不代表它结构合理，不代表别人接得住，也不代表它安全，更不代表它能撑过后续迭代。

这也是为什么我特别在意那类来自技术审查视角的批评。它们指出的问题很具体，不是抽象地说“AI 不靠谱”，而是说当使用者本身不理解代码时，debug 很容易退化成机械动作。报错来了，贴给 AI。修完了，继续贴下一个。短期看问题像是被推进了，长期看系统却可能变成一团没人真正理解的东西。

Figure 4: Demo 成功和工程可信之间，隔着完整的工程纪律。

我自己现在看 vibe coding，也会强迫自己先问一句，这个东西现在到底只是原型，还是已经有人开始把它当成软件资产。因为一旦语境从“我自己试试看”切到“我要拿它上线”，整个判断标准就完全变了。

更麻烦的是，这种风险在前期不显眼。界面是活的，交互是通的，甚至还能发给别人看。可一旦有懂工程的人接手 review，很可能马上就会看到命名混乱、模块边界模糊、没有测试、没有安全防护、改一处动全身。也就是说，vibe coding 最擅长制造一种“我已经做出来了”的感觉，而最难的部分，往往恰好藏在这个感觉后面。

它不等于工程提效

写到这里，我觉得还有一个边界必须拉清楚，不然这个话题很容易永远吵不明白。vibe coding 和 AI-assisted engineering 不是同一件事。

它们都在用 AI，也都可能提高效率，但两者对人的要求不一样。前者更偏向“先把东西长出来”，后者更偏向“在工程纪律里使用 AI”。这个区别一开始听着像措辞问题，实际却会决定一个项目最后长成什么样。

在更严格的 AI-assisted engineering 里，AI 是加速器，不是托管者。你还是要主动定结构、拆模块、定 review 标准、补测试、管边界。AI 帮你快，但不替你承担工程判断。vibe coding 则更容易从创意和结果出发，先把可见成品做出来，再决定要不要往后补工程约束。

Figure 5: 两者都用 AI，但责任边界完全不同。

我现在比较接受的说法是，vibe coding 适合探索、验证、试错，AI-assisted engineering 适合长期维护、协作交付和生产级演进。你当然可以把两者混着用，但前提是你知道自己什么时候在探索，什么时候已经进入工程阶段。

不然就会出现一种很常见的对话错位。有人夸 vibe coding，很可能是在夸它把 demo 做得快。有人骂它危险，可能是在说把 demo 直接当生产系统很冒险。两边其实都没错，只是说的根本不是同一个层级。

讨论会走向哪里

我现在越来越觉得，vibe coding 已经快要离开“流行词阶段”了。因为不管是平台教程，还是更尖锐的批评，都已经不满足于只说它酷不酷，而是在问更实际的问题，它能不能被教，能不能被约束，能不能形成更稳定的方法。

Figure 6: 它正在从热词变成一个需要边界和方法的实践。

如果这场讨论会继续成熟下去，我猜最后留下来的不会是“会不会用 vibe coding”，而是“谁能把它和工程判断一起用”。

对我来说，这反而是个好信号。任何会留下来的实践，最后都得从“感觉很强”走到“边界清楚、失败可复盘、结果可判断”。vibe coding 还没走完这条路，但它已经开始往那个方向去了。

我现在的判断

我现在对 vibe coding 的看法，既不是兴奋，也不是鄙视，而是把它当成一种很强的原型化能力。它确实改变了开发入口，也确实会让更多人第一次真正碰到“我能把想法做出来”的时刻。

但我也越来越确定，它不是自动生成可信工程的机器。你越清楚它擅长的是压缩原型阶段，不是替你接管工程判断，就越不容易被它带来的顺滑感骗过去。