vibe coding 半年，我付了三笔学费

“Vibe coding”这个词是 2025 年初有人在网上提的，意思很直白：不逐行看代码，凭感觉让模型写，跑起来就行，出问题再说。

我真正开始这么用是今年年初——工具能自己读代码、自己跑命令之后，随手让它写变成了默认做法。半年下来，我的态度从”真爽”变成了”分场景”，中间付了几笔学费。

半年前写过一篇把它接进真实项目的规矩，那篇讲的是”应该怎么做”。这篇讲另一面：规矩没管住的时候，事情是怎么变糟的。

先说它真的适合什么

一次性的小工具。 比如把一堆杂乱的 CSV 合并、清洗、导出。写完用完就扔，坏了重跑一遍就行，不需要看懂。

数据探索。 想知道这批数据长什么样，让它写几段分析代码比我手敲快得多。探索过程本身就是要迭代的，代码质量无所谓。

原型验证。 判断一个想法值不值得做，先用最粗的方式跑通，跑通了再正经重写。这种情况下，”能跑”就是全部要求。

自己用的自动化。 定时备份、整理文件、批量改图这类，只服务我一个人，出错的代价是重跑。

共同点很清楚：这些代码没有被别人依赖，也不打算长期维护。

第一笔：一个数据清洗脚本。

我花了一晚上，跟它来回对话，把一份脏数据收拾干净了。跑通了，很爽，脚本就放在那儿。

三个月后规则变了，我要改一个字段的处理逻辑。打开脚本一看，一百多行，嵌套的判断和正则混在一起，变量名是 df、df2、tmp、tmp2。我能看懂每一行在干什么，但完全看不懂它为什么这么写——哪些判断是为了处理真实存在的脏数据，哪些是它防御性地加的。

结果那个脚本我直接重写了。一晚上的产物，维护成本超过了重写成本。

第二笔：一个部署脚本。

它写得非常顺手，甚至还帮我加了日志和错误提示。我差点就提交了。

提交前扫了一眼，发现里面有一行把某个路径拼接写死了，那路径里带着我这台机器的用户名；还有一处把密钥的位置直接写在命令里。

这两处都不是它”故意”的，是它在我的环境里跑通了，就认为这么写是对的。

第三笔：一个”看起来能跑”的爬虫。

处理页面的时候，它对大部分页面都正常。少数页面结构不一样，解析失败——它没有报错，而是跳过继续，最后输出了一份”完整结果”。

两周后我拿这份结果做分析，觉得数字对不上，回头查才发现有百分之十的数据被静默丢掉了。

这笔账最贵的地方不是数据错，而是我发现得太晚。要是它当时崩掉，我五分钟就知道了。

一、vibe 出来的东西要标记。 我在仓库里单独放了个目录，专门放这类脚本，文件头写一句”实验性，未审阅”。这样至少未来的我知道别指望它。

二、要进主干，必须补测试。 逻辑正确性不要求它一上来就写对，但要求它有测试兜底。测试是我来定标准，它的活是把测试跑绿。

三、静默失败零容忍。 解析、转换、批处理这类代码，不许有”出错就跳过”的分支。宁可崩，不要悄悄丢数据。

四、密钥和路径不交给它写。 涉及配置和凭证的地方我手写，它只负责调用。

复盘这半年，我发现”爽”的来源其实不是效率，而是不用做决定。

正常写代码的过程中，有相当一部分时间花在犹豫上：这个方案行不行、命名怎么起、边界情况要不要处理、这里会不会有坑。vibe coding 把这些决定都外包出去了，所以过程特别流畅。

代价是这些决定并没有消失，只是被推迟了——推迟到你要改它、或者别人要读它的时候。那时候你得先逆向理解一个陌生人的思路，再回头做当时省下的那些决定。

所以爽是真爽，但它是”把账单推到以后”的那种爽。而账单不会消失，只会加上利息。

vibe coding 降低的是开始的成本，没有降低维护的成本。它让”我有个想法”到”能跑起来”这一段变得非常短，但代码一旦进入需要被人读懂、被修改、被依赖的阶段，该付的成本一分不少。

所以我的用法变成了很土的一句话：可以 vibe 着写，但要正经着留。前者是探索，后者才是资产，搞混这两件事，就会攒下一堆看起来很能干、实际上没人敢碰的代码。