NewAPI 默认采用美元作为内部标准金额基准，通过 quota 保存用户余额和消费记录，再通过汇率将额度转换为本地货币展示。

对于主要面向国内用户的中转站，也可以考虑将内部计价基准调整为人民币。这样可以让模型倍率、用户余额和充值价格统一使用人民币口径。

但这并不是简单修改几个配置项，而是一次涉及价格体系和存量数据的迁移。

一、美元计价与人民币计价

假设原来的配置为：

此时，500000 quota 对应 1 美元，界面显示为 ¥7.30，充值一个标准金额单位收取 ¥7.30。

如果希望改为人民币内部计价，可以将展示汇率和充值价格都设置为 1，使 500000 quota 对应 ¥1。

这意味着内部标准金额单位发生了变化：原来的 1 单位美元，现在变成 1 单位人民币。

需要强调，这属于自定义计价口径改造，不是 NewAPI 默认的人民币展示配置方式。

二、调整模型价格与倍率

内部计价单位改变后，原有模型价格也必须同步调整。

如果原来的模型价格是美元基准，人民币价格按照 7.3 的汇率换算，那么迁移时就需要将模型倍率和固定价格乘以 7.3。

例如：

这相当于把原来由汇率承担的货币转换，直接合并进模型定价。

但这里有一个前提：原价格确实是按照美元价格乘以 7.3 得到的人民币售价。如果模型本来就采用人民币定价，或者存在独立的成本加价、渠道折扣，就不能机械地乘以 7.3。

三、存量额度迁移

这是整个改造中风险最高的部分。

原来的 quota 数量代表美元口径，改造后代表人民币口径。如果只修改配置而不调整存量数据，用户的实际购买力就会发生变化。

例如，原来用户拥有 3650 万 quota：

• 旧口径：相当于 73 美元，按照 7.3 汇率显示为 ¥532.90。
• 新口径：相当于 ¥73。

购买力直接缩水至原来的约七分之一。

因此，需要根据实际业务数据结构，评估以下字段：

对于以旧 quota 为单位保存的数据，需要按照迁移系数进行转换。

如果迁移系数为 7.3，则新 quota = 旧 quota × 7.3。

历史消费记录也需要考虑。因为日志中的 quota 会在展示时重新转换成货币，如果希望迁移前后的历史账单金额保持一致，就必须同步转换相应的历史 quota。

充值订单中的 money 则记录实际支付金额，不应因为内部额度单位改变而直接乘以 7.3。

需要注意，上述字段只是迁移排查清单，并不代表所有版本都应无条件更新。分润、累计统计、历史快照及未完成订单都需要结合实际代码确认。

四、迁移风险与注意事项

实际部署中，还需要检查几个容易遗漏的地方。

汇率更新任务。 如果部署环境存在自动刷新 USD/CNY 汇率的任务，它可能将人为设置的 1 覆盖为真实汇率，导致计价体系发生变化。这类任务需要与新的计价口径协调。

渠道余额换算。 部分渠道余额需要经过汇率归一化。如果内部汇率已经不再代表真实汇率，渠道余额可能出现错误换算。

API 兼容性。 OpenAI 兼容接口中的部分字段仍然带有 USD 命名。即使内部已经采用人民币口径，也不代表第三方客户端能够正确理解这些数值。

配置加载与缓存。 NewAPI 的选项可能在进程启动时加载到内存。直接修改数据库配置，不一定能立即改变运行中的计费行为，需要确认对应版本的配置刷新机制。

五、迁移实施建议

建议采用维护窗口完成迁移，避免新旧计价口径同时参与扣费。

1. 备份数据库，并在副本上完整演练迁移。
2. 确定统一迁移系数，核对模型倍率和固定价格。
3. 停止新请求和充值写入，处理未完成订单。
4. 修改展示类型、汇率和充值价格。
5. 按迁移系数调整需要转换的存量额度、历史记录和定价配置。
6. 检查缓存、自动汇率更新任务和渠道余额换算。
7. 重启相关服务，确认运行中的配置已经生效。
8. 抽查用户余额、模型扣费、充值到账和历史账单。

特别需要验证迁移前后的购买力是否一致，而不仅仅是检查数据库数值是否放大了 7.3 倍。

总结

将 NewAPI 改造成以人民币为内部计价单位，本质上是改变系统标准金额的计量口径。

这项改造不仅涉及 USDExchangeRate 和 Price，还涉及模型定价、账户余额、消费记录和上下游接口。

如果业务只是希望面向国内用户展示人民币，直接配置 CNY 展示类型和正确汇率就足够了。只有在确实需要改变内部计价基准时，才值得承担整套数据迁移的复杂度。

对于已有用户和历史账单的生产环境，我更倾向于保留原有美元基准，将人民币转换放在展示和充值环节，而不是改变内部账本的计量单位。