检查一至二：边界与授权
写清模型负责哪些环节、输出交给谁；确认语料授权与敏感数据处理方式。边界不清会导致下游系统接收无法校验的结果，出错时也很难判断该由哪一环负责。
检查三至四：检索与格式
检查文档切分是否按条款或章节、检索结果是否带来源；输出是否按约定格式返回，便于程序校验。格式不稳定会让集成工作反复，接口联调时间成倍增加。
检查五：评测基线
确认评测集覆盖主要任务与错误类型，并保存基线结果。评测要能区分关键字段与一般字段，否则总体分数会掩盖真实风险，验收结论也不可靠。
检查六至七：成本与监控
设置调用额度、并发上限与超时降级；监控失败率、延迟与异常输出。缺少限流时，一次批量任务就可能耗尽当月额度，业务在月中突然中断。实施清单常把注意力放在选型与上线，却忽略退出条件：数据不可用、效果不达标、预算超限时如何停止、如何回收数据、如何交接。缺少退出条件会导致项
检查八：版本与回滚
记录模型、提示词、检索配置的版本，确保可回退。生成式系统的质量问题常由配置变更引起，没有版本记录就无法定位，只能整体重做一遍。目在低效状态长期消耗。建议在启动前把停止条件写进项目确认单，并指定复核人；每阶段结束按条件评估一次，达到即暂停或转向，避免沉没成本继续扩大。
适用与不适用
适合谁
- 准备把模型接入生产系统的团队
- 负责集成与运维的工程人员
- 需要编写上线评审材料的技术负责人
不适合谁
- 仍在使用公开试用接口做探索的团队
- 没有下游系统集成的独立工具场景
典型场景
某企业的单据抽取服务在测试环境正常，上线首日因批量任务并发过高触发限流，接口超时。团队补上队列与降级策略，并把额度预警接入值班群，问题才稳定下来。
可执行步骤
- 按八项做成上线检查表并指定举证人
- 用评测集跑一次完整基线
- 压测并发并设置额度与降级
- 核对输出格式与下游校验逻辑
- 记录版本并演练一次回滚
常见坑
- 测试环境只用少量样本，未做并发压测，上线即触发限流。
- 输出格式随提示词变化，下游解析失败，错误批量堆积。
- 没有额度预警，月中耗尽配额，业务中断。
- 配置变更无记录，质量下降时无法定位原因。
- 回滚只回模型不回提示词，问题依旧存在。
自检与验收清单
- 八项是否都有证据
- 是否做过并发压测
- 输出格式是否有校验
- 额度与失败率是否告警
- 回滚是否覆盖全部配置
常见问题
内部工具也要做这些检查吗？
可以简化监控与压测，但输出格式、评测基线与版本记录建议保留，否则工具一旦被依赖就难以维护。
限流会不会影响业务？
合理限流加队列比无限制更稳。关键是按业务优先级分配额度，并在接近上限时提前预警。
评测基线和谁确认？
由业务负责人确认指标口径与门槛，技术团队提供结果。涉及对外内容时，合规或法务应参与确认。
这类工作最小可运行的验收标准是什么？
选一个真实业务小样本，约定输入、输出格式与抽检比例，连续跑两周；由业务负责人按预先写明的通过条件判定，并记录失败样本的归因。样本量不必大，但必须覆盖真实异常情况，且每次失败都能追溯到数据、提示或流程的具体环节。