由来“Vibe Coding”氛围编程这个词由卡帕西在 2025 年 2 月 3 日发布在 X 上的一条推文中提出。img原文内容如下There’s a new kind of coding I call “Vibe coding”, where you fully give in to the Vibes, embrace exponentials, and forget that the code even exists. It’s possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good.有一种新型的编码方式我称之为“氛围编程”Vibe coding你完全沉浸在感觉里拥抱指数级加速忘掉代码的存在。这之所以成为可能是因为大语言模型如搭配 Sonnet 的 Cursor Composer正变得越来越强大。Also I just talk to Composer with SuperWhisper so I barely even touch the keyboard. I ask for the dumbest things like “decrease the padding on the sidebar by half” because I’m too lazy to find it.我还会用 SuperWhisper 直接和 Composer 对话几乎不怎么碰键盘。我会提出一些蠢得可爱的需求比如“把侧边栏的内边距缩小一半”因为我懒得自己去找。I “Accept All” always, I don’t read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it.我总是点“全部接受”再也不读差异对比了。遇到报错信息我就直接复制粘贴进去不加任何注释通常这样就能修好。The code grows beyond my usual comprehension, I’d have to really read through it for a while. Sometimes the LLMs can’t fix a bug so I just work around it or ask for random changes until it goes away.代码已经超出了我平时能直接看懂的范围要真正理解它我得认真读上好一阵子。有时候大语言模型修不了某个 bug我就绕开它或者随便让它做些改动直到问题消失为止。It’s not too bad for throwaway weekend projects, but still quite amusing. I’m building a project or webapp, but it’s not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.对于随手一做的周末项目来说这还算不错但也确实挺有意思的。我在构建一个项目或网页应用但这不太算是真正意义上的编程我只是看到东西、说说需求、跑跑代码、复制粘贴然后大多数时候它就能跑起来。二、小结定义Vibe Coding 指在模型足够强的前提下开发者用自然语言驱动 AI 生成代码并主动放弃阅读、理解和掌控代码的一种探索式编程模式。卡帕西本人也说它“不太算是真正意义上的编程”而是看、说、跑、粘贴四个动作的循环see / say / run / copy-paste“大体上能跑就行”。要求1模型够强。他明确说之所以可行是因为 LLMCursor Composer 配 Sonnet已经“好得过头”。这是 Vibe Coding 成立的硬条件离开足够强的模型这套玩法立刻崩。2自然语言/语音为主的交互。他用 SuperWhisper 对着 Composer 说话几乎不碰键盘连“把侧边栏 padding 减半”这种琐碎事也直接口述因为懒得自己去找交互媒介从“敲键盘”退化成“说话”。约定1永远 Accept All不读 diff不审查模型改了什么。2报错原样粘回去、不加任何说明把调试也外包给模型通常就修好了。3代码增长到超出自己理解并且坦然接受这一点不去补课读懂。4改不动就绕过或随机试遇到模型修不了的 bug要么绕开要么乱改到它消失为止。适用这套做法“对用完即弃的周末项目还不赖”。也就是说卡帕西从一开始就把它定位在低风险、抛弃型的场景而非一套正式的、普适的工程方法论。本质主动、自觉地放弃对代码的理解与责任这是 Vibe Coding 与普通“AI 辅助编程”的根本区别后者你仍在读、在懂、在负责。三、优缺点总结起步极快中期混乱后期崩盘。优点1速度与迭代成本极低。从想法到可运行原型可以压缩到几分钟试错几乎没有成本。这对验证假设、做 demo、探索“这个方向到底行不行”特别有价值。2释放注意力到意图层。你不再纠结语法、API 签名、样板代码而是专注于“我到底想要什么”。卡帕西的说法是关键能力从“掌握语法”变成了“表达意图”。3降低门槛、扩大产出。一方面非专业人士也能做出东西民主化另一方面这点常被忽略它让专业开发者写出大量本来根本懒得写的小工具、自动化脚本。即“扩大了软件存在的总量”。4抛弃型场景的完美契合。一次性脚本、周末项目、个人小工具写完就丢没有维护负担。这正是它最初被框定的语境。缺点1质量与可维护性。代码可能“能跑”但结构混乱、命名随意、抽象错误。短期看不出来半年后回头看就是技术债的雷区而你当初没读过它更难偿还。2理解缺失 黑盒。这是最致命的一点。一旦出 bug 而 LLM 又改不动你会陷入“复制错误信息、随便换个写法再试”的循环。因为你不理解代码调试能力直接归零。放弃掌控感在顺境是解放在逆境是灾难。3安全性。未经审查的代码容易引入漏洞、硬编码密钥、不安全的依赖。这在公开部署时尤其危险。4扩展性天花板。小项目顺风顺水但随着代码量和复杂度上升缺乏一致架构的代码会越来越难驾驭LLM 的上下文也撑不住整个系统。5技能退化。长期只“Vibe”而不读、不写、不理解基础工程能力会萎缩尤其对还在成长期的开发者。四、适用场景适用的判断标准不是“该不该用 AI”而是我们是否需要对这段代码长期理解和负责。1示例型、低风险反例修改系统配置属于高风险不适用、探索性 → Vibe Coding 收益远大于风险放手干。2生产环境、需长期维护、涉及安全/资金/合规 → 必须退回到“读得懂、负得起责”的 AI 辅助编程甚至 Spec Driven Development 这种更规范的开发模式。五、看法展望以当前的 AI 编码工具Claude Code、LLMClaude Opus 4.8及配套生态如记忆、上下文、知识图谱等来看Vibe Coding 确实只适合低风险、示例性的个人或临时探索项目正因如此业内开始推行一种新的 AI 开发模式规范驱动开发Spec Driven Development该模式强制要求必须“先规划、再动手”在编写任何代码之前由人和 AI 共同生成一份结构化、可测试、可被 AI 理解和执行的规范文档让它成为双方共同的“单一事实来源”再据此驱动 AI 生成代码。整个过程就像盖房子前先画好施工图从而保证结果可控、稳定。不过参考里奇·萨顿的“苦涩的教训”未来随着 LLM、AI 编码工具及 AI 生态代码库语义、知识图谱等的持续发展AI 将越来越能理解人类需求与代码语义Vibe Coding 当前遇到的各类问题也将逐步减少适用场景可能不断扩大尤其在中小型项目中。7 月 15 日OpenAI 发布了 Codex Micro 键盘用来控制 Codex可以理解为专为 Vibe Coding 设计。img六、苦涩的教训12024 年图灵奖获得者里奇·萨顿强化学习之父提出。2核心观点利用人类的先验知识或手工设计的规则来提升 AI 性能短期有效但长期会