VA-02 · 发布检查清单执行留痕

① 场景引入

一、这件事现在是什么样

验收与发布 · 真实业务触发

v3.4 定于周五 20:00 发布。发布前 48 小时，江晓要做发布检查 —— 公司有一份两年前的检查清单模板，但从来没人逐项打勾：「都记得的」。v3.3 事故复盘的第一条改进就是「回滚预案缺失」，当时清单里有这一项、发布当晚谁也没看。这次她要的不只是一份清单 —— 是逐项核验过、缺项能拦住发布、事后能作为证据留档的执行记录。

二、痛点 · 每条都有来源

1. 「连锁反应式灾难」上线的复盘：影响范围图没拉、回滚预案没有 —— 检查清单躺在文件夹里，发布当晚没人翻
   依据：连锁反应式灾难上线判例：跨域限制只在生产环境生效导致数据服务失效 —— 需求评审时没拉出影响范围图，一行代码的变更踩了别人的线；「上线后 24 小时手机不要静音，你是第一责任人」是产品经理的自保实录
2. 《如期上线》的实操基线：发布前核对影响范围、回滚预案与灰度计划 —— 检查留痕本身就是交付证据与免责凭证
   依据：发布管理的实操基线：《如期上线》复盘模板要求发布前核对影响范围、回滚预案与灰度计划；需求确认书（In/Out ofScope）是对外交付的护身符
3. 同类事故二次发生的根因不是没清单、是清单没有执行闭环 —— 「都记得的」是事故前最常听到的三句话之一
   依据：Agent 项目的行业失败率：麦肯锡统计超 90% 企业 Agent 试点即失败，「Demo 惊艳、两周被叫停」的复盘直指责任归属无人敢碰 —— 每个场景必须有人拍板点

三、换个做法之后

变化不在「快」，在「参与的角色」和「覆盖的范围」

✕ 现在的做法

• 「连锁反应式灾难」上线的复盘：影响范围图没拉、回滚预案没有 —— 检查清单躺在文件夹里，发布当晚没人翻
• 《如期上线》的实操基线：发布前核对影响范围、回滚预案与灰度计划 —— 检查留痕本身就是交付证据与免责凭证
• 同类事故二次发生的根因不是没清单、是清单没有执行闭环 —— 「都记得的」是事故前最常听到的三句话之一✓ 交给 Agent 之后多来源文件一次读入，先做口径与完整性校验，再开始算每条结论绑定来源文件、字段或条号，可以被审产出是企业真会流转的正式件（带签批栏），不是一张展示用的表该拦的地方给出「现在还不能提交」，并给不用干等的替代方案

四、场景闭环

5 步 · 每一步的产出都是下一步的输入

1. 五维清单升级 · 老模板翻新功能/依赖/环境适配/回滚/监控告警五个维度 —— 老模板缺的维度补上
2. 逐项核验 · 不是打勾是验证每项检查配「验证动作」：回滚预案不是「有」而是「演练过一次」—— 打勾要有证据第 3步缺项拦截 · 红灯亮起来高危缺项（回滚预案/数据变更回退）自动红灯 —— 处置三选一：补齐/带风险发布（签字）/延期
3. 影响范围图 · 一屏给研发本次发布涉及的模块与依赖关系可视化 —— 「踩了别人的线」的预防针第5 步执行留痕 · 发布当天的作战板每项的核验人/时间/证据截图 —— 发布后归档，这就是交付证据

要准备什么：现有检查清单模板（如有）两年前的也行 —— 在它基础上升级本次发布计划与涉及模块发布内容 —— 检查的针对性来源回滚与数据库变更方案回滚预案是否真的存在且可执行 —— 高危项灰度/私有化客户对照96 家标准版+ 44 家私有化的发布策略

为什么这个场景值得做

优先级评分：痛感 4 × AI 适配 4 ÷ 落地难度 2 = 8.0

最大差异点：不要求先建发布流程。现有清单模板（哪怕是两年前的）+ 本次发布计划扔进来 —— 五维检查逐项核验，报告当天出。

评分口径：痛感看「这事没做好谁会生气、生气到什么程度」；

AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」；

落地难度是分母 —— 需要客户先做数据治理的场景，分数会被压得很低。

五、会产出什么

判断标准只有一个：这份东西能不能直接进企业的流程

• 正式件本体：发布检查执行报告.xlsx 五维逐项核验 + 红绿灯 + 处置记录
• 可派发清单：影响范围图.xlsx 本次发布涉及模块与依赖 · 一屏给研发
• 可派发清单：回滚预案核验单.xlsx 代码/数据/配置三层回退 · 演练状态

这套东西不承诺什么：不做「自动发布或自动拦截」—— 发布按钮由人按；清单给红绿灯，缺项的处置（补齐/带风险发布/延期）是人拍板。

② Live Demo（演示逐步）

演示模式 · 可视化预演 本页展示的是「应该怎么跑、每一步看什么、交付什么」，用的是真实业务格式的脱敏构造数据， 不宣称已接入客户生产系统，也不承诺任何效率提升百分比。

案例设定：驭数科技（虚构）发布前 48 小时：v3.4 定于周五 20:00 发布。公司有一份两年前的检查清单模板，但从来没人逐项打勾。v3.3 事故复盘的第一条改进就是「回滚预案缺失」—— 当时清单里有这一项、发布当晚谁也没看。江晓要的不只是一份清单，是逐项核验过、缺项能拦住发布、事后能作为证据留档的执行记录。

检查维度5 维 · 32 项红灯项1 项 · 回滚数据方案处置周四晚补齐 · 发布照常留痕32 项 · 全部证据在档

输入产品手上能拿到的东西

不需要整理格式、不需要改文件名 · 直接拖进对话框

• 01_旧版发布检查清单.txt 两年前的模板 —— 升级的底版文档归档 · 2024 版
• 02_v3.4发布计划.xlsx 本次发布的全部内容—— 检查的针对性来源发布计划 · 2026-08-26
• 03_研发回滚方案.txt 红灯项的第一现场 —— 「代码回退即可」谭锐提供的方案 · 2026-08-27
• 04_v3.3事故复盘节选.txt 上次的教训 —— 本次检查的对照基准v3.3 复盘归档 · 2026-07
• 05_客服与实施值班表.xlsx 发布夜的作战序列 —— 留痕的责任人值班安排 · 2026-08-29

注意标橙色那一份 —— 01_旧版发布检查清单.txt。它文档归档 · 2024 版，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

提示词就说这么几句

没有模板、没有表单 · 专业规则由 Skill 兜底

周五要发 v3.4，发布计划、涉及的模块清单、研发给的回滚方案都在这，我们那份两年前的检查清单模板也找到了，帮我做发布检查。 老模板先翻新：五个维度缺什么补什么，别拿两年前的口径糊弄这次； 逐项核验 —— 每一项都要有验证动作，不是打个勾就完：回滚方案这种，要具体到能不能演练； 数据库表结构变更这项重点看 —— 代码能回退，数据呢？ 缺项的给我亮灯：红黄绿分开，红灯的处置给我三个选项（补齐/带风险/延期）各带代价； 最后给我一份发布当天的作战板：每项谁核验、什么证据、几点前完成。

短是因为「五维检查框架、验证动作规则、缺项处置三选一」都在能力包里。产品经理只要把发布计划扔进来。

触发两年前的五项模板 vs 本次的结构变更

打勾式清单防不了险 —— 要的是验证动作与证据

江晓把旧模板、发布计划、研发回滚方案、v3.3 复盘、值班表全部扔进来 —— 检查清单的升级从「上次怎么死的」开始。

第 1 步 · 五维升级 · 老模板翻新

功能/依赖/环境/回滚/监控 —— 32 项带验证动作

第 2 步 · 逐项核验 · 第一轮结果

31 绿 1 红 —— 红在回滚的数据层

项核验结果证据代码回滚演练通过预发环境回退演练记录数据回滚方案不通过「无需回滚」≠ 方案配置生产生效通过生产配置截图（v3.3 同款项）（其余 29 项）通过各项证据在档31 绿 1 红 —— 红的那项是数据库结构变更的回滚：研发方案写「新增表无需回滚」，但半成品数据的残留问题没人回答。红灯不是失败 —— 红灯是清单在干活的样子。3红灯处置 · 三选一带代价

补齐/带风险/延期 —— 逼出决策而不是制造僵局

选项内容代价建议A 补齐周四晚补数据回退脚本并演练4 小时（谭锐加班）推荐B 拆分表结构变更拆到 v3.5，功能先发导出功能的表要兼容旧结构（+0.5 人日）可行C 带风险签字发布，事故时人工清表风险签字 + 人工清理的不确定性不推荐三选一的逻辑：补齐保发布、拆分保安全、带风险保面子 —— 清单的职责是把选项和代价摆上桌，拍板是沈知行的事 —— 「拦住不是目的，逼出处置决策才是」。

第 4 步 · 影响范围图 · 给研发的一屏

本次变更踩到谁的线 —— 可视化预防「连锁反应」

第 5 步 · 作战板 · 发布当晚的执行序

32 项 × 责任人 × 证据 —— 当晚跑一条勾一条

时段动作核验人证据19:30冻结代码与配置谭锐冻结记录19:40执行发布序列谭锐+运维部署日志20:10核心用例抽测

（VA-01 高危 18 条）江晓用例记录20:40私有化环境抽验（实施侧配合）实施组长抽验截图21:00发布确认 · 转入 2 小时观察窗沈知行作战板勾选全绿作战板的五个时段对应五个角色 —— 每项证据归档后，这份报告就是发布本身的「交付证据」：真出了问题，「检查过且有证据」与「没检查」的责任认定是两个世界。

发布还挂着红灯 —— 数据回滚方案没闭环前不能点发布回滚预案的数据层（新增表的数据回退脚本）是本次唯一的红灯 —— 「新增表无需回滚」的判断经不起追问：新代码回退后表内残留的半成品数据，会让 v3.5 重新上线这张表时变成脏表。带着这个红灯发布，等于把「回滚预案缺失」—— v3.3 复盘的第一条改进 —— 原样留给下一次复盘。给出的不是干等：方案 A（周四晚补齐·推荐）：谭锐今晚 4 小时补数据回退脚本（清空脚本 + 演练一次预发）—— 红灯转绿，周五发布照常 —— 成本 4 小时加班，换来回滚三层（代码/数据/配置）的完整闭环；方案 B（拆分发布）：表结构变更拆到 v3.5，导出功能用兼容旧结构的临时方案（+0.5 人日开发 + 0.5 人日验证）—— 发布风险最低，但华正的导出（续约前置条件）晚一个版本、临时方案的技术债要还。两案差的是「今晚的 4 小时」对「一周的拆分」—— 而v3.3 用 62 人时和 12 家客户停服 47 分钟，给这道选择题标好了价。

之后这一次跑完，公司多了什么

不讲省了多久：讲少了几个隐患、沉淀了什么

• ✓ 「回退代码回不了数据」的高危缺口在发布前 48 小时暴露 —— v3.3 的教训没有原样重演
• ✓ 拦住不是目的、逼出处置才是 —— 三选一带代价，发布照常且风险有主
• ✓ 「研发不专业」被核验记录排除 —— 病根是两年前的模板没写数据回退，改模板护住以后每次发布
• ✓ 留痕报告成为事后证据 —— 「检查过且有证据」与「没检查」的责任认定是两个世界

追问现场可能被问到的

答不上来的问题，比答得漂亮的问题更能决定这场演示的结果

• 每次发布都这么查吗？ 大版本全量五维、小版本查回滚与依赖两项 —— 闸门的厚度跟着风险走，但从不为零。
• 「带风险发布」敢选吗？ 敢 —— 前提是签字。带风险发布不是逃检，是明码标价的风险转移：谁签的字，谁为那个风险负责。
• 作战板谁维护？ 核验人各自勾各自的 —— 作战板是共享文档，发布当晚的状态一目了然，谁也别想在糊涂里混过去。

③ 能力沉淀（Skill / 提示词 / 预期输出 / 人工边界）

1. Skill 能力包

导入之后，同类任务会自动按这套规则走 —— 提示词才能写得那么短

发布检查清单执行留痕 · Skill

SKILL.md 主本 + references（输出骨架 / 判据 / 渲染脚本）· 符合 WorkBuddy Skill 规范

版本 v1.0

release-checklist.zip

在 WorkBuddy 里直接上传这个 zip 即可导入

包内结构

• SKILL.md 主本 —— YAML 元信息 + 执行流程 + 硬规则 + 人工边界
• references/output_template.md 输出骨架（sheet 名 / 分区顺序 / 列头）+ 可直接运行的渲染脚本
• references/judgement_rules.md 判据与口径 —— 什么情况算异常、什么情况必须拦住

references 不会一次性全读进来 —— Agent 按需取用。所以 Skill 可以写得很细，不会拖慢每次对话。

2. 原始素材

这些就是产品手上真实能拿到的东西 —— 格式不统一是常态，不是问题

📁VA-02 · 演示素材

脱敏构造数据 · 真实业务格式 · 埋点可核验

共 5 份

• 01_旧版发布检查清单.txt 两年前的模板 —— 升级的底版
• 02_v3.4发布计划.xlsx 本次发布的全部内容 ——检查的针对性来源
• 03_研发回滚方案.txt 红灯项的第一现场 —— 「代码回退即可」
• 04_v3.3事故复盘节选.txt 上次的教训 —— 本次检查的对照基准
• 05_客服与实施值班表.xlsx 发布夜的作战序列 —— 留痕的责任人

怎么用

• 把素材全部拖进 WorkBuddy 对话框（不需要整理格式、不需要改文件名）
• 粘贴下方提示词发送
• 拿到正式件初稿 —— 签批栏留空，推荐意见留空，由你填

3. 提示词卡片

周五要发 v3.4，发布计划、涉及的模块清单、研发给的回滚方案都在这，我们那份两年前的检查清单模板也找到了，帮我做发布检查。 老模板先翻新：五个维度缺什么补什么，别拿两年前的口径糊弄这次； 逐项核验 —— 每一项都要有验证动作，不是打个勾就完：回滚方案这种，要具体到能不能演练； 数据库表结构变更这项重点看 —— 代码能回退，数据呢？ 缺项的给我亮灯：红黄绿分开，红灯的处置给我三个选项（补齐/带风险/延期）各带代价； 最后给我一份发布当天的作战板：每项谁核验、什么证据、几点前完成。

为什么这么短就够了：短是因为「五维检查框架、验证动作规则、缺项处置三选一」都在能力包里。产品经理只要把发布计划扔进来。

换成你自己的业务：把素材换成你手上的真实文件即可。导入 Skill 之后，

该走几步、什么口径、什么情况必须拦住，Agent 自己知道 —— 你只需要说清这是什么事。

自己组织输入的三步法

• 用自然语言说清核心需求 —— 就按平时跟同事交代活的方式说：什么事、什么文件、什么要求。不用讲究格式。
• 调用 Skill 补齐专业规则 —— 导入本页 Skill 后，流程、口径、硬规则 Agent 自己知道。
• 用「增强提示词」补全遗漏 —— 输入框旁边有增强按钮，把随口说的话补成更完整的表述。

分工：自然语言负责「这是什么事」，Skill 负责「该怎么做」，增强提示词负责「别漏了什么」。

4. 预期输出

不方便现场跑的时候可以直接拿这份给客户看 · 与实跑结果同结构

📋正式交付物

带签批栏 / 冻结首行 / 开筛选 —— 判断标准是「能不能直接进企业的流程」

共 3 份

• VA-02_发布检查执行报告.xlsx 正式件本体 · 五维逐项核验 + 红绿灯 + 处置记录
• VA-02_影响范围图.xlsx 本次发布涉及模块与依赖 · 一屏给研发
• VA-02_回滚预案核验单.xlsx 代码/数据/配置三层回退 · 演练状态

Skill 里固化了什么：从 v3.3 的教训里「想起」了那个缺失的预案该拦的地方拦住了排除性结论把技术动作翻译成钱

输入清单：现有检查清单模板（如有）两年前的也行 —— 在它基础上升级本次发布计划与涉及模块发布内容 —— 检查的针对性来源回滚与数据库变更方案回滚预案是否真的存在且可执行 —— 高危项灰度/私有化客户对照96 家标准版 +44 家私有化的发布策略

人工边界：不做「自动发布或自动拦截」—— 发布按钮由人按；清单给红绿灯，缺项的处置（补齐/带风险发布/延期）是人拍板。

升为客户真实案例还缺什么：客户当前真实输入文件（不要整理过的）岗位现行 SOP 与审批链（金额分档、谁签字）至少一次真实出过问题的案例客户当前正在用的正式输出模板客户确认的阈值口径（多少天算临期、多少金额算大额）

5. 同一角色下的其他场景

验收与发布 · 产出即下一步输入

VA-01 · 验收测试用例生成 — 没有专职测试的公司，验收就是产品经理拿自己的手机点一遍 · 「感觉没问题」是唯一的测试报告 查看 →VA-03 · 事故复盘初稿 — 事故复盘停在「下次注意」—— 三个月后同类事故再来一次 · 复盘的价值在改进项闭环，初稿是闭环的起点 查看 →

上下游串起来就是完整链路。每一步的产出都是下一步的输入，不用在不同工具之间来回复制粘贴。

场景内容基于 WorkBuddy 产品能力整理，演示中的企业、人物与数据均为虚构，不代表任何客户的实际成效；痛点引用的公开来源已做脱敏处理。网页版由原资料转换，部分演示表格以原文形式展示。