nlp小白菜前阵子有个朋友在群里晒战绩：用AI聊天窗口点了几下，一个内部工具后端加前端全出来了，测试也跑了，部署也上了，语气里全是“vibe coding 真香”的兴奋。我没当场泼冷水，过了三天他私信我，说生产环境出问题了——某个状态数据在数据库里翻来覆去对不上，日志里全是重复执行和死锁。我带他翻代码，发现AI确实写得“很自信”：该加锁的地方没加锁，该幂等的地方没幂等，两个文件里的变量名各叫各的，唯一的共同点是它们居然都能编译通过。
这就是vibe coding最迷人的表象和最危险的真相：它能让你在几分钟内拥有一个“看起来在运行”的系统，却无法保证这个系统在逻辑上是自洽的。近一年这个词被炒得火热，社区里从“0基础学vibe coding”到“用vibe coding做全栈开发”的教程满天飞，连大厂都出了官方的入门学习资源，似乎不会用自然语言让AI写代码就成了技术落伍者。但我作为接手过好几个“AI爽文项目”善后现场的人，必须把丑话说在前头：vibe coding对于原型验证、一次性脚本、低风险页面，确实是个高效工具；可一旦涉及状态管理、业务流程、数据一致性，它的“无法自洽”会以你意想不到的方式反噬整个项目。
这篇文章不是要否定vibe coding，而是要拆掉那些吹过头的神话。我会从概念和热度讲起，然后把AI生成代码最大的死结——逻辑自洽性——掰开揉碎，再用spec-driven这套方法论做对照，最后分享我在实战里总结出的驯服法则。想靠自然语言生成代码的朋友，无论你是刚接触还是已经深度使用，都应该先看清这套模式的边界在哪。
1. 先搞清楚：你们口中的vibe coding到底是哪一套
1.1 vibe coding的走红轨迹：从个人实验台到Google官方学习资源
vibe coding这个说法最早是从AI社区流行起来的，它描述的是一种“把写代码的主导权交给AI”的编程方式：你负责描述意图、拍板决策，AI负责生成实现代码。你不再是逐行敲键盘的程序员，更像一个产品经理和技术总监的混合体，对着对话窗口提需求、看产出、提修改意见。
这个词在2025年前后彻底出圈，从技术圈一路蔓延到普通用户。现在你搜“vibe coding”，能搜出一堆教程资源，甚至Google都推出了面向零基础用户的官方学习资源，内容涵盖“怎么用自然语言让AI生成应用”“怎么调试AI写的代码”“怎么把生成的代码部署上线”。这会给人一种错觉：好像编程的入门门槛被彻底铲平了，会说话就会写程序。
但请注意一个关键事实：大厂推这类资源，角度是“降低编程入门门槛”“让非技术人员也能体验创造软件的乐趣”，而不是“教你用vibe coding构建核心业务系统”。宣传口径和真实工程需求之间，隔着一条巨大的认知鸿沟。
1.2 “让AI写，我只负责描述和拍板”看似美好的第一体验
我必须承认，vibe coding的第一体验确实爽。我自己刚开始试的时候也震惊了：要求AI写一个带登录、列表、筛选、分页的管理后台，它几十秒就给你铺出几百行代码，打开页面居然真的能跑；说“给我加个导出Excel的功能”，它马上封装好下载逻辑；说“这个按钮样式改成圆角渐变”，它连CSS都给你调好。
这种即时反馈会迅速刺激多巴胺分泌，让你产生“我已经掌握编程”的错觉。尤其是对没有系统编程经验的人来说，第一次看到AI把自己的想法变成可点击的网页、可运行的程序，那种成就感非常真实。
问题是，这种成就感建立在“程序能跑”的浅层标准上，而不是“程序耐得住真实业务蹂躏”的深层标准上。就像一个装修队告诉你“房子已经盖好了，能住”，但你搬进去之后才发现水电管道全是歪的，只是墙皮糊得好看而已。
1.3 真正能帮到哪些人：我的适用性判断
我不打算一棍子打死vibe coding，事实上它有一套非常明确的适用边界，我在大量项目里验证过。下面这张表是我个人经验的总结：
| 适合用vibe coding的场景 | 不适合用vibe coding的场景 |
|---|---|
| 原型验证、Demo演示 | 核心业务逻辑、订单/支付流程 |
| 一次性脚本、数据处理小工具 | 高并发、多线程状态同步 |