烧掉800亿Token实测：Vibe Coding为何注定失败

引言：40天、800亿Token的AI编程实验

一位B站UP主用一个极端的方式验证了一个业界热议的问题：Vibe Coding（凭感觉编程）到底能不能撑起真实的软件工程？

据其自述，他仅一天就消耗了约40亿Token，按40天保守估算累计烧掉约800亿Token，专门用于测试各种AI调度机制。得出的结论相当尖锐：Vibe Coding写得越快，死得越早。

背景知识：Token与上下文窗口

Token是大语言模型处理文本的基本单位，一个Token大致对应英文中的4个字符或3/4个单词，中文则通常一个汉字占1-2个Token。模型每次生成或理解文本都以Token为计费和处理单元，这也是为什么40天烧掉800亿Token在成本上极为惊人——按主流商用API定价，这可能意味着数十万美元的开销。与Token紧密相关的是"上下文窗口"（Context Window），即模型单次能够"记住"和处理的Token总量上限。早期GPT-3.5仅有4K上下文，如今Claude、Gemini等已扩展到百万Token级别。但即便窗口再大，模型对长上下文中间部分的注意力仍会衰减（即"迷失在中间"现象），这正是文章反复强调的"单模型上下文限制"的技术根源。

这个观点听起来反直觉——毕竟过去一年AI编程工具的宣传核心正是"一句话生成应用"。但当我们剥开演示的外壳，会发现问题的根源在于复杂度与上下文限制这两个绕不开的工程本质。

Vibe Coding的甜蜜期：早期效果为何惊艳

Vibe Coding最初形态就是"一句话生成demo"：一个HTML小游戏、一个火箭发射动画、一个简单的管理系统。彼时还没有中间输出、没有sub-agent这些机制。

为什么这些演示看起来如此惊艳？UP主给出了一个值得深思的解释：

"本质上是AI由于你的需求模糊，自动匹配到了它的训练数据集。训练数据集质量越高、模型学习的压缩程度越低，效果就越好。"

换句话说，那些"一键生成火箭发射小游戏"的演示之所以完美，是因为模糊的需求恰好命中了训练集中的高质量样本。前端特效、经典小游戏这类内容在互联网上有海量优质代码，AI只需做低压缩度的"检索式生成"即可。

延伸：训练数据分布与检索式生成

这里触及了大模型工作原理的本质。神经网络训练过程可以理解为对海量数据的有损压缩——模型将互联网规模的文本压缩进数十亿到数千亿的参数中。对于在训练集中高频出现、模式清晰的内容（如经典前端特效、常见小游戏），模型几乎是在做近乎无损的"记忆检索"；而对于罕见、定制化的业务逻辑，模型则需要进行高压缩度的泛化推理，出错概率大幅上升。这解释了演示效果与真实项目之间的巨大鸿沟——演示恰好落在数据分布的"甜蜜区"内。

这也解释了为什么内行看到"一键生成"就会警惕——它们展示的是数据集覆盖度，而非真正的工程能力。

Vibe Coding能跑通的三个隐藏前提

UP主强调，Vibe Coding在demo阶段确实能跑通，但这依赖于三个容易被忽视的前提条件。

1. 复杂度低、无持续维护需求

典型的demo场景（比如一个用SQLite做的进销存小系统）具有共同特征：代码量小、需求属于主流、无需长期迭代。

2. 结果可以肉眼检查

因为代码量小，开发者可以直接用眼睛验证结果是否正确，不需要严格的校验、约束或plan。AI往往能自主判断出最佳实现路径。

3. 代码量可控

UP主给出了一组经验数据：早期Web应用demo的代码量大概在2万行左右，而现在真实项目已经膨胀到8万到12万行。他指出复杂度"几乎是线性增长"（但并非严格100%线性）。

在代码量小的阶段，即便出现"领域入侵"（把A模块的逻辑写进B模块）、强耦合、弱类型写法这些工程坏味道，也"无所谓，反正AI能维护能跑就行"。问题在于，一旦系统变大，这些债务全部会爆发。

背景知识：软件工程债务与架构治理

上述"领域入侵""强耦合""弱类型"等属于经典的技术债务范畴。软件工程数十年积累的核心方法论——如领域驱动设计（DDD）、SOLID原则、分层架构——本质上都是为了对抗复杂度增长带来的熵增。研究表明，软件维护成本往往占总成本的60%以上，而混乱的架构会使维护成本呈指数级上升。这正是为什么代码量从2万行膨胀到12万行时，此前被忽略的坏味道会集中爆发的深层原因。

转折点：当demo要变成生产系统

这是整篇分析的核心论点。当一个Vibe Coding的demo要真正投入生产使用时，它需要面对一整套软件工程的要求：

• RBAC权限体系
• 缓存、数据库、任务队列
• 正式的技术选型
• 可观测性、可维护性、高性能
• 可控的架构

延伸：生产级系统的隐性门槛

RBAC（基于角色的访问控制）是企业系统权限管理的事实标准，通过"用户-角色-权限"的间接映射实现灵活授权。而可观测性（Observability）通常包含日志（Logging）、指标（Metrics）、链路追踪（Tracing）三大支柱，用于在分布式系统出现故障时快速定位问题。任务队列（如RabbitMQ、Kafka）则用于解耦系统组件、削峰填谷。这些能力在demo中完全可以省略，但在生产环境中缺一不可——它们正是软件工程成熟度的标志，也是AI在快速生成阶段最容易忽视的部分。

架构失控会导致代码腐烂

UP主指出，如果不人工把控架构、任由AI自行迭代，会出现两种失败模式：

1. 调查不完全——AI因上下文限制无法全面了解系统，做出错误设计；
2. 过度设计——引入大量不必要的抽象、依赖和"造轮子"行为。

他举了一个生动的例子：本来只需要一个进程内的本地队列（"一个上层接口就完事了"），AI却搞出一套要求幂等、要求可靠、引入一大堆依赖的复杂实现，而这些东西"其实别人的库早就做了"。

plan机制引入新问题

为了应对复杂度，人们开始让AI先做plan（规划）再执行。但plan本身也有陷阱：

• 假实现：看起来规划好了，实际是占位符（"假牙签"）；
• plan本身有缺陷：需要反复迭代好几个小时；
• 单模型上下文限制：单个模型的上下文窗口有限，无法全面调查，得出的结论天生有缺陷。

最终，开发者会"意识到需要回归软件工程"——维护工程文档、开发规范、约束。AI并没有让软件工程消失，只是把它推迟到了系统变复杂的那一刻。

Agent Team与模型跑分：两个被高估的方案

Agent Team的信息损耗问题

对于多智能体协作（Agent Team），UP主的批判集中在信息传递的有损压缩上：

"单位字数下的信息密度是有极限的。AI没办法判断什么内容重要、什么不重要，改变表达之后可能导致边界丢失，然后就错了。"

背景知识：多智能体协作的信息瓶颈

Agent Team（多智能体系统）是当前AI工程的热门范式，典型如AutoGPT、MetaGPT等框架，通过让多个AI角色（如"产品经理""架构师""程序员"）分工协作完成复杂任务。其理论优势在于分工降低单个Agent的认知负担，但实践中存在一个根本性瓶颈：Agent之间只能通过自然语言（文本）传递信息，而自然语言是一种有损压缩介质。当一个Agent将复杂的技术约束"翻译"成文字传给下游Agent时，隐含的边界条件、异常处理等细节极易在转述中丢失——这与"传话游戏"中信息层层失真的原理如出一辙，也是Agent Team难以处理长链路复杂任务的深层原因。

他以某AI编程工具为例：因为上下文压缩导致约束丢失，最终无法判断命令本身是否有问题，酿成事故——这也是后来业界引入沙盒、审查机制的原因。

模型跑分的可信度问题

对于模型跑分，UP主持谨慎态度，列出了几个造假空间：

• 不知道实际跑了几次；
• 是否偷用测试数据训练模型；
• 使用的框架、调度机制不透明；
• 是否用了内测版模型。

延伸：基准测试与数据污染

AI编程能力常用的基准测试包括HumanEval、SWE-bench等。所谓"偷用测试数据训练"在业内称为"数据污染"（Data Contamination）——由于基准测试题目往往公开在互联网上，若被纳入模型训练数据，模型就等于"提前看过考题"，跑分自然虚高却无实际能力提升。这也是为什么SWE-bench等推出了持续更新的私有测试集版本。此外，评测时的prompt工程、采样次数（pass@k中的k值）、脚手架框架都会显著影响成绩，使得不同来源的跑分几乎无法横向比较。

他给出的判断标准很实用：

"跑分不好看的模型一定不好用；但跑分高的可能造假。反正跑分不行的就不用。"

即跑分只有排除法价值，不能作为选型的正向依据。

结论：认知带宽才是根本瓶颈

整篇分析最深刻的洞见，在于把问题归因到人的认知容量：

"当一个人的脑袋容量有限时，他能关注的事情是有限的。面对一个复杂架构、超大系统，他就不能解决相应的问题。"

基于此，UP主对当前流行的"AI企业合作"、"复杂调度"、"Cloud Workflow"、"Agent Team"等方案给出了极端的判断：它们注定失败。

这个结论或许过于绝对，但其背后的逻辑值得每一个AI编程从业者思考：

• Vibe Coding的成功建立在"低复杂度 + 高质量训练数据 + 可肉眼验证"的三重前提上；
• 一旦系统进入真实生产环境，上下文限制和信息压缩损耗会成为无法回避的硬约束；
• 软件工程从未消失，AI只是让你在错误的时刻误以为可以跳过它。

真正可持续的方式，或许不是用AI取代软件工程，而是让AI在人工把控的架构框架内工作——写得慢一点，才能活得久一点。

核心要点