运营变更对内通知

要解决什么问题

积分比例、满减门槛、客服口径一类运营规则一改，一线和运营往往各听各的：有人按旧话术解释，有人已经按新规则承诺客户。对外有 API changelog、对用户有更新说明，但内部同步缺的是一份结构固定、边界写死的底稿——尤其灰度期和回滚之后「已发生的业务按哪版算」，最容易在同一件事上出现两种口径。

技能如何工作

本技能把用户给出的变更事实整理成对内通知要点，按固定五步输出：

1. 变更：一句话前后对比。
2. 影响：角色、流程、指标谁受影响。
3. 生效：时间与过渡期；未知则标待确认，不写「已上线」。
4. FAQ：3～7 条一线会被追问的点，并覆盖灰度/分批、回滚/暂停、生效日边界、存量处理、例外申诉；即使本次不灰度、无回滚，也要显式写明，避免被理解成「还没想好」。答不上的问法保留题目、答案写待确认。
5. 待确认：未决项列表，不代改后台、不代发全员公告。

使用前应先对齐：变更摘要、影响业务线、生效时间、是否有过渡期、已知异议点。

适用边界

• 适合：积分/活动规则调整、客服与社群话术切换等需同步一线的场景。
• 不适合：对接方 API 变更（见 api-consumer-notice）、整份制度白话摘要（见 policy-plain-digest）、对外公关稿。
• 限制：不连接配置中心或公告系统；灰度与回滚的最终口径需负责人给定，技能只强制必答项与模板结构。