vibe-coding 翻车实录

看到一篇帖子，一个程序员在网上求助，说公司 vibe-coding 的项目已经失控了。

年初 Agent 火了，公司管理层觉得这是个降本增效的大机会。很快下达了任务。做一个客服 Agent，覆盖 App 在线客服和电话客服两个场景。

问题从第一天就在。团队里没有 AI Agent 工程师，全是 Java 和前端。面对一个全新的技术栈，只能边学边干。从系统设计到架构搭建到业务开发，全程依赖 Codex 这类 AI 编程工具。

赶了几个月，第一版上线了。

然后噩梦开始。

代码没人看得懂

上线之后效果远低于预期。各种异常频繁出现，但团队根本定位不到原因。

大量核心代码是 AI 生成的。结构复杂、抽象层级混乱。很多逻辑连开发人员自己都看不懂，更不用说维护和排查。

于是进了一个死循环。代码看不懂，只能继续让 AI 帮忙改。AI 修了一个 Bug，引入两个新 bug。今天修好 A，明天 B 又炸了。系统越修越乱。

随着业务量增加，问题开始集中爆发。电话线路并发一高就崩溃。在线客服长时间沉默、响应超时、上下文丢失。用户得不到正常服务。

最终的结局极其讽刺。不是为了提升客服效率吗。实际结果是，原本稳定运行的人工客服体系被拖下水。客服人员每天不是在服务用户，是在接管异常会话、处理系统故障、安抚投诉。

比上线之前更差了。

他在帖子的最后问，这种情况怎么破局。

这不是一个 Bug，这是一个模式

我说实话，读到这个案例的时候，我脑子里全是本周写的那几篇文章在闪。

这不是一个团队运气不好。有一说一，这是 vibe-coding 的标准翻车路径。

从头看。没有 AI 经验的团队，被要求从头搭建 AI 系统。没有 CLAUDE.md，没有架构文档，没有上下文管理。全程靠 prompt 驱动。每一行代码都是对 AI 说「帮我写个 X」，然后把生成的东西粘进来。

这些代码之间的关联，AI 知道。人不知道。

当这个系统的复杂度超过一个人的理解上限时，任何改动都变成赌博。你不知道改这一行会炸掉哪个模块，因为模块之间的关系从来没有人梳理过。AI 在生成每一段代码的时候是独立的，它不会告诉你「注意，这段逻辑跟三个月前写的那段有冲突」。

这不是 Codex 的问题。这是没有给人留下理解系统的空间。

但这不只是这一个团队的问题

这个案例的背后，是一整个正在大面积发生的现象。

外面现在漫天飞舞的「零基础开发」「AI 让你三天上线一个 App」「不会写代码也能做系统」。这些话术的目标用户不是开发者，是老板。

老板被洗脑了。

他们听到的逻辑是这样的。既然 AI 能写代码，那为什么还要养那么多程序员。既然 vibe-coding 效率这么高，那为什么还要立项、设计、评审、测试那一整套流程。

于是出现了这个经典场景。老板拍板，团队硬着头皮干。不是因为他们相信 vibe-coding，是因为老板相信。而老板不知道的是，那些「零基础三天上线」的 Demo，跟真正能跑的、能扛住并发、能处理异常、能长期维护的生产级系统，中间隔着一整个软件工程的深渊。

vibe 了一堆屎山。动词非常准确。

看起来是一堆功能，实际上是一堆没有结构、没有约束、没有验证的代码堆积。刚上线的时候可能还能跑。稍微加点压力，整座山开始塌。而且最恐怖的是——塌了你不知道怎么修，因为山是你拉的，但你不是搭的，AI 搭的。

这就是第一批 vibe-coding 的受害者。不是 AI 的使用者，是被 AI 营销裹挟着上了战场的人。

为什么会翻成这样

三个原因，层层嵌套。

第一，跳过了从 L0 到 L1 的过渡。

整个项目如果映射到刚写完的 AI 自主层级那篇框架里，就是直接从 L0——助手模式——跳到了 L3——目标驱动的自主。把边界不清晰的大任务直接交给 Agent，没做分解、没做验证、没做独立审查。

正确的路径应该是先在 L1 待一段时间。每段 AI 生成的代码有人看守、有人审批、有人理解。等团队熟悉了 AI 的生成模式之后，再逐步向上走。

第二，没有上下文管理。

整套系统没有 CLAUDE.md。没有文档记录架构决策。没有一份文件说清楚「这套系统的核心模块是什么、之间的关系是什么、有哪些边界约束、有哪些已知的坑」。

我们上周翻来覆去讲的那件事——给 AI 结构，它就跑；不给结构，它就瞎跑。这个团队给了 AI 多少结构。零。每一段 prompt 都是独立的，每一次生成都在重新理解上下文。

第三，验证缺席。

测试呢。代码审查呢。独立的安全检查呢。都没有。代码生成之后直接就上线了。

没有一个独立于 AI 的验证机制。AI 说修好了就是修好了，AI 说我理解了就是我理解了。连一个能自动跑通的基础测试套件都没建起来。

这跟 AI 自主层级那篇里写的「摘要替身」反模式一模一样。AI 的工作摘要替代了真正的审查。直到系统开始崩溃，才发现摘要里什么都没提到。

怎么破局

不是「关掉 AI 回到手动挡」。那太浪费了。是回到正确的层级，重新搭地基。

第一步，停下来。先别修新的 bug 了。

每修一次引入两个新 bug，这个循环不停下来，系统只会更烂。先冻结新功能，所有人力转向理解和文档化。

如果我是这个团队的技术负责人，我会花一周时间做一件事。让团队把现有系统从头到尾梳理一遍，不是改代码，是写文档。每个模块做什么、依赖什么、有哪些已知问题、哪些代码是 AI 生成的、属于哪个 prompt、当时的上下文是什么。

这周会很痛苦。但必须做。

第二步，建一本 CLAUDE.md。

把梳理出来的内容写成一个文件。不用长，讲清楚四件事就够了。

系统的核心目标是什么——在线客服和电话客服的接入、路由、响应、记录。模块边界在哪——哪个模块管哪件事。技术约束有什么——并发上限、延迟要求、数据格式。有哪些已知的坑——之前修过的 bug 类别、容易出现问题的模块。

这个文件不是为了 AI。是为了让人和 AI 可以站在同一块地基上。

第三步，从 L0 回到 L1。

先把 AI Agent 的自主层级打回到 L1。有人看守模式。

每次让 AI 改代码，改完之后。人读一遍改了什么。人跑一遍测试。人确认没有引入新的问题。然后才合并。

这个过程会很慢。真的真的。但慢就是快。上一版就是太快了，快到自己都不知道系统里有什么。怎么讲呢，快就是慢。

第四步，搭一套独立验证。

不用一开始就全覆盖。从最高频的几条交互链路开始。反正我觉得，用户发起一次在线对话，系统应该走完哪几步。每一步的响应时间上限是多少。上下文应该记住什么。

把这些写成自动化测试。让它们在你改完代码之后自己跑一遍。就算 AI 帮你写了测试，你也要读一遍，确认测试确实在测该测的东西。

同样的逻辑，配一个独立的审查 Agent。不是让同一个 Agent 写代码又审代码。是写代码的和审代码的分开。Codex 有 Auto-review 功能，Claude Code 有 /code-review 模式。

第五步，不上新功能，先把现在的东西修稳。

不接新的业务需求。这一到两个 sprint，只修 bug、加测试、写文档、清理架构。

等系统在压力测试下能稳定跑通了，基础测试覆盖率到了及格线，CLAUDE.md 和架构文档更新到最新状态了。那时候再考虑加新功能。

而且那时候 AI 才能真正帮上忙。因为它知道系统长什么样了，知道哪里容易踩坑了，知道什么改动会影响什么模块。

最后

这个案例应该被更多人看到。

不是因为它特别惨。是因为它特别典型。

vibe-coding 不是坏东西。说真的，但 vibe-coding 没有上下文管理、没有验证机制、没有层级意识，就是灾难加速器。

我之前写 Claude Code 那 27 个功能的时候说了一句话。把它当实习生，给它结构，它就跑。不给结构，它就瞎跑。

这篇文章就是「不给结构」的完整现场回放。

文件不在脑袋里。我觉得在文件夹、在 CLAUDE.md、在架构文档、在测试套件里。

先搭房子，再让 AI 装修。

其实吧，这个案例应该进每个技术团队的入职文档。

---

以上，觉得有收获，点个赞、在看、转发支持一下；想不错过更新，记得星标⭐。下次见。