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 写代码AI 辅助/结对vibe codingAI 主导意图粒度函数级、模块级拆解明确场景级、体验级一句话描述验收标准类型正确、逻辑无 bug、代码可解释跑得通、体验顺、结果符合预期遇错处理人读日志、定位根因、修改后验证整个日志贴回去AI 自己修代码资产人要理解并长期维护人允许代码处于黑盒状态典型场景生产项目、多人协作、长期维护原型验证、个人工具、快速 Demo这张表并不是说哪种更高级。生产级代码当然需要结对和审查但如果你只是做一个下周要用的内部脚本花两个小时去理解 AI 为什么选了某个库其实是在浪费生命。vibe coding 的高明之处是把你的时间从读懂每行代码里解放出来放到判断这个产品到底好不好用上去。2.3 代码资产观住在自己买的房里和住酒店是两种心态第三代码资产观不同。平时写代码像买房子你得知道自己家有几间房、水管走向、电闸在哪vibe coding 更像住酒店你只需要知道房号水电管井一概不用管而且你随时可以退房换一家。这意味着 vibe coding 写出来的项目对 owner 来说是一个黑盒它能跑但你大概率说不清它内部有几条路由、几个状态。这种资产像租来的车开着顺手就行别指望它陪你十年。很多人误以为 vibe coding 是懒人做法但其实它对人的要求更高。它把里里外外都要懂的工作换成了审美判断、目标管理、风险嗅觉的工作。你得知道什么时候该让 AI 继续什么时候必须喊停这比看懂一个 if else 复杂得多。3. vibe coding 为什么能跑通修复闭环 验收迁移3.1 工具能力的质变从生成代码变成生成-运行-修复自治回路可能有人会问如果 AI 生成的代码经常有 bugvibe 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 续写风险低收益薄结对编程人 AI审查建议、解释逻辑、定接口需要保持专注速度不是最快vibe codingAI给方向、验收体验、喊停黑盒技术债安全风险需额外兜底我个人比较推荐的做法是白天处理核心模块时用结对模式让 AI 把方案讲清楚再合入晚上做内部工具或者临时脚本时切换到 vibe 模式快速产出。这两种模式交替使用既能保证生产代码的质量又能享受 vibe coding 的爽感。6.2 最后一个实用技巧让 AI 顺手写一条冒烟测试最后分享一个小技巧。即使是 vibe 模式我也会在第一次对话里要求 AI 顺手写一个小的冒烟测试脚本比如 main 函数跑通、关键接口返回 200、输入非法参数时给出友好提示。每次 AI 改完代码就让这个脚本跟着跑一遍。这么做的好处是避免一个 vibe 里非常常见的悲剧AI 改了 A 功能顺手把 B 功能弄坏了而你根本不知道因为你的验收只盯着 A。我在实际使用中抓到过很多次这种改坏。一个小脚本三分钟就能写完但它让 vibe coding 的体验从盲人开车变成了戴了夜视仪开车。如果你也想尝试这种新的编码状态我建议你把它作为第一条规矩写进去。Vibe coding 不是不负责任地乱写而是把责任从每一行代码转移到整体效果你依然要守好安全和可维护性的底线。