release-readiness

“我觉得没问题”会让一个你从未演练过的回滚，在周五下午 6 点无法撤销的 Bug 随版本发布。本技能将“可以发布”转化为可衡量的标准：一份逐项附有证据的准入／不准入清单、一套 5 分钟内完成的冒烟测试、一套按阶段推进且以指标为晋级门槛的发布流程、预先定义的回滚阈值，以及部署后验证。每个部分都给出具体标准，而非空泛目标。

---

调研问题

先检查 .agents/qa-project-context.md——如果文件存在，就使用其中的信息，并跳过已回答的问题。然后只询问尚未回答的问题。

发布节奏和流程：

• 发布频率如何？由谁做出准入／不准入决定？（持续／每日／每周发布，还是由工程负责人／QA 负责人／发布经理决定——这决定清单应当有多详尽。）
• 是否有固定的发布列车时间表，还是临时发布？
• 从开发环境到生产环境之间有多少个环境？（staging、预发布、canary）

当前状况：

• 当前的准入／不准入流程是什么样的？是否有文档记录？
• 是否曾回滚过某次发布？耗时多久？（这可以看出回滚是实际可行的，还是仅仅停留在设想中。）
• 最近一次发布事故是什么，根本原因是什么？目前是否有阻止发布的 Bug？

基础设施和能力：

• 是否具备回滚能力？回滚需要多久？
• 是否可以分阶段／金丝雀部署？
• 是否使用功能标记？如何管理？（这决定采用基于功能标记还是基于基础设施的分阶段发布。）
• 配置了哪些监控和告警？数据库迁移是否可逆？

团队和沟通：

• 发布期间及发布后由谁值班？
• 如何通知相关方？是否有发布沟通渠道？
• 如何生成发布说明？

---

核心原则

1. 发布信心来自证据，而非感觉

“我觉得没问题”不是准入／不准入标准。证据包括：所有 CI 流水线均通过、staging 上的冒烟测试通过、达到性能预算、没有未解决的 P0／P1 Bug。如果无法指出数据，就说明尚未准备好。

将每项结果关联到候选提交、已部署构建、环境、配置和运行时间。保留首次尝试失败的记录和重试结果。分别列出通过、失败、跳过、阻塞和未运行的检查；即使退出状态为绿色，也可能隐藏了被排除的测试。提交之前的证据，不能证明变更后的版本已准备就绪。支付沙箱不可用意味着支付检查处于阻塞状态，而不是已通过。单独记录具名审批人的实际决定和 QA 建议；不要根据乐观态度推断已获批准。

2. 冒烟测试是最后一道安全网，而非唯一一道安全网

冒烟测试可以发现灾难性故障，但不能替代整个开发周期中的全面测试。如果冒烟测试套件是你与生产环境之间唯一的防线，那么上游流程就存在问题。

3. 分阶段发布可以缩小影响范围

同时向 100% 的用户发布，意味着任何 Bug 都会影响 100% 的用户。分阶段发布（金丝雀、按百分比发布、按环发布）可以让你在问题影响 1% 的用户时就发现问题，而不是等到影响所有用户。

4. 必须在发布前定义回滚标准

如果等到出故障时才决定是否回滚，就会在争论中浪费宝贵的时间。提前定义标准，并以基线为参照：“如果 15 分钟内错误率超过基线的 2 倍，就回滚，无需讨论。”将触发条件与 DORA 目标挂钩——如果某次发布的错误率会让你超过变更失败率目标，或者恢复时间会使 MTTR 超标，就应由回滚规则阻止该发布。

5. 每次发布都是一次学习机会

部署后验证不只是为了发现 Bug。还要记录哪些进展顺利、哪些环节耗时较长、哪些环节令人紧张，并持续改进流程。

---

收集当前本地证据

如果已完整检出 QA Skills，请针对候选版本配置的检查运行 node <qa-skills>/scripts/qa.mjs run --project <project> --goal "Check release readiness"。 阅读 report.html 和 result.json。 将所有失败、受阻、未完成、跳过和未运行的项纳入发布检查清单。 报告仅能作为其中所列检查的证据，不能自动视为批准发布。 使用 risk-based-testing 找出当前测试套件中缺失的关键流程，并在提出是否放行的建议前 执行这些领域工作流。

是否放行检查清单

将此清单用作模板，并根据具体情况调整。每一项都应能通过证据核实，而不只是“我检查过了”。将已完成的清单保存为带版本的文件（例如 RELEASE-<version>.md 或已跟踪的问题），以便审核批准过程。

添加证据表格，列出检查项、候选版本/构建、环境、命令或报告链接、 执行时间、结果和未解决的问题。就绪情况审查完全可以以不放行的建议和缺失证据结束。 无需部署或执行部署后操作来让检查清单看起来完整。

自动化检查（必须通过）

• 所有 CI 流水线均通过 — 单元测试、集成测试、端到端测试、类型检查、代码检查
• 冒烟测试套件在预发布环境通过 — 在预发布环境中验证关键用户流程
• 本次发布没有未解决的 P0/P1 级缺陷 — 检查问题跟踪系统，按里程碑/标签筛选
• 满足性能预算 — API 响应时间和捆绑包大小均在阈值内；前端发布运行 Lighthouse CI（仅 API/后端发布可跳过 Lighthouse，因为它衡量的是页面加载，而非服务健康状况）
• 安全扫描无异常 — npm audit / Snyk / Dependabot 中没有高危或严重漏洞
• API 契约测试通过 — 公共 API 没有破坏性更改
• 视觉回归测试通过 — 没有意外的视觉变化
• 无障碍检查通过 — axe-core 扫描未发现新的违规项

手动检查（放行前核实）

• 已审查功能开关 — 记录本次发布中启用/禁用的开关；确认生产环境的开关状态
• 已配置监控和告警 — 新功能均配置了相应告警（错误率、延迟、业务指标）
• 已记录并测试回滚计划 — 已编写操作流程；已在预发布环境演练回滚
• 已测试数据库迁移 — 已测试正向迁移；如果架构更改可逆，则已验证反向迁移
• 已审查第三方依赖项变更 — 已检查新增或升级的外部依赖项是否存在破坏性更改
• 已准备发布说明 — 已更新变更日志，并编写面向利益相关者的摘要
• 已确定值班工程师 — 指定人员可随时响应，并了解本次发布的内容
• 沟通计划已就绪 — 利益相关者知晓发布安排；支持团队已了解变更内容
• 没有相互冲突的发布 — 其他团队不会同时部署
• 已确认部署时段 — 不在流量高峰期或周末前部署（持续部署除外）

风险评估

• 已对变更范围分类 — 小型（配置更改、文案更新）、中型（新功能、重构）、大型（架构更改、迁移）
• 已估算影响范围 — 如果出现问题，可能影响多少比例的用户？
• 已评估回退复杂度 — 能否在 5 分钟内回退？回退是否需要数据迁移？

---

冒烟测试套件设计

应包含的内容

冒烟测试仅覆盖关键用户旅程。如果这些测试失败，说明应用存在根本性问题。

典型的冒烟测试套件（5-8 项测试）：

1. 应用健康状况 — 主页可以加载，返回 200，控制台中没有 JavaScript 错误
2. 身份验证 — 用户可以使用有效凭据登录，并成功建立会话
3. 核心工作流 — 能够完成交付主要价值的操作（例如创建文档、提交表单、加入购物车或完成购买流程）
4. 数据检索 — 关键数据可以正确加载（仪表板内容完整、搜索返回结果、产品页面可以加载）
5. 支付/交易（如适用）— 使用测试凭据完成支付流程
6. API 健康状况 — 主要 API 端点返回符合预期架构的有效响应
7. 导航 — 关键导航路径正常工作（深层链接、重定向、菜单项）
8. 错误处理 — 访问无效路由（404）时，应用会显示对用户友好的错误页面

不应包含的内容

• 边界情况（属于回归测试）
• 视觉上的完美度（属于视觉回归测试）
• 性能基准测试（属于性能测试）
• 全面的表单验证（属于单元测试/集成测试）

保持快速

目标：整个冒烟测试套件在5 分钟以内完成。

• 尽可能并行运行测试
• 使用 API 调用而非 UI 交互来完成准备工作（通过 API 创建测试用户，而不是通过注册表单创建）
• 跳过非关键断言（不检查确切的文案，只检查元素是否存在）
• 使用预先创建数据的专用测试账户（不要在每次运行时从头创建数据）
• 避免不必要的等待 — 使用智能等待（等待元素出现，而不是使用 sleep(3000) / waitForTimeout）

特定环境的冒烟测试

预发布环境冒烟测试：

• 运行完整的冒烟测试套件（全部 5-8 项测试）
• 可以使用测试支付服务提供商
• 可以使用即将发布的版本配置测试功能标志
• 可以测试数据库迁移

生产环境冒烟测试：

• 运行预发布环境冒烟测试的子集（3-5 项测试）
• 使用合成测试账户（明确标记，不会影响分析数据）
• 绝不使用真实支付交易进行测试（使用沙盒模式或跳过）
• 重点检查：应用可以加载、身份验证正常、核心读取操作正常、API 可以响应

部署后冒烟测试：

• 部署完成后立即运行（60 秒内）
• 内容与生产环境冒烟测试相同
• 如果有任何测试失败，则触发警报并开始评估是否回滚

预发布环境不等于生产环境：两者的数据量、流量模式、第三方配置和基础设施规模都不同。正因如此，除了预发布环境验证之外，还需要进行生产环境和部署后冒烟测试。

---

分阶段发布验证

发布阶段

典型的分阶段发布流程。基于功能标志的发布采用相同的阶梯式流程，但会增加一个 25% 的阶段（见下文）：

阶段	流量占比	持续时间	目的
金丝雀发布	1%	15-30 分钟	发现崩溃、异常和明显故障
早期采用者	10%	1-2 小时	验证错误率、延迟和业务指标
部分发布	25-50%	2-4 小时	确认系统在大规模流量下保持稳定
全量发布	100%	—	部署后监控 24 小时

阶段之间的监控内容

在进入下一阶段之前，请验证以下所有指标：

错误指标：

• 错误率（HTTP 5xx）不高于基线
• 异常数量不高于基线
• 日志中没有出现新的错误类型

性能指标：

• P50 和 P95 延迟处于可接受范围内（相对于基线，而非绝对上限）
• 超时错误没有增加
• 数据库查询耗时保持稳定

业务指标：

• 转化率没有下降
• 用户参与度（页面浏览量、操作次数）保持稳定
• 收入/交易量正常（如适用）

基础设施指标：

• CPU 和内存使用情况正常
• 队列深度或消息积压没有增加
• 没有因新增日志而导致磁盘空间问题

自动晋级标准

定义阶段之间自动晋级的规则。每个关卡都包含错误率上限、相对于基线的延迟上限、稳定性观察窗口，以及在较高阶段的业务指标护栏。完整的 canary→10%→50%→100% 晋级规则集，请参阅 references/rollout-automation.md。

功能标志渐进式发布

基础设施级 canary 部署的替代方案：

1. 将新代码部署到 100%，但关闭功能标志
2. 先为内部用户启用标志（内部试用）
3. 为 1% 的用户启用（相当于 canary）
4. 逐步增加：10%、25%、50%、100%
5. 完全发布且稳定运行 1 周后，移除标志

优点： 回滚更快（只需切换标志），无需更改基础设施，还可以针对特定用户群体。

缺点： 增加代码复杂度（分支逻辑），过时的标志会成为技术债务，也无法发现基础设施问题。

工具

平台	擅长领域	备注
LaunchDarkly	企业级规模；Guarded Rollouts（自动 canary 分析，自 2025 年 5 月正式发布）；用于提示词/模型发布的 AI Configs；Agent 图	2025 年收购了 Highlight.io——还提供与标志关联的可观测性
Statsig	以实验为先的文化；适用于双边市场的 Switchback 实验（2026 年 2 月更新）；自动调优	于 2025 年 9 月被 OpenAI 收购；截至 2026 年年中仍独立运营，但在进行多年期基础设施投入前，应权衡收购及路线图风险
GrowthBook	以开源为先；通过扫描代码引用检测过时标志；基于 SQL 的实验	如果你希望自托管并避免供应商锁定，这是不错的选择
Unleash	开源、GitOps 风格的标志定义、环境范围限定	Apache 2 许可；Enterprise 层级支持 SSO/审计
Flagsmith	将终止开关作为核心概念；canary 警报；提供开源选项	2026 年发布了“什么是终止开关”和“发布测试”指南
Harness FME（前身为 Split）	目标用户渐进式发布，并与部署流水线关联的监控；数据仓库原生实验和标志归档（2026 年）	被 Harness 收购后更名

供应商原生的 canary 分析（LaunchDarkly Guarded Rollouts、Statsig Auto-tune、Flagger）如今已很常见——如果你的平台提供此类功能，优先使用，而不是自行编写发布策略 YAML。鉴于本文档记录的供应商变动（Statsig→OpenAI、Split→Harness FME），建议优先选择兼容 OpenFeature 的 SDK（CNCF 规范；Harness FME 等现在都已采用该标准），以便随时更换标志工具。

发布 AI/大模型功能

AI 功能需要采用独特的发布模式：提示词版本和模型 ID 可独立于代码配置，而且必须配备终止开关。

1. 在 AI Configs 平台（LaunchDarkly AI Configs、自定义数据集或功能标志 JSON）中固定提示词模板版本和模型 ID。
2. 在标志后逐步发布提示词/模型组合——先面向内部用户，然后依次覆盖 1%、10% 等用户。
3. 按用户群体监控评估指标（幻觉率、越狱成功率、每次请求成本），而不仅仅是错误率。
4. 成本护栏：设置预算熔断器，当模型的单次请求成本激增时，以开放方式关闭该功能（平稳回退）。
5. 终止开关：使用单个标志禁用 AI 路径，并转至确定性回退方案或“功能不可用”状态——上线前应在预发布环境中测试。

提示词级评估测试模式请参阅 ai-system-testing，canary 指标设计请参阅 testing-in-production。

---

回滚标准和流程

自动回滚触发条件

请在部署前定义这些阈值。触发任何条件时，都会自动开始回滚。所有阈值均相对于测得的基线，而非绝对上限。

指标	阈值	操作
错误率（5xx）	连续 5 分钟 > 基线的 2 倍	自动回滚
P95 延迟	连续 5 分钟 > 基线的 3 倍	自动回滚
健康检查	连续失败 3 次	自动回滚
崩溃率（移动端）	>0.5%	自动回滚
错误预算	1 小时内消耗 >50%	自动回滚

手动回滚触发条件

这些情况需要人工判断，但应制定明确的准则：

• 客户报告严重问题 — 多名用户报告同一问题
• 数据完整性问题 — 有证据表明数据已损坏或不正确
• 发现安全漏洞 — 漏洞正遭到利用，或发现高危 CVE
• 监控盲区 — 发现无法监控新功能的关键指标
• 值班工程师判断 — 值班工程师始终有权触发回滚

回滚流程

步骤 1：做出决定（< 2 分钟）

• 触发条件是自动还是手动？
• 如果是手动：问题是否符合回滚标准？如果符合，立即继续。不要争论。

步骤 2：执行回滚（< 5 分钟）

• 紧急停用开关（最快，有则优先使用）： 切换受影响功能专用的紧急停用开关。它不同于完整代码回滚——无需重新部署即可停用单项功能。每次发布前都要在预发布环境中测试该开关；未经测试的开关不能算开关。
• 功能标记回滚： 禁用新代码路径的功能标记。如果同时存在两者，这种方式比紧急停用开关慢（发布标记与紧急停用开关解决的是不同问题）。
• 代码回滚： 恢复到上一个部署版本（重新部署上一个镜像／制品）。如果问题不局限于单个带标记的功能，请使用此方式。
• 数据库回滚： 如适用，运行向后迁移。如果迁移不可逆，则跳过此步骤并单独处理数据。
• 缓存失效： 如果旧版本会提供过期或不正确的数据，请清除 CDN 和应用缓存。

步骤 3：验证（< 5 分钟）

• 运行生产环境冒烟测试
• 确认错误率恢复至基线
• 检查回滚后的版本是否正常提供服务

步骤 4：沟通（< 10 分钟）

• 使用下方的回滚模板通知发布频道
• 如果对用户造成影响，请更新状态页面
• 向支持团队简要说明情况

步骤 5：调查（下一个工作日）

• 分析根本原因
• 编写能捕获该问题的回归测试
• 如果缺少检查项，请更新发布准入检查清单
• 安排修复并重新发布

回滚公告模板

在步骤 4 中将此内容发到发布频道。完整的发布和回滚模板请参阅 references/communication-templates.md。

Subject: [Rollback] v{version} — {date} {time}
Status: ROLLED BACK
Reason: {one line — e.g. error rate 4x baseline within 8 min}
Impact: {who was affected, for how long}
Current state: Running previous version v{prev_version}
Next steps:
- Root cause investigation: {owner}
- Fix ETA: {estimate or "investigating"}

数据注意事项

如果迁移无法回滚：

• 向前修复： 在当前（已损坏）版本上部署修复，而不是回滚
• 双写： 迁移期间同时写入旧架构和新架构；回滚时丢弃新写入的数据
• 影子迁移： 在后台迁移并验证，然后再切换。回滚时只需停止切换
• 时间点恢复： 从备份恢复数据库（最后手段；会丢失备份之后的更改）

---

部署后验证

即时检查（0-15 分钟）

• 生产环境冒烟测试通过
• 错误率不高于部署前基线
• 错误跟踪器中没有新的异常类型
• 健康检查端点返回正常状态
• 关键页面加载正常（手动抽查 2-3 个页面）

短期（15 分钟 - 2 小时）

• 合成监控确认所有关键路径均正常运行
• 错误率趋势平稳或下降（没有上升）
• P50 和 P95 延迟在预期范围内
• 支持工单量没有增加
• 业务指标（转化量、收入、注册量）正常
• 没有内存泄漏或资源耗尽趋势

中期（2 - 24 小时）

• 夜间批处理作业成功完成（如适用）
• 其他地区开始活动后，没有出现与时区相关的问题
• 邮件 / 通知正常送达
• 第三方集成运行正常
• 没有性能逐渐下降的情况

---

反模式

“在预发布环境中运行正常”

预发布环境不等于生产环境，两者的数据量、流量模式、第三方配置和基础设施规模都不同。在预发布环境中运行成功是就绪的必要条件，但不足以证明已就绪。 修复方法： 除了在预发布环境中验证，还要使用生产环境冒烟测试和分阶段发布。

没有回滚计划

“出了问题再想办法”意味着你要在压力之下、睡眠不足、用户不断投诉的情况下想办法。错误往往就是在这种时候发生的。 修复方法： 记录回滚流程。每季度演练一次。记录所需时间。将其整理成检查清单，而不是依赖口口相传的知识。

周五下午部署

你在周五下午 4 点部署。晚上 6 点出现问题。团队正在吃晚饭。问题持续恶化一整夜。周一早上将是一片混乱。 修复方法： 在周初、当天较早时部署，确保整个团队都能随时监控。如果必须在周五部署，请在中午前完成，并加强监控。

因为“流水线是绿色的”而跳过冒烟测试

CI 流水线使用测试环境中的测试数据进行测试。冒烟测试则用于验证已部署的应用能否在生产配置、生产数据和生产基础设施下正常运行。 修复方法： 冒烟测试不可跳过。如果测试太慢，就加快速度；如果不稳定，就修复。绝不要跳过。

大爆炸式发布，而非渐进式发布

将 6 周的改动累积到一次大型发布中，意味着：更多内容可能出错，更难判断是哪项改动导致问题，风险更高，回滚时间更长，压力也更大。 修复方法： 缩小发布规模，提高发布频率。如果无法持续部署，就争取每周或每两周发布一次，并确保改动规模小且易于理解。

部署后不做验证

你完成部署后就转去开发下一个功能。一小时后，用户已经遇到错误，却没有人监控这些情况。 修复方法： 指派专人，在部署后 30-60 分钟内监控仪表板。设置阈值适当的自动告警。运行部署后冒烟测试。

不愿回滚

“我们快修好了，还是直接推送热修复吧。”与此同时，你在压力下排查问题，用户又要多受影响 45 分钟。 修复方法： 先回滚，再调查。能正常运行的旧版本胜过无法运行的当前版本。面子可以挽回，用户信任却更难重建。

功能标志不断累积

你使用功能标志安全地逐步发布（很好！），却从不清理它们（不好）。一年后，你有 200 个标志，没人知道哪些仍在启用，标志间的相互作用还会引发难以解释的错误。 修复方法： 2026 年的最佳实践是使用平台级过期检测，而不是日历提醒。使用 GrowthBook 的过期标志检测（代码引用）、LaunchDarkly 的归档流程，或 Flagsmith 的标志使用时长遥测，找出代码路径在 N 周内从未触及的标志。再配合每季度一次的检查：超过期限的标志要么归档，要么记录负责人和保留理由。日历日期会过时；代码引用扫描不会。

会说谎的金丝雀告警

自动回滚与一个噪声大、延迟到达或仅部分聚合的指标绑定。告警在错误的时间触发（或未触发），团队因此不再信任它——于是实际事故发生时，信号被忽略。 修复方法： 像测试其他内容一样对待金丝雀告警——它有假阳性率和假阴性率，且两者都要测量。设置一个“影子”运行期：告警发布判断结果，但不实际回滚；将其判断结果与真实情况对比两周。只有当假阳性率低于你的容忍阈值后，才启用自动回滚。参考：https://www.flagsmith.com/blog/when-canary-alerts-go-wrong

双边系统的切换实验

对于市场、网约车、广告竞价以及其他处理组会通过共享状态影响控制组的系统，标准 A/B 测试会失效。将流量平分为 50/50 并不能隔离实验——双方看到的都是同一个被扭曲的市场。 修复方法： 使用切换设计——在较短的时间窗口（几分钟到几小时）内，让整个系统在控制组和处理组之间交替运行。Statsig 的 Switchback 实验（2026 年 2 月）可为常见场景自动执行这一操作。不要因受污染的 A/B 测试结果而阻止发布；应采用正确的设计重新测试。参考：https://www.statsig.com/updates

---

验证

部署完成后立即运行这些检查，从最小范围的检查开始。扩展 references/rollout-automation.md 中的错误追踪器查询。

# Health endpoint returns healthy
curl -s https://your-app.com/health | jq .

# Response time + status in one shot
curl -o /dev/null -s -w "HTTP %{http_code} in %{time_total}s\n" https://your-app.com

# New errors since deploy (Sentry CLI) — should be empty
sentry-cli issues list --project your-project --query "firstSeen:>15m"

# Datadog: compare 5xx count for the service before vs after deploy — must not increase

通过标准：健康状态返回 healthy，状态码为 200 且响应时间在你的延迟预算内，Sentry 查询没有返回新问题，并且部署后的 5xx 计数不高于部署前的基线。

---

完成标准

• Go/no-go 检查清单为每个范围内项目记录证据或明确的缺口，并注明确切的候选版本身份，且作为带版本的制品保存。建议与实际审批决定应分别记录；缺少的签核仍应标记为缺少。
• 冒烟测试结果应对应发布候选版本，并披露失败、重试、跳过、阻塞和未运行的检查。Go 建议须满足项目约定的证据门槛；否则应给出 no-go 或有条件的建议，并列出具体的待办事项。
• 回滚标准应记录为相对于基线的具体阈值，并且至少在 staging 上演练过一次回滚流程
• 制定分阶段发布计划，明确各阶段的流量百分比、晋级标准和防护指标
• 为仅进行就绪性审查的情况定义部署后验证。如果部署和验证属于范围且已获授权，应分别记录其实际结果。

参考文件（位于 references/ 中）

• rollout-automation.md — 自动金丝雀→10%→50%→100%晋级标准（相对于基线）以及部署后验证命令片段。
• communication-templates.md — 撰写发布或回滚公告时加载：可填写的发布和回滚模板。

相关技能

• testing-in-production — 与渐进式发布直接重叠。有关发布时应用的安全发布技术（功能开关、金丝雀发布、暗发布、护栏指标），请查看该技能；有关决定是否发布的决策，请查看此处。
• synthetic-monitoring — 发布后持续运行的定时探测。发布就绪性涵盖部署后一次性的验证窗口；合成监控涵盖持续的 SLA 验证。
• qa-metrics — 提供 DORA 证据（变更失败率、MTTR）以及你在是否发布的决策和回滚阈值中引用的错误率／通过率数据。
• ci-cd-integration — CI 流水线必须通过，作为前置条件；请前往该技能搭建流水线，再回到此处设置门槛。
• ai-system-testing — 发布 AI／大模型功能时：提示词版本评估测试和紧急停止开关设计。此处的发布模式会指向该技能。
• compliance-testing — EU AI Act／EAA／GDPR 要求，这些要求可能在是否发布的决策之前依法阻止发布。
• playwright-automation — 冒烟测试通常在此实现；有关测试结构，请查看该技能；有关哪些用户旅程对冒烟测试至关重要，请查看此处。
• quality-postmortem — 发布出问题时，复盘会将遗漏的检查项反馈到此处的是否发布检查清单中。