vibe coding 用了三个月，账单是以前的四倍——我终于搞清楚钱花在哪了

vibe coding 用起来是真的爽。跟 AI 说一句「给我做个登录页」，三十秒代码就出来了，不用想文件结构、不用管什么框架约定、上手就能跑。但爽了三个月之后，我发现团队里有人开始收到账单的时候愣住了——月度 token 消耗是以前的四倍，但项目进度并没有快四倍。

这不是个案。我观察了身边七八个从传统开发转 vibe coding 的团队，发现了一个规律：vibe coding 的成本不是线性增长的，它是阶梯式跃升的。理解这个规律，你才能判断 vibe coding 适不适合你的场景，以及什么时候该踩刹车。

第一个坎：上下文窗口用满的那一刻

vibe coding 的本质是把决策权交给 AI。AI 需要知道你的代码、你的需求、你的约束条件——这些全靠上下文窗口。窗口小的时候，你不得不精简 prompt，每一步都是显性决策，成本可控。窗口大的时候，你开始习惯把整个项目都丢给 AI，「反正够装」。

问题来了：够装这个假设是错的。

大多数团队的代码库在 3~6 个月后会突破 10 万 token。Cursor 的 Pro 套餐每月 20 美元，Claude Code 每月 20 美元，GitHub Copilot 每月 10 美元——加起来 50 美元听起来不贵。但如果你的团队有 5 个人在高频使用，实际月消耗轻松突破 200 美元，还不算 copilot 额外调用的 GPT-4o API。

真正的问题是：这些钱花出去，换来了多少有效的代码？

我做过一个实测：同一个中型功能页面，手动开发 + AI 辅助（只在局部查语法）vs 纯 vibe coding（整块功能全丢给 AI）。前者的 token 消耗是后者的 1/8，但交付质量更高——因为人类的审美判断在关键时刻介入了，而不是等 AI 把整个页面做完了才发现方向跑偏。

第二个坎：代码一致性成本

vibe coding 的第二个隐藏成本是代码一致性。你让 AI 写了 50 个组件，分布在 20 个文件里，每个组件的风格都不太一样——命名、prop 类型、样式写法，多多少少有出入。团队新成员接手的时候，光是读懂这些「风格随机的 AI 代码」就要多花两三天。

这不是黑 AI，这是工程化的问题。任何没有统一约束的批量代码生成都会有这个问题，只是 AI 让它发生得更快、更隐蔽。你以为省了开发时间，实际上是把技术债务往后推迟了——而且利息很高。

我见过最极端的案例：一个三人团队用 vibe coding 做了两个月，代码库里出现了三套状态管理写法、两套 API 调用模式、四个不同版本的工具函数集合。后来要接一个支付功能，光是梳理现有代码就花了两周，比从头重写还累。

解法很简单：给 AI 定风格指南。 你可以在项目根目录放一个 .cursorrules 或者 system-prompt.md，明确约定命名规范、组件结构、状态管理模式。把风格约束从「人脑记得」变成「文件写清楚」。这一步做不到，vibe coding 的工程成本迟早会反噬。

第三个坎：调试成本不对称

vibe coding 的第三个隐藏成本是调试成本不对称。传统开发的调试成本是可见的——代码哪里有问题，console 报什么错，一行行追下去就行。vibe coding 的调试成本是隐蔽的：AI 生成了一整块功能，你不知道哪一行是问题的根源，错误信息指向的可能只是表象，真正的原因藏在 AI 生成的 200 行代码的某个角落里。

这个问题在调试 AI 生成的异步逻辑时尤其突出。AI 很喜欢加 setTimeout、加 setInterval、加各种「看起来合理」的边界处理。一旦这些逻辑出错，人类工程师往往要先花半小时理解 AI 的思路，才能找到 bug 在哪。而理解 AI 的思路本身就是一个高认知负载的任务，比自己写还累。

我的经验是：vibe coding 适合做「从零到一」的功能探索，不适合做「从一到精」的深度调试。 如果你发现自己在 vibe coding 的产出上花了大量时间修 bug，说明这个功能已经不适合继续 vibe coding 了——要么自己重写核心逻辑，要么把范围缩小到 AI 能稳定驾驭的粒度。

怎么判断 vibe coding 是不是在烧冤枉钱

有一个简单的判断标准：你每次提交代码，平均改了多少个文件？

如果平均每个 commit 只改 1~2 个文件，说明 vibe coding 在帮你做小步迭代，这是健康的使用方式。如果平均每个 commit 改了 10+ 个文件，说明你经常让 AI 批量生成，然后批量接受——这种模式下技术债务积累极快，不建议长期维持。

另一个标准是回滚频率。如果你发现代码回滚的次数明显比以前多了，说明 AI 的产出不够稳定，需要更频繁地回到上一个可用版本。频繁回滚本身就是 vibe coding 成本的一部分，因为它意味着你花了时间接受了 AI 的代码，又花了时间推倒重来。

下一步：给你的 vibe coding 加上成本意识

如果你想继续用 vibe coding，又不想月底被账单吓到，我建议从三件事开始：

第一，建立 token 预算机制。 每周查一次各工具的用量报表，设置提醒阈值。大多数团队发现自己的 token 消耗是预期的 2~3 倍时，都会主动优化使用方式——这个反馈回路比任何工具都有效。

第二，给 AI 定风格指南，前面说过了。 .cursorrules 或者 system-prompt.md，花半小时写清楚，长期省下的调试时间远不止这个数。

第三，设定 vibe coding 的适用范围。 我的建议是：原型验证、一次性脚本、简单 CRUD 页面，这些场景 vibe coding 很值。涉及复杂状态流、多方外部依赖、或者需要深度业务理解的模块，AI 的产出需要更仔细地 review，不要无脑接受。

vibe coding 不是银弹，但它可以是很好的起手式。知道它的成本边界在哪里，才不会被账单教育。