模板要版本化
提示词与检索配置分散在各应用里时，改动无法追溯，成本波动也说不清原因。做法是集中存放模板、编版本号、记录变更人与生效时间；边界是模板变更要跑评测，不能为了省 token 直接删约束。
计量要落到请求
至少记录场景、模型、输入输出 token、是否缓存命中与是否重试。怎么落地：在网关或统一 SDK 采集，避免各应用自行上报；边界是日志脱敏，提示词正文可不落库，只留长度、哈希与场景标签。
路由与降级策略
按任务难度分流到不同模型，并为高峰准备降级顺序。为什么必要：单一模型承接全部请求，成本高且脆弱；有路由才能在不影响主链路的前提下压缩支出。边界是降级要经过评测，且保留回滚开关。
对账与责任人
每月把本地计量与账单对齐，差异有人解释、有人关闭。做法是把对账结果放进经营会，与预算执行一起看；边界是合同中的计价与调价条款须由法务审阅，技术团队不代替法务出具意见。
适用与不适用
适合谁
- 多团队共用同一套模型接口的企业
- 提示词分散、改动频繁的产品团队
- 需要按月向财务解释支出的平台方
不适合谁
- 单一应用、调用量很小、无预算约束的项目
- 没有权限改动调用链路的业务部门
典型场景
一家出行平台的算法团队把提示词集中到模板库，给每次调用打上场景与版本标签，再按任务难度分流模型。上线一个月后，账单异常能直接定位到具体模板版本，对账差异也第一次在一周内关闭，责任落到人。
可执行步骤
- 把提示词与检索配置集中到模板库，编版本号并记录变更人与生效时间
- 在网关或统一接口层采集请求级 token、缓存与重试标记，按场景落库
- 按任务难度设计路由规则，明确降级顺序与回滚开关，并指定负责人
- 指定对账责任人，每月比对本地计量与供应商账单，差异限期关闭
- 把计价、调价与超量条款提交法务审阅后再签约，留书面意见
常见坑
- 提示词散落在各仓库，改了一处没同步，成本波动查不到源头，排查很慢，反复踩坑。
- 埋点只记总数不记场景，账单拆不开，优化只能凭感觉，汇报时也说不清依据。
- 路由规则写死在代码里，调整要发版，紧急降级根本来不及，只能硬扛，事后补记录。
- 对账发现差异却没人负责，拖到季度末只能按账单付款，争议无从解决，责任也落不下来。
自检与验收清单
- 模板是否集中管理、有版本号与变更人
- 埋点是否覆盖 token、缓存与重试标记
- 路由与降级是否有可用的回滚开关
- 对账差异是否有责任人跟进并关闭到底
- 计价、调价与超量条款是否经法务审阅
常见问题
模板集中管理会不会拖慢迭代
短期会增加一次迁移成本，长期反而更快：改动可追溯、评测可复用、回滚有依据。折中做法是先集中管理高频模板，低频的逐步迁入，避免一次性大改导致业务停摆。
路由策略谁来定
业务与技术共同定：业务给出可接受的质量底线，技术给出各模型的能力与成本数据。规则应有明确的责任人，并定期用评测集复核。只由技术单方决定，容易出现降级后业务不认账的情况。
合同条款要看什么
重点看计价单位、缓存与工具调用是否另计、最低消费、调价机制与超量单价。这些条款直接影响预算准确性，且往往写在附件里。建议由法务与财务共同审阅，技术团队提供口径解释。