运营变更对内通知
用途
把运营规则/策略变更整理成对内通知要点：变更内容、影响范围、生效时间、一线 FAQ、待确认。
只出同步底稿，不改生产配置，不代发全员公告系统，不编造未确认的生效时刻。
适用场景
- 适合：积分规则调整、活动门槛变更、客服口径切换等需同步一线/运营的变更。
- 不适合：API/接口变更通知（见
api-consumer-notice）；整份制度白话（见policy-plain-digest）；对外公关危机稿。
边界与差异化
- 参考：
api-consumer-notice、policy-plain-digest、changelog-user-facing。 - 本技能差异：运营规则对内同步，不是 API 变更、整制摘要或对用户更新日志。
- 禁止：写成「配置已上线」若用户未确认；缺生效时间则待确认。
怎么使用(普通用户)
- 「运营规则变更，写对内通知：变更、影响、生效、FAQ」
- 「积分兑换比例从 100:1 改为 120:1，下周一生效，帮我同步一线」
使用前必问
变更摘要、影响角色/业务线、生效时间、是否有过渡期、已知异议点。
使用步骤
- 变更：一句话说清前后对比。
- 影响：谁、什么流程、什么指标受影响。
- 生效：时间与过渡期；未知则待确认。
- FAQ：3–7 条一线可能被问到的点。
- 待确认：未决项列表；不自动改系统。
一线 FAQ 必答问法（含灰度与回滚）
FAQ 不该只回答「新规则是什么」。一线真正被追问的是边界情况——其中灰度期与回滚最容易漏写，也最容易造成同一件事两种口径：
| 类别 | 必备问法 | 为什么必须写 |
|---|---|---|
| 灰度/分批 | 「为什么我的账号还是旧规则？」「同事的跟我不一样是不是出错了？」 | 灰度期一线会同时收到两种反馈，没有统一口径就会被当成 bug 上报 |
| 回滚/暂停 | 「昨天说改了今天怎么又变回去了？」「按新规则领的还算数吗？」 | 变更被回滚时一线最难解释；须提前约定已发生的业务按哪版算 |
| 时间边界 | 「生效当天 0 点前下的单算哪版？」 | 跨生效点的订单是投诉高发区 |
| 存量处理 | 「之前领的旧券还能用吗？有效期怎么算？」 | 不写清就会各说各话 |
| 例外与申诉 | 「客户不接受能不能特批？找谁？」 | 没有申诉路径时，一线只能硬顶或乱承诺 |
判定规则：
- 灰度与回滚两类即使本次不涉及，也要显式写「本次不灰度」「无回滚计划」——留空会被理解成「还没想好」。
- 回滚口径必须回答「已按新规则发生的业务如何处理」；只写「回退到旧规则」不够。
- 用户没给答案的问法，FAQ 里保留问题、答案写「待确认」——不要因为答不上来就删掉它，问题不会因为没写就不被问到。
输出模板
## 运营规则变更 · 对内通知要点
### 变更
- 之前：...
- 之后：...
### 影响
- ...
### 生效
- 时间：...
- 过渡：...
### 一线 FAQ
1. Q: ... A: ...
### 待确认
1. ...
示例
输入：会员日满减从满 200-20 改为满 300-30；客服与社群需同步；生效日待定，可能下周四。
输出：变更对比；影响客服/社群话术与活动页；生效标待确认（疑下周四）；FAQ 含旧券是否可用等；待确认最终生效日与旧券处理。
常见问题(FAQ)
- 能直接改后台吗？ 不能。
- 和 API 通知有何不同？ API 面向对接方；本稿面向内部运营/一线。
- 生效时间未知？ 正文标待确认，勿写死日期。
已知限制
- 不连接配置中心/公告系统。
- 中文交互；不依赖海外 API。
- 灰度与回滚口径需用户或运营负责人给定，本技能只提示必答项。
变更说明
- 0.1.1: 新增「一线 FAQ 必答问法（含灰度与回滚）」（原扣分点）——五类必备问法（灰度分批、回滚暂停、时间边界、存量处理、例外申诉）及各自的必要性；配三条判定规则：灰度与回滚即使不涉及也要显式写明否则会被理解成没想好、回滚口径必须回答「已按新规则发生的业务如何处理」、答不上来的问法保留问题并标待确认而不是删掉。
- 0.1.0: 首发。把运营规则变更整理成对内通知要点。
