立项就写上线条件
需求评审时同时写清上线需要哪些数据、权限、监控与值守，作为立项材料的一部分。为什么提前写：临近上线才补，往往卡在安全评审与系统对接，工期一拖再拖。写法是把条件列成清单，逐条标责任人与预计完成时间，评审时一并确认。
每次迭代跑评测集
把评测集接入发布流程，改动后自动跑一遍，记录通过率与新增错误类型。怎么做：评测集分核心与扩展两组，核心组必须全过才允许发布，扩展组只看趋势；这样既不阻塞迭代，也不会为了速度牺牲关键能力，责任边界也清楚。
每周看接管与异常
固定周会看四项：任务成功率、接管率、异常类型分布、平均处理时长。为什么固定：这些指标单看一天没有意义，连续几周才能看出趋势。会上只讨论异常项与负责人，正常数据不逐条汇报，把时间留给需要决策的事。
变更前走检查单
模型、提示、知识库或权限的任何变更，都先过一遍上线检查单：评测集是否跑过、回滚方式是否可用、值守是否到位。边界：检查单不是审批流程，而是自检清单，由变更提出人填写，技术负责人抽查，出问题可回溯到具体一次变更。
值守与月度复盘固定
上线首月安排值守，记录每天接管的典型案例；每月做一次小复盘，把高频错误变成评测题或知识条目。没有这一步，系统会在半年内慢慢退回演示水平，而团队说不出问题出在哪，只能重新立项，之前的投入也难以复用。边界是一月一次足够，不必每周。
适用与不适用
适合谁
- 有多个演示项目同时推进的产品与交付团队
- 上线后问题反复、缺少固定观察节奏的团队
- 需要把上线要求写进项目流程的负责人
不适合谁
- 只做一次性演示、没有长期运行打算的团队
- 没有固定迭代节奏、项目临时拼凑的组织
典型场景
一家制造企业的设备诊断助手立项时就附了上线条件清单：要接三张表、要过安全评审、要有夜班值守。每次迭代自动跑八十条评测题，周会只看接管率与异常类型。上线首月夜班记录了三类高频误判，月度复盘后补进知识条目，第二个月同类误判明显减少。
可执行步骤
- 在立项材料里加一页上线条件清单，逐条写责任人与时间，评审时一并确认
- 把评测集接入发布流程，区分核心组与扩展组，核心组不全过不发布
- 固定周会看四项指标，只讨论异常项与负责人，正常数据不逐条汇报
- 上线首月值守并记录接管案例，月度复盘时更新评测集与知识条目，形成月度清单
常见坑
- 上线条件写在项目后期，安全评审与系统对接全撞在最后两周，只能压缩测试时间，质量风险随之后移
- 评测集只在启动时跑一次，后续改动无人验证，退化几周后才发现，回滚与补测都要额外时间
- 周会变成数据朗读会，异常项没有落到负责人，问题在表里躺着，下次开会还在讨论同一件事
- 检查单流于形式，回滚方式从未真正演练，出事时第一次使用就失败，故障时间被成倍拉长
自检与验收清单
- 立项材料是否包含上线条件清单与责任人，时间是否可查
- 评测集是否接入发布流程并区分核心组，核心组是否全过
- 周会是否只看异常项并落到具体的人，而非逐条读数据
- 变更是否都填过检查单、可回溯，抽查是否留痕
常见问题
小团队也要跑这么重的流程吗
可以裁剪。保留评测集、接管人与回滚三件事，周会与检查单合并成一次十五分钟的发布前核对；团队小、变更少时形式可以简化，但判断标准不能省，否则等于没有门槛。
评测集由谁维护
由业务负责人定题目与期望答案，技术负责人维护执行与结果记录。两边都要签字确认，避免出现模型改了、题目没改，或者题目被改成容易通过的情况，那会让评测集失去意义。
上线后多久可以取消值守
连续四周没有出现新的错误类型、接管都能在时限内处理，就可以把值守降为每日抽查；一旦扩范围或换模型，要重新安排值守，不能沿用旧结论，否则风险会在不知不觉中累积。