日/周/月额度该怎么设计才不惹用户骂

额度规则本身不难，难的是「用户能不能自己算清楚」。一条让用户需要提工单才能算明白的规则，就是一条坏规则。

规则要能心算

「每天 10 美元」用户能心算，「每天按你昨天的用量的 1.2 倍」不能。任何需要解释的规则最终都会变成客服工单。

分清楚这三者，用户体验和客服成本都会明显下降。

网关的用量查询页应该一次性回答这三个问题，而不是让用户提工单。

未激活不计时

包月 Key 通常约定首次调用起生效。如果从下单那天开始算，用户买了不用的那段时间会被白白消耗掉。

包月 Key 通常有个「首次调用起生效」的约定。

这在实现上要注意：未激活的 Key 在被调用时才开始计时，而不是从下单那天开始——否则用户买了却不用的那段时间会被白白消耗掉。

剩余额度要显示完整口径

「剩余额度按已结算用量计算，进行中的请求可能尚未计入」这句话应该出现在页面上，而不是藏在帮助文档里。

「额度」是时间窗口内的总量上限，「限流」是瞬时速率上限，「余额」是账户层面的预付余额。

很多系统把它们混在一起，导致用户在错误的时间看到错误的信息——比如明明还有余额，却被「今日额度已用完」拦住。

今日重置和提前重置要说清楚

有的实现会在日界切换时重置额度并把已用部分保留。用户看到「今日剩余突然变满」时，需要知道这是重置而不是数据错乱。

所以续费时要保留：今日已用量、已兑换的额外额度、以及原到期时间的叠加规则。

但要注意：支付、报表、清理任务各自可能配了不同的时区，配置要在文档里写清楚。

实操：在请求前做一次成本预估。

额度查询页要回答四个问题：还剩多少、今天用了多少、什么时候到期、状态是什么。

CHARS_PER_TOKEN = 3.2   # 粗略经验值，中英混排差异很大

def estimate_tokens(text: str) -> int:
    return int(len(text) / CHARS_PER_TOKEN) + 1

def estimate_cost(system: str, history: list[str], output_tokens: int) -> float:
    prompt_tokens = estimate_tokens(system) + sum(estimate_tokens(h) for h in history)
    return prompt_tokens / 1_000_000 * IN_PRICE + output_tokens / 1_000_000 * OUT_PRICE

# 这个估算只用来做「要不要截断历史」的粗筛，
# 精确计费永远以服务端返回的 usage 为准。

几个容易踩的坑

• 把「今日额度」「并发上限」「账户余额」当成同一个东西。
• 日/周/月窗口用的时区没说清楚，用户看到的数字和自己的记录对不上。
• 没有 Key 级限流，一个跑飞的脚本把共享额度吃完。
• 结算重试没有幂等约束，同一笔用量被记了两次。

小结

先跑通最小请求，再逐项加功能——这是接入任何网关都适用的节奏。

如果你也碰到上面这些问题，可以看看 https://aiminis.info/ —— 一个把协议适配、渠道调度、用量与额度都收敛在一起的 AI API 网关，OpenAI 与 Anthropic 两套协议都能直接接。