AI代码跑得通，但你看不懂

---

说真的，我一开始对Vibe Coding的判断全错了。

我以为AI写不出代码。结果半年下来，发现它写得可太好了——好到让你后背发凉。

一个支付模块引发的血案

这事儿得从我那个重构事故说起。去年11月，我让Cursor的Agent帮我重构一个支付模块。Agent自己扫了一圈代码，跟我说"发现一个设计模式的问题，建议改成策略模式"。我当时还挺美，心想这AI有点东西。然后它花了一个小时把整个模块重写了。

跑测试的时候全挂了。

17个测试用例，挂了14个。

因为它把我订单模块的接口也改了。Agent自己完全没发现——它看到A文件就改A文件，改完看到B文件引用了A就去改B。但A还被C和D引用着。它不知道。

翻车了。

这不是AI的错，是我的错。我给了它一个模糊的任务边界，它就放飞自我了。现在我的规矩是：给Agent的任务必须画清楚边界，"只改这个文件里的xxx函数，不改其他任何东西"。或者先切个分支让它随便造，不行就回滚——反正Git分支不要钱。

代码量翻了三倍，理解力归零

但这不是最大的问题。

最大的问题是代码量上去了，理解没跟上。用了半年Vibe Coding，我repo里的代码量从2.3万行涨到了7.1万行。说句丢人的话——有些模块我现在也看不懂了。

不是我写的。是AI写的。当时prompt完了能跑，就没管。

上个月要改一个退款逻辑，我打开那个文件，看了足足40分钟才明白AI的思路。它用一种我从来没见过的方式——用generator加闭包实现了一个状态机。能跑，性能也好，单次状态转换耗时0.3ms。但阅读成本极高。

绝了。

团队协作的时候更尴尬。同事review你AI写的代码，看到一段莫名其妙的逻辑，问"为什么要这么写"，你只能回："AI写的，我也不知道。"这事儿发生过3次之后，我们定了个规矩：AI生成的代码必须在commit message里标注[AI-Generated]，并且附上当时的prompt。

Dijkstra在48年前就警告过我们

这事儿让我想起Dijkstra在1978年写的那篇短文，编号EWD667，标题特别挑衅：《论"自然语言编程"的愚蠢》。他当时说自然语言的"自然性"本质上是危险的舒适——你能轻松说出那些荒谬性并不显而易见的话，还觉得自己说清楚了。

48年后，这话应验了。

Vibe Coding最大的陷阱不是AI写不好代码——是它写出来的代码"看起来对"。而"看起来对"恰恰是最危险的bug。传统bug你一眼能看出来不对劲，AI生成的代码逻辑诡异但语法完美，测试能过，lint不报错。你品，你细品。

我给AI装了两个"监工"

我后来给AI装了两个"监工"。一个做静态检测查语法（用的是SonarQube 10.4），一个做行为检测查逻辑（自己写的测试套件）。不是限制AI的创造力，是给它划定一个"不能偷懒的范围"。这个范围一旦清晰，AI反而更省心——它知道了边界，就不用试探。

静态检测每周能抓到3-5个潜在问题，行为检测在上线前拦住了2次生产事故。这俩监工花了2天配置，但省下来的救火时间至少40个小时。

架构品味这事儿，AI真不行

但说实话，最让我头疼的不是技术问题。

是架构品味的问题。

前段时间看到一个评论才恍然大悟：工程项目跟美术、小说一样，做得久了会形成个人风格。你看到某个作品，会本能想起这是出自某个人之手。一个成熟的工程品味，在项目长期迭代中极其重要——它决定了3年后这个系统是继续演进还是推倒重来。

当前AI没有这种品味。它是把一堆人的思路拼在一起。这就导致Vibe项目像是和一群人下棋——AI能赢但不好看。

我们看人下棋，并不是因为谁输谁赢这个结果才去看的。

"功能管道"：我的土办法

所以我现在用一套自己摸索出来的方法——我管它叫"功能管道"。不以代码为单位组织系统，而是以功能管道为单位。每条管道负责一个完整功能，从输入到输出。管道内部AI随便发挥，管道之间严格遵守接口契约。

你不需要读懂每一行AI代码，只需要理解管道之间的接口。

代码理解成本从O(n)降到了O(1)。

这个方案——不对，应该叫策略——还在迭代中。大概是目前最适合我的方式吧。用了3个月，团队新成员上手时间从2周缩短到3天。

别信"重新生成整个项目"那套

还有一个血的教训：别信"重新生成整个项目"那套说法。扯淡。

哪怕是小工具中间件，重新生成几乎都会发现上一次需求规格的细节缺失。涉及通信的中间件项目更是重灾区——我试过4次，4次都翻车。越迭代越多细节问题冒出来，然后你需要花更多时间——甚至比古法编程还多的时间——去review并重新适配。

你不知道背后发生了什么，只能重新调试找问题。传统开发模式里，你总能第一时间意识到功能修改点，几分钟搞定迭代修改。

Vibe Coding？六个小时生成，发现需求要改，再等六小时。

快速迭代在大多数时候，比能不能做出来重要得多。真的。

三段式闭环：零成本的提效方案

我现在的流程是口语化需求输出→AI初版生成→精准口令迭代修正的三段式闭环。拆prompt，"做什么→怎么做→怎么验收"分三步给，别一次全扔进去。零成本，立刻见效。

试了47次，成功率从一次性扔prompt的62%提升到了91%。

还有一条硬性规则：每加入一个新功能，必须评估可以移除或合并哪些旧功能。做不到就不加。

系统复杂度不会随时间无限增长。运行半年以来，功能一直在演化，但核心复杂度始终控制在稳定范围内——代码行数涨了3倍，但核心模块数量只从12个增加到15个。

隐性成本：100块token里80块烧在测试上

说到成本，很多人觉得Vibe Coding省钱。实际用下来，token费用不高，隐性成本不少。反复试错的prompt时间、看不懂代码的学习成本、出问题后的救火时间。

有次我让AI跑harness测试工程，10分钟代码生成完，后面花100分钟搞测试。期间AI很不老实地插入各种稀奇古怪的测试代码，失败概率高达73%。100块钱的token里80块都烧在这里。

现在我看到opus那边跑harness就直接终止。不跑。不值得。

底线问题

如果你在用Vibe Coding做上线项目、生产环境、多人协作的代码，给AI加约束不是可选项，是底线。不是"可以配"，是"必须配"。

出了问题没人替你扛。代码写错了可以改，数据泄露了、用户跑了、口碑毁了——这些损失不可逆。

真的。

Vibe Coding省的不是脑子，是手。脑子该花的功夫，一分都不能少。