Vibe Coding 是什么？AI 主导的编程新范式与实操指南

最近一段时间，我被问得最多的一个词就是 vibe coding。群里有人说这是不是某个新出的编程软件，还有人跑到搜索框里打"vibe coding 下载"，以为装上一个工具就能开箱体验。其实 vibe coding 不是一个能下载的产品，而是一种2025年以来被反复讨论的 AI 编程工作方式：vibe 是气氛、手感的意思，coding 是写代码，合在一起就是"凭感觉、凭氛围写代码"。更准确一点说，它是把写代码的主笔权彻底交给 AI，你坐在副驾驶位置上，只负责提供方向、感受运行结果，然后在合适的时机踩刹车。它和你平时"让 AI 帮我写一个函数"是两种完全不同的协作关系，这也是我想写这篇内容的原因。

1. vibe coding 不是一个工具，而是一种把主笔权交给 AI 的编码状态

1.1 这个词从哪里来，为什么它不是旧词新包装

这个词第一次被大规模讨论是在2025年初。当时一位在深度学习领域很有话语权的研究者发了一段话，大意是说，自己现在写代码的方式已经变成了：完全凭感觉说出想法，AI 把代码写出来，程序跑起来之后他只看整体效果，不再逐行去读。他把这种状态起了一个名字，叫 vibe coding。话里话外还带着一点自嘲和玩闹，但圈内很快意识到，这不只是一个玩笑，它描述的是一种真实的、正在被越来越多人采用的工作方式。

如果你细品这个定义会发现，关键词有两个：一是"凭感觉给指令"，二是"不逐行读代码"。很多人平时用 AI 写代码，其实只满足第一点，并不满足第二点。他们让 AI 写了一个函数之后，还是会自己在编辑器里读一遍、改一改，再决定要不要合入。而 vibe coding 的定义恰恰是把第二点推到了极端：你允许自己对生成的代码在细节层面一无所知，只要这个程序在整体上"感觉是对的"，你就继续往下走。

1.2 vibe coding 的核心循环长什么样

所以 vibe coding 的运行方式不是一句 prompt 就完了，它是一个闭环：先用一句口语描述想做什么，AI 生成初始骨架；接着让它直接运行，遇到报错就把日志原封不动贴回去；AI 自己修，再运行，直到跑通；然后你亲自点一遍功能，凭"手感"告诉它哪里不对；它再改；如此循环。在这个循环里，人很少打开源码文件去检查内部实现，人的主要产出是意图、反馈和决策。

举个例子。我想给朋友做一个"把网页正文提取成 Markdown 的命令行工具"，我可能只会告诉 AI："我想从一些新闻页面里把正文抓下来，保存成 md 文件，标题做文件名，用命令行跑，越简单越好。"至于它选 Python 还是 Node，用 requests 还是别的库，我完全不管。等它跑通了，我再拿几个真实页面测一下，觉得提取出来的内容格式不够干净，就回一句"正文里多余的广告链接清理一下"，它又会自己去改。整个过程里我可能一眼源码都没看。

2. 平时用 AI 写代码和 vibe coding 的分水岭：三张对比清单

2.1 意图粒度：你要给的是场景，不是函数

第一，意图粒度不同。平时用 AI 写代码，你是一个工头，习惯把需求拆到函数级："在订单服务里加一个方法，把金额转换成美元字符串，小数位保留两位。"AI 只是一个执行者。而 vibe coding 把需求开成场景级甚至情绪级："我想搭一个给朋友抢票提醒的小服务，每天早上把余票信息发到手机，界面不重要。"你给出的不是实现方案，而是使用场景和体验预期。这种粗粒度指令，恰恰是 vibe 状态能成立的第一个前提。

2.2 验收标准：代码没有原教旨，体验才是裁判

第二，验收标准不同。平时你验收的是代码质量：类型对不对、边界情况有没有覆盖、有没有副作用。vibe coding 验收的是体验感知：页面点起来顺不顺畅、输出看起来对不对、报错信息能不能看懂。换句话说，一个关注"代码是否按人类逻辑写对"，一个关注"运行结果是否符合当时的气氛"。我用一张表把两者放在一起，会更直白。

这张表并不是说哪种更高级。生产级代码当然需要结对和审查，但如果你只是做一个下周要用的内部脚本，花两个小时去理解 AI 为什么选了某个库，其实是在浪费生命。vibe coding 的高明之处，是把你的时间从"读懂每行代码"里解放出来，放到"判断这个产品到底好不好用"上去。

2.3 代码资产观：住在自己买的房里，和住酒店是两种心态

第三，代码资产观不同。平时写代码像买房子，你得知道自己家有几间房、水管走向、电闸在哪；vibe coding 更像住酒店，你只需要知道房号，水电管井一概不用管，而且你随时可以退房换一家。这意味着 vibe coding 写出来的项目，对 owner 来说是一个黑盒：它能跑，但你大概率说不清它内部有几条路由、几个状态。这种"资产"像租来的车，开着顺手就行，别指望它陪你十年。

很多人误以为 vibe coding 是懒人做法，但其实它对人的要求更高。它把"里里外外都要懂"的工作，换成了"审美判断、目标管理、风险嗅觉"的工作。你得知道什么时候该让 AI 继续，什么时候必须喊停，这比看懂一个 if else 复杂得多。

3. vibe coding 为什么能跑通：修复闭环 + 验收迁移

3.1 工具能力的质变：从"生成代码"变成"生成-运行-修复"自治回路

可能有人会问：如果 AI 生成的代码经常有 bug，vibe coding 不是会一直翻车吗？其实 vibe coding 能火起来，靠的是工具能力的一次质变。早期的 AI 助手是点状能力：你生成一段代码，复制到工程里，跑挂了，剩下的事全是你自己来。现在的 AI 编程工具已经长出了"修改文件、执行命令、读取日志、再修改"的闭环能力，相当于一个驻场团队。报错不再是你的工作，而是 AI 的下一轮输入。

这个"报错-修复-再运行"的闭环，是 vibe coding 成立的前提。说句实话，用早期那种只能生成代码块的助手，你根本 vibe 不起来，因为每一步断点都需要人肉接续。而今天你只要把报错原样贴给 AI，它就能完成大部分修复。我自己在实操中试过几次比较离谱的报错，比如依赖版本冲突、跨文件类型不匹配，AI 都自己查文档解决了。这个闭环一旦成立，人在循环里就变成了"验收员"而不是"操作员"。

3.2 验收目标从代码质量迁移到产品氛围，让"能跑"变成"够用就好"

另一个让 vibe coding 成立的原因，是验收目标的迁移。软件开发的传统评价体系默认"代码质量等于产品质量"，但对很多快速原型和个人工具来说，这其实是错的。用户摸到的只是界面和结果，用户不看你里面用了什么架构。当验收目标从"代码优雅"切换到"体验符合预期"之后，AI 主导的生成方式就变得非常合理。

比如我做过一个生成周刊摘要的网页工具，最后验收时我只看三件事：一键能不能跑出结果、排版是不是我想要的、速度能不能接受。AI 当时用的是一套我完全不熟的框架，但我根本不需要知道。这类场景最适合 vibe coding。反过来，嵌入式领域的所谓"vibe coding"就很难真正成立：你要面对真实的引脚、时序、内存布局，AI 生成的代码经常是"看起来写得很仔细，烧进板子就黑屏"，因为硬件交互没有"猜"的余地。所以听到"嵌入式 vibe coding"这种说法时，我一般会提醒对方，vibe 的边界在于失败代价有多大。

4. 哪些项目千万别 vibe 过头：风险清单与保护性习惯

4.1 看起来很快的假速度，和几类很常见的翻车

先说翻车现场。我见过有人用 vibe coding 的方式做一个批量下载小工具，当时跑得飞起，过了两周数据量一大，直接崩了。原因是他自始至终没有看过 AI 用的内存处理方式，数据一多就把内存吃满。这种"假速度"是 vibe coding 最常见的坑：demo 能跑的时候你感觉良好，等真实负载、边界输入、异常情况一起涌上来，黑盒里的问题就会一次性爆发。

第二类问题叫技术债。AI 生成的代码往往没有注释、没有测试、喜欢复制粘贴相似结构，短期推进度特别快，但后续要加一个功能时，你会发现 AI 自己也开始改不动了。我见过一个项目，对话到第几十轮之后，AI 开始频繁把旧的正常代码改坏——它的上下文太长了，记不清前面约好的接口。这就是 vibe 模式失灵的信号。

第三类问题是安全。这是我最想提醒的。如果你让 AI 处理账号、密码、个人信息相关功能，又完全不审查代码，相当于把一个你不认识的人领进了机房。常见的硬编码密钥、缺少输入校验、登录逻辑漏洞，在 vibe 状态下特别容易发生。我自己的底线是：凡是涉及用户数据、权限、网络的代码，必须做一次专门的人工安全审查，不能让 vibe 全权负责。

4.2 不该使用 vibe coding 的场景，以及三条保命习惯

那么哪些场景不适合 vibe 过头？我给自己列过三个边界：第一，交易、支付、医疗、基础设施这类"你必须能解释每一行行为"的系统；第二，多人协作的大仓库，你 vibe 出来的代码别人没法接手，因为没有设计文档、没有注释、没有测试；第三，嵌入式底层以及任何失败代价很大的场景。另一点同样重要：哪怕项目本身是内部小工具，也建议留三条保命习惯。

三条保命习惯：一是定期让 AI 写一份 README 和架构说明，逼它把黑盒打开一个口子；二是要求 AI 在改动前先说计划，而不是直接闷头改；三是在进入下一个里程碑时，抽 30 分钟做一次"理解检查"，至少读一遍核心文件的一半内容，确认没有明显的离谱操作。这三件事花不了多少时间，但能避免很多后期推倒重来的悲剧。

5. 我完整走一遍 vibe coding 流程，以及两个关键时机判断

5.1 从一句口语需求到跑起来的完整五步

下面是我现在比较顺手的一套流程，你可以直接抄。第一步，选择工具。要求不高：能多文件编辑、能自动执行命令、能读报错信息，主流 AI 编程 IDE 或者插件都行。第二步，写第一句需求。这里有个关键技巧：不要给技术栈，给场景和边界。

提示：vibe coding 的第一句话越接近"跟一个不太熟的全栈工程师讲需求"越好，技术选型交给 AI。

这里是我惯用的开场白结构，你可以直接套用：

我想在命令行做一个天气查询小工具：输入城市名，回车就输出温度、湿度、风力，数据来源用公开免费接口，最好 pip 装完就能用。你先搭个骨架，跑起来之后我再逐条加功能。

第三步，等 AI 搭出骨架后，你亲自动手运行一次。如果报错，把报错文本完整贴回去，不要自己查 Stack Overflow。第四步，功能验证用体感测试代替代码走查：命令行输出顺不顺、页面点击流不流畅、报错信息友不友好。第五步，每完成一个小里程碑，就让 AI 写一段总结，把它的实现思路和关键文件说明落到文档里，这是给未来的自己留的地图。我实操下来还有一个心得：在 vibe 模式下，需求描述里加一句"注意基本安全习惯，不要用 eval，不要硬编码密钥"，非常有用。AI 会把它当作一条全局约束，这类约束放在会话里，比写完之后再让它返工省事得多。

5.2 两个让 vibe 失效的信号，以及我如何切回传统模式

最后说两个让我从 vibe 状态强制切回传统模式的信号。第一个信号：你发现自己连续几次对 AI 的修改只能说"不对，再改改"，但说不清哪里不对。这说明你已经失去了对产品的判断依据，再 vibe 下去只是在掷骰子。第二个信号：你开始害怕分享代码。当你不敢把项目地址发给同事，说明你心里清楚这个黑盒经不起别人看一眼，这时候就该停下来做审查或重写。

我现在的习惯是：日常开发里 vibe 模式只用在个人工具、原型和一次性脚本上；一旦项目要进入生产环境、要被人维护、要处理敏感数据，我就会切换到传统的结对-review 节奏，把每一段核心代码重新读一遍、补上测试、画清楚架构。这不是对 vibe coding 的不信任，而是我知道这个状态适合什么、不适合什么。

6. 三种 AI 协作模式切换经验，和最后一个实用小技巧

6.1 自动补全、结对编程、AI 主导是连续光谱，按需切换

如果把 AI 编程的协作程度排成一条光谱，最左边是自动补全，中间是结对编程，最右边就是 vibe coding。自动补全模式下你主导一切，AI 只负责接住你手速，风险最小但收益也最薄。结对编程是你们一起写，AI 给出建议并解释，人来做最终决定，适合生产代码。vibe coding 则是 AI 主导、人验收，产出速度最快，但风险也最集中。很多人的误区是只选其中一种，其实你完全可以按天按项目去组合它们。

我个人比较推荐的做法是：白天处理核心模块时用结对模式，让 AI 把方案讲清楚再合入；晚上做内部工具或者临时脚本时切换到 vibe 模式，快速产出。这两种模式交替使用，既能保证生产代码的质量，又能享受 vibe coding 的爽感。

6.2 最后一个实用技巧：让 AI 顺手写一条冒烟测试

最后分享一个小技巧。即使是 vibe 模式，我也会在第一次对话里要求 AI 顺手写一个小的冒烟测试脚本，比如 main 函数跑通、关键接口返回 200、输入非法参数时给出友好提示。每次 AI 改完代码，就让这个脚本跟着跑一遍。这么做的好处是避免一个 vibe 里非常常见的悲剧：AI 改了 A 功能，顺手把 B 功能弄坏了，而你根本不知道，因为你的验收只盯着 A。

我在实际使用中抓到过很多次这种改坏。一个小脚本三分钟就能写完，但它让 vibe coding 的体验从"盲人开车"变成了"戴了夜视仪开车"。如果你也想尝试这种新的编码状态，我建议你把它作为第一条规矩写进去。Vibe coding 不是不负责任地乱写，而是把责任从"每一行代码"转移到"整体效果"，你依然要守好安全和可维护性的底线。