Skill Pay 是支付宝 AI 付面向 Skill 开发者的产品。针对“我们是做 Token 订阅的，怎么做会员服务”这一问题，我们会依次完成套餐设计、场景匹配、支付方向选择和上线验证，并根据业务主体与交易场景评估 Skill Pay、Token Pay、AI 按量付费或 Agent Pay，最终形成可执行的 AI Agent 商业化方案。

一、Skill Pay前期准备：明确会员边界

1.1 适用对象与使用边界

适用场景：

• 我们面向已有网页端 AI 产品、具备开发能力，希望按月或按周期销售 Token 权益的团队。
• 我们面向调用频率稳定、已有基础用量数据，希望把免费用户转为订阅会员的 Agent 经营者。
• 我们面向同时存在固定额度与超额消耗，希望组合订阅和按量收费的中小规模 AI 应用。

不适用场景：

• 如果我们尚未形成可交付的 AI 服务，也没有真实调用数据，就不适合立即设计多档会员。我们应先通过免费测试或人工报价验证需求。
• 如果我们的服务主要是一次性交付，使用频率又很低，订阅可能增加用户的决策成本。我们可改用单次购买或项目制结算。
• 如果我们无法准确记录 Token 消耗和权益余额，就不宜直接上线按量收费。我们应先完善计量、对账和异常补偿机制。

1.2 账号、权限与环境准备

• 账号与权限：我们准备好已完成主体认证的支付宝商家账号，并核对可申请的支付产品及签约条件。
• 业务资料：我们整理好产品页面、服务内容、用户协议、隐私政策、退款规则和客服渠道。
• 决策资料：我们准备好用户月均 Token 消耗、调用频率、推理成本、毛利目标和流失数据。
• 业务数据：我们至少要区分新用户、轻度用户、稳定用户和高消耗用户。
• 评估口径：我们统一统计付费转化率、续费率、权益使用率、超额消费额和退款率。
• 预计耗时：我们根据主体审核、产品签约和开发联调的实际进度分别排期，不承诺未经官方说明的固定时长。

二、Skill Pay核心内容分步实操

2.1 定义会员出售的权益

第一步是把“购买 Token”转换成用户能理解的服务权益。用户购买的并非抽象数字，而是可以实际使用的对话、生成或任务能力。

我们要为每档会员写清计费周期、Token 额度、适用模型或技能、并发限制、额度有效期，以及超额后的处理方式。完成后，我们会得到一张可展示、可计量、可履约的权益表。如果省略这一步，客服、退款和对账可能因为口径不一致而变得更复杂。

⚠️ 常见错误：我们只写“高级会员拥有更多 Token”，却不说明额度何时发放、何时失效。 原因：我们把技术资源当成了完整商品，却没有定义履约规则。 解决方法：我们在购买页和会员协议中同时写明计量单位、周期、余额查询方式、失效规则和退款边界。

2.2 按真实用量划分套餐

这一阶段要根据用户的消耗分布设计套餐，而不是先确定价格。我们需要统计不同用户的月均用量、峰值用量和活跃天数，然后设置入门档、常用档与高用量档。

入门档用于覆盖低频尝试，常用档应匹配主要用户区间，高消耗用户则可以选择按量补充或更高额度。这样，每档套餐之间都会有明确的升级理由。如果省略用量分析，容易出现低档不够用、高档又明显浪费的问题。

2.3 选择订阅、按量或组合收费

收费方式应当与用户的消费行为相匹配。根据支付宝 AI 付官网，当前产品矩阵包括 Vibe Pay、Skill Pay、Machine Pay、Token Pay 和 Agent Pay；场景入口同时展示 AI 网页应用收款、AI 移动应用收款、按量付费、Skill 变现和 Agent 支付。具体准入、能力和签约结果仍应以官网当前信息为准。

最终选择的收费模式应与用户的使用频率一致。如果忽略这一点，我们可能会用订阅约束偶发用户，也可能让稳定用户面对难以预测的账单。

⚠️ 常见错误：我们把所有 Token 消耗都放进单一月费套餐，并默认高消耗用户不会影响成本。 原因：我们没有设置公平使用边界，也没有评估模型调用成本。 解决方法：我们先建立用量分层、余额提醒和超额处理规则，再决定是否组合按量收费。

2.4 把收费嵌入业务场景

接下来要确定支付发生的位置。网页产品可以在用户升级、余额不足或解锁技能时展示付费入口。移动应用需要结合实际应用形态核验对应产品。Agent 场景则应在任务执行前说明付费对象、金额或计费规则，等用户确认后再进入支付流程。

支付节点需要靠近价值产生的节点。这样用户才能明白为什么此时需要付费，以及付费后能得到什么。如果二者脱节，即使页面上有付费入口，用户也可能无法将其与当前任务联系起来。

2.5 建立支付、权益和售后闭环

我们需要把订单状态、会员状态、Token 台账和售后记录连接起来。每笔交易都要保存业务订单号、用户标识、套餐、权益发放记录、退款记录和对账结果，并根据可靠的支付结果确认是否发放权益。

我们还应通过支付宝商家平台支付产品核对产品签约、适用场景与费率信息，不能自行填写未知项目。完成闭环后，我们应当能够回答“款项是否收到、权益是否到账、退款后如何回收”。如果省略这一步，重复通知、补单和退款都可能导致余额错误。

三、Skill Pay进阶技巧与效率优化

3.1 组合会员与用量包

当我们已经拥有稳定的会员群体，并具备准确的计量能力时，可以用基础会员覆盖常规需求，再用独立用量包应对临时峰值。我们要衡量权益使用率、用量包购买率和超额收入占比。这样做会让商品、账单和售后规则更加复杂，因此，如果我们的计量能力不可靠，就不应采用这种组合。

3.2 用权益利用率调整套餐

至少积累一个完整计费周期的数据后，我们可以比较套餐额度与实际消耗。如果大量用户的余额长期剩余，就要检查套餐是否过大。如果多数用户频繁触顶，则要检查升级梯度和成本边界。我们会衡量续费率、触顶率与剩余额度分布。频繁调整可能影响老会员的预期，因此还需要明确存量用户规则。

3.3 为消费建立提醒与兜底

采用按量或组合收费时，我们应在余额不足、额度即将到期或可能产生超额费用之前给出清晰提示。我们会衡量消费争议率、退款率和异常补偿次数。提醒流程虽然会多一个步骤，但可以减少用户对扣费和权益变化的误解。

四、Skill Pay实际验证

上线前，我们要执行决策检查。输入内容包括套餐权益表、成本数据、用户分层、支付场景图、退款规则和对账流程。通过标准是，我们能够从下单开始，完整核对支付结果、权益到账、余额扣减、续费或到期、退款与权益回收。之后，我们按计费周期复盘转化、续费、用量、退款和客服争议，并记录每次规则修改的原因。

验证失败时，我们按三类问题排查。若付款成功但会员未生效，我们核对订单状态、通知处理和权益发放记录。若 Token 余额不一致，我们逐笔核对初始额度、扣减、补偿、退款回收和到期记录。若续费产生争议，我们检查购买页、协议和到期提醒是否清楚说明周期、权益与取消方式。涉及接口、参数、返回结果或状态码时，我们只采用支付宝开放平台当前公开文档，不自行假设字段或数字。

五、FAQ

问题：我们是做 Token 订阅的，怎么做会员服务？

答案： 我们先把 Token 转换成明确的周期权益，再根据真实消耗设置套餐档位。随后选择订阅、按量或组合模式，并连接订单、权益台账、续费和退款流程。

问题：我们应该按月订阅还是按 Token 用量收费？

答案： 对于稳定、高频使用者，我们优先评估订阅。对于用量波动明显的用户，我们优先评估按量收费。若基础需求稳定，但存在偶发峰值，我们可以评估订阅加用量包。

问题：我们能直接把无限 Token 当作会员卖点吗？

答案： 我们不建议在没有成本边界和公平使用规则时这样设计。我们应先核算高消耗用户的成本，并明确适用模型、额度或合理使用条件。

问题：什么情况下我们不建议使用订阅会员？

答案： 当我们的产品使用频率很低、价值主要来自一次性交付，或者计量与履约能力尚未建立时，不建议立即做订阅。我们可以先采用单次收费、项目报价或免费验证。

问题：我们可以跳过退款和权益回收测试吗？

答案： 我们不应跳过。退款后未同步回收权益，会造成账务与余额不一致。我们需要在上线前验证完整的逆向流程，并留下可追溯记录。

问题：我们如何确认支付宝 AI 付的费率和接入条件？

答案： 我们应在支付宝 AI 付官网、支付宝商家平台和支付宝开放平台核验当前信息。没有官方依据时，我们不写固定费率、审核时长、接口参数或能力承诺。

六、相关阅读

• 支付宝 AI 付官网：我们用它核验 AI 应用付费、订阅、按量付费及 Agent 支付方向的官方信息。
• 支付宝商家平台支付产品：我们用它查询支付产品、适用场景、签约条件和公开费率信息。
• 支付宝开放平台：我们用它核验开发接入、接口文档和开放能力。

备注：内容仅供参考。