Simon Willison：所有按量计费的服务都该默认开启「硬预算上限」

一句话：软上限是通知，硬上限才是保险

10 月 3 日，独立开发者圈最受尊重的观察者 Simon Willison 发表了一篇短文，标题是《We're going to need default hard budget caps on pretty much everything》（我们需要给几乎所有东西加上默认的硬预算上限）。他的主张只有一条，但很锋利：所有按量计费的服务和 API，都应该默认开启「硬」预算上限——这个月花到 $X，服务就停掉并返回错误。而「花到 $X 就发一封警告邮件」这种软上限，在他看来根本不算数。

为什么是现在？因为 coding agent 彻底改变了「花钱」这件事的摩擦系数。以前你要烧钱，至少得自己动手点几下控制台；现在一个 agent 半夜自己就能注册托管数据库、拉起 GPU 任务、调用按次计费的 API。Willison 写道：没人想一觉醒来，看到一封半夜发来的超预算警告邮件，然后发现那个失控的服务在你睡觉的时候又多烧了几百甚至几千美元。

反方观点他替你想好了：报错 vs 天价账单，你选哪个？

反对硬上限最常见的理由是：企业不希望自己的线上应用因为触及预算就开始报错。Willison 的回应很直接：他相信绝大多数企业和个人，宁愿看到报错，也不愿收到一张超过 1 万美元的意外账单。

更关键的是他对「默认项」的坚持：硬上限应该是默认开启的，想关掉可以，但必须是一个显眼的、主动的选择——比如一个写着「移除预算上限，超额后我的应用不会被关停，我将承担后续费用」的复选框。把「活得危险」变成 opt-in，而不是让所有人默认裸奔。

大厂已经在动了，但都没做成默认

Willison 点名最想看到这项功能的是 AWS——他听过太多人因为「怕一个失控的服务让自己破产」而拒绝在个人项目上用 AWS 的故事。巧的是，AWS 在 9 月 16 日刚刚发布了月度项目支出上限：达到限额后项目当月暂停。Google Cloud 则在 7 月推出了针对单个服务的 Spend Caps（目前还是公开预览）。但两家都没有把它做成默认项，而且可用范围都还有限。

这篇文章发出的第二天就冲到了 Hacker News 热榜前列（300+ 赞、150+ 评论）。评论区里最有价值的是一条「反方实证」：一位曾在提供硬上限的服务商做过客服的前员工说，每当有正当业务在流量爆发期被硬上限掐断，都会带来噩梦级的客诉甚至法律威胁——这大概就是大厂十年来一直拖着不做的原因。硬上限保护的是钱包，伤害的是可用性，这笔账每个服务商都在心里算过。

给 vibe coder 的 takeaway：先设上限，再放 agent 过夜

这篇文章和 vibe coding 的关系是直接的：我们这个群体是「让 agent 通宵干活」最积极的人，也是离「一夜醒来看到天价账单」最近的人。三条实操建议：

第一，今晚就去给你的云账号和 API key 设上限——AWS 的月度项目支出上限、Google Cloud 的 Spend Caps、各个模型供应商的用量上限，有一个算一个，全部打开。不要等到第一次被烧到才动手。

第二，把「花钱」纳入给 agent 的约束条件，就像你给它写测试要求一样：在任务描述里明确单次运行的 token/调用预算，超了就停下来问你，而不是自己想办法绕过去。

第三，如果你在做面向用户的 vibe 产品，把硬上限做成你产品的默认项——Willison 的论点反过来读就是产品建议：你的用户里一定有人会让 agent 失控，默认的硬上限是你能给他们的最便宜的保险。