需要审批的系统或流程变更：生成含影响分析…

在提议需要审批的系统或流程变更、准备 CAB 审查记录、部署前记录风险与回滚步骤或规划发布沟通时使用。

适用场景

解决思路

1. 使用 `/change-request $ARGUMENTS` 生成结构化变更请求；若遇到不熟悉的占位符或需检查已连接工具，查看 `CONNECTORS.md`。
2. 在构建请求时应用 assess-plan-execute-sustain 框架。
3. Assess：明确什么正在变化。
4. Assess：明确谁受影响。
5. Assess：评估变化重要性，标记为低 / 中 / 高。
6. Assess：预判应预期什么阻力。
7. Plan：制定沟通计划，明确谁、什么、何时、如何。
8. Plan：制定培训计划，明确需要哪些技能、如何交付。
9. Plan：制定支持计划，包括帮助台、倡导者、常见问题。
10. Plan：制定带里程碑的时间线。
11. Execute：宣布并解释“为什么”。
12. Execute：提供培训与支持。
13. Execute：监控采用情况。
14. Execute：处理阻力。
15. Sustain：衡量采用与有效性。
16. Sustain：强化新行为。
17. Sustain：处理遗留问题。
18. Sustain：记录经验教训。
19. 沟通原则：先解释为什么，再解释是什么。
20. 沟通原则：尽早且频繁沟通。
21. 沟通原则：使用多种渠道。
22. 沟通原则：承认正在失去的东西，而不只是获得的东西。
23. 沟通原则：提供清晰路径供提问和表达关切。
24. 输出变更请求标题、请求者、日期、优先级（关键/高/中/低）、状态（草稿/待审批/已批准/进行中/完成）。
25. Description：说明什么在变化以及为什么。
26. Business Justification：说明为什么需要变更，如成本节约、合规、效率、风险降低。
27. Impact Analysis：按用户、系统、流程、成本填写影响等级（高/中/低/无）和详情，说明谁或什么受影响以及如何受影响。
28. Risk Assessment：按风险、可能性（高/中/低）、影响（高/中/低）、缓解措施填写。
29. Implementation Plan：按步骤、负责人、时间线、依赖项填写。
30. Communication Plan：按受众、消息、渠道、时机填写。
31. Rollback Plan：写出逐步回滚计划，包括触发条件（何时回滚）、步骤（如何回滚）、验证（如何确认回滚成功）。
32. Approvals Required：按审批人、角色、状态填写。
33. 若连接 ITSM：自动创建变更请求工单；拉取变更咨询委员会（CAB）日程和审批工作流。
34. 若连接项目跟踪器：链接到相关实现任务和依赖；对照里程碑跟踪变更进度。
35. 若连接聊天工具：为沟通计划起草干系人通知；向相关团队频道发布变更更新。
36. 提示：影响要具体，不要写“所有人”，要写如“账单团队 200 名用户”。
37. 提示：始终准备回滚计划，即使自信也要为失败做计划。
38. 提示：尽早沟通；意外会造成阻力，预告能建立支持。

适用边界 · 注意事项

• 无需审批、低风险且可即时回退的日常小改动，不必套用完整变更请求。
• 紧急故障恢复或安全事件处置应走事件响应/应急流程，不应被常规 CAB 审批拖延。
• 若组织没有变更审批或 CAB 流程，可裁剪模板，否则完整审批章节会空转。