没人谈论的Vibe Coding隐性成本

AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

此刻，在某个生产代码库中，有一条注释写着：

// AI generated — do not touch

在它下面，有人又加了一句：

// seriously. nobody touch this.

这条注释不是在开玩笑。它是一个求救信号。整个行业的代码库中充满了这样的注释。

过去十二个月里，我一直在观察这种模式。Demo跑通了。种子轮融资完成了。又有两位工程师加入，在已发布的代码基础上继续构建。他们打开代码库，发现了这些注释。他们问创始人哪些部分可以安全地修改。

创始人自己也说不清楚。

事情就是从这里开始变贵的。

1、没人预算过的账单

行业分析师现在预测，到2027年，AI生成代码将积累1.5万亿美元的技术债务。不是因为工程师不行。不是因为团队懒。而是因为那些快的团队——那些自信地推进、带着势头发货、却从未充分考虑Demo之后会发生什么的团队。

一项对810万个pull request的大规模研究发现，采用AI编码工具后，技术债务增加了30-41%。Vibe-coded项目的测试覆盖率平均只有12%，而传统开发的代码库为68%。维护AI生成代码的成本在18个月内膨胀了300%。

每次都让我震惊的数字是：Y Combinator报告称，其2025年冬季批次中25%的公司代码库有95%是AI生成的。世界上四分之一的最受瞩目的早期公司。几乎完全建立在没人编写、没人审查、没人完全理解的代码之上。

宿醉不是要来了。它已经来了。

2、为什么这种债务与你见过的任何一种都不同？

我认为大多数报道都没有说到点子上。

人们谈论vibe coding债务，好像它就是那种老掉牙的技术债务——赶工的功能、跳过的重构、在当时看来合理的捷径。不是的。差得远。

传统的技术债务是你自己匆忙写的代码。你理解它。你只是抄了近路。重构虽然烦人但是可行的——你知道代码想做什么，你只需要做得更干净。

Vibe coded债务是没人写的代码。这意味着没人有它的心智模型。

Vibe coding留下的债务是现代的、干净的，在隔离状态下逻辑正确。风险不在于任何一个函数。它存在于函数之间的关系中，这些关系未被记录且脆弱，没有人理解。

开发者知道某些东西能工作。但他们不知道它为什么能工作。

再读一遍那句话。因为知道它能工作和知道它为什么能工作之间的差距，正是让代码库变得危险的原因。

一家中型SaaS公司在vibe-coded的v2重写后分享了内部审计结果：23个模块中有847处重复的业务逻辑。14种不同的日期格式化实现。零集成测试。重写花了3个月。修复花了7个月，3个月的工作量，而且这还是乐观版本——他们在问题进一步恶化之前就发现了它。

有一个可预测的拐点。一旦vibe-coded代码库在没有治理的情况下超过大约25,000行，添加新功能的成本就开始超过手动开发的成本。速度优势——这种方法感觉合理的全部理由——消失了。你留下了一个比你一开始好好写还要慢的代码库，由不完全理解它的人维护，没有测试告诉你修改什么会破坏什么。

这才是真正的账单。

3、三种模式。每次都是。

我听到的每个关于vibe coding债务的故事，都可以追溯到以下三件事之一。通常三个同时存在。

模式一：上下文失忆

生成你代码库的AI不记得它上次构建了什么。每次对话都是全新的开始。所以它做出了局部合理的决策——在隔离状态下看起来正确的选择——却没有意识到它应该遵循的全局模式。

结果是一个内部自相矛盾的代码库。不是因为AI犯了错误——每次单独的生成都没问题。而是因为没有持久化的规范告诉它系统应该是什么样的。所以它即兴发挥。14种不同的日期格式化实现不是bug。它是要求AI在不告诉它如何已解决的情况下14次解决同一个问题的自然结果。

规范是在AI生成任何东西之前给它一个一致的系统模型的机制。没有它，你不是在构建一个系统。你是在生成一组恰好住在同一个仓库中的、各自合理的函数。

模式二：没有规范，没有追索权

当vibe-coded代码库出了问题时，没有任何东西可以对照检查。

输出正确吗？它应该做什么？规范在某人输入提示时存在于他们脑海中。提示消失了。意图消失了。剩下的只是可能在做预期的事情也可能没做的代码，没有正式的方法来区分。

这就是为什么调试vibe-coded的生产问题如此痛苦。你不是在追踪你自己写的代码中的bug。你在阅读一个无状态模型产生的代码，这个模型对你的系统没有持久的理解，试图重建从未被正式记录的意图。

这是考古学。昂贵、缓慢，而且永远不完全。

超过40%的初级开发者承认部署了他们不完全理解的AI生成代码。75%的组织报告了需要事后审查的质量问题。规范本是可以让审查成为可能的东西。规范是没人写的东西。

模式三：隐性腐朽

在一次安全审查中，45%的AI生成代码样本引入了映射到OWASP Top 10的漏洞。不是明显的失败。是漏洞。那些看起来像正常工作的代码、通过了测试、干净地部署、然后悄悄等待的东西。

我觉得最能说明问题的信号不是漏洞。而是这个：在AI重度使用的代码库中，重构活动下降了60%。

重构需要足够理解代码，才能自信地改进它。当这种理解不存在时——当注释写着// seriously. nobody touch this.而每个人都默默同意时——工程师停止重构。代码库不会随时间变得更好。它变得更糟，因为每个新功能都建立在一个没人完全信任的基础上。

2025年3月，一个vibe-coded的支付网关由于输入验证不足批准了200万美元的欺诈交易。AI从其训练数据中复制了不安全的模式——人类审查者第一遍就能发现的模式。

这是极端版本。常见版本更安静。可靠性下降。发布变慢。工程团队中一种日益增长、未曾说出口的感觉：他们在维护不属于他们的东西。直到最终有人把它放到议程上。

"我们需要谈谈代码库。"

4、出路不是重写

我想直说这件事，因为重写的冲动很强，而且几乎总是错的。

重写的论点在情感上很有吸引力。从头开始。这次做对。但重写会复制隐藏在旧代码中的业务逻辑bug——因为旧代码往往是那些bug的唯一文档。它们花费的时间比预估的长。它们让现有产品在运行的几个月内无人维护。

出路是结构性的，不是戏剧性的。

它从本可以预防问题的同一种纪律开始。写下系统应该做什么。不是一份长文档，而是一份精确的文档。这个模块做什么？它的边界是什么？什么必须始终为真？什么绝不能发生？

这份规范就成为你检查新代码的标准。当你使用AI进行修复时，它就成为AI工作的框架。它成为防止同样的债务再次积累的机制。

避免危机的团队不是那些少用AI的团队。他们是那些将编码、审查和测试分离为具有不同职责的不同角色的团队——而且每次生成周期都以规范开始，而不是以提示开始。规范优先。生成其次。始终对照规范进行验证。

这个顺序就是一个随时间变得更好的代码库和一个得到// seriously. nobody touch this.注释的代码库之间的全部区别。

5、我希望你从中得到什么？

我使用AI编码工具。我尊重的人都在使用。生产力提升是真实的。那些弄清楚如何有纪律地使用它们的团队将构建两年前不可能实现的东西。

我所反对的是一种特定的错觉：工具可以取代纪律。它不能。从来没有。

AI在制造看起来完成的东西方面非常出色。它在制造真正的完成品方面很差。没有结构的速度不是优势。它是还款窗口更短的债务。

如果你读到这里并认出了这个模式：没人想碰的函数、拖了几天的调试会话、越来越强烈的感觉——你在维护一个没人完全理解的系统——你并不孤单。这正在发生在各地的团队身上，就在此刻。

但你也不是束手无策。代码库是可以恢复的。纪律是可以学习的。同时理解两者的工程师是市场现在支付最高薪水的人。如果你读过这个系列之前的一篇文章，你已经知道了这一点。

出路始于整个事情本应开始的地方。

写下系统应该做什么。精确地。在你改变任何其他东西之前。

代码中的注释已经告诉你有问题了。现在你知道该怎么做了。

原文链接: The Hidden Cost of Vibe Coding Nobody Talks About Until It's Too Late

汇智网翻译整理，转载请标明出处