几乎所有服务都需要默认开启硬性预算上限
文章摘要
Simon Willison 这篇短文提出一个观点：未来几个月乃至几年里，所有按用量计费的服务和 API 都应该提供默认开启的硬性预算上限——用户设定「每月超过 X 美元就切断服务、直接返回错误」，而不是「超过 X 美元给我发封警告邮件」。他强调必须是硬限制，软限制解决不了问题。
他的理由与 AI 编程代理有关。编程代理，以及换了个不那么吓人的界面的「个人代理」，大幅降低了做出能干活的程序的门槛，而这些程序常常会花钱：调用付费 API、部署托管应用、使用会按存储和算力额外计费的系统。没有人愿意早上醒来才看到一封半夜发出的预算警告，然后发现失控的服务在自己睡觉时又烧掉了几百甚至几千美元。
他预料到一个反对意见：企业不希望托管应用因为超预算就开始报错。他的判断是，大多数企业和个人宁可服务报错，也不想收到一张一万美元以上的意外账单。因此硬上限应该是默认设置，想「冒险」的人可以主动关掉——比如在醒目位置放一个复选框，写明「移除预算上限；超出预算后应用不会被关停，我将承担后续费用」。
他最希望看到这项功能的是 AWS：很多人出于（合理的）担心，不敢用 AWS 做个人项目，怕某个失控的服务让自己破产，也确实有人没料到这一点而吃了大亏。写到这里他发现，AWS 在 9 月 16 日发布的新体验里恰好推出了支出上限：升级到付费计划后可以为项目设置月度支出上限，达到上限后该项目当月暂停。不过文档注明这一体验目前只对部分客户开放，他希望能尽快覆盖已有账户。Google Cloud 也在 7 月推出了类似的 Spend Caps，可以对项目中的特定服务设置月度上限，看起来正在形成趋势。
文末他提出一个理想场景：AI 代理本身也可以帮忙，在推荐服务商时优先推荐支持硬预算上限的平台，并提醒经验不足的开发者不要把应用部署在没有上限、可能让自己陷入麻烦的服务上。
HN 评论精华
帖子获得 650 分、300 多条评论，讨论非常热烈，核心分歧是：硬上限对小用户和企业分别意味着什么，以及云厂商迟迟不做到底是技术难题还是商业动机。
GCP 的新功能「名不副实」。 modeless 一开始很兴奋 Google Cloud 终于有了按服务的硬上限，读完文档后改口说是「假的」：只支持四个服务，其他一概不支持；只能按月设置，也不考虑抵扣和折扣。there_is_try 补充说，在 AI Studio 中创建的项目可以使用硬上限。
企业到底要不要硬上限？ twoodfin 认为这是客户「没想清楚就以为自己想要」的功能：「永远别让我花超过 X」也意味着「周日凌晨两点因为 IT 忘了算新报表的开销，把关键业务停掉」。simonw 回应说，医院这类场景就该勾选「无上限」。曾在一家有硬上限的后端服务做客服的 motionlessveloc 说那是一场噩梦：客户因自然增长、走红或大型活动被硬生生切断，投诉甚至威胁起诉不断，所以一般还是用告警更好。反方声音同样很多：traceroute66 说主张用告警的人应该去搜一下「告警疲劳」，告警可以被忽略、被错过，硬上限才能逼人把成本控制和监控做对；cogman10 指出对小企业和个人来说，这可能是「糟糕的一晚」和「破产」的区别；figassis、Shorel、layer8 等人认为二者根本不冲突，软上限加告警、再设一个更高的硬上限兜底即可。cj 引用他人观点称「只有业余开发者真正需要」，simonw 回了一句：今天的业余爱好者就是明天在公司里决定用哪家服务的人。
技术上有多难。 MobiusHorizons、Anon1096、miki123211 解释：云计费高度细粒度，用量通过异步事件上报，有时按 24 小时批处理，计费系统本来就不在请求链路上。simonw 也承认确实难，比如一条扫描万亿行的 SQL 查询，跑完才知道要花 100 美元。eddythompson80 指出，如果让每个服务在执行前都向计费系统申请额度，计费系统就会变成全局单点故障，可用性要求高到不现实；miki123211 则描述了「预留额度 + TTL」的可行设计。Joker_vD 反问：手机运营商能实时计费，云厂商为什么不行？miki123211 回答说电信业早期也是事后结算，直到预付费出现才发明了实时鉴权协议 CAMEL，而云厂商从来没有这个压力。mattlondon 的说法很有代表性：Google 能造出全球一致的分布式数据库，却做不到「超过 X 美元就停」？他认为这更像商业模式问题，而不是工程问题。
存储怎么办。 bpodgursky 问：难道超限就把 S3 数据删了？simonw 引用 AWS 文档：项目暂停后会保留数据 90 天。3eb7988a1663 指出，「停止产生新费用」和「删光一切」是两回事；Dylan16807、csande17 提出按容量设上限、上传时预扣当月存储费等方案。zbentley 则提醒，他处理过的最大一笔意外账单恰恰来自存储（遗留的 EBS、清理任务失效的 S3 桶等），每月高达数十万到上百万美元。
是故意的吗？ akd 的解释被认为一针见血：硬上限之所以少见，是因为对值得同情的个人免单、同时从失控的企业客户身上赚钱更划算。apt-apt-apt-apt 补充说，没有 PM 愿意因为「花工程时间让收入减少 20%」而被开除。foldr 则认为大厂经常免除意外账单，真正的原因是实时计算全部用量很难。曾在 AWS 客户顾问委员会任职的 Terretta 说，大企业都不希望计费部门「内联」进系统控制，AWS 已经提供了 API 和模板，用户可以自己搭断路器；dwedge 和 dcminter 反驳说，自己拼凑的方案做不到一分钟内全部停掉，这恰恰没抓住重点。
亲身经历。 jcims 说自己的个人账户因为开启 SQS 数据事件写入 CloudTrail 形成反馈循环，每天烧 4000 美元，最终累计 2.5 万美元；iambateman 的 OpenAI key 被盗，一小时被刷掉 300 美元，原因是 30 美元的上限需要另外勾选一个默认关闭的「强制执行」选项（后来 OpenAI 退了款）；mstaoru 在 Google AI Studio 只充了 10 美元，生成视频后余额变成 -160 美元；HamadMalikKhan 说设了 500 美元上限并开启自动充值的 OpenAI 账户照样花了 600 美元。traceroute66 提到 Upcloud、Exoscale、Verda 等欧洲服务商早就提供硬上限和清晰的价目表。
延伸观点。 kqr 认为不只是钱，可靠的生产系统里一切都该有硬上限：队列长度、请求大小、等待时间、认证次数等。yencabulator 建议把硬上限默认设为「上月账单的 3 倍」，可以调整倍数。theodpHN 调侃说，1970 年代大型机和分时系统早就内置了美元、算力、磁盘、打印、时间等各类资源限额。dools 则认为问题根源在 MCP：与其让代理反复调用产品，不如让代理写成确定性的脚本。也有少数人（如 gjvc）对 Simon 本人发起人身攻击，认为他最近的文章质量低，这类评论没有获得多少认同。