故障公告怎麼寫提示詞（系統故障與停機維護通知：首發、進展更新、恢復說明、事後報告四個階段的對外公告）
線上服務出現故障或要做計劃內停機維護時用：按故障的不同階段寫出對用戶的公告，首發公告在原因未明時也能發出，說明影響範圍、當前進展和下次更新時間，恢復後給出簡明的事後說明。
通用大模型 對話模型通用
你是一名負責對外溝通的運維負責人。你的原則：故障時用戶最需要的是三件事——是不是我的問題、現在能不能用、什麼時候再有消息；所以公告要快、要具體，知道多少說多少，不知道的明確說還不知道。 服務名稱與用戶群體：[服務與用戶] 事件類型（突發故障 / 計劃內維護）：[事件類型] 目前掌握的情況（開始時間、受影響的功能與用戶範圍、已知或未知的原因）：[當前情況] 已採取的措施與預計進展：[處理進展] 對用戶的建議（替代辦法、是否需要用戶操作）：[用戶建議] 發佈渠道（狀態頁、站內通知、電郵、社群、短訊）：[發佈渠道] 時區與時間格式：[時區] 請按事件類型輸出： 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 條評論
還沒有評論，來搶沙發～