القائمة
Use when: 风险管控完成后准备上线发布、需要制定上线检查清单与回滚方案、正式发版流程 Do NOT use when: 上线流程已标准化且由运维自动化执行、仅需简单发布无需检查清单
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Product Manager Skills Pack - Full lifecycle support from demand to delivery 让一个产品经理拥有一个产品团队的能力 Use when: Starting a new product, planning features, analyzing market, designing solutions, managing growth, strategic decision
Use when starting any product management task - automatically detects task type and invokes appropriate PM skill using intelligent routing
Use when: 需要检查super-pm skills健康状态、定期维护审计、验证元数据完整性 Do NOT use when: 正在使用某个功能skill、仅需执行产品管理任务
Use when: 有初步需求清单需要细化细节、需明确需求场景和边界条件、需求描述模糊需要结构化 Do NOT use when: 需求已足够详细可直达开发、仅需快速立项无需深入
Use when: 需要理解用户体验全链路、发现用户痛点与机会点、优化用户转化流程 Do NOT use when: 用户流程已非常清晰、仅需单一功能分析而非全局体验
Use when: 需要了解市场格局与竞争态势、收集行业数据、分析竞品优劣势、评估市场机会 Do NOT use when: 市场已有充分内部调研数据、仅需简单规模估算无需深度分析
| name | pm-release |
| description | Use when: 风险管控完成后准备上线发布、需要制定上线检查清单与回滚方案、正式发版流程 Do NOT use when: 上线流程已标准化且由运维自动化执行、仅需简单发布无需检查清单 |
| allowed-tools | ["Agent","Read","Write","AskUserQuestion","Bash"] |
bash "$(dirname "${BASH_SOURCE[0]}")"/check-update.sh 2>/dev/null || true
# 读取技能包版本号
SKILL_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")" 2>/dev/null && pwd)" || true
if [ -f "$SKILL_ROOT/VERSION" ]; then echo "📦 super-pm $(cat "$SKILL_ROOT/VERSION")"; fi
mkdir -p docs/04-风控管理
echo "🚀 上线执行方案制定工具已启动"
当流程要求与用户交互时：
使用 AskUserQuestion:
📦 上线策略选择
选择本次上线的方式：
A) 全量发布（一次性上线所有用户） B) 灰度发布（逐步放开用户比例） C) 蓝绿部署（新旧版本并行） D) 金丝雀发布（小流量验证）
继续询问：
🌍 环境部署策略
需要在哪些环境部署？
A) 仅生产环境 B) 测试环境 → 生产环境 C) 开发环境 → 测试环境 → 预发布环境 → 生产环境 D) 自定义环境流程
使用 AskUserQuestion:
✅ 上线检查项
必须检查哪些项目？（可多选）
A) 功能测试（核心功能验证） B) 性能测试（压力测试、容量验证） C) 安全检查（漏洞扫描、权限验证） D) 兼容性测试（多端、多浏览器） E) 数据备份（数据库、配置文件） F) 监控告警（日志、指标、告警规则） G) 文档完备（用户手册、运维文档） H) 全部检查
使用 AskUserQuestion:
⏰ 发布时间窗口
选择合适的发布时间：
A) 工作日白天（便于快速响应问题） B) 工作日夜间（用户量少，影响小） C) 周末夜间（最低峰时段） D) 根据业务特点灵活选择
继续询问：
📅 发布节奏
发布频率是？
A) 单次发布（一次性完成） B) 分阶段发布（多个版本逐步上线） C) 持续发布（多次迭代，持续优化）
使用 AskUserQuestion:
🔙 回滚触发条件
什么情况下需要回滚？
A) 严重Bug导致功能不可用 B) 性能严重下降（响应时间、错误率） C) 用户投诉激增 D) 数据异常（关键指标暴跌） E) 以上全部情况
继续询问：
⏱️ 回滚时间要求
从决定回滚到完成回滚，最长可接受时间：
A) 5分钟内（快速回滚） B) 15分钟内（标准回滚） C) 30分钟内（慢速回滚） D) 1小时内（可接受）
使用 AskUserQuestion:
📢 上线通知对象
需要通知哪些人？（可多选）
A) 内部团队（产品、研发、测试、运营） B) 管理层（项目发起人、部门负责人） C) 外部用户（发布公告、更新日志） D) 合作伙伴（第三方服务、渠道方） E) 客服团队（提前准备FAQ）
使用 Write 工具生成 docs/04-风控管理/上线执行方案.md。
利用 Agent 工具并行执行独立子任务，大幅缩短总执行时间。
当步骤1-3的用户信息收集完成后，以下两个任务可以并行执行：
| 子任务 | 说明 |
|---|---|
| 检查清单编排 | 基于上线策略和检查项，自动生成完整上线检查清单 |
| 回滚方案设计 | 根据回滚触发条件和时间要求，输出回滚操作步骤 |
在步骤6生成文档前，使用 Agent 工具激活子任务并行执行。
| 维度 | V1.1.0（串行） | V2.0.0（Subagent并行） | 节省 |
|---|---|---|---|
| 检查清单 | 用户逐一确认检查项 | Agent并行生成完整清单 | 约3轮交互 |
| 回滚方案 | 依次询问回滚细节 | Agent自动输出回滚步骤 | 约2轮交互 |
| 通知机制设计 | 逐个问询通知对象 | Agent并行编排通知方案 | 约2轮交互 |
| 总交互轮次 | 约12-15轮 | 约6-8轮 | 减少50%+ |
| 耗时估算 | 12-18分钟 | 6-9分钟 | 节省约8分钟 |
上线执行方案 → docs/04-风控管理/上线执行方案.md
# 上线执行方案
## 一、上线概况
- **上线策略**: [从步骤1提取]
- **环境部署**: [从步骤1提取]
- **发布时间**: [从步骤3提取]
- **回滚要求**: [从步骤4提取]
- **生成时间**: [当前时间]
---
## 二、上线策略
### 2.1 发布方式
**策略**: [从步骤1提取]
**选择理由**:
- [说明为什么选择此策略]
- [适用的场景]
### 2.2 灰度发布计划（如适用）
**阶段划分**:
- **阶段1**: 1% 用户（内部用户、白名单）
- **阶段2**: 10% 用户（观察期：24小时）
- **阶段3**: 50% 用户（观察期：12小时）
- **阶段4**: 100% 用户（全量发布）
**观察指标**:
- 错误率 < 1%
- 平均响应时间 < 500ms
- 用户投诉数 < 5起/小时
### 2.3 蓝绿部署方案（如适用）
**环境准备**:
- Blue环境：当前生产版本
- Green环境：新版本
**切换流程**:
1. 部署Green环境
2. 健康检查通过
3. 切换流量到Green
4. Blue环境待命（可快速回滚）
---
## 三、上线检查清单
### 3.1 功能测试
| 检查项 | 验收标准 | 负责人 | 状态 |
|--------|---------|--------|------|
| 核心功能验证 | 所有P0功能正常 | 测试负责人 | ⏳ 待测试 |
| 边界条件测试 | 异常情况处理正确 | 测试负责人 | ⏳ 待测试 |
| 兼容性测试 | 主流浏览器、设备正常 | 测试负责人 | ⏳ 待测试 |
| 回归测试 | 无严重Bug | 测试负责人 | ⏳ 待测试 |
### 3.2 性能测试
| 检查项 | 验收标准 | 负责人 | 状态 |
|--------|---------|--------|------|
| 压力测试 | 支持[XX]并发用户 | 性能工程师 | ⏳ 待测试 |
| 容量验证 | CPU < 70%，内存 < 80% | 运维工程师 | ⏳ 待验证 |
| 响应时间 | 平均 < 500ms，P99 < 2s | 性能工程师 | ⏳ 待测试 |
| 数据库性能 | 慢查询 < 1% | DBA | ⏳ 待验证 |
### 3.3 安全检查
| 检查项 | 验收标准 | 负责人 | 状态 |
|--------|---------|--------|------|
| 漏洞扫描 | 无高危漏洞 | 安全工程师 | ⏳ 待扫描 |
| 权限验证 | 越权访问测试通过 | 安全工程师 | ⏳ 待验证 |
| 数据加密 | 敏感数据加密存储 | 研发负责人 | ⏳ 待确认 |
| 日志脱敏 | 日志中无明文敏感信息 | 研发负责人 | ⏳ 待确认 |
### 3.4 数据备份
| 检查项 | 验收标准 | 负责人 | 状态 |
|--------|---------|--------|------|
| 数据库备份 | 全量备份完成 | DBA | ⏳ 待备份 |
| 配置文件备份 | 配置已备份到Git | 运维工程师 | ⏳ 待备份 |
| 回滚脚本准备 | 回滚脚本验证通过 | 研发负责人 | ⏳ 待准备 |
### 3.5 监控告警
| 检查项 | 验收标准 | 负责人 | 状态 |
|--------|---------|--------|------|
| 日志监控 | 日志正常输出 | 运维工程师 | ⏳ 待验证 |
| 指标监控 | Grafana面板配置完成 | 运维工程师 | ⏳ 待配置 |
| 告警规则 | 关键指标告警配置完成 | 运维工程师 | ⏳ 待配置 |
| 值班人员 | 上线期间有人值班 | 项目经理 | ⏳ 待安排 |
### 3.6 文档完备
| 检查项 | 验收标准 | 负责人 | 状态 |
|--------|---------|--------|------|
| 用户手册 | 更新用户操作文档 | 产品负责人 | ⏳ 待完成 |
| 运维文档 | 更新部署、配置文档 | 运维工程师 | ⏳ 待完成 |
| API文档 | 更新接口文档 | 研发负责人 | ⏳ 待完成 |
| 更新日志 | CHANGELOG已更新 | 产品负责人 | ⏳ 待完成 |
---
## 四、发布时间规划
### 4.1 发布时间窗口
**发布日期**: [YYYY-MM-DD]
**发布时间**: [HH:MM]
**预计时长**: [XX]小时
**选择理由**:
- [为什么选择这个时间]
- [用户访问低峰期/业务低峰期]
### 4.2 发布时间线
| 时间 | 任务 | 负责人 | 预计时长 |
|------|------|--------|---------|
| T-2h | 最终检查清单确认 | 项目经理 | 30分钟 |
| T-1h | 团队就位，最后一次同步 | 项目经理 | 15分钟 |
| T-0 | 开始上线 | 运维工程师 | - |
| T+0.5h | 环境部署、配置更新 | 运维工程师 | 30分钟 |
| T+1h | 功能验证（冒烟测试） | 测试负责人 | 30分钟 |
| T+1.5h | 监控指标观察 | 运维工程师 | 30分钟 |
| T+2h | 发布通知 | 产品负责人 | 15分钟 |
| T+4h | 灰度放开至10%（如适用） | 运维工程师 | - |
| T+24h | 全量发布完成 | 项目经理 | - |
---
## 五、回滚方案
### 5.1 回滚触发条件
**立即回滚**（红色预警）:
- ✅ 严重Bug导致核心功能不可用
- ✅ 错误率 > 5%
- ✅ 响应时间 > 5s
- ✅ 数据丢失或损坏
**评估后回滚**（黄色预警）:
- ⚠️ 性能下降明显（响应时间 > 1s）
- ⚠️ 用户投诉 > 10起/小时
- ⚠️ 关键指标下降 > 20%
### 5.2 回滚流程
发现问题 → 评估严重程度 → 决定是否回滚 ↓ 通知相关人员（项目经理、技术负责人） ↓ 执行回滚操作 ↓ 验证回滚成功 ↓ 复盘分析
### 5.3 回滚操作步骤
#### 方式1：代码回滚
```bash
# 1. 切换到稳定版本分支
git checkout [稳定版本tag]
# 2. 重新构建
npm run build
# 3. 部署
kubectl set image deployment/app app=[新镜像]
# 4. 验证
curl -I https://app.example.com/health
# 1. 停止应用写入
kubectl scale deployment/app --replicas=0
# 2. 恢复数据库
mysql -u root -p < /backup/backup_YYYYMMDD.sql
# 3. 验证数据完整性
mysql -u root -p -e "SELECT COUNT(*) FROM users;"
# 4. 重启应用
kubectl scale deployment/app --replicas=3
# 1. 恢复配置文件
kubectl rollout undo deployment/app
# 2. 验证配置
kubectl get configmap app-config -o yaml
# 3. 重启应用
kubectl rollout restart deployment/app
目标: [从步骤4提取]
快速回滚清单:
通知时间: 上线前[XX]小时
通知对象: [从步骤5提取]
通知内容:
【上线通知】
项目：[项目名称]
版本：[版本号]
时间：[YYYY-MM-DD HH:MM]
变更内容：[简要说明]
影响范围：[用户/功能]
联系人：[姓名+电话]
通知节点:
通知渠道:
通知时间: 上线完成后[XX]小时内
通知对象:
通知内容:
【上线成功通知】
项目：[项目名称]
版本：[版本号]
上线时间：[YYYY-MM-DD HH:MM]
新增功能：[功能列表]
优化改进：[改进点]
问题修复：[修复内容]
已知问题：[如有]
反馈渠道：[联系方式]
应用层:
系统层:
业务层:
| 指标 | 阈值 | 级别 | 通知方式 |
|---|---|---|---|
| 错误率 | > 1% | 黄色 | 项目群 |
| 错误率 | > 5% | 红色 | 电话+项目群 |
| 响应时间 | > 2s | 黄色 | 项目群 |
| CPU使用率 | > 80% | 黄色 | 项目群 |
| 内存使用率 | > 90% | 红色 | 电话+项目群 |
监控工具: Grafana / 阿里云监控 / 自建监控
监控看板:
| 角色 | 姓名 | 电话 | 职责 |
|---|---|---|---|
| 项目经理 | [姓名] | [电话] | 总协调 |
| 技术负责人 | [姓名] | [电话] | 技术决策 |
| 运维负责人 | [姓名] | [电话] | 系统运维 |
| 测试负责人 | [姓名] | [电话] | 质量保障 |
| 产品负责人 | [姓名] | [电话] | 业务决策 |
发现问题 → 初步评估（5分钟内）
↓
通知相关人员 → 问题定位（15分钟内）
↓
制定方案 → 方案执行（30分钟内）
↓
验证结果 → 问题解决
↓
复盘总结
P0 - 致命问题:
响应: 立即处理，所有人停下手头工作
P1 - 严重问题:
响应: 1小时内处理，指定专人负责
P2 - 一般问题:
响应: 24小时内处理，排入迭代计划
复盘会议: 上线后[XX]天内
参与者:
过程回顾:
问题分析:
改进措施:
复盘报告:
建议执行：
✅ Good 示例：
- 有数据引用：「根据 Q4 数据，留存率从 35% 降至 28%」
- 有验证来源：「数据来源：Google Analytics, 2025-12-01」
- 有明确建议：「建议将新手引导步骤从 5 步减少至 3 步」
❌ Bad 示例：
- 模糊结论：「数据表明留存率有所下降」
- 无来源：「根据经验，这个功能很重要」
- 没有行动建议：「留存是个问题」
出现以下情况立即停止并回溯：
| 误区 | 正确做法 |
|---|---|
| 使用"应该"、"大概"、"看起来"做结论 | 必须基于实际数据和验证 |
| 未运行检查就声称已完成 | 先验证，再陈述 |
| 因时间紧迫跳过关键步骤 | 没有例外，时间紧更要严格 |
| "这次应该没问题"的想法 | 每次都要重新验证 |
docs/ 目录⚠️ 任何一项未通过 → 补全后再标记完成。
项目状态: 上线执行方案已制定 生成时间: [时间戳] 生成工具: super-pm
---
## 推荐下一步
执行完成后，输出：
✅ 上线执行方案已生成！
🎯 建议下一步：
1. /pm-change（建立变更管理机制）
2. /pm-retro（进行迭代复盘）
3. /pm-roadmap（更新产品路线图）