---

name: product-launch-checklist language: zh description: "为任何产品发布生成完整的发布前、发布当天和发布后检查清单。当准备产品发布、功能上线或重大更新时使用。产出分配到角色、按级别划分的检查清单，覆盖工程就绪、市场与传播、客服支持和发布后监控。"

product-launch-checklist 的简体中文翻译，英文版本为规范版本。

产品发布检查清单

绝不在没有逐项检查的情况下发布。生成一份完整、分配到角色的检查清单，覆盖发布前就绪、发布当天执行和发布后监控。

提议的操作

清单获批后可以执行：把各项交给 action-runner，它会先预览（试运行、标注风险），只通过已连接的操作类 MCP（GitHub / Linear / Slack）执行你批准的内容，并把做过的事记回大脑。典型做法：在指定的仓库或项目中为每个检查项开一个任务（🟡），以及把发布摘要发到 Slack（🔴，需单独批准）。这个技能只提议；由 action-runner 把关并执行，绝不悄悄进行。

所需输入

如未提供，请向用户询问：

• 发布名称和计划发布日期
• 发布级别（1 = 重大产品发布，2 = 重要功能上线，3 = 渐进式更新）
• 团队成员及角色（技术负责人、产品经理、市场、客服等）
• 功能描述（发布的是什么）
• 回滚能力（能否用功能开关控制，或快速回退？）

从大脑读取 / 写入大脑

如果存在 professional-brain（brain/），先用它再提问：

• 先读： 要发布的 entities/ 功能，以及相关的 decisions/（范围、日期、负责人）。
• 之后写： 把发布决策和负责人记入 decisions/。这个技能也可以把清单交给 action-runner 去建任务，它会把实际做过的事记回大脑，形成闭环。

如何使用这个技能

提供：

• 发布名称和日期
• 发布级别（1 = 重大，2 = 功能，3 = 渐进）
• 团队成员及角色

这个技能生成分级的检查清单。第 3 级发布只用"基本项"部分。第 2 级增加"市场与传播"。第 1 级使用全部部分。

---

输出格式

发布检查清单：[功能 / 产品名称]，目标日期：[日期]

发布级别： [1 / 2 / 3] 发布负责人： [产品经理姓名] 技术负责人： [姓名] 发布决策截止： [日期和时间，通常为发布前 24 小时]

---

🔧 发布前：工程与产品（提前 2 周）

• 功能开关已创建并在预发环境测试
• 所有验收标准已经产品经理确认
• 代码已评审并合入主干
• 测试已签字确认（回归 + 新功能）
• 性能测试已完成（负载、延迟）
• 安全评审已完成（如涉及数据或认证变更）
• 回滚流程已记录并测试
• 监控和告警已配置
• 错误日志已就位，严重级别正确
• 数据库迁移已在预发环境用生产级数据量测试

📢 发布前：市场与传播（提前 1 周）

• 博客文章已撰写、审阅并排期
• 应用内公告或提示已配置
• 邮件活动已起草并检查
• 社交媒体内容已起草并排期
• 落地页或功能页已在预发环境上线
• 媒体联络已发出（仅第 1 级）
• Product Hunt 或社区帖子已准备（仅第 1 级）

🎓 发布前：销售与客服（提前 1 周）

• 销售赋能一页纸已完成
• 常见问题文档已共享给销售和客服团队
• 帮助中心文章已撰写并发布
• 客服团队演示或培训已完成
• 客户成功团队已就重点客户做好准备
• 价格已更新（如适用）
• 合同或服务条款已更新（如适用）

📊 发布前：数据分析（提前 1 周）

• 埋点事件在预发环境正确触发
• 发布指标看板已配置
• 基线指标已记录
• 成功标准已记录并共享给团队
• A/B 测试已配置（如适用）

---

✅ 发布决策：提前 24 小时

标准	状态	负责人
所有严重缺陷已解决	🟢 / 🔴	技术负责人
测试签字确认完成	🟢 / 🔴	测试
回滚已测试	🟢 / 🔴	技术负责人
帮助中心文章已上线	🟢 / 🔴	客服
监控已启用	🟢 / 🔴	技术负责人
产品经理签字确认	🟢 / 🔴	产品经理

发布决策： [发布 / 不发布] 决策负责人： [产品经理与技术负责人共同]

---

🚀 发布当天

• 为 [X%] 的用户打开功能开关（从低开始：5% 到 10%）
• 在团队 Slack 或频道确认已发布
• 指标看板已打开并持续监控
• 在发布后 15 分钟、1 小时、4 小时检查错误率
• 博客文章发布 / 邮件发出
• 社交媒体内容上线
• 客服团队在前 4 小时待命
• 产品经理全天可联系
• 发布后 2 小时检查通过则开关扩大到 50%
• 发布后 4 小时检查通过则开关扩大到 100%

---

📈 发布后（第 7 天、第 30 天）

• 第 7 天指标回顾：采用率、错误、客服工单
• 第 7 天客户反馈已汇总
• 复盘已排期
• 经验已记录
• 第 30 天对照目标回顾成功指标
• 从代码库移除功能开关（清理）
• 根据反馈把后续功能加入待办列表

---

延伸材料

这个技能附带支持文件，可用时请使用：

• references/launch-tiering.md：发布分级：让仪式感与风险相匹配。在产出时应用它；它包含上面方法摘要压缩掉的校准和判断。
• templates/launch-plan.md：可填写的成果模板，质量关卡写在里面。当用户想自己完成文档而不是生成时提供。

评分量表（0 到 40）

交付前给这个技能的任何产出打分；32 分以上才算可以交付。

维度	0	5	10
级别校准	没写级别，或清单深度明显不匹配（改个文案却用全套第 1 级流程，或新的收入线只有一份简单清单）	写了级别但没有理由；部分内容的增删与级别不一致	写明级别及理由（定价、法务、影响范围，而不是工程工作量），各部分与级别匹配，级别上的分歧有记录地解决
负责人与时间	检查项和关口由"团队"或没人负责；没有日期	大多数项目有负责人，但关键关口（发布决策、扩量、复盘）缺少具名个人或具体时间	每个检查项、关口和决策都有一个具名个人和日期时间，包括设在发布前约 24 小时的发布决策时间
回滚与分阶段上线	没有回滚计划，或第一天开关就全量	回滚有记录但没有测试；有分阶段，但扩量步骤没有通过标准	回滚经过测试，回退时间已知（"X 分钟，于 [日期] 测试"），开关按 5% 到 10% → 50% → 100% 分阶段，每次扩量都以具名的检查为关口
发布决策的诚实度	没有关口，或关口只是走过场：默认全绿，被阻塞的工作也打了勾	有关口和标准，但被阻塞的项目被淡化、状态过于乐观，或"不发布"没有修订计划	状态诚实（红色写明阻碍和负责人），即使意味着推迟也按表决策，"不发布"会产生带日期的重新决策，并在发布时就约好复盘

质量检查

• 生成清单前确认了发布级别（范围决定深度）
• 发布决策有具名负责人和具体决策时间
• 回滚流程已记录并测试（而不只是计划）
• 功能开关分阶段扩大（5% → 50% → 100%），而不是一次全量
• 发布时就约好了发布后复盘

反模式

• 不要对渐进式更新使用第 1 级清单：生成清单前先恰当地给发布分级
• 没有确认的周末工程值守，不要在周五发布
• 不要把发布决策负责人写成"团队"：必须是具名个人
• 第 1、2 级发布不要跳过回滚计划：上线前就知道回退时间
• 不要在没有约好发布后复盘的情况下结束发布：必须在发布时就约好，而不是之后

指南

• 发布决策必须有具名负责人："团队"不是负责人
• 除非有周末工程值守，否则绝不在周五发布
• 建议所有发布都从不到 10% 的流量开始，即使是简单功能
• 记录回滚时间："我们可以在 X 分钟内回退"应该在发布前就知道

示例触发语

• “准备产品发布。”
• “给我一份发布日检查清单。”
• “规划功能上线。”
• “大版本上线前还缺什么？”