为什么我们把赔付规则写进产品，而不是藏在客服话术里

机制上线进度（2026-07-09 更新）：本文描述的是赔付体系的完整设计。赔付规则与算法按文中口径执行；当前为申请制——联系客服提交后，按公开算法人工审核核算入账（申请方式见此）。自动监控已上线，自动计算与自动入账正分阶段推进；在此之前，文中描述的全自动计算、自动到账与月度邮件能力均指目标态。

市面上的 SLA 是什么样的

去翻十家主流 API 服务的 SLA 文本，会发现它们长得几乎一样：

• 可用率承诺（常见 99.9% / 99.95%）
• 一张按不可用时长映射的赔偿比例表（5%–50% 月费）
• 一条”需用户主动申诉并附证据”的条款
• 一条”不可抗力除外”的条款

这些文本的 真实使用率是多少？ 我们问过几个同行：几乎为零。用户出了问题的第一反应是换一家，不是读 SLA。

原因很简单：申诉流程的成本高于能拿到的赔偿。 要登录、要提工单、要上传截图、要等 7 个工作日审核，最后可能拿到 15% 月费的代金券——算上时间成本是负收益。

我们做的事情

我们把赔付从一份”出问题了再去翻的文档”变成了产品里的自动逻辑——规则、计算、入账都不需要你做任何动作。

1. 自然月 + SKU 大类 + 三档赔付

每个自然月（UTC+8）跑完，按你当月每个 SKU 大类（Claude / Claude Code / GPT / Gemini / Qwen / 国产 5 折一组 / Doubao）的可用率独立算赔付：

• ≥ 99% — 不赔付
• 98% – 99% — 该 SKU 当月订单额 2%
• 95% – 98% — 5%
• < 95% — 10%（月上限也是 10%）

档位独立计算的意思：你这个月 Claude 96% / GPT 99.5% / Gemini 100%，只对 Claude 部分按 5% 赔，其他 SKU 不动。 为什么不是连续公式或更细的中间档？因为客户和 BD 都得能脑子里算出来。每次跟客户解释「你 96.3% 对应 5pp + 0.3 × X」就是浪费时间。三档跳变还会强化「保 95%」的目标线，oncall 自己都知道这是底线。

2. 月末自动结算，不需要你发现问题

月末跑完，次月 3 日 9 点所有受影响客户收到一封邮件：每个 SKU 大类的当月可用率、赔付金额、计算明细。金额先入预备账户——你能在邮件和后台看到，但还不能用。 7 天申诉窗（次月 3–10 日）里你或我们任一方可以对计算提异议；窗口结束、无成立申诉时，金额自动转为账户余额、从此可用。超窗默认接受。 单笔 ≥ ¥5000 的赔付会先冻结 24 小时由运营复核（防 dashboard bug 错赔），复核通过后再入预备账户。

极小样本不触发赔付：单 SKU 月调用 < 100 次，或某 SKU 全平台月样本 < 1000 次，按规则不触发当月赔付——50 次调用算出来的「94%」统计噪声太大，不能作为赔付依据。SLA 覆盖关系不变，只是这种情况没可计算的赔付。

3. 失败口径只算我们能负责的硬错误——这是有张力的

只有这三类请求计入「不可用」分子：

• 上游服务器返回 5xx（500/502/503/504）
• 上游 60 秒内不返回首字节（超时）
• 我方网关 5xx（路由 / 计费层崩溃）

主动限速、上游 401 / 429、客户端 4xx、余额耗尽都不计入。这是个有争议的选择，我们必须把张力说清楚：

客户端遇到「明明用不了但 SLA 数字还是 99%」是可能的——比如你单 key 触发了 QPS 限速（我们返回 429，让你重试），或者上游某个账号 token 过期我们正在切。这些场景你感受到的是「服务不稳」，但 SLA 数字不动。

选这个口径不是为了保数字，是因为只有我方网关 + 上游服务端的硬错误是 SLA 这个语义能负责的事。限速是产品策略（写在接入文档里），客户端 4xx 是请求层错误，把这两类塞进可用率会让 SLA 变成一个我方也搞不清意义的数字。 对于真的会影响你跑代码的限速 / 401 / 429 问题，我们的策略是oncall 主动看告警 + 30 秒切渠道，不是等你工单。

4. 维护窗扣除是有约束的，不能用来美化数字

计划维护可以从分母里扣，但同时满足三个条件才行：≥ 7 天公告 + 单次 ≤ 4h + 月累计 ≤ 8h。超出 8h 部分回到分母算故障；上游主动维护（哪怕提前公告）也不可扣——那是上游问题不是我方。 这条规则刻意写紧，是为了避免运维把维护窗做成 SLA 美化工具。

这么做的代价

• 财务预期需要重新建模 — 赔付是实际成本，不再是”不会被兑现的承诺”。我们按历史故障数据建了一个赔付准备金率，大约是营收的 0.4%。
• 监控精度门槛抬高 — 如果你判错了故障，就是在给用户送钱。我们的故障判定算法内部做了双人 code review，跑 shadow 一个月才上线。
• 故障叙事没法糊弄 — 以前可以说”偶发波动”，现在账单里白纸黑字写着赔付金额，不够诚实就是自己打脸。

为什么是现在写这篇

最近和几个团队聊，发现大家对 API 服务的 SLA 预期已经非常低了——“反正写了也没用”。我们想表达的是：SLA 可以不是法律文本，可以就是产品本身。 这不是我们聪明，只是行业标准太低了。

如果这篇文章让你看到”诶原来可以这样做”，那就够了。