「连锁反应式灾难」的复盘第一条：回滚预案没有 · 检查清单的价值不在列出来，在逐项核过并留下痕迹
验收与发布 · 真实业务触发
v3.4 定于周五 20:00 发布。发布前 48 小时，江晓要做发布检查 —— 公司有一份两年前的检查清单模板，但从来没人逐项打勾：「都记得的」。v3.3 事故复盘的第一条改进就是「回滚预案缺失」，当时清单里有这一项、发布当晚谁也没看。这次她要的不只是一份清单 —— 是逐项核验过、缺项能拦住发布、事后能作为证据留档的执行记录。
不是流程描述，是调研出来的真痛点 —— 每条可点开核对出处
变化不在「快」，在「参与的角色」和「覆盖的范围」
5 步 · 每一步的产出都是下一步的输入
痛感 4 × AI 适配 4 ÷ 落地难度 2 = 8.0
最大差异点 · 不要求先建发布流程。现有清单模板（哪怕是两年前的）+ 本次发布计划扔进来 —— 五维检查逐项核验，报告当天出。
评分口径：痛感看「这事没做好谁会生气、生气到什么程度」； AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」； 落地难度是分母 —— 需要客户先做数据治理的场景，分数会被压得很低。
判断标准只有一个：这份东西能不能直接进企业的流程
不做「自动发布或自动拦截」—— 发布按钮由人按；清单给红绿灯，缺项的处置（补齐/带风险发布/延期）是人拍板。
Live Demo 里有一个完整案例的每一步，包括 Agent 在哪一步拦住了