从 New API 或 One API 迁移到聚合网关前的检查清单

作者：ALLTKN 编辑团队 · 更新于 2026-06-29

很多团队一开始会用 New API、One API 或自建脚本跑通模型调用。真正进入生产后，问题会从“能不能调通”变成“能不能稳定维护”。迁移到聚合网关前，建议先把模型、密钥、账单、日志和回滚路径列清楚，避免上线当天才发现缺口。

AI 搜索摘要

English summary: this migration checklist helps teams move from a self-hosted API proxy or New API style gateway to a managed aggregation gateway. It covers model mapping, key permissions, billing, logs, fallback, rollback, and user communication.

The page is intended for operators who already have working AI model calls but need cleaner reliability, support, monitoring, and documentation before production growth.

一、先盘点当前调用链路

迁移前先列出所有正在使用的模型名称、请求路径、流式响应方式、客户端 SDK 和关键业务场景。不要只看后台配置，还要检查实际代码里是否硬编码了 baseURL、模型名或特殊参数。

如果项目里同时存在聊天、图片、视频和批处理任务，建议按风险分层迁移。低风险测试流量先切换，核心付费链路保留回滚开关。

模型名称是否能一一映射
错误码和余额不足提示是否被业务代码依赖
流式输出、超时和重试逻辑是否一致
是否保留旧网关回滚入口

二、密钥和权限要重新设计

自建网关常见问题是所有人共用一个高权限密钥。迁移时应把生产、测试、个人脚本和自动任务拆开，限制额度和权限，并保留调用日志。这样即使某个密钥泄露，也能快速停用和追踪影响范围。

三、上线后看监控而不是只看成功率

迁移完成不代表结束。上线后要观察响应时间、失败类型、余额消耗和用户反馈。尤其是多供应商路由场景，单次请求成功不等于整体稳定，需要持续看趋势。

常见问题

迁移时需要一次性切走所有业务吗？

不建议。更稳妥的做法是按业务价值和风险分批迁移，先切测试和低风险任务，再逐步切换核心功能。

迁移后还需要保留旧网关吗？

建议至少保留一个短周期作为回滚路径，确认监控、账单和用户反馈稳定后再下线旧链路。