两条路，先选一条
转工程化意味着按生产标准重做权限、审计、异常与运维；归档则保留证据供下次复用。最差的是既不转也不归档，原型环境挂着没人管，最后连配置都找不回来，交接时连运行环境都重建不了，复诊也难接上。
评测集变回归集
转生产后，评测集应纳入发布流程，每次模型或提示词变更都重跑。没有回归集，退化只能靠用户投诉发现，而那时问题已经扩散到业务侧，处理成本更高，回归也就失去了意义，团队会逐渐不再相信评测。
配置要版本化
模型版本、提示词、检索参数、样本切分方式都应记录并版本化。出问题时能回到上一个可用组合，而不是凭记忆重配，也不至于把责任推给模型供应商，也便于判断问题究竟出在模型、提示词还是检索配置上。
监控看接管与失败
上线后重点看人工接管率、失败类型分布与响应时延。只看调用量会掩盖质量问题，尤其当用户默默改用人工时，数据看起来一切正常，实际效果已经打折，等到发现时，业务方已经不太愿意继续用了。
定期补样本
业务变化会产生新表达与新场景，评测集应每季度补一批新样本。否则回归测试会逐渐失真，团队对结果的信任也会下降，最后干脆不跑这套流程，再想恢复就不得不重新抽样与标注，成本翻倍，效果也打折。
适用与不适用
适合谁
- 原型验证通过、准备转工程化的项目
- 需要把验证资产沉淀下来的企业，有沉淀需求
- 多场景并行、希望复用评测能力的团队
不适合谁
- 一次性概念验证、不打算继续投入的场合
- 尚无运维责任人、也没有预算的团队
典型场景
某运营商的工单摘要原型验证通过后转入工程化。团队把评测集接入发布流程，每次模型升级自动重跑；上线三个月时一次升级导致摘要变长，回归测试当天发现并回滚，未影响一线使用，并把回归用例留在一线团队手里。
可执行步骤
- 在原型结束会上决定转工程化或归档，并指定负责人，并写入结项纪要，双方签认
- 把评测集接入发布流程，设置回归通过门槛，明确不达标就不允许发布，写进流程
- 配置与提示词纳入版本管理并保留快照，每次变更都留快照与回滚点，标注日期
- 上线后监控接管率、失败类型与响应时延，并设置告警阈值与明确的接收人
- 每季度补充新样本并复核基线指标，把新样本加入回归集并重新定基线
常见坑
- 原型环境长期挂着，无人维护也无人下线，成了灰色系统，安全评审时说不清，出了问题也没人负责。
- 模型升级不重跑评测，质量悄悄下降，等投诉才发现，此时已扩散到业务，追责时才发现没有记录，影响面更大。
- 配置只存在个人电脑，换人后无法复现，排查只能靠猜，事故复盘也很被动，团队之间也容易互相猜疑。
- 评测集多年不更新，与真实表达脱节，回归结果失去参考，团队逐渐不再使用，回归流程名存实亡，信任也下降。
自检与验收清单
- 是否明确转工程化或归档并有签认，且有签字，可核查
- 评测集是否接入发布流程与回归门槛，可核查，有门槛
- 配置与提示词是否版本化留存，可回滚到上一版
- 接管率与失败类型是否纳入监控，有告警接收人
- 样本补充是否有周期与责任人，并指定责任人，可追溯
常见问题
归档需要保留什么？
至少保留任务定义、评测集与标注规范、评测报告、失败样例与配置快照。下次遇到相似场景可直接复用，省去重新抽样与标注，也能对比两次方案的差异，也便于评估迁移成本。
模型升级一定要重跑评测吗？
要。即使供应商称兼容，输出风格与长度也可能变化。重跑成本远低于线上质量事故的处理成本，也能为是否升级提供一份可追溯的书面依据，也能作为验收材料留档，也可以留档。
原型转生产要重写吗？
多数情况需要重构，尤其是权限、审计、异常处理与并发部分。原型代码可作为业务逻辑参考，但不宜直接承载生产流量，也不应跳过安全评审，否则后期整改的成本会更高，返工更贵。