表一：生产就绪清单
覆盖数据、权限、接管、监控、回滚与合规六类，每项写状态、责任人与完成时间。为什么用清单而不是方案文档：清单能被逐项核对，方案往往读完仍不知道做没做。边界是清单只列必要条件，不把功能需求混进来，否则又要重开一轮讨论。
表二：评测集与接管登记
评测集记录题目、期望答案、当前结果与失败原因；接管登记记录时间、原因、处理人与结论。为什么两张表要放在一起看：评测反映上线前的能力，接管反映上线后的真实表现，两者对照才能判断问题来自模型、数据还是场景选择。
表三：上线评审单
写清上线范围、灰度比例、观察指标、回滚条件与决策人。怎么做：评审单控制在一页，逐项打勾并签字，未通过项写明补齐时间。边界是评审单不替代合同验收，它只回答这一次能不能放量，不承担交付物是否合格的结论。
字段要少而硬
每张表控制在十个字段以内，必填项要能被第三方核对。为什么强调少：字段一多，填写人开始应付，数据质量下降，最后没人相信表上的内容。做法是先跑一次真实项目，删掉没人看的字段，再固定版本，后续只增不减要重新评审。
谁来填、谁来签
业务方填范围与接管，技术方填数据、监控与回滚，安全方填权限与合规，最后由项目负责人签字。边界：签字人必须是能对结果负责的人，不能由助理代签；否则出事时找不到决策依据，清单也失去约束力。
适用与不适用
适合谁
- 准备做上线评审、需要统一材料的项目组
- 多个项目并行、清单口径不一致的交付团队
- 需要向客户证明上线条件的服务方
不适合谁
- 希望用一份厚方案替代逐项核对的团队
- 没有明确责任人、只由文员代填的项目
典型场景
一家制造企业的两个数字化项目同时准备上线，材料格式各不相同。质量部把三张表统一：就绪清单十项、评测集与接管登记合为一张、评审单控制在一页。第一个项目填完后发现有四项无人认领，补齐后上线，第二个项目直接沿用，评审时间缩短到半天。
可执行步骤
- 把上线要求归成数据、权限、接管、监控、回滚、合规六类，逐类写必要条件
- 为每张表指定填写人与签字人，避免最后由文员统一补，并由项目负责人确认
- 评测集与接管登记合并成一张表，按时间顺序追加记录，签字人要对内容负责
- 评审单控制在一页，未通过项写明补齐时间与责任人，补齐后由质量部复核
- 上线后回看清单，删掉无人使用的字段再固定版本，下次评审再决定是否保留
常见坑
- 清单做成几十页的方案附件，评审时无人逐项核对，等于没写，责任也落不到人，问题在上线后才暴露。
- 只写要求不写责任人，出问题时找不到人认领，进度一拖再拖，上线时间一再推迟，业务方失去耐心
- 评测集与接管记录分开存放，判断问题时对不上时间与场景，复盘时说不清问题出在哪一环
- 签字由助理代签，决策依据缺失，事后追责没有凭据，双方各说各话，复盘时也找不到当时的判断依据。
自检与验收清单
- 三张表是否都指定了填写人与签字人，是否可查
- 字段是否控制在十项以内，字段是否有示例，是否有填写示例
- 未通过项是否写明补齐时间，补齐是否有人跟踪
- 评测集与接管记录是否可对照，能否对上时间
- 上线后是否回看过清单并删减字段，版本是否固定
常见问题
三张表能合成一张吗
可以先合成一张跑一个项目，但要保留三块区域，否则填写人容易只填就绪项、漏掉接管记录。跑顺之后再按需要拆开，拆与合的标准是看谁在用、多久看一次，而不是表格数量本身。
清单需要客户签字吗
涉及范围、验收标准与数据边界的部分需要，内部监控与回滚项由项目负责人签即可。客户签字的意义在于确认预期一致，不是把内部工程细节推给对方审阅，签字范围要提前说清。
项目很急，能不能先上线再补
可以让步但不能全免。数据、权限、接管三项必须在放量前完成，监控与回滚可以并行补齐；把让步项写进评审单并约定补齐时间，比事后口头解释更容易被接受，也便于复盘。