cyz7111 发版检查清单
使用这个 skill 生成贴合仓库、产品范围和发版上下文的实用发版检查清单 release checklist。对前端项目，重点关注旧业务逻辑是否稳定、已有用户路径是否被影响、是否误发多余代码，以及是否漏发必要改动。
工作流程
- 只有在无法从上下文推断时，才追问发版目标：
- 版本、分支、tag、环境、平台或截止时间
- 发版类型：feature、bugfix、hotfix、rollback、基础设施、依赖升级、移动端、后端、前端、文档或数据迁移
- 期望输出：检查清单 checklist、go/no-go 结论、风险评审、release notes、rollback plan，或这些内容的组合
- 前端业务范围：本次需求/缺陷涉及哪些页面、路由、组件、状态流、接口、埋点或权限场景
- 起草前先检查本地上下文：
- 阅读已有发版文档、CI 配置、包元信息、changelog、部署脚本、migration 目录和测试命令。
- 当用户要求针对某次发版检查时，使用
git status、git diff、近期提交和变更文件来判断风险。 - 对前端变更，优先查看路由、页面入口、共享组件、hooks、store、API client、权限判断、feature flags、构建配置和样式全局文件。
- 保留用户已有改动，避免破坏性 git 命令。
- 围绕真实发版风险构建清单，不输出空泛模板。
- 区分必须阻断项 blockers 和推荐检查项。
- 有帮助时补充负责人、证据和可执行命令。
- 当信息足够时，用简洁的 go/no-go 状态收尾。
清单结构
除非用户要求其他格式，优先使用这个结构：
## 发版检查清单 Release Checklist
### 阻断项 Blockers
- [ ] 检查项 - 已知负责人/证据/命令
### 必做检查 Required Checks
- [ ] 检查项 - 已知负责人/证据/命令
### 风险评审 Risk Review
- 风险：
- 缓解措施：
- 回滚方案 Rollback：
### 发版后检查 Post-Release
- [ ] 检查项 - 已知负责人/证据/命令
### Go/No-Go
状态：Go | No-go | 信息不足 Needs information
原因：
常见检查项
只选择与当前发版相关的检查项：
- 源码管理：工作区是否干净、目标分支是否正确、PR 是否已 review、版本 tag、changelog。
- 前端业务稳定性：原有页面路径、核心业务流程、权限分支、异常态、空态、加载态、边界输入是否仍按旧逻辑工作。
- 变更影响分析 impact analysis：变更文件是否影响共享组件、公共 hooks、store、路由守卫、API client、全局样式、构建配置或运行时配置。
- 误发/漏发：是否包含与本次需求无关的代码、调试代码、实验代码、临时开关、console、mock、未完成页面；是否漏掉必要配置、资源文件、接口适配、类型定义、文案或样式。
- 测试：单元测试、集成测试、e2e、smoke test、回归测试、受影响包测试、人工 QA。
- 构建与打包：可复现构建、产物版本、校验和、sourcemap、容器镜像、移动端 build number。
- CI/CD：流水线是否通过、必要审批、部署权限、环境变量、secrets、feature flags。
- 数据库与数据：migrations、backfills、兼容性、rollback 路径、备份、长查询风险。
- API 与兼容性：schema 变化、向后兼容、客户端版本支持、废弃通知。
- 可观测性：dashboard、日志、trace、告警、SLO 影响、错误预算。
- 安全与合规：依赖审计、认证授权变化、PII 处理、许可证影响。
- 发版沟通：release notes、相关方确认、支持团队交接、事故沟通频道。
- 灰度与放量：分阶段发布、canary、feature flag 放量、rollback 条件、on-call 负责人。
- 发版后：smoke check、指标观察、支持队列、后续 ticket。
前端业务回归重点
当发版对象是前端项目时，额外执行这些检查：
- 建立旧业务逻辑基线：
- 从需求、历史代码、路由、测试用例、线上表现或用户描述中梳理“原来应该怎么工作”。
- 明确哪些旧路径必须保持不变，哪些行为是本次允许改变的。
- 做变更影响分析 impact analysis：
- 将变更文件映射到页面、组件、状态、接口、权限、埋点、样式和构建产物。
- 标记高风险共享点，例如公共组件、公共 hooks、全局 store、全局 CSS、请求拦截器、路由配置、权限判断。
- 检查误发：
- 查找与本次需求无关的文件改动、临时代码、调试日志、mock 数据、隐藏入口、未完成 UI、实验开关和环境配置变更。
- 如果发现疑似误发，不要直接删除；在清单中标记为 blocker 或待确认，并说明依据。
- 检查漏发：
- 对照需求和影响范围，确认页面入口、接口字段、类型定义、资源文件、样式、feature flag、环境变量、文案和测试是否齐全。
- 如果只看到调用方或只看到被调用方改动，提示可能存在半截变更。
- 设计回归路径：
- 覆盖核心旧流程、新增流程、权限差异、异常态、空态、加载态、刷新/返回/重复提交等用户路径。
- 对共享组件或全局逻辑变更，要求至少列出受影响页面清单。
输出规则
- 保持清单具体、可执行。
- 只有在确认命令存在，或项目文件强烈暗示时，才写出精确命令。
- 缺少证据时，将检查项标为
待确认 Needs verification，不要假装已经通过。 - 面向用户输出发版结论时，区分“已观察到的事实”和“基于上下文的推断”。
- 高风险发版必须包含 rollback 条件和监控窗口。
- 对前端发版，必须单独输出“旧业务稳定性”“误发风险”“漏发风险”“影响范围”四类结论。