如何设置用户使用额度

额度系统是 AI 产品从「免费试用」走向「可持续商业化」的关键枢纽。它既是成本控制手段，也是用户转化的核心杠杆。本文从数据库设计、免费与付费额度策略、刷新机制、超额处理四个维度，拆解额度系统的完整实现路径。

为什么额度系统是 AI 产品商业化的核心

AI 产品的每一次调用都有真实成本——GPU 算力、模型 API 费用、存储带宽。与传统的纯软件 SaaS 不同，AI 功能无法提供「无限使用」而不亏损。这就决定了额度系统不是锦上添花的运营工具，而是产品能否活下去的基础设施。

一个设计良好的额度系统，需要同时解决三个问题：

1. 成本可控：防止单个用户或组织消耗过量资源导致亏损
2. 用户可感知：让用量透明化，用户清楚知道自己消耗了什么、还剩多少
3. 转化可驱动：在免费额度耗尽的自然时刻，引导用户完成付费升级

这三个目标互相牵制。额度设得太紧，用户还没体验到价值就流失；设得太松，免费用户占比过高却无法转化；超额处理太粗暴，用户产生负面情绪；太温和，又起不到成本保护作用。

下面我们逐一拆解。

额度系统设计

核心数据模型

额度系统的数据模型需要回答四个基本问题：用户有多少额度、消耗了多少、什么时候刷新、超额后怎么办。一个经过实践验证的表结构如下：

-- 额度账户表：每个用户/组织一个账户
CREATE TABLE credit_accounts (
  id            UUID PRIMARY KEY,
  owner_id      UUID NOT NULL,              -- 用户或组织 ID
  owner_type    VARCHAR(20) NOT NULL,       -- 'user' | 'organization'
  plan_tier     VARCHAR(20) NOT NULL DEFAULT 'free',  -- 当前套餐等级
  balance       BIGINT NOT NULL DEFAULT 0,  -- 当前可用额度（分）
  monthly_quota BIGINT NOT NULL DEFAULT 0,  -- 每月总额度
  used_this_month BIGINT NOT NULL DEFAULT 0, -- 本月已用额度
  last_reset_at TIMESTAMPTZ,                -- 上次刷新时间
  next_reset_at TIMESTAMPTZ,                -- 下次刷新时间
  created_at    TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  updated_at    TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
 
-- 额度变动流水表：每次额度变化的不可变记录
CREATE TABLE credit_transactions (
  id            UUID PRIMARY KEY,
  account_id    UUID NOT NULL REFERENCES credit_accounts(id),
  type          VARCHAR(30) NOT NULL,       -- 'grant' | 'usage' | 'topup' | 'expire' | 'refund' | 'adjust'
  amount        BIGINT NOT NULL,            -- 正数增加，负数扣减
  balance_after BIGINT NOT NULL,            -- 变动后余额（用于审计对账）
  feature       VARCHAR(50),                -- 触发消耗的功能模块
  model_id      VARCHAR(50),                -- 消耗的模型标识（如 gpt-4o、claude-sonnet）
  token_count   INT,                        -- 本次消耗的 Token 数量
  metadata      JSONB,                      -- 扩展信息
  created_at    TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
 
-- 额度规则表：定义各套餐的额度配置
CREATE TABLE quota_rules (
  id            UUID PRIMARY KEY,
  plan_tier     VARCHAR(20) NOT NULL,       -- 'free' | 'pro' | 'team' | 'enterprise'
  feature       VARCHAR(50) NOT NULL,       -- 功能模块
  model_id      VARCHAR(50),                -- 模型标识，NULL 表示通用规则
  cost_per_call INT NOT NULL,               -- 每次调用消耗额度（分）
  daily_limit   INT,                        -- 每日上限（NULL 表示不限）
  monthly_limit INT,                        -- 每月上限（NULL 表示不限）
  effective_from DATE NOT NULL,
  effective_to  DATE                        -- NULL 表示永久有效
);

关键字段说明

几个容易踩坑的设计细节需要特别注意：

余额用整数存储。 额度以「分」为单位（或采用最小不可分割单位），避免浮点精度问题。1 个 Credit = 100 分，对外展示时再做换算。

流水表不可修改。 credit_transactions 是审计和对账的唯一依据，一旦写入不允许 UPDATE 或 DELETE。所有修正通过新增一条 type = 'adjust' 或 type = 'refund' 的记录完成。

balance_after 字段必须保留。 这是排查「用户说余额不对」时的关键证据。如果每次变动都记录变动后余额，可以完整还原任何时间点的账户状态。

套餐规则与账户分离。 quota_rules 定义规则，credit_accounts 记录实例。这样修改套餐配置不会影响已有用户的当前周期额度，只在下次刷新时生效。

额度扣减流程

这里有一个关键设计：先预扣，后确认。在调用 AI 模型之前先把额度冻结（或扣减），调用失败再退回。这防止了模型调用失败但额度已经丢失的问题。如果采用「事后扣减」模式，在模型超时或网络异常时容易出现额度不一致。

免费额度策略

免费额度是 AI 产品获客的第一道门槛。设多少、怎么刷新、新用户给多少，直接影响转化漏斗的顶部宽度。

额度数量的确定方法

免费额度的设定不是拍脑袋，而是基于一个核心公式：

免费额度 = 用户感受到产品价值所需的最小使用量

太少，用户在体会到产品价值之前就耗尽了；太多，用户没有动力付费。实践中可以参考以下数据：

新用户福利策略

新用户注册时的额度发放是一个精心设计的转化节点。常见策略有三种：

一次性赠送。 注册即送 100 Credit，用完即止，不刷新。优点是简单直接，缺点是用户可能一次性挥霍完然后流失。

首日加倍。 注册当天赠送 3 倍日常额度，第二天恢复正常。利用「损失厌恶」心理——体验过大量额度后再被削减，用户付费意愿更强。

任务解锁。 注册送基础额度，通过完成引导任务（填写资料、邀请好友、首次使用特定功能）逐步解锁更多额度。这种方式的转化率最高，因为用户在「赚额度」的过程中已经完成了产品教育。

免费额度的刷新周期

付费额度策略

套餐额度设计

付费额度的设计核心是「梯度感」——用户能清楚感知每一档多得到了什么。

这里有几个值得注意的设计原则：

单价递减。 套餐越高，单个 Credit 的实际成本越低。这既是经济激励，也是心理锚定——用户会觉得升级「更划算」。

额度不是唯一差异点。 如果付费套餐只是「更多额度」，用户会反复比价。应该同时在功能维度做差异化：更好的模型、更快的速度、更多的自定义选项。

年度折扣。 年付通常打 8 折。这锁定了用户 12 个月的留存，同时降低了退款压力。

额外额度购买

当月度额度用完后，允许用户按量购买额外额度（Top-up）是重要的收入补充。设计要点包括：

• 最低起购量：设置最低购买门槛（如 $5 起），避免大量小额交易带来的支付手续费损耗
• 有效期：额外购买的额度有效期应长于月度赠送额度（如 12 个月），让用户感觉「买了就不会浪费」
• 使用优先级：额外额度应在月度赠送额度用完后才消耗，避免用户觉得「刚买的额度还没用，免费额度就先过期了」

额度刷新机制

额度刷新是用户容易困惑的环节，也是工程实现中 bug 频发的区域。

刷新类型对比

刷新的工程实现

刷新时需要注意的几个工程细节：

不要在刷新瞬间清零所有账户。 如果用户量大（百万级），集中刷新会导致数据库压力骤增。应该分批执行，按用户 ID 哈希分桶，每批处理 1000-5000 个账户。

刷新前快照。 在重置额度前，记录用户上个周期的使用数据（总消耗、剩余额度、使用天数），用于后续的数据分析和运营决策。

套餐变更的处理。 用户升级套餐时，立即按新套餐额度补差价；降级时，在当前周期结束时生效。不要在月中降级时直接削减额度，这会造成极差的用户体验。

超额处理

当用户额度耗尽时，如何处理直接决定了用户的留存和付费意愿。

三种处理模式

超额提示的设计

超额提示不是简单的「额度不足」弹窗，而是一个精心设计的转化触点：

1. 提前预警：在余额低于 20% 时提醒，不要等到归零才通知
2. 量化损失：告诉用户「还剩 3 次生成机会」而不是「余额 15 Credit」，把抽象数字翻译成具体功能
3. 场景化推荐：在用户刚好用完额度的功能页面展示升级入口，而不是跳转到通用的定价页
4. 提供选择：给出「升级套餐」和「购买额外额度」两个选项，而不是只有一个

并发与一致性

额度扣减面临经典的并发问题：同一用户同时在多个设备或浏览器中使用产品，多个请求可能同时检查余额并扣减。

常见的解决方案：

• 乐观锁：通过 version 字段实现，每次更新时检查版本号是否一致，不一致则重试
• 悲观锁：使用 SELECT ... FOR UPDATE 锁定账户行，保证同一时间只有一个事务能修改余额
• Redis 原子操作：使用 Redis 的 DECRBY 命令实现原子扣减，再异步同步到数据库

对于大多数 AI 产品，Redis 方案在性能和一致性之间取得了最好的平衡。

实战案例

案例一：Midjourney 的订阅额度模型

Midjourney 采用纯订阅制，每个套餐包含固定数量的「Fast GPU 时间」。Basic 套餐每月 $10，约 3.3 小时快速生成时间；Standard 套餐 $30，15 小时；Pro 套餐 $60，30 小时。

其设计亮点在于「Relaxed Mode」——当快速额度用完后，用户仍然可以生成图片，只是排队优先级降低、速度变慢。这种软降级模式让用户在额度耗尽后仍能使用产品，只是体验有所下降，避免了硬停止带来的断裂感。

Midjourney 不设免费额度，只提供 25 张免费试生成图片（无需信用卡）。这个额度恰好够用户生成 5-6 张完整图片，足以感受产品能力，又不足以完成一个完整项目。

案例二：OpenAI API 的分层额度体系

OpenAI 的 API 额度体系是 Credit 模式的典型代表。新用户注册后获得 $5 免费额度（有效期 3 个月），之后需要预充值。不同模型有不同的 Token 单价，系统按实际消耗的 Input Token 和 Output Token 分别计费。

其设计的关键点在于「分层限速」：Free tier（免费额度用户）、Tier 1-5 不同等级有不同的 RPM（每分钟请求数）和 TPM（每分钟 Token 数）限制。随着累计消费金额的增加，用户自动升级限速等级。这既保护了系统不被滥用，又让高消费用户获得更好的服务体验。

OpenAI 的额度不会过期（预充值模式下），但免费额度有 3 个月有效期。这是一个平衡——免费额度有期限促使用户尽快体验并转化为付费用户，付费额度不过期则降低了用户的购买阻力。

额度系统检查清单

在上线额度系统之前，逐项检查以下要点：

数据层

• 额度余额使用整数（分）存储，不涉及浮点运算
• 每次额度变动都写入不可变流水记录，包含 balance_after
• 并发扣减有明确的锁策略（乐观锁/悲观锁/Redis 原子操作）
• 套餐规则表与账户表分离，修改规则不影响已有账户

业务逻辑

• 免费额度足够用户完成至少一个「有价值」的完整操作流程
• 额度不足时在用户当前页面展示升级入口，不跳转通用定价页
• 余额低于 20% 时触发预警通知
• 套餐升级立即生效，降级在当前周期结束后生效
• 额外购买额度有明确的有效期，且长于月度赠送额度

用户体验

• 用户可以在任何页面查看剩余额度和刷新时间
• 额度数字翻译为具体功能次数（如「还能生成 3 张图片」）
• 超额时有清晰的提示，说明原因和可选操作
• 刷新日前后不出现额度跳变或重复扣减

运营与监控

• 有后台管理界面，支持手动调整额度、查看流水、处理客诉
• 异常消耗有告警机制（单用户单日消耗超过阈值时通知）
• 免费用户到付费用户的转化率有追踪指标
• 定期（每月）审视免费额度是否仍然合理

小结

额度系统看似只是「数字的加减法」，实际上涉及产品设计、用户心理、工程架构和商业模型四个层面的交叉决策。一个好的额度系统，让用户感到公平透明，让产品覆盖住运营成本，让商业化路径清晰可见。

核心原则只有三条：让用户在免费额度内感受到价值，在额度耗尽时看到升级的理由，在付费后觉得物有所值。围绕这三条原则去设计具体的数字和流程，方向就不会偏。

参考资料

1. Stripe —「What is a credits-based subscription model and how does it works?」 https://stripe.com/resources/more/what-is-a-credits-based-subscription-model-and-how-does-it-work

2. OpenMeter —「Credit Systems Are Challenging」 https://openmeter.io/blog/credit-systems-are-challenging

3. FlexPrice —「Essential Billing Features for Credit-Based Pricing」 https://flexprice.io/blog/essential-billing-features-for-credit-based-pricing

4. Lago —「What are credit-based pricing models and how do they work?」 https://getlago.com/blog/credit-based-pricing

5. Tetrate —「Usage Quotas」 https://tetrate.io/learn/ai/usage-quotas

6. Schematic —「What Are The Advantages of Using a Credit Based Pricing Model for SaaS?」 https://schematichq.com/blog/is-a-credit-based-system-the-right-fit-for-your-saas-pricing

7. Dev.to —「How I Designed a Credit System That Actually Makes Users Upgrade」 https://dev.to/sholajegede/how-i-designed-a-credit-system-that-actually-makes-users-upgrade-59h5