产品发布检查清单的作用，是把“应该没问题”改成每一项都有负责人、证据和截止时间。建议分成 T-7、T-1、上线时、上线后四个阶段，覆盖功能、内容、权限、埋点、客服和回滚。没有回滚条件的发布，不算完成准备。
四个时间点：把上线风险前置
| 阶段 | 核心问题 | 必须留下的证据 |
|---|---|---|
| T-7 | 范围、依赖和风险是否可控？ | 冻结范围、负责人、风险清单 |
| T-1 | 所有关键路径能否走通？ | 验收记录、文案与埋点截图 |
| 上线时 | 谁在什么时间执行什么动作？ | 发布日志、版本号、观察人 |
| 上线后 | 指标异常时如何处置？ | 监控结果、回滚判断、复盘项 |
T-7：锁定范围、依赖与回滚
- 写清本次发布包含和不包含的内容，避免临时需求混入。
- 列出研发、设计、数据、客服、法务等依赖，并为每项指定交付人。
- 提前确认回滚版本、数据兼容方式和触发阈值，不能只写“必要时回滚”。
- 准备面向用户的变更说明，区分新功能、限制和已知问题。
这一阶段的产物不是一张“待办列表”，而是一张能让旁观者判断是否适合继续发布的风险地图。
T-1：按用户路径做一次可复核验收
从入口、核心动作、异常分支到退出路径走一遍。每一步记录环境、账号角色、预期结果和实际结果；截图或日志只作为证据，不代替结论。
| 检查面 | 至少核对什么 |
|---|---|
| 功能 | 核心路径、边界输入、异常提示和兼容性 |
| 内容 | 标题、按钮、帮助文档、空状态和多语言 |
| 权限 | 不同角色可见范围、分享和撤销权限 |
| 数据 | 事件名称、属性、触发时机和去重规则 |
| 支持 | 客服话术、FAQ、反馈入口和升级路径 |
上线当天：把执行动作写成时间线
在同一画布中按时间排序：发布开始、冒烟验证、数据确认、扩大范围、最终确认。每个动作写执行人和回报位置，出现异常时暂停后续步骤，而不是边猜边推进。
上线后：用指标和触发器决定继续还是回滚
观察指标要和目标一致，同时保留错误率、关键路径完成率、客服反馈等护栏指标。提前写出“何时暂停”“谁批准回滚”“回滚后如何通知”，避免异常发生时临时争论。
在 Boardmix 中维护发布清单
用表格放检查项，用标签区分阶段，用评论记录证据和决定。发布完成后不要删除未通过项，把它们移动到复盘区域并注明处理人和日期。这样下次发布可以复制结构而不复制未经验证的假设。
常见问题
检查清单越长越好吗？
不是。只保留会改变发布决定或影响用户体验的项目；重复的行政动作合并，关键风险则拆成可验收步骤。
发布计划和发布检查清单有什么区别？
计划回答何时做、谁负责和依赖关系；检查清单回答每一项是否真的完成并有证据，两者应互相链接。
下一步：复制四阶段表格，给每个检查项补负责人、证据链接和截止时间，再邀请发布相关角色逐项确认。
粤公网安备44030502008643