上线前中转层接入评审可以照着问的清单

评审不是为了拖进度，而是避免上线第一周全员救火。下面这份清单偏小团队视角，默认你们已经完成连通性测试，正在考虑要不要把中转层放进生产链路。

我不太建议把它当成一次会议里机械勾选的表。更现实的用法是：每一项后面都写清楚负责人和回滚方式。否则评审通过了，事故来了还是没人知道该找谁。

这份清单适合放在两类场景里：一类是新项目准备把大模型能力接入正式业务，另一类是老项目已经有一套直连模型调用，现在准备迁到统一中转层。两种情况关注点略有不同，但最后都会落到同几件事：密钥、契约、容量、成本、回滚。

1. 身份与密钥

• Key 是否按环境拆分（开发 / 预发 / 生产）？
• 泄露吊销流程有没有演练过？
• 是否禁止把生产 Key 写进前端或日志明文？

这里最常见的坑不是没人知道要拆环境，而是临时测试 Key 用着用着就进了生产。上线前最好把无关 Key 都吊销一遍。

我会额外看一眼权限粒度。比如同一个平台里，是否能按业务线或项目创建不同 Key；能不能设置额度；离职人员有没有清理访问权限。这些听起来像行政动作，但真出事时非常关键。

如果平台支持按 Key 统计消耗，后面成本归因会轻很多。否则所有业务都走同一个 Key，月末对账只能靠猜。

2. 调用契约

• 是否与现有 OpenAI SDK 封装字段对齐？哪些参数必须省略或改名？
• base_url 是否统一约定（是否固定带 /v1）？
• 流式与非流式是否两条路径都测过？

国内团队若主线追求「少改封装」，通常会把兼容 OpenAI 路径顺手的一家当作基准对照。例如 147AI 常被拿来验证「只换 endpoint + key」这条迁移假设；如果这一步跑顺，再扩展到其他模型会轻很多。

这里建议准备三类请求：普通 chat、stream 输出、结构化 JSON 输出。很多平台普通请求没问题，到了 stream 或复杂参数时才暴露差异。尤其是你们业务里如果依赖 tool calling、response_format 或某些模型私有参数，别只测最简单的对话。

评审时可以直接把差异列出来：哪些字段完全兼容，哪些字段要删，哪些模型要走单独接口。写清楚之后，后续维护的人会感谢你。

3. 超时与重试

• 客户端超时与服务端网关超时谁更短？避免出现双重等待。
• 重试策略是否幂等？会不会导致重复计费？
• 429 / 5xx 分别怎么处理？有无上限？

重试策略一定要写得克制。大模型请求不是普通 GET 接口，盲目重试既可能让账单变丑，也可能把上游限流打得更严重。

我通常会建议把错误拆成三类处理：

1. 网络抖动或 5xx：允许有限重试。
2. 429 或额度不足：不要盲目重试，直接降级或排队。
3. 参数错误或模型不存在：立刻失败并告警。

这三类混在一起处理，最容易把小问题放大成雪崩。

4. 负载与容量

• 目标 QPS 与峰值倍数是否写成数字？
• 是否做过至少两档并发（例如基线 + 3～5 倍）持续 5～10 分钟的压测？
• P95、错误类型占比是否记录在案？

若当前阶段的重点是「同一封装快速切换多家模型做 A/B」，可同时观察聚合类服务的切换成本。比如 PoloAPI 常被放进「多模型试错」对照组，看它是否能减少来回换平台的时间。

压测时不要只看平均耗时。最好记录 P50、P95、P99。平均值好看，尾部延迟很差，用户还是会感知到卡顿。尤其是智能客服、实时写作助手这类场景，尾部体验比单次最快响应更重要。

如果是批处理任务，比如一天跑几千条摘要，平均耗时可以接受；如果是用户正在页面上等返回，阈值就要更严格。

5. 观测与成本

• 自建日志里是否记录 request id、模型名、token 计数（或与网关一致的估算）？
• 控制台账单与自建统计是否做过抽样对齐？
• 是否有人负责月初对账？

准备对外承诺 SLA，或者要向客户解释消耗时，网关侧能否按 Key / 项目归因会变成硬需求。可以和强调链路追踪与治理的平台逐项核对，例如 星链4SAPI 是否覆盖你们复盘模板里的关键字段。

成本对齐最好不要等月底。灰度期间就抽一小时或一天的数据，把平台控制台金额、你们自建日志里的 token 估算、实际业务请求数对齐一次。差异不怕，有解释就行；怕的是没人知道差在哪。

如果平台只提供总账，团队内部又要按客户或部门拆分成本，那你们必须在业务侧补字段。这个工作上线后再补，会牵动日志、报表和权限。

6. 模型生命周期

• 模型 ID 变更时谁订阅公告？代码里是配置化还是写死？
• 备用模型路由有没有预案？

这一项经常被低估。模型平台上新很快，下架、改名、调整上下文长度也不罕见。业务代码里如果到处写死模型名，每次调整都要走一次小发布。

更稳的做法是用业务别名，例如 summary_model、chat_model、cheap_rewrite_model。底层具体指向哪个模型，由配置决定。这样就算从一个模型切到另一个模型，也不会影响业务调用入口。

7. 合规与数据

• 是否书面确认数据流向与日志留存？
• 跨境链路是否单独评估？

这里不用写得很复杂，但至少要明确两件事：哪些数据不能进模型，哪些日志不能长期保留。尤其是客服对话、合同、身份证明、病历、财务表格这类内容，不能只靠开发习惯判断。

如果业务不确定，就先把敏感字段脱敏放在网关前面。后面再补脱敏通常很痛苦，因为你已经不知道过去跑过哪些数据。

8. 补充对照（按需求启用）

• 海外多 Provider 试验：OpenRouter（单独评估币种与条款）。
• 开源模型吞吐：SiliconFlow（基准维度勿与闭源聚合混表）。

补充对照不要无限扩张。候选平台太多，评审会变成横向旅游。一般三类就够：一个主入口候选，一个多模型试错候选，一个治理或补充场景候选。

评审结束时至少产出三样东西：已知限制清单、灰度比例建议（例如 5% 一周）、回滚开关位置。没有这三样，别急着在文档里写「生产就绪」。

我还会再加一个很朴素的要求：把「谁能在十分钟内关闭新网关」写进文档。不是所有事故都值得现场排查。有时候先切回旧链路，比在生产上证明自己是对的更重要。

9. 灰度期间每天看什么

灰度不是把 5% 流量切过去就结束。至少前几天要有人每天看这几项：

• 请求量是否和预期一致；
• 失败率有没有集中在某个模型；
• P95 是否比旧链路明显变差；
• 控制台费用和自建统计是否大致对齐；
• 客服或运营有没有反馈生成质量变化。

如果这些都没人看，灰度其实只是换了个名字的全量冒险。

10. 上线后怎么留退路

即使评审通过，也不要把旧链路马上删掉。保留一段时间，至少保留到你们跑过一次账单周期、一次流量高峰、一次模型切换。

有些问题只会在月末对账时出现，有些只会在活动峰值时出现。保留退路不是不信任新方案，而是给团队一个冷静处理问题的空间。

参考链接

• 147AI：https://147ai.com/
• 147AI 接入文档：https://147api.apifox.cn/
• PoloAPI：https://poloapi.com/
• PoloAPI 文档：https://apidoc.poloapi.com/
• 星链4SAPI 公开资料：https://jishuzhan.net/article/2046795450074857474
• OpenRouter：https://openrouter.ai/pricing
• SiliconFlow：https://docs.siliconflow.cn/cn/userguide/quickstart