故障公告怎么写提示词（系统故障与停机维护通知：首发、进展更新、恢复说明、事后报告四个阶段的对外公告）
线上服务出现故障或要做计划内停机维护时用：按故障的不同阶段写出对用户的公告，首发公告在原因未明时也能发出，说明影响范围、当前进展和下次更新时间，恢复后给出简明的事后说明。
通用大模型 对话模型通用
你是一名负责对外沟通的运维负责人。你的原则：故障时用户最需要的是三件事——是不是我的问题、现在能不能用、什么时候再有消息；所以公告要快、要具体，知道多少说多少，不知道的明确说还不知道。 服务名称与用户群体：[服务与用户] 事件类型（突发故障 / 计划内维护）：[事件类型] 目前掌握的情况（开始时间、受影响的功能与用户范围、已知或未知的原因）：[当前情况] 已采取的措施与预计进展：[处理进展] 对用户的建议（替代办法、是否需要用户操作）：[用户建议] 发布渠道（状态页、站内通知、邮件、社群、短信）：[发布渠道] 时区与时间格式：[时区] 请按事件类型输出： A. 突发故障——四份公告： 1. 首发公告（发现后尽快发出，100 字以内）：现象、影响范围、开始时间、我们正在处理、下次更新时间。原因未明时写「原因正在排查」，不猜测。 2. 进展更新（可多次使用的模板）：自上次更新以来的新进展、目前恢复到什么程度、仍受影响的部分、下次更新时间。没有新进展时也要按时更新，并如实说明。 3. 恢复公告：恢复时间、影响时长、目前状态、用户是否需要做什么（重新登录、检查数据）、是否还在观察。 4. 事后说明（恢复后几个工作日内，400 字以内）：发生了什么、影响了谁、时间线（三到五个节点）、原因（用非技术语言）、我们已经和将要做的改进、对受影响用户的安排。 B. 计划内维护——三份：提前通知（含维护窗口、影响、建议用户提前做的事）、维护前提醒、完成通知；如延长，另加延时说明。 通用要求： - 每份公告开头标注状态（排查中 / 已定位 / 修复中 / 观察中 / 已恢复）和发布时间； - 时间一律写具体时刻并注明 [时区]，不写「稍后」「近期」； - 影响范围写用户能自查的描述（如「部分使用支付宝付款的订单」），不写内部系统名； - 道歉一次即可，放在首发或恢复公告里； - 不出现「个别用户」「偶发」等淡化说法，除非有数据支持； - 为每个发布渠道给出长度合适的版本。 另外输出：客服在此期间的统一答复口径 3 条；发布前自查清单。 约束：不承诺未经确认的恢复时间与补偿；不归咎于用户或第三方（可以陈述事实）。
高亮处换成你自己的内容：[服务与用户]、[事件类型]、[当前情况]、[处理进展]、[用户建议]、[发布渠道]、[时区]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[当前情况] 有多少写多少，哪怕只知道「10:20 开始，登录页打不开」。首发公告的价值在于快，不在于全。[处理进展] 没有就写「刚开始排查」。计划内维护则把维护窗口和受影响功能写清。
常见失败与调整：
- 等查清原因才发第一条：这段沉默里用户会自己猜。先发首发公告，把「下次更新时间」定在 30 分钟后。
- 承诺了恢复时间又做不到：没有把握就只承诺「下次更新时间」，这是你一定能做到的。
- 事后说明写成技术复盘：用户不关心哪个配置项错了，关心的是会不会再发生。原因用一两句非技术语言，重点放在改进措施上。
示例输出
示例，仅供参考（虚构：一款在线预约软件，支付功能故障）
首发公告
【排查中】10 月 14 日 10:35（北京时间）
自 10:20 起，部分用户在提交预约并付款时出现「支付失败」提示。浏览、取消预约等功能不受影响。我们正在排查原因。如果您已被扣款但订单未生成，请不要重复支付，款项会原路退回。下次更新时间：11:05。
恢复公告
【已恢复】10 月 14 日 11:42
支付功能已于 11:30 恢复正常，本次影响持续约 70 分钟。期间被扣款但未成功下单的订单，退款将在 1–3 个工作日内原路退回，无需您操作。给您带来的麻烦，我们很抱歉。我们会继续观察两小时，并在三个工作日内发布事后说明。
客服统一口径（节选）：「目前已知的是 10:20 到 11:30 之间付款可能失败，现在已经恢复。您那笔如果扣了款但没有订单，会自动退回，不用再申请。」
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～