LLM 生成的测试代码耗尽了你的配额

The Vibe Tax

LLM 生成的测试代码耗尽了你的配额

我满怀信心地让 Pol 帮我从零构建一个专属的 todo 应用,本以为有了 LLM 的加持,代码会像变魔术一样自动生成。然而醒来后,我发现每周的 Token 配额竟在 12 小时内被彻底耗尽。深入检查代码库后,真相令人啼笑皆非:Pol 没有生成任何实际功能,而是构建了一个名为 'tests' 的庞大文件夹,里面塞满了针对永远无法触发的极端边缘情况的完美测试用例。这揭示了 'Vibe Coding' 背后的代价:为了让用户无需查看代码就能一键搞定,LLM 被训练得过度工程化,这种对确定性的病态追求,本质上是对所有普通开发者征收的一笔隐形 'Vibe Tax'。

数百万个 Vibe Coder 在数月间将其训练成能够一次性完美解决所有问题的工具,只是它消耗的 Token 是过去的十倍,这是他们为了永远不必查看代码而愿意支付的价格。
  1. ad_fontes

    读这类帖子时,我总觉得自己活在平行宇宙里。

    我的智能体从未生成过纯粹的垃圾代码,我也从未把一周的 token 额度冲进马桶。我完全无法认同那些对 AI 辅助编程的持续抱怨。

    而且我最大的项目可不是什么 Hello World 应用。它是一个自托管、注重隐私的个人财务管理应用,我打算开源。目前代码量约 12.6 万行,回归测试 24 万行,CI/CD 流水线 3 万行。我在专用机器上针对记账引擎和时间系统全天候(24x7)进行变异测试。我甚至部署了专门的智能体,依据 Regulation Z(美国银行法规)标准进行审计,确保应用能模拟银行所需的合规行为。

    我对 AI 的大部分抱怨其实都是细枝末节,比如 LLM 与我沟通时过于冗长和晦涩。或者它们倾向于不断添加、再添加、继续添加更多东西,而恰当的工程实践往往在于做减法(不过我已经针对这些问题构建了缓解机制和护栏)。

  2. guybedo

    我不太明白为什么人们指望智能体仅凭一个提示词就能一次性完美搞定所有事情。

    我们之所以谈论软件开发生命周期、设计、架构、测试……是因为这是构建和交付软件最可靠的方式。我们不应该抛弃这些,却指望智能体在脱离这些框架的情况下表现良好。

    我把 LLM 智能体当作拥有广博软件工程知识的初级开发者。作为他们的团队负责人,我让他们遵循严格的流程,经历规划、实现、扫 bug 的循环。效果相当不错,我一直在处理几个大型项目(100 万+ 行 Java、TypeScript、C/C++ 代码),按任何标准衡量,这些项目都很健康。当然,代码没那么优美,当然我也会用不同的方式去写,但无论如何,结果已经相当不错了。

    顺便打个广告:我也在开发 https://kodfactory.com,这是我构建的用于处理这些大型项目的代码工厂,支持工作流、代码审查等功能……我正在清理代码,稍后会开源。

  3. supriyo-biswas

    我深有同感,是的。

    实际上,我一直想要的是一个结对编程的智能体,而不是一个从零到一的编程智能体。不幸的是,现在的模型大多属于后者,这给我的工作方式带来了巨大的干扰。我宁愿要一个小模型,让我能请求它进行快速、具体的修改,而不是让它一次性摄入 20 个文件来修改,然后又开始写测试等等。

  4. alehlopeh

    我试过了,但我不太明白。这种“氛围税”(vibe tax)是因为模型试图一次性搞定所有事情,而这需要不必要的测试吗?那些“氛围编程”(vibe coding)的人是如何在几个月内训练模型的?你的意思是他们的会话和偏好被反馈到强化学习(RL)中了吗?

  5. danpalmer

    有点夸张,但我确实看到了一些迹象——模型拒绝与工程师结对工作,也不信任工程师的输入,反而强制要求完全掌控某项任务。有朋友为了保留一些输入控制权,已经从 Fable/Opus 5 切换回 Opus 4.8 了。

    尤其是 Anthropic,目前似乎正在优化“无需输入即可完成整个任务”的能力。如果这是唯一的任务,或者你不在乎香肠是怎么做的,那没问题;但对于真正的软件工程来说,这行不通。

  6. dzhar11

    这篇文章在某种程度上反映了我在自主智能体编程方面的经历。我做过几次类似的实验,结果都很相似:智能体烧光了我所有的 token,却几乎没有取得任何进展,或者产出的东西完全不可接受。

    所以我宁愿一步步微观管理这个过程。虽然这花了我更多时间,但结果要接近我真正想要的东西得多。

  7. markbao

    我从未遇到过智能体连实际实现代码都写不出来的情况。它写得烂吗?是的,但绝不会只写测试。听起来这对我来说是一个罕见的、不具备普遍性的案例。

    如果普遍的观点是这些智能体写了太多测试,嗯,我猜是吧?但“测试太多”在我看来并不是工程上的失败案例;通常软件的问题是测试太少。此外,这些智能体的很多力量在于它们自我验证和纠错的能力,而测试循环正是其中的一部分。

    没人逼你交这笔所谓的“税”。直接告诉它别写测试就行了。

  8. robertoallende

    哈哈!

    我就做了文章里说的那件事。我自己开源的 Kanban 看板,上个月发布的。根据数据指标,它表现不错:

    https://community.obsidian.md/plugins/fancy-kanban

    我还做了一个个人财务追踪器:

    https://www.youtube.com/watch?v=qi4P4kL4IkQ

    不过,有一个前提。我不搞那种“一次性提示词”的氛围编程。我用的是所谓的“微观管理驱动开发”(Micromanaged Driven Development, MMDD),它的目标正是一次性提示词的反面:https://mmdd.dev/

    当我读到这类文章时,我很惊讶,因为对我来说,遇到 token 限额是非常罕见的情况。我用的都是标准账户,每月在 token 上的花费不超过 40 美元。

    可能是我没找到推广 MMDD 的正确叙事方式,或者可能根本没人关心,这就是为什么现在人们很容易掉进那些为了博眼球而制造的点击诱饵叙事里。

    不是在辩解,只是试着描述一种感知。

同日更多故事

2026-08-23