findscripter 何时使用
当一项系统或流程变更需要审批、且后果不可忽视时，用本技能产出一份结构化变更请求（Change Request / RFC），供 CAB（变更咨询委员会）评审或决策人签批。典型场景：
- 上线/部署/迁移前，需正式记录变什么、影响谁、风险多大、出问题怎么回滚。
- 为 ITSM 变更工单准备内容，对接变更评审与审批流。
- 流程/工具/组织调整需要走审批，并提前规划干系人沟通。
不该用的边界：
- 不需审批的琐碎改动（拼写、配置微调、不影响行为）——直接改，别走流程。
- 仅需为代码改动建审计轨迹 / 会话交接——用
technical-change-tracker。 - 变更已发生、要做事后复盘归因——用
postmortem-writer。 - 只关注"如何让人改变行为"的组织变革落地——用
org-change-management（本技能管审批前的请求文档，那个管批准后的采用）。
步骤
按 评估 → 计划 → 执行 → 巩固（assess-plan-execute-sustain）逐段构建请求，缺一段评审会被打回：
- 评估 Assess：变的是什么？影响谁？量级（低/中/高）？会遇到什么阻力？
- 计划 Plan：沟通计划（谁、说什么、何时、用什么渠道）+ 培训计划 + 支持计划（帮助台/FAQ/对接人）+ 带里程碑的时间线。
- 执行 Execute：先讲清"为什么"再宣布"做什么" → 培训与支持 → 监控采用 → 处理阻力。
- 巩固 Sustain：度量采用与有效性 → 强化新行为 → 收尾遗留问题 → 记录经验教训。
沟通原则（贯穿全程）： 先讲 why 再讲 what；早讲、勤讲；多渠道；不仅说"得到什么"也承认"失去什么"；给出清晰的提问/反馈通道。
指令
按下面模板填满即为一份合格变更请求；影响分析、风险评估、回滚计划三块必填，不可留空。
## 变更请求：[标题]
**申请人:** [姓名] | **日期:** [日期] | **优先级:** [紧急/高/中/低]
**状态:** 草稿 | 待审批 | 已批准 | 实施中 | 已完成
### 描述
[变什么、为什么]
### 业务理由
[为何必要——降本/合规/效率/降风险]
### 影响分析
| 范围 | 影响 | 细节 |
|------|------|------|
| 用户 | [高/中/低/无] | [谁受影响、怎样受影响] |
| 系统 | [高/中/低/无] | [涉及哪些系统] |
| 流程 | [高/中/低/无] | [哪些工作流变化] |
| 成本 | [高/中/低/无] | [预算影响] |
### 风险评估
| 风险 | 可能性 | 影响 | 缓解措施 |
|------|--------|------|----------|
| [风险] | [高/中/低] | [高/中/低] | [如何缓解] |
### 实施计划
| 步骤 | 负责人 | 时间线 | 依赖 |
|------|--------|--------|------|
| [步骤] | [人] | [日期] | [依赖什么] |
### 沟通计划
| 受众 | 信息 | 渠道 | 时机 |
|------|------|------|------|
| [谁] | [告诉他们什么] | [怎么传达] | [何时] |
### 回滚计划
[逐步说明如何撤销本变更]
- 触发条件: [何时回滚——量化阈值，如错误率>X%]
- 回滚步骤: [如何回滚，按序]
- 验证: [如何确认回滚成功]
### 所需审批
| 审批人 | 角色 | 状态 |
|--------|------|------|
| [姓名] | [角色] | 待批 |
连接器可用时（ITSM / 项目跟踪 / 协同 IM）： 接 ITSM 可自动建变更工单、拉 CAB 排期与审批流；接项目跟踪可关联实施任务与依赖、按里程碑跟踪进度；接 IM 可起草干系人通知、向相关频道发布变更更新。
示例
一句话提示词： "为下周把订单服务从单体拆出独立部署，写一份变更请求：申请人=我，优先级=高，要 CAB 评审。重点填影响分析、风险评估、回滚计划三块。"
影响分析要写具体，不要写"所有人"： 反例"影响所有用户"；正例"影响计费团队约 200 名坐席，结算页改版，需重新培训 30 分钟"。
回滚触发要量化： 反例"出问题就回滚"；正例"上线后 30 分钟内 5xx 错误率 > 2% 或下单成功率 < 99%，即执行回滚：切流量回旧版本 → 验证旧版健康检查通过 → 关闭新部署 → 通知值班。"
注意事项
- 影响要具体可量化——"所有人"不是影响评估，"计费团队 200 人"才是。
- 永远准备回滚计划——再有把握也要为失败留后路；回滚的触发条件、步骤、验证三者齐全才算数。
- 早沟通——突袭制造阻力，预告争取支持；先讲 why 再讲 what。
- 本技能产出的是审批前的请求文档；批准后的落地采用、阻力管理交给
org-change-management。 - 高风险/不可逆变更（数据迁移、删表、改权限）必须在回滚计划中标注不可逆步骤与数据备份点。
互见
- related：
technical-change-tracker—— 批准后追踪代码改动状态与会话交接 - related：
enterprise-project-manager—— 把实施计划拆成可执行的项目任务与依赖 - related：
business-process-mapper—— 流程类变更先画清现状/目标流程再评估影响 - combines_with：
org-change-management—— 变更批准后，承接沟通节奏、阻力应对与采用度度量 - combines_with：
stakeholder-update-writer—— 落地沟通计划，向各受众发布变更进展 - combines_with：
pre-deploy-checklist/release-manager—— 部署类变更对接上线检查与发布执行 - combines_with：
postmortem-writer—— 变更若引发事故，回滚后做事后复盘
采编自 anthropics/knowledge-work-plugins（Apache-2.0 许可证），对 change-request 技能做了中文适配重写，保留评估-计划-执行-巩固框架、影响/风险/实施/沟通/回滚/审批输出模板、连接器编排与"影响要具体、永远备回滚、早沟通"等关键约束。