人民币充值、积分与客户价格

版本：2026-09-12 / 三类客户定价讨论基线。依据用户本轮业务说明与“固化到文档里去”的要求保存。客户背景与迁移目标来自用户；以下推荐方案作为后续设计讨论依据，具体金额、优惠政策及模型对接客户是否迁移仍待确定，不代表已实施或已对外承诺。

三类客户：业务背景与平台安排

以上是用户提供的业务事实，不是生产配置审计结果。“企业”不再笼统指 uumi 客户：FDE 购买定制产品与服务，模型对接客户购买模型供应能力。

当前推荐零售与 FDE 使用统一平台，模型对接业务暂保留 uumi。此项细化此前“所有客户统一迁移”的范围，不能再据旧描述要求模型对接客户强制迁入。

三类客户的推荐定价方式

零售：标准价格与充值套餐，保留老客户实际待遇

• 将模型和功能可用范围、模型消费价格、充值到账数量分别管理。完整功能与模型目录不等于所有新模型自动享受旧模型优惠。
• 设置零售标准方案与老零售客户方案；已使用的旧模型以实际价格待遇核对迁移，不仅保留界面上的“倍率 1”。
• 新增模型单独定价。旧价格保护覆盖哪些模型、有效多久、是否保留未来旧充值套餐，需要继续确认。
• 历史余额转换与未来充值优惠分开处理。建议保留已有余额购买力，不将其自动扩大为永久提供所有旧充值优惠。

单笔资金来源、固定单位且不混用其他权益时，可用下式核对实际价格：

到账比例 = 本笔到账可用积分 / 本笔人民币实付
一次调用的实际人民币成本 = 本次消耗积分 / 到账比例

纯演算示例：充值 100 元到账 500 积分，调用扣 1 积分，对这笔充值而言成本为 0.2 元；这些数字不是实际套餐。多次不同优惠充值、赠送和到期混用时，需按资金来源及扣减顺序核算，不能用当前充值比例倒算历史全部成本。

FDE：服务费用与使用额度分别报价

推荐将专属套餐拆成可解释的两部分，而不是把定制价值全部放入充值优惠：

用户侧可保持消费倍率 1、充值非 1:1；后台仍需区分服务金额、使用额度对应金额与赠送。服务费不自动计入可消耗模型余额。

只有购买量不同的客户优先使用不同套餐；模型组合、服务保障或协议价格确有差异时再配置专属价格方案，不要求每个企业复制完整价格表。企业专属账户首期仍不引入多人共享余额。

模型对接：供应规格报价，暂留 uumi

建议保留现有充值 1:1 的业务方式，逐步把对客报价明确为“模型＋供应规格／服务等级＋计费单位＋客户单价”，按需要使用协议价或用量阶梯。

同模型的不同价格应对应明确差异：功能、性能、并发、限流、稳定性或实际承诺。若只是内部供应成本不同、对客能力和承诺相同，则优先作为内部渠道调度处理；不要求暴露供应商密钥或内部配置。

报价还需明确失败计费、退款、调价通知和生效规则。大量内部倍率可继续作为实现方式，但对客应能解释最终单价。

模型对接客户暂留 uumi 不阻塞零售迁入统一平台，也不要求立即统一钱包。未来可先评估统一客户档案和账单查询，再决定账户与余额迁移。

统一平台与既有 uumi 的边界

新平台 Core 负责新平台客户的账户、价格方案、积分和结算；Console 展示本人有效价格，Admin 管理账户与方案绑定，Edge/Worker 使用 Core 的价格依据。

新平台私有供应网关不负责终端客户售价；既有 uumi 模型对接业务可以继续独立承载自己的客户和账务。两者的业务角色要区分，“新平台网关无终端客户”不能被解释为立即删除 uumi 的模型对接账户。是否复用同一部署或拆实例尚未决定，需另行设计身份、凭据与账务隔离。

新平台价格方案与验收建议

首期建议从零售标准、老零售客户、FDE 基础和少量企业协议方案开始。每个账户绑定一个基础方案，协议只覆盖特殊项目；多个用户同属一个方案时共享该方案价格，不宣称自动逐用户独立报价。

模型目录与价格表分开：协议未覆盖的模型使用该账户明确指定的基础方案；基础方案也缺价时，调用前明确提示未配置并拒绝扣费，不因目录隐藏与计费回退采用不同规则而产生意外价格。

建议用零售 A、FDE B、FDE C 对同模型同参数验证：

1. 服务端通过真实身份确定客户与账本，客户不能靠提交其他客户 ID 或切换 Key/调用组取得他人价格。
2. 页面报价、预扣与结算使用同一方案和版本；最终金额按实际用量计算，不要求与估算预扣数值相等。
3. 调价不改变已锁定的在途价格，重试不重复扣款，失败按约定退款或释放。
4. 协议未覆盖与基础方案缺价分别可解释；充值优惠和协议价不会未经约定重复叠加。
5. 老客户余额购买力与约定保留模型的实际价格可核对；新增模型有明确价格。

上述是待实现、待验收的要求，不表示当前 Core 或旧网关已经全部满足。

新统一平台已确认的边界

• 对客支付统一人民币，不提供多币种钱包；系统内以积分表示可用余额和调用消费。
• 企业首期使用专属账户及协议价，不引入多人共享余额、成员邀请或部门预算。
• 充值套餐与具体售价后续敲定；差异价格必须支持不同客户。
• Console 的客户页面参考 new-api 后修改；Admin 负责价格和客户运营配置。
• 复用既有计费执行基础，不为每个产品重复建设钱包。

建议分开的五类规则

充值套餐不自动等于包月订阅。充值优惠影响“买到多少积分”，客户协议价影响“每次用多少积分”，两者可以同时存在，但必须明确组合规则，不能默默叠加。

人民币统一是产品规则，不是把上游所有 USD 文本替换成 RMB。支付金额、报价、回调、订阅、计费单位和历史记录都需做真实单位映射。对外只显示人民币／积分，供应成本的原始单位仍按事实保存。

FDE 企业账户和价格表

首期以一个专属账户绑定一个生效价格方案。建议 Admin 提供客户类型、客户名称、账户绑定、适用价格表、有效期和内部备注；企业标签不提升后台权限，也不增加成员模型。

价格表可按模型／计费规格覆盖单价。文本需要区分输入、输出、缓存等单位；媒体需要区分张、秒、次及影响价格的模型、分辨率、时长等维度。不能用一个全局折扣覆盖所有不同成本结构的模型。

建议价格选择顺序：

1. 在有效期内的企业协议价，匹配该模型与计费规格时优先。
2. 未覆盖项目使用该客户明确指定的基础价格方案。
3. 基础方案缺少价格时按明示政策拒绝调用或提示未配置，不静默给出意外低价。

一个项目最终选出一套有效价格；企业价不再默认乘 VIP 折扣。充值赠送是否适用于企业价，另由套餐适用规则决定。以上顺序为讨论建议，不宣称上游已经实现。

充值与积分

建议沿用一个权威积分余额，并在账务记录中保留积分来源。如果赠送积分与购买积分拥有不同期限、使用范围或退款规则，则需要来源批次／资金子账户记录；不是仅在前端拆两个数。

建议订单保存：人民币实付（整数分）、购买积分、赠送积分、套餐及版本、适用客户、支付交易标识、入账状态和时间。没有赠送活动时赠送为零。用户看清本次得到多少积分，运营能够核对实付与赠送，不能把赠送积分计为现金收入。

需要进一步决定：基础换算比例；是否赠送；积分是否过期；赠送与购买积分的扣减顺序；企业是否享受公共充值活动；退款时赠送如何处理。未决定前不创建默认套餐、有效期或折扣。

消费与价格快照

概念关系：

到账积分 = 购买积分 + 明确适用的赠送积分
调用消费 = 按实际计量维度，对本次锁定的有效价格规则求值

简单单价模型可用“实际用量 × 单价”；阶梯、缓存、多维媒体规则需要完整规则计算，不能全部简化成一个乘法。内部继续采用经过校验的最小整数额度与明确舍入规则，不直接用显示小数扣账。

建议调用受理时锁定账户、价格方案／版本及匹配规则，预扣与最终结算使用同一套价格依据，再按实际用量补扣或释放。修改价格只影响约定生效时间后的新调用；在途任务是否有特殊处理需另明确。

每次消费应能追溯：账户、产品来源、Key／调用者、模型与规格、用量、有效价格、价格版本、预扣、实际扣减、释放／退款及关联请求／任务。客户无需看到供应成本，但必须能解释为什么扣这些积分。

用量页面需要补的重点

Console 在 new-api 现有日志和统计上补齐：

• 用量与积分分列：Token、张、秒或次，不能全叫 Token。
• 消费明细可解释本账户有效价格、计量构成、最终积分与结算状态。
• 筛选和汇总口径一致；目前上游部分统计不支持明细的全部筛选。
• 充值、购买积分、赠送、消费、人工调整与退款分别展示。
• 结果失败、费用结算中、部分输出和退款完成分别表达。
• 产品／Key／模型归属与请求 ID 可定位；缺失的跨产品字段标为待接入。
• 默认显示积分，不按当前充值比例把历史消费折算成错误的“实际人民币成本”。

两端页面调整

“我的价格”只显示本人有效价格，不展示其他客户报价。公开 Developer 展示公开参考价，登录后显示本人价格；二者来源一致但权限和选价上下文不同。

上游可复用与需扩展的部分

以下上游能力说明来自此前固定源码阅读，不是本次文档固化新增的运行验收：

• 分组倍率已有使用组倍率及用户组到使用组的特殊倍率。
• 选取倍率在匹配特殊倍率时替代普通倍率，不是把二者重复相乘。
• 充值报价存在充值组倍率与金额档位折扣；它不是已验证的购买／赠送来源账本。
• 套餐处理创建／更新强制 USD，采用人民币产品规则需要明确适配。

简单等级价可映射已有分组机制；复杂企业逐模型协议价、版本有效期、报价预览和赠送积分来源需补适配或扩展。不能无条件给每个企业复制渠道与模型组，把计价规则和供应路由绑死。

下一步讨论

先确认计价规则，再定具体金额：换算与精度 → 充值套餐种类 → 企业价格覆盖／回退 → 优惠叠加 → 价格生效和历史解释。UI 可先表达明确标记的示例，示例不作为真实报价。