深度聊聊：被吹爆的 Vibe Coding ，为什么一进真实项目就容易失控？

第一次用 AI 写代码，很多人的感受都差不多：爽，是真的爽。

你随手丢一句需求，它几分钟就给你搭出一个能跑的 demo ；你再补一句“这里换个颜色”“这个字段加上”“顺手改一下校验”，它又能立刻接上。那种感觉很像什么？像你刚找到一个特别勤快、还几乎不嫌烦的搭子——说改就改，说写就写，反馈快得让人上头。

可一旦项目不再是小 demo ，而是开始往“真系统”走，味道就变了。

你会发现，AI 还在很努力地输出，代码也还在不断增长，可项目本身却越来越乱：前面说过的约束，它忘了；前天修过的 bug ，今天又在另一个文件里冒出来；本地 replay 测得一片绿，真丢到测试环境一跑，啪，挂了。

这时候很多人会下意识地想：是不是模型还不够强？

其实往往不是。

问题更常出在另一层——我们有没有把“想清楚、做出来、验明白”这三件事分开。

说白了，就是：planning 、execution 、verification 到底有没有被当成三件不同的事来处理。

Vibe Coding 到底是什么？为什么它在 demo 阶段那么香？

先说结论：Vibe Coding 并不是错，它只是特别适合某些场景。

所谓 Vibe Coding ，你可以把它理解成一种很自由、很对话驱动的 AI 编程方式。它大概长这样：

• 一边聊天，一边改代码
• 需求、实现、测试全混在同一个长对话里
• 没有固定 plan ，AI 想到哪儿写到哪儿
• 跑个 mock 、做个 replay ，看起来没问题，就先当完成
• 关键决策不单独沉淀，全靠对话历史“记着”

为什么这种方式一开始特别好用？原因很简单——它正好贴合了 demo 和 MVP 的需求。

你需求还很模糊，只说一句“给我搞个登录页”，AI 就能自己补很多东西：选框架、搭路由、写样式、凑交互。你几乎不需要前期设计，不需要 spec ，不需要 plan ，甚至不需要太多上下文，就能很快看到东西跑起来。

这对“验证一个想法”特别有价值。

因为 demo 阶段你最关心的，其实不是“这个系统未来三个月怎么演进”，而是：这个点子能不能先被看见、被演示、被感知。

所以在这个阶段，Vibe Coding 的优势非常明显：

• 上手门槛低
• 反馈速度极快
• 容忍需求模糊
• 几乎没有前置成本

问题在于，demo 只要求“跑起来”，工程交付要求的是“跑得稳、改得动、出了问题找得到原因”。

这两者，根本不是一回事。

为什么自由式 AI coding 前期越爽，后期越容易翻车？

真正麻烦的地方在于：Vibe Coding 的很多优点，放进复杂项目里，恰恰会倒过来变成缺点。

下面这几个崩点，几乎是很多团队踩过一轮之后才会真正意识到的。

崩点一：上下文越来越长，但关键决策根本没“落地”

很多人会觉得，现在上下文都这么长了，几十万 token 都能塞，那 AI 不是应该更懂项目了吗？

听起来合理，现实却没那么美。

因为 LLM 的“看过”，不等于工程意义上的“记住”。它并不是像人一样建立了稳定、可追溯的长期约束模型，而是在当前上下文里尽量续写出一个“看起来合理”的下一步。

于是对话一长，问题就来了：

• 前面明明说过“不能用全局变量”，后面它还是用了
• 前面强调“必须走事务”，隔几轮它又绕过去了
• 某个 bug 刚在 A 文件修过，B 文件又原样再来一遍
• 你想回头查“为什么当初这里这么设计”，只能翻聊天记录翻到怀疑人生

最麻烦的不是代码变多，而是控制感在变弱。

项目越长，你越容易进入一种奇怪的状态：代码越来越像是“它在生成”，而不是“你在掌控”。

崩点二：它不是按计划执行，而是边干边改主意

自由式 coding 有一个特别容易被忽略的问题：计划漂移。

你原本只想做个很小的改动，比如加个字段、补个校验、修个状态判断。结果 AI 做着做着，顺手就把旁边一整块也给“优化”了。

听起来还挺积极，对吧？

可复杂系统里，最怕的就是这种“顺手”。

比如：

• 你只让它加一个字段，它顺手把数据层重构了
• 你只让它改个校验逻辑，它顺手改了状态流
• 你只让它修一个接口，它顺手把相关抽象全换了一遍

局部看，每一步都像是在“变更更优雅”；全局看，却可能已经悄悄偏离最初需求。

这就是复杂项目最危险的地方：副作用不是线性的，是会连锁扩散的。

一个“顺手重构”，背后可能牵出三四个模块的隐式依赖。而这些依赖，在聊天过程中通常并没有被明确写出来，只是“好像应该没问题”。

工程里最怕这种“好像”。

崩点三：replay 是绿的，不代表真环境也是绿的

很多 AI coding 的验证方式，说白了，是一种“先看起来没错”。

跑个固定输入，输出对了；

mock 一下数据库，请求通了；

本地单进程把流程串起来，似乎都没报错。

于是大家点点头：可以，完成了。

但只要你做过真实项目，你就知道，很多 bug 本来就不是在 happy path 上出现的。

真正会出事的地方，往往藏在这些角落里：

• 并发下的竞争条件
• 超时和重试
• 事务边界不一致
• 真实数据分布下的边缘 case
• 集成环境里组件之间的时序问题
• 回归测试没覆盖到的旧行为破坏

AI 生成代码还有一个很现实的倾向：它特别容易朝着“通过当前测试”去优化，而不是朝着“在真实世界里长期正确”去优化。

也就是说，它会非常努力地满足你眼前那套验证条件，却未必真的理解这套代码在生产环境里要面对什么。

所以 replay 绿，不等于正式测试绿；正式测试绿，也不一定等于线上稳。

这句话一点都不夸张。

崩点四：看起来像智能协作，实际上常常是一团黑盒

现在很多人开始用多 agent 工具，感觉像是“AI 团队”在替自己干活：有的负责读代码，有的负责写代码，有的负责测。

理想状态当然很好。可一旦流程没有显式拆开，最后经常还是回到一个问题：谁在什么时候做了什么决定，你根本看不清。

尤其在自由模式下，常见情况是：

• 同一个 agent 一会儿在扫描代码，一会儿在做计划，一会儿又开始改实现，顺手还把测试跑了
• 哪一步是“分析得出的结论”，哪一步是“为了继续往下走临时拍的脑袋”，界限很模糊
• 中间产物没有保存，状态只存在于对话和模型内部推理里

结果就是，一旦出问题，你很难判断：

• 是一开始理解需求就错了？
• 还是 plan 本来就不合理？
• 还是执行偏了？
• 还是验证方式压根不够？

当 orchestration 变成黑盒，可控性就会迅速下降。

那为什么“流程约束式 AI coding”更慢，却更稳？

因为它做了一件很朴素、但特别重要的事：

把“想”和“做”拆开，把“决定”和“执行”拆开。

一个更靠谱的流程，通常不会让 AI 上来就写，而是按几个阶段来：

• 先扫描（ Explore ）：读代码库、找依赖、看影响范围
• 再计划（ Plan ）：列出子任务、对应文件、改动边界，让人先看一遍
• 然后执行（ Execute ）：按子任务逐个落地
• 最后验证（ Test / Review ）：按层次去验，不是随手跑一下就算完

你会发现，这种方式的重点不在于“限制 AI”，而在于把错误尽量前移。

与其让 AI 写出一大坨代码之后再发现方向错了，不如在动手前就把错误理解暴露出来。

为什么 plan 一旦不锁，项目就容易飘？

因为 plan 的价值，不只是“列个待办清单”，它其实承担了三层作用。

第一，它会把很多原本隐含的假设显式写出来。

AI 在 plan 阶段会暴露自己的理解——包括理解错的地方。你这时候纠正，成本最低。

第二，它给变更画了边界。

每个子任务改哪些文件、碰哪些接口、不碰哪些地方，都能事先说明。这样一旦执行阶段越界，人能很快察觉。

第三，它是可回滚的决策点。

计划错了，重做 plan 就好；如果一边写一边想，往往等你意识到错的时候，代码已经堆了一大层，返工成本直线上升。

说得直白一点：plan 的作用，不是拖慢开发，而是防止后面成倍返工。

为什么 scan / plan / execute / test 混在一起，几乎必乱？

因为这四件事本来就不是同一种脑力活动。

• scan 是理解现状
• plan 是设计变更
• execute 是落实方案
• test 是证明结果

把它们混在同一条对话流里，AI 很容易出现一种典型状态：边写边重新理解需求，边验证边修改实现，最后到底是“按什么标准完成的”，你自己都说不清。

更现实一点讲，人类也很难在关键节点插手。

如果没有明确 checkpoint ，你基本只能等它“都做完了”再看结果。而到了那个时候，很多问题已经不是一句“你重来一下”能轻松解决的了。

相反，分阶段加 checkpoint 的好处很明显：

每往前走一步，都得先证明当前这一步站得住。

这不是官僚流程，这是工程上的刹车系统。

聊天记录为什么替代不了显式产物？

因为聊天记录是线性的，工程决策是网状的。

你回头翻聊天，会发现它当然“都说过”，可问题是：

• 决策散落在几百条消息里
• 同一个约束前后可能被不同表述重复提过
• 新开一个会话，很多前文就等于没了
• 后来加入项目的人，几乎不可能靠补聊天记录来真正理解系统

这就是为什么真实团队最后都会回到那些看起来“传统”的东西上：

• spec.md
• implementation_plan.md
• workflow_state.md
• 测试报告
• review 记录

这些东西看起来不像对话那么“丝滑”，但它们有一个决定性的优点：能查、能复用、能版本化、能交接。

你今天写的约束，明天还能被新会话、新成员、新 agent 继续拿来用。

这才叫工程上的“记忆”。

为什么 replay 只能算一层验证，绝不是全部？

replay 当然有用，它并不是没价值。

问题在于，replay 解决的是：“在当前假设下，这段逻辑看起来是否成立？”

而正式测试解决的是另一个问题：

“在真实系统里，这个改动会不会破坏别的东西？会不会在复杂条件下失效？”

两者根本不是一个层次。

所以比较健康的验证方式，应该是分层的：

• lint：先把明显问题筛掉
• unit test：验证局部逻辑
• integration test：验证模块之间真的能协同
• regression test：防止旧行为被悄悄改坏
• 必要时再做真实环境下的端到端验证和压测

replay 是其中一层，不是全部。

如果把 replay 当成“完成标志”，那基本就是在拿局部假设代替真实世界。

为什么显式 delegation 比黑盒 orchestration 更靠谱？

因为显式 delegation 至少让你知道：谁负责想，谁负责做，谁负责验。

比如：

• Architect agent：负责研究代码、产出 plan
• Developer agent：按 plan 实现
• Tester agent：设计和执行测试

这样做的好处非常实际：

• 输入输出清楚，状态容易追踪
• 中途可以暂停，让人做审查
• 某个环节不行，可以单独优化或替换
• 出问题时，更容易定位到底是计划错了还是执行偏了

说白了，工程系统一旦复杂起来，最怕“所有事都由一个聪明黑盒自动搞定”。

听起来高级，出了问题却最难救。

同一个任务，两种做法，差别到底在哪？

例子一：给 /api/user 增加 phone 字段

这个需求表面看很简单：在返回里加个 phone，然后做非空校验。

如果是自由 Vibe Coding

你一句话发过去：“给 /api/user 加个 phone 字段，要非空。”

AI 立刻开干：

• 改 DTO
• 改 controller
• 改 service
• 可能顺手还把 migration 也补了

三分钟后，代码能跑，接口也返回了。你一看：“可以啊，挺快。”

但第二天很可能就出事：

• 老客户端根本没传 phone，直接 500
• 某个内部工具字段映射写死了，现在炸了
• 校验逻辑被写在 controller ，service 层绕开后照样能进

问题不是它不会写，而是它没认真判断这个改动到底会影响谁、约束应该落在哪一层、兼容性怎么处理。

如果是流程约束式

做法会完全不一样。

先把需求讲清楚：

• /api/user 返回新增 phone
• 后端需要校验
• 但对老客户端要兼容，没传时允许 null
• 校验逻辑放在 service 层，统一复用

然后 AI 先出一个 plan ，你来审：

• 修改 UserDTO，增加 phone @Nullable
• 在 UserService.validateUser() 里加校验：有值时非空
• 修改 controller ，保证返回结构一致
• 增加集成测试，覆盖“有 phone”“无 phone”“空字符串”
• 本次不改 database migration

接下来再按任务逐个实现、逐个测试。

这套流程看起来慢了 5 到 10 分钟，但它换来的是什么？

是你一开始就把兼容性、校验位置、测试标准都说清楚了。后面大概率不会因为“顺手一改”引发连锁返工。

例子二：把订单状态流从同步改成事件驱动

这个就更能说明问题了。

需求是：

• 订单服务发布 OrderStatusChanged
• 库存服务订阅后更新库存
• 报表服务订阅后更新聚合表
• 数据库要有事件表和出队机制

如果是自由 Vibe Coding

你说一句：“把订单状态流改成事件驱动。”

AI 立刻进入高能状态：

• 在订单服务里加事件发布
• 在库存服务里加订阅
• 顺手改点 schema
• 再顺手补个重试机制

你中途又想起来一句：“哦对，报表服务也要订阅。”

它继续接上，问题是——

报表服务很可能用的又是另一套事件格式，版本也没统一，语义也没锁死。

本地跑一遍 replay ，单进程、同 JVM 、甚至事件直接方法调用，绿得发亮。

可一上集成环境，熟悉的灾难就来了：

• 事件丢了
• 顺序乱了
• 重试导致重复消费
• 幂等没做好，库存扣错了
• 报表和库存看到的状态还不一致

这不是因为 AI 写不出代码，而是因为这种任务本来就要求你先把一堆关键决策钉死：

• 事件 schema 是什么？
• 版本怎么管？
• 至少一次还是恰好一次？
• 怎么持久化？
• 怎么重试？
• 怎么幂等？
• 乱序怎么处理？
• 回滚和补偿谁负责？

这些问题如果不先想清楚，后面写得越快，翻车也越快。

如果是流程约束式

更靠谱的做法通常会是这样：

先写清 spec：

• 事件名称、版本、schema
• 消费语义
• 各服务订阅边界
• 失败补偿策略

然后让 AI 先 scan 三个服务，产出一份现状梳理：

• 当前状态流怎么走
• 涉及哪些状态字段
• 哪些事务边界已经存在
• 哪些地方最容易出一致性问题

接着再出 plan ，并做人审：

• 阶段 1：定义事件 schema
• 阶段 2：改订单服务，引入事件表和发布层
• 阶段 3：改库存服务，实现订阅和幂等消费
• 阶段 4：改报表服务
• 阶段 5：补集成测试，覆盖丢失、重复、乱序等场景

每一阶段做完，都必须停一下：

• 跑单元测试
• 跑这一阶段的集成测试
• 输出结果
• 人确认无误后再继续

最后再到真实消息队列环境里跑端到端测试和压测。

这才是处理复杂改造时更稳的方式。它不一定让你“今天下午就看到全套跑通”，但能明显降低那种“看起来都好了，结果集成环境炸穿”的概率。

那到底什么时候该用哪一种？

说到底，这不是“谁更先进”的问题，而是任务和方法要匹配。

如果你现在只是：

• 验证一个创意
• 搭个 demo
• 做个 MVP
• 改一个很局部、可快速回滚的小功能

那用 Vibe Coding 完全没问题。甚至可以说，它在这种场景下非常合适。

可如果你要做的是：

• 多模块协作
• 跨服务改造
• 涉及状态机、事务、并发
• 需要长期维护
• 要上线、要审计、要交接

那最好从第一天就别把 AI 当“自由发挥型选手”，而要把它放进流程里。

你可以把这个判断记成一句特别实用的话：

任务越复杂、影响范围越大、回滚成本越高，就越不能只靠 Vibe 。

最后聊一句：AI 能加速开发，但不能替你承担工程责任

Vibe Coding 的问题，不是它没用，而是很多人对它的期待本来就放错了位置。

它擅长的是帮你快速把东西“做出来”。

可软件工程真正难的地方，从来不只是做出来，而是：

• 做得对
• 改得动
• 出问题能定位
• 过几个月还有人接得住

所以真正靠谱的 AI-native 工程，不是“让 AI 自己决定怎么建系统”，而更像是这样：

• 用 AI 提速大量编码和样板工作
• 用人类守住架构、约束、审查和关键决策
• 用流程把这些环节串起来，让整个过程可重复、可回溯、可维护

说得再直白一点：

Vibe Coding 适合拿来“爽一下”；真正要把软件落到地上，还是得靠流程把节奏拉回来。

毕竟，写代码最快的时候，常常不是项目推进最稳的时候。

而一个系统能不能长期活下去，拼的也从来不只是“生成速度”，而是——你有没有办法持续地把复杂性关进笼子里。