pm-release

Preamble

bash "$(dirname "${BASH_SOURCE[0]}")/../../check-update.sh" 2>/dev/null || true
mkdir -p docs/04-风控管理

echo "🚀 上线执行方案制定工具已启动"

---

跨 Agent 交互规则

当流程要求与用户交互时：

1. 如果当前环境支持 AskUserQuestion，使用 AskUserQuestion（最佳体验）。
2. 如果当前环境不支持 AskUserQuestion，必须用普通聊天消息提出同样问题。
3. 一次只问一个问题。
4. 提问后必须停止当前回合，等待用户回答（STOP and WAIT）。
5. 不得在用户回答前生成文档、写入 docs。
6. 已有 docs 文件不能替代本轮用户回答。

---

执行流程

步骤 1: 确定上线策略

使用 AskUserQuestion:

📦 上线策略选择

选择本次上线的方式：

A) 全量发布（一次性上线所有用户） B) 灰度发布（逐步放开用户比例） C) 蓝绿部署（新旧版本并行） D) 金丝雀发布（小流量验证）

继续询问：

🌍 环境部署策略

需要在哪些环境部署？

A) 仅生产环境 B) 测试环境 → 生产环境 C) 开发环境 → 测试环境 → 预发布环境 → 生产环境 D) 自定义环境流程

步骤 2: 制定上线检查清单

使用 AskUserQuestion:

✅ 上线检查项

必须检查哪些项目？（可多选）

A) 功能测试（核心功能验证） B) 性能测试（压力测试、容量验证） C) 安全检查（漏洞扫描、权限验证） D) 兼容性测试（多端、多浏览器） E) 数据备份（数据库、配置文件） F) 监控告警（日志、指标、告警规则） G) 文档完备（用户手册、运维文档） H) 全部检查

步骤 3: 规划发布时间

使用 AskUserQuestion:

⏰ 发布时间窗口

选择合适的发布时间：

A) 工作日白天（便于快速响应问题） B) 工作日夜间（用户量少，影响小） C) 周末夜间（最低峰时段） D) 根据业务特点灵活选择

继续询问：

📅 发布节奏

发布频率是？

A) 单次发布（一次性完成） B) 分阶段发布（多个版本逐步上线） C) 持续发布（多次迭代，持续优化）

步骤 4: 设计回滚方案

使用 AskUserQuestion:

🔙 回滚触发条件

什么情况下需要回滚？

A) 严重Bug导致功能不可用 B) 性能严重下降（响应时间、错误率） C) 用户投诉激增 D) 数据异常（关键指标暴跌） E) 以上全部情况

继续询问：

⏱️ 回滚时间要求

从决定回滚到完成回滚，最长可接受时间：

A) 5分钟内（快速回滚） B) 15分钟内（标准回滚） C) 30分钟内（慢速回滚） D) 1小时内（可接受）

步骤 5: 规划通知机制

使用 AskUserQuestion:

📢 上线通知对象

需要通知哪些人？（可多选）

A) 内部团队（产品、研发、测试、运营） B) 管理层（项目发起人、部门负责人） C) 外部用户（发布公告、更新日志） D) 合作伙伴（第三方服务、渠道方） E) 客服团队（提前准备FAQ）

步骤 6: 生成上线执行方案

使用 Write 工具生成 docs/04-风控管理/上线执行方案.md。

---

Subagent 并行加速（v2.0.0 新增）

利用 Agent 工具并行执行独立子任务，大幅缩短总执行时间。

可并行子任务

当步骤1-3的用户信息收集完成后，以下两个任务可以并行执行：

子任务	说明
检查清单编排	基于上线策略和检查项，自动生成完整上线检查清单
回滚方案设计	根据回滚触发条件和时间要求，输出回滚操作步骤

触发方式

在步骤6生成文档前，使用 Agent 工具激活子任务并行执行。

V1 vs V2 对比

维度	V1.1.0（串行）	V2.0.0（Subagent并行）	节省
检查清单	用户逐一确认检查项	Agent并行生成完整清单	约3轮交互
回滚方案	依次询问回滚细节	Agent自动输出回滚步骤	约2轮交互
通知机制设计	逐个问询通知对象	Agent并行编排通知方案	约2轮交互
总交互轮次	约12-15轮	约6-8轮	减少50%+
耗时估算	12-18分钟	6-9分钟	节省约8分钟