昨天刚写完 Token 预算失控,今天现实就送来一个教科书级别的案例。
5 月 30 日,V2EX 上炸了一条帖子:一家公司忘了给 Claude 设限额,一个月烧掉 5 亿美元。 不是年预算,不是项目预算,是一个月的账单。同时,Flathub 宣布禁止 AI 生成的应用上架,阮一峰在周刊里写了"Token 费用难以负担",而另一边,有人 30 天用 AI 写了 11 万行代码。
这一天关于 AI 的消息,拼出了一幅完整的图景:AI 的"野蛮生长"阶段结束了,成本控制和质量管理正在成为新的核心议题。
5 亿美元的教训:AI 不是水电,是印钞机
一个月 5 亿美元是什么概念?按美国工程师平均年薪 15 万美元算,这笔钱能雇 4000 个工程师干一年。而它只是一家公司一个月的 Claude API 账单。
怎么烧掉的?帖子里没提公司名,但推演一下不难:Agent 模式下的循环调用。一个"重构这个代码库"的任务,Agent 会读文件 → 改代码 → 跑测试 → 报错 → 读文件 → 改代码 → 再跑 → 循环 N 次。每次循环吃掉几十万 token,一次任务几百万 token。如果不设上限,一个失控的 Agent 循环就是一台烧钱机器。
这不是孤例。昨天 V2EX 上还在讨论"Cursor 一个月用掉 $500",今天这个数字翻了 10000 倍。
核心问题不是 AI 太贵,是我们还没学会给 AI 设预算。 就像十年前云服务器刚普及时,无数公司被"忘了关 EC2 实例"的账单吓醒。现在轮到 AI API 了——你开的不是一个实例,是一个会自己循环的 Agent。
阮一峰的警告:Token 费用难以负担
同一天,阮一峰在科技爱好者周刊第 398 期里写了"Token 费用难以负担"。他的读者群体主要是独立开发者和中小团队——这些人的感受最真实。
大公司烧 5 亿美元还能扛,独立开发者烧 $500 可能就断了现金流。更糟的是,AI API 的定价模型对"意外使用"几乎零防护——设定每日限额是手动操作,很多开发者根本就不知道有这个选项。
一个合理的做法:任何调用 AI API 的应用,第一条代码不是 client.chat.completions.create(),而是预算护栏。 每日上限、每次任务上限、异常循环熔断——这些不是"nice to have",是"否则你会破产"。
Flathub 的禁令:AI 生成的代码,质量谁来担保?
Flathub 宣布禁止 AI 生成的应用上架。理由没明说,但不难猜:质量不可控,安全不可审计。
AI 生成的代码有两个致命问题:
- 你不知道它从哪学的。 训练数据里可能有 GPL 代码,生成的代码可能有版权雷。Flathub 作为分发平台,没法为每一行 AI 生成的代码做合规审查。
- 你不知道它为什么这么写。 人类开发者可以解释设计决策,AI 不行。当应用出了安全问题,Flathub 需要知道是谁的责任——如果是人类开发者,能找到人;如果是 AI 生成的代码,找谁?
这个禁令不会停留在 Flathub。可以预见:应用商店、Linux 发行版、企业采购名单,都会陆续加上"禁用 AI 生成代码"或至少"AI 辅助代码需标注"的条款。
对开发者来说,这是个警告信号:AI 可以帮你写代码,但你不能让 AI 替你负责代码。
"MVP 思维已经失效了?"
还有一个讨论值得关注:"AI 编程时代,MVP 思维已经失效了?"
传统 MVP(最小可行产品)的逻辑是:用最少的工作量验证核心假设。但 AI 让"最少的工作量"几乎变成了零——一个下午就能搭出完整的功能原型。结果是:MVP 不再稀缺,稀缺的是"判断哪些 MVP 值得做"。
用 AI 编程的开发者面临的新困境是:做出来太容易了,以至于判断"该不该做"变成了最难的环节。以前是"能不能做"卡住你,现在是"做出来之后呢"卡住你。
30 天 11 万行代码的隐忧
有人在 V2EX 分享:"30 天 11 万行代码,我用 Trae 和 Gemini 造了个 AI 测试引擎。"
11 万行。30 天。如果全是人类手写,这需要一支 5 人团队干半年。现在一个人 + AI 就完成了。
但问题是:谁 Review 了这 11 万行代码? 如果没人 Review,那这个"AI 测试引擎"本身可能就是一个巨大的 Bug 农场。测试引擎要测别人的代码,首先自己的逻辑要对——如果 AI 生成的测试用例本身就是错的,那整个测试流程都是一场自欺欺人。
这就是 AI 编程时代最危险的陷阱:速度掩盖了质量问题。 写代码的速度快了几个数量级,但确保代码正确的手段没有同步进化。
我的判断
几条消息放一起看,结论很清晰:
1. AI 账单管理是必要工程能力。 把 API 限额、预算护栏、循环熔断写进系统设计的第一天——就像你写 web 应用第一天就考虑 Rate Limiting 一样。
2. 可审计性是 AI 代码的硬门槛。 Flathub 的禁令只是个开始。如果你用 AI 写的代码要进生产环境,最好准备一个文档记录"哪些模块是 AI 生成的、人工审查了哪些部分"。这在未来会变成合规要求。
3. 产能爆炸不一定是好事。 11 万行代码一个月确实厉害,但 Review 能力的瓶颈不会因为你写得更快就消失。如果团队只有两个人的 Review 带宽,AI 写出 11 万行代码只会制造 11 万行的技术债。
4. 最稀缺的能力不是写代码,是判断"不写什么"。 MVP 思维失效了,不是因为 AI 让 MVP 没用了,而是因为 MVP 太容易了——真正的瓶颈转移到了决策层。知道"不做"比知道"怎么做"值钱得多。
今天那家烧掉 5 亿美元的公司,大概明天就会把"加预算上限"排到 P0。你的下一个 commit,最好也是。
浙公网安备 33010602011771号