发版门禁清单

要解决的具体问题

发版评审时最常见的两种问题：关键信息散落在聊天记录和口头确认中，导致回滚方案缺失、值班人未明确就被“差不多可以了”推着上生产；紧急热修时为了赶时间跳过必要检查，反而因没有退路造成更大故障。

核心能力与关键步骤

这个技能生成的是人在回路的门禁包，不是自动化发布工具。它做四件事：

1. 范围确认：用版本/环境/变更摘要锁定本次发版的边界，避免“改了什么说不清”。
2. 检查表：覆盖配置、迁移、监控、回滚、值班、沟通六大类，每项标 是/否/不适用/未知 并附一句证据或缺口说明。默认关键项包括：

- 变更范围与影响面已说明
- 配置/开关变更已列出且有负责人
- 数据迁移/兼容策略已确认（或明确无）
- 监控与告警已覆盖新风险点
- 回滚步骤可执行且已演练/可复述
- 值班与升级路径明确

1. Go/No-Go建议：任一关键项为 否 或 未知 则建议 No-Go；全部为 是 或合理 不适用 则建议 Go，但最终裁定人必须人工签字，AI 不代替决策。
2. 未决与负责人：列出发版前必须补齐的事项及责任人。

紧急热修时采用缩短清单，但有不可逾越的底线：

• 不可省项：回滚步骤、值班与升级路径、变更范围说明。回滚方案未知时仍判 No-Go。
• 可降级为事后补：相关方沟通、文档更新、监控告警完整覆盖，但须标 热修后24小时内补 并写明责任人。
• 可标不适用：全量回归、非相关模块验证、常规变更窗口，但须注明 因热修豁免 及批准人。

判定规则很明确：豁免必须有批准人，写不出就按 No-Go 处理；热修若涉及数据迁移、配置变更或多模块改动，不适用缩短清单；缩短项数不降低单项标准，不能因紧急把 未知 写成 是。

适用边界与注意点

这个技能不执行任何发版命令、不合并代码、不修改生产配置。它不运行 git/kubectl/CI 命令，不声称“已验证生产安全”，也不编造已完成的检查结果。

适用场景包括：发版评审前自检、值班交接时确认可否上线、把口头检查变成可勾选记录。不适用场景包括：“帮我直接发布”“跑流水线”“改生产开关”。

已知限制：不验证用户陈述的真实性，不访问 CI、集群、配置中心，不替代公司变更管理/CAB 流程，也不保证发版成功。