Cloudflare 费用控制上线：先决定暂停后用户还能做什么
面向 AI 应用创始人的服务暂停方案：厘清费用上限范围，保住已完成内容，处理未完成任务，并有依据地恢复服务。
Cloudflare 在 11 月 13 日宣布推出 Spend Management Beta，初期面向使用 Workers 和 Durable Objects 的按量付费客户。它提供了一种新选择：当支出达到设置的阈值时，暂停支持范围内的活动。对小型 AI 产品来说，这让预算讨论变成了服务可用性决策：钱不够时，应该停止用户的哪项任务？
官方发布文章确认了功能及初期范围。本文面向使用应用生成器的创始人，以及负责线上产品的小团队，提供一张可复用的暂停检查表、一个报告生成场景和一套可要求开发者演示的演练方法。我们没有在客户账户中启用该功能，也没有测量其拦截生效时间。我们的判断是：基础设施费用控制适合作为最后一道保护，但启用拦截前，应先设计用户遇到暂停时的体验。即使中断有代价，设置上限仍可能合理。真正危险的是停服后才发现：用户拿不到已有成果，客服看不到待处理任务，也没人知道重启会不会让同一任务重复扣费。
1. 费用告警与持续服务承诺，要分别负责
告警是提醒人作决定；拦截则已经替人执行了一个决定。两者可以同时存在，但负责人和验收条件不能混在一起。
告警是否有效，要看正确的人有没有及时收到可采取行动的信息。暂停是否有效，则要看后续支持范围内的操作是否停止，以及受影响用户是否得到真实、可恢复的结果。收到一封邮件，并不能证明后者成立。
先写清产品卖给用户的承诺。免费原型在预算用完后拒绝新任务，可能完全合理。付费研究工作台即使停止昂贵的生成，也可能需要保留下载和账户访问。预约服务则可能需要人工接手，因为拒绝请求可能意味着错过一次预约。这些是团队需要决定的产品行为，不是 Cloudflare 自动提供的保证。
用一句普通话写下来，例如：“无法生成新报告时，用户仍能取回已经完成的报告。”然后要求实现负责人列出兑现这句话所需的全部依赖。如果下载也依赖被暂停的服务，那么当前实现就无法兑现承诺。再漂亮的维护页面也解决不了这一点。
还要约定谁能临时提高额度。无限制的应急放开可能重现超支；无人能调整又可能让可避免的中断持续。指定主要负责人、备份人员，并记录每次例外的理由，让财务决策可追溯，而不是让客服在对话中临时拍板。
2. 先画出控制边界，再谈应用是否受保护
基础设施产品的边界，并不等于你的一款应用的边界。Cloudflare 的费用控制文档说明，初期上限作用于账户内所选产品的整体用量，不能针对单个 Worker 或 Durable Object 命名空间。文档也明确提醒：用量上报和拦截生效需要时间，某些收费仍会继续，因此上限不保证最终账单金额。
如果一个账户下放了几个实验项目，这个范围尤其重要。一个流量异常的试验可能连带影响使用同类产品的付费应用。反过来，一款应用也可能通过未包含在所选上限中的依赖继续产生费用。需要的是账户依赖图，而不只是一个显示“已启用”的开关截图。
列出公开网站、登录、已保存文件、生成接口、支付通知、定时任务、客服工具和内部后台，并逐项标注所属账户及依赖产品。不知道的地方明确写“待确认”。如果托管由应用生成器管理，还要确认自己是否拥有对应账户的控制权。基础设施厂商提供费用控制，不代表生成器的订阅或点数也会因此受控。
也不要为了让图更整齐就立即拆分账户。拆分本身会增加权限、部署和运维成本。先找出真实的共同故障边界，再判断最重要的用户承诺是否值得为此调整。周末原型接受一起暂停，可能很合适；多个付费产品共享同一边界，则需要更认真地评估。
即使最终只选告警，这张图也有价值：它能告诉响应人员从哪里排查，以及以后启用拦截可能影响哪些用户。
3. 运行费用与模型预算，是两套控制
AI 应用可能没调用多少模型，却消耗很多运行资源；也可能托管便宜，推理费用很高。这两个问题要分开处理。
Workers 计费文档说明了请求和 CPU 的收费方式，以及单次执行的 CPU 控制。它有助于排查失控执行，但不代表一份报告、一张图片或一次对话的完整成本。流程还可能调用外部模型、保存上传文件或使用其他服务。 AI Gateway 费用上限文档描述的是经过网关路由的请求预算，包括按维度划分和拦截行为。这是另一套控制入口。绕过该路由的模型调用，不能默认受到同样保护。要求开发者把一个昂贵的用户操作从头画到尾：哪些调用走网关？哪些直接使用供应商凭据？推理失败后会不会再调用一次其他供应商？管理工具是否也走相同路径？这些答案应来自配置和调用记录，而不是“我们用了 Cloudflare”这句话。
一种实用分工是：应用规则决定用户能否启动任务，模型预算约束被覆盖的推理请求，基础设施边界限制支持范围内的运行支出。这几层可以互补，但不会因为出现在相关面板里就自动成为同一笔原子操作。
除非应用真的跨越全部工作步骤执行了约束，否则不要向用户承诺固定的单人最高成本。基础设施保护处理的是更大的风险边界，产品仍需为不同用户设计公平的任务准入规则。
4. 在完全停止前，设计一个仍然有用的简化服务
“优雅降级”是指完整功能无法运行时，主动提供范围缩小但仍有价值的体验。它不等于悄悄换用便宜模型。缩减后的服务仍需符合展示给用户的承诺。
Google 的 SRE 过载处理章节强调，应认真设计降级条件和行为。放到小型 AI 应用里，就是判断哪些工作可以省掉，而不会让剩余结果误导用户。这是可靠性原则的应用，不是某套 Cloudflare 配置已经能保留这些能力的证据。
文档助手可以停止新上传，但让已有文档继续可读。设计工具可以关闭新变体生成，但让用户下载已批准图片。研究产品可以展示带原始日期的已有报告，而不是把旧报告伪装成新答案。每个选择都要求相应依赖仍能工作。
有些任务就应该停止。如果便宜模型无法可靠提取必需字段，能输出文字也不代表它适合替代。简化模式会明显改变质量时，应在用户依赖结果之前说明；流程允许的话，让用户选择等待或取消。
在应用还正常运行时就定义切换方式。更早启动应用层限制，可能保留容量让已经接受的任务收尾。等到基础设施开始拒绝调用，负责显示解释页面的代码也可能运行不了。演示时要走用户实际访问的入口，包含登录和已保存数据，不能只展示一个孤立的设计预览页。
5. 用报告应用推演三种未完成状态
假设有一款虚构产品“港湾报告”：用户上传访谈笔记，启动综合分析，稍后回来下载。这只是设计场景，不是真实客户案例，也不是已完成的实验。
创始人决定可以暂停新生成，但已有报告应能取回。团队却发现，首页是静态页面，报告下载需要经过带身份校验的 Worker 路由。所以首页还在，并不能证明最重要的承诺仍然成立。
再看三位用户：安娜的报告已经完成；小本提交的任务尚未开始；小陈的模型结果已经返回，但最终保存还没有确认。这三个人需要不同提示，也需要不同恢复决策。
如果取回路径可用，安娜应该拿到现有文件。小本需要真实的等待或取消状态，不能被告知“正在生成”。小陈则需要核对：先检查是否已有可用结果，再决定是否发起另一轮付费生成。“再试一次”无法准确覆盖这三种情况。
团队提出，先在应用层拒绝新生成，同时让已接受任务收尾；另外单独验证最终基础设施暂停时，已完成文件是否仍可访问。如果失败，就要调整取回方案，或者收窄公开承诺。不能因为额度开关有效就宣布可以上线。
如果涉及购买或点数，还要写明何时扣除权益、放弃的任务如何处理。托管限额不会自动产生退款规则。规则必须与真实计费实现和用户条款一致，且负责人能核实最终状态。
这样的推演可以产生具体开发要求，而无需创始人自己选择队列库或编写计费接口。
6. 把这张暂停检查表交给开发者
将下表复制到上线评审中，每项都换成自己应用的证据。“不适用”要有原因，“未知”则要在启用拦截前指定负责人解决。
| 决策项 | 所需证据 | 通过条件 |
|---|---|---|
| 控制范围 | 账户与产品依赖图 | 明确共享应用和未覆盖服务 |
| 用户承诺 | 每项核心任务的一句话承诺 | 承诺与暂停后仍可用的依赖一致 |
| 新任务 | 实际演示准入行为 | 停止接单后不会虚假接受任务 |
| 已接受任务 | 任务记录与状态变化 | 区分等待、运行、完成和不确定状态 |
| 已保存成果 | 登录后取回文件的演练 | 可访问已有成果，或已明确披露限制 |
| 模型支出 | 调用路径和预算配置 | 清楚哪些调用受控、哪些绕过控制 |
| 通知 | 收件人及送达检查 | 主要与备份人员能收到可行动的信息 |
| 用户提示 | 受影响页面的实际渲染 | 状态、下一步和支持入口清晰 |
| 恢复 | 指定负责人及重启步骤 | 开放任务前已检查支出原因 |
| 状态核对 | 任务与权益记录 | 不会自动重复生成或扣除权益 |
每行附上日期、环境、测试者和证据位置。配置截图适合证明范围；用户路径录像更适合证明体验。两者不能互相替代。
检查表应足够简短，方便故障中使用。完整架构文档可以放在证据链接之后，顶层记录只需让响应人员迅速知道：哪里受影响、自己能改什么、用哪些检查确认恢复。
非技术创始人需要判断的，不是每项实现是否优雅，而是证据是否支持正在销售的承诺。如果还不清楚，就解决缺失的那一行，不要靠修改措辞让评审看起来已经完成。
7. 提示要解释任务状态，避免诱导重复提交
好的提示先谈用户的工作，再谈基础设施。“新报告暂时无法生成，已有报告不受影响”，只有在两句话都核实后才能使用。如果已有文件也取不出来，就直说，并提供可访问的支持入口。
对于排队任务，要说明是否已经接受、是否会自动继续，以及在支持取消的情况下如何取消。不要编一个没人能保证的恢复时间；明确的进度更新渠道比虚构倒计时更有用。
HTTP 行为也很重要，因为调用方不止真人。HTTP 语义标准定义了临时服务不可用及 Retry-After 字段的语义。应由实现负责人根据真实情况选择响应。但这不代表 Cloudflare 拦截后会返回你理想中的应用响应，必须检查面向用户的实际路由。
浏览器不断重试，可能制造混乱，并在恢复后重复执行。已知任务仍在处理中时，应阻止重复提交，用应用层任务标识核对请求。重试读取与重试购买、生成，不能采用同一套决策。
客服应使用与界面一致的状态用语，并能定位请求、看到已确认状态、解释下一步；不应为此随意暴露私密提示词。如果客服后台也依赖被暂停的服务，就安排其他渠道接收问题，并获得恢复所需的最少信息。与应用一起失效的客服链接，并不是完整的后备方案。
8. 演练队列、周期和依赖，不要人为制造生产事故
不要为了证明策略存在，就故意耗尽生产预算。先在独立测试环境模拟应用的不可用状态。条件合适、产品支持时，再在没有其他客户负载的隔离账户核实供应商层行为。记录中必须区分“应用模拟”与“实际观察到的供应商行为”。
Cloudflare Queues 重试文档解释了重试、达到次数上限后的处理，以及死信队列的作用。但它不能证明你产品中的每个任务在费用暂停后会发生什么。保留时长、重试配置和应用状态，共同决定恢复时可以安全执行的操作。要求演示已完成、等待中，以及外部结果返回但尚未最终保存三类任务。每次操作后检查持久化记录，统计成功结果和权益变化，不能只看绿色响应码。还要测试恢复时用户仍开着旧页面的情况。
把一次演练记录写具体。拟议的 HR-01 可以包括测试账户、生效策略、应用版本、三条合成任务编号，以及停止接受新提交的时间。逐条写明最后确认的状态、据以确认的记录，以及实际检查人。演练尚未运行时，结果全部留空。这是记录设计，不表示港湾报告已经通过测试。
重新开放后，用同一批编号与暂停前对照。检查安娜是否仍能在正确账户里打开原文件，小本是否只有预期中的那条待处理请求，小陈结果不明的工作是否已有明确处置。新生成一次成功，不能证明旧工作没有丢失。记录人工介入，并单独核对相关权益。某项必要观察无法取得时，让该行继续保持待确认，指定人员补查，不要仅凭新请求成功就宣布恢复。
单独检查计费周期。订阅周期可能不是每月一号开始，因此应用的用户额度重置、计划发布与基础设施上限可能处于不同节奏。记录真实周期，不要假定大家都按自然月计算。
Workers 运行限制文档也有帮助：放宽费用策略后，执行约束仍然存在。提高金额不会修好超时、错误请求或其他依赖耗尽。演练应让响应人员能区分原因，避免每次失败都只会说“把额度加上去”。9. 恢复服务，也要有受控的开放决定
恢复生成之前，先查明支出上升原因。真实需求、滥用客户端、重复失败、部署回归，需要不同处理。原样重启一个失控循环，既是可用性决定，也是新的支出决定。
用简短故障记录保留：受影响产品与账户、用户症状、最后确认正常的时间、当前任务状态、怀疑原因、已采取动作，以及下一位复查人。确认事实与假设分开写。告警和故障时间接近，只能提供线索，不能直接证明因果关系。
Durable Objects 计费文档说明了为什么有状态服务要单独检查成本：它的收费维度与普通网页请求不同。应查看对应资源的用量，而不是假设访问最多的页面就是费用来源。先核对不确定任务，再启动重试。对港湾报告来说，就是确认小陈的结果是否保存、权益是否已扣除，再决定需不需要另一轮尝试。恢复流程应保留已有成功结果，而不是默认用新生成覆盖它。
解除控制后，先验证一个小范围的完整用户任务，再看新增费用和错误，最后决定是否放开全部积压。这是建议的运维方法，不是宣称供应商提供自动分阶段恢复。还要写清原症状重现时，谁有权再次停止开放。
最后用用户能采取行动的话说明变化：等待任务会不会自动继续、是否需要重新提交、结果缺失如何反馈。不能只凭面板状态宣布恢复；恢复意味着用户通过公开入口又能完成承诺的任务。
10. 判断这款产品是否适合自动拦截
当限制财务风险比持续接受新任务更重要、作用范围已明确、用户后续处理清晰时，拦截是合理选择。小型实验生成器可能符合条件；有付费交付期限、共享基础设施或关键运营责任的产品，则需要更谨慎地决定如何维持服务。
尚未画清依赖或演练恢复的团队，可以先考虑告警。但这仍留下费用风险，必须明确谁监控、谁响应，并设置复查日期，而不是默认“总会有人注意到”。
不掌握托管账户的团队，今天最直接的交付物是一组给生成器厂商的问题：有哪些费用控制，触发后停什么、保留什么，谁能恢复，以及客户能检查哪些证据？没有核对实际配置之前，不要暗示第三方生成器支持这项 Cloudflare 新功能。
有些产品缩减服务后会误导用户。如果核心任务无法可靠完成，就停止接单，并提供约定的替代办法。界面看起来很忙，不等于服务仍在持续。
今天值得采用的，是一份有证据支撑的服务策略：选定边界，写清用户承诺，演练未完成任务，指定恢复负责人。新的基础设施控制可以支持这份策略，但不能替团队决定，哪一种用户损失可以接受。