AI 危機聲明擬稿：禁止擅自道歉與承諾

01解決的工作問題

事故、服務中斷、重大客訴、資安事件或公共爭議一旦發生，公司通常要在幾十分鐘到幾小時內拿出第一版對外聲明，而這正是最容易把AI用錯的時刻。時間壓力下，把零散的事件回報丟給AI，會得到一份讀起來很完整、很有誠意的稿子——但那份完整感很危險：AI為了讓聲明像一份『像樣的聲明』，習慣自己加上道歉、把責任歸屬寫死、承諾補償、保證不再發生，甚至把技術人員都還不敢確認的『初步研判』直接寫成『原因是』。這些內容一旦被公司發布，就等於公司自己承認了責任、開出了承諾，事後想收回比什麼都難。真正該讓AI做的，是把已經查證的事實、還在調查的事、完全不知道的事三者徹底分開，並且把道歉、責任、賠償、承諾這四類真正需要策略判斷的內容整段留白，逼公關、法務、主管在發布前把『要不要道歉、道歉到什麼程度』這個問題真正攤開來討論，而不是被AI已經寫好的草稿牽著走。

02什麼時候用、什麼時候別用

什麼情況下該用這一套

• {'t': '事件已經發生，時間壓力大', 'd': '需要在短時間內把零散的事件回報整理成一份可審閱的聲明架構，而不是從空白開始寫。'}
• {'t': '已經有一份現場事實清單可以餵給AI', 'd': '哪怕不完整，只要有現場回報、客服紀錄或系統記錄，AI就能開始做三分類。'}
• {'t': '公司有法務或公關角色可以審查', 'd': '涉及道歉、責任、賠償、承諾的段落一定要有人決定並審過，這個方法不是給沒有審核角色的單位用的。'}

什麼情況下別用

完全沒有查證資訊時

沒有任何已確認事實，AI只能生出空殼或幻想細節，不如先等現場回報進來。

需要立即口頭回應媒體提問

這個方法產出的是書面聲明初稿，臨場問答需要另一層守門機制，不是同一件事。

已進入司法程序或有保險理賠爭議的事件

這類聲明每一個字都可能被引用為呈堂證供，草稿必須全程由法務主筆，AI只能做最基礎的事實整理。

想讓AI直接決定要不要道歉

這正是這個方法要擋下的事——道歉與否是公司的策略決定，不是AI的文字風格選擇。

誰會用到

公關

你是最先拿到AI草稿的人，也最容易被AI的『完整感』誤導——草稿讀起來已經很像一份聲明，但道歉、責任那幾段其實是空的，你要把它們找出來交給法務和主管決定，而不是自己順手補上。

法務

你要做的不是潤稿，是逐字比對——AI套稿時有沒有不小心改動你寫的責任歸屬用字。三分類表裡『已確認事實』欄位只要有一句其實還沒查證，這篇聲明發出去就是法律風險。

主管

最終核定是你的責任，但你要核的不是文字通不通順，是道歉的程度、賠償的承諾、責任的用字這三件事有沒有經過法務跟公關真正討論過，還是只是AI寫得順口。

所屬工作情境

04完整步驟圖的文字版，逐步展開

一句話版（快速回顧）

1. 整理事實清單：只放已經查證過的內容，未查證的另外標出，這一步決定AI能不能亂補。
2. 請AI把事實分成已確認事實、調查中、尚未確認三欄，禁止自行推論原因或補資料。
3. 請AI依三分類事實生成聲明骨架，道歉、責任歸屬、賠償承諾、保證不再發生四類段落全部留白標記需人工決定。
4. 法務、公關、主管審閱骨架，決定要不要道歉、責任怎麼寫、要不要承諾補償，並親自撰寫這些段落。
5. 請AI把人工撰寫的段落套進聲明語氣，逐字比對確認沒有更動實質意思。
6. 法務逐字覆核是否構成法律承認、公關覆核語氣與時機、主管核定發布，並排定下次更新調查進度的時間。

完整版（每一步誰做、產出什麼）

05開始前要準備什麼標「必要」的沒備齊就先別開始

事件時間軸必要

什麼時候發生、什麼時候發現、目前進度到哪，越精確越好，並註明哪些已確認、哪些只是回報。

受影響範圍的已知資訊必要

哪些客戶/用戶/地區受影響，就算只有粗估範圍也要註明是粗估。

客服或第一線回報紀錄必要

外部已經在問什麼、抱怨什麼，聲明要能對得上民眾真正關心的問題。

公司內部對外溝通的既有原則可選

例如『重大事件一律先報備法務』這類既有流程，聲明的產出方式不能跳過。

過去類似事件的聲明範本（如果有）可選

格式與慣用結構可以參考，但這次的事實內容不能套用過去的。

餵進去的東西要長這樣

事件時間軸＋受影響範圍的已知資訊＋客服/系統回報紀錄＋目前已知原因（含哪些只是初步研判）。

• 時間軸要精確到分鐘，並註明哪些是已經確認發生、哪些只是回報但還沒查證。
• 受影響範圍如果只有粗估，要明確寫『粗估』，不要寫成確定數字。
• 客服或第一線回報要附上原始說法或截圖佐證，不要用自己的話重新詮釋後再貼給AI。
• 目前已知原因如果是初步研判，提供時就要標明『初步研判』，不要等AI幫你判斷是不是確定。
• 事件資訊裡若含會員/客戶個資，先去識別化或代稱再貼給AI。

【事件時間軸】
08:14系統更新完成
08:20客服開始接到會員反映無法登入（已確認）
08:40技術團隊發現登入異常同時伴隨資料顯示錯置，2位會員提供截圖佐證（已確認，附截圖）
09:10 APP緊急下線維護（已確認）
09:50技術團隊初步排查懷疑是快取設定錯誤（初步研判，尚未100%確認）

【受影響範圍】
全台15家分店會員皆可能受登入異常影響（已確認）；實際看到他人資料的人數目前僅2件有截圖佐證，其餘範圍未知（尚未確認，不可估算）。

【客服/系統回報】
累計37通電話反映無法登入、2件資料錯置信件（附截圖）。

【目前已知原因】
技術主管初步研判與本次更新的快取設定有關，尚未查完log，無法100%確認（初步研判）。

06Prompt（快速／完整／進階）

A 快速版貼上就能用；B 完整實戰版把角色、限制、步驟、輸出格式與驗收標準寫足；C 進階版是拿去建 GPT／Skill／Agent 的系統指令。三種都附可替換變數、使用範例、預期輸出與人工確認點。

以下是這起事件目前掌握的所有資訊（時間軸、受影響範圍、客服/系統回報、目前已知原因），請幫我整理成危機聲明的第一版骨架：
1. 把每一條資訊分類為【已確認事實】【調查中】【尚未確認】三欄，任何你自己推論出來、清單裡沒有直接依據的內容一律不能算已確認事實。
2. 依三分類事實寫出聲明架構：事件時間軸、目前受影響範圍、已採取的處理措施、下一次更新調查進度的時間。
3. 以下四類內容一律不要自己寫，直接留白並標記【需人工決定：由法務/公關/主管撰寫】——道歉語句、責任歸屬的用字、賠償或補償的承諾、保證不再發生的承諾。
4. 任何數字（受影響人數、金額、修復時間）如果清單裡沒有明確依據，不要自己估算，寫「範圍尚在盤點」。
規則：不確定就標【尚未確認】，不要為了聲明讀起來完整就幫我補內容。
事件資訊：{貼上}

事件資訊：
- 08:14 系統更新完成後，客服開始接到會員反映APP無法登入，測試後確認全台15家分店的會員都受影響。
- 08:40 技術團隊發現登入異常同時伴隨資料顯示錯置——部分會員反映登入後看到別人的預約紀錄，還有一位會員在客服信箱附上截圖，顯示對方的姓名與手機末三碼。
- 09:10 技術團隊將APP緊急下線維護。
- 09:50 內部初步排查懷疑是這次更新的快取設定錯誤造成資料錯置，但技術主管表示還沒有辦法100%確認，需要再查log。
- 目前累計客服接到37通反映無法登入的電話，以及2件反映看到他人資料的信件（附截圖）。
- 全台會員總數約8萬人，但目前無法確定實際看到他人資料的人數，技術團隊還在查。
- APP預計中午12點前恢復，但尚未100%確定。
請依照剛剛的規則，整理成危機聲明骨架。

【三分類事實表】
已確認事實：
- 08:14系統更新後，APP出現全台15家分店會員登入異常。
- 08:40部分會員反映登入後看到其他會員的預約紀錄，其中2件經客服取得截圖佐證，顯示對方姓名與手機末三碼。
- 09:10 APP已緊急下線維護。
- 目前累計客服接獲37通登入異常電話、2件資料錯置信件（含截圖）。

調查中：
- 技術團隊初步排查，懷疑是本次更新的快取設定錯誤造成資料錯置，但技術主管尚未100%確認，需要再查log。→ 這是初步研判，不能寫成確定原因。
- APP預計中午12點前恢復，但尚未確定是否能如期。

尚未確認：
- 實際看到他人資料的會員人數（目前只有2件有截圖佐證，但快取問題若屬實，受影響範圍可能更廣）。
- 是否有會員資料被下載或外流到APP畫面以外的地方。

【聲明骨架初稿】
一、事件說明（已確認事實）
今日（日期）8點14分系統更新後，部分會員反映APP登入異常，並有會員反映在登入後看到其他會員的部分資訊。我們已於8點40分起緊急處理，並在9點10分將APP下線維護。

二、目前掌握範圍
目前已知全台15家分店的會員都可能受到登入異常影響；部分會員反映的資料顯示問題，目前已知2件並附有截圖佐證，實際影響範圍仍在盤點中。

三、原因與處理進度【調查中，措辭需保留彈性】
初步排查方向與本次系統更新有關，實際原因仍在確認，預計（需人工決定：填入實際可承諾的時間）前更新調查結果。

四、【需人工決定：由法務/公關/主管撰寫】
- 是否道歉、道歉語句
- 責任歸屬的用字（是否使用『疏失』等字眼）
- 是否承諾補償或後續保護措施
- 是否承諾不再發生

五、下一步
APP恢復時間、下一次更新調查進度的時間點（需人工確認後填入）。

【樣本不足/需人工決定的部分】
- 受影響會員實際人數無法從目前資訊推算，不可自行估算填入。
- 原因尚未100%確認，骨架中已保留為【調查中】用語，不可寫成定論。
- 道歉、責任、賠償、承諾不再發生四類段落全部留白，等待法務/公關/主管決定。

以下是聲明骨架初稿，以及法務/公關/主管已經寫好的道歉、責任、賠償/補償、承諾相關段落。請做套稿與比對：

1.【套稿】把人工撰寫的段落套進骨架對應位置，只調整語氣與段落銜接的用字，不得更動這些段落的實質意思、責任強度、承諾範圍。
2.【逐字比對】列出你在套稿過程中，對人工撰寫段落做了哪些用字調整，每一處都要說明『調整前』與『調整後』，方便法務逐一核對有沒有不小心改變責任強度。
3.【一致性檢查】檢查全篇有沒有出現骨架裡本來標記【尚未確認】的內容，卻在人工段落或你自己套稿時被講成確定的原因或事實。
4.【禁止事項自我檢查】確認你自己沒有額外加入任何道歉、責任、賠償或承諾的句子——這些內容應該全部來自人工提供的段落，不是你生成的。
5.【風險提示】指出全篇有哪幾句話讀起來可能被解讀為『承認法律責任』，即使字面上沒有直接說『我們的錯』。

規則：
- 不得因為語氣需要就加重或減輕人工撰寫段落的責任強度。
- 不得把【調查中】【尚未確認】的內容改寫成確定語氣。
- 發現骨架與人工段落有矛盾（例如骨架寫『原因調查中』，但道歉段落卻寫『已知是我們的疏失』），要明確指出，不要自己選一個版本。

聲明骨架：{貼上}｜人工撰寫的道歉/責任/賠償段落：{貼上}

（貼上骨架初稿，並附上法務公關主管寫好的段落，例如：『我們對此次會員資料顯示異常造成的困擾，鄭重致歉。初步了解與本次系統更新的快取設定有關，我們已於9點10分將服務暫停，全面排查。我們將於今日下午5點前公布完整調查結果與後續保護會員資料的具體措施。』）

【套稿後全稿】（節錄第三、四段）
三、原因與處理進度
初步了解與本次系統更新的快取設定有關，我們已於9點10分將服務暫停，全面排查，預計今日下午5點前公布完整調查結果。

四、致歉與後續說明
我們對此次會員資料顯示異常造成的困擾，鄭重致歉。我們將於下午5點前一併公布後續保護會員資料的具體措施。

【逐字比對】
- 骨架原句：『原因與處理進度【調查中，措辭需保留彈性】』→套稿後：『初步了解與本次系統更新的快取設定有關』。這是直接採用你提供的段落原文，我沒有額外調整用字。
- 你提供的道歉段落原文與套稿後完全一致，我只調整了段落標題（『四、致歉與後續說明』），內文逐字未動。

【一致性檢查——發現矛盾，已標出不擅自選擇】
⚠骨架第三節原本標記【調查中】，但你提供的道歉段落開頭寫『初步了解與本次系統更新的快取設定有關』——這句話讀起來介於『調查中』與『已確認原因』之間。若技術團隊還沒100%確認，建議法務確認『初步了解』這個用語是否已經是公司願意承擔的表述強度，還是要再保留更多彈性（例如改成『相關因素仍在確認』）。我沒有自行修改，因為責任強度的拿捏屬於你們的決定範圍。

【自我檢查——我沒有額外加入的內容】
本次套稿沒有新增任何道歉、責任或承諾語句，全篇道歉與致歉相關文字均逐字來自你提供的段落。

【風險提示】
1. 『我們對此次……造成的困擾，鄭重致歉』這句雖未直接說『我們的錯』，但搭配下一句『初步了解與本次系統更新的快取設定有關』放在一起讀，可能被解讀為公司已經承認原因與自身操作有關，建議法務確認這個組合是否是你們要的責任承擔程度。
2. 『下午5點前公布完整調查結果』是一個具體承諾時間，若5點無法如期公布，會變成第二個信任問題，建議公關確認這個時間點是否保留了緩衝。

請把以下危機聲明的三分類規則與四類禁止內容，寫成一份可以直接建立成常駐審核助手的系統指令。

【系統指令要包含】
1. 角色與任務：只負責把事件資訊整理成三分類事實表與聲明骨架，不負責、也不得決定要不要道歉、責任怎麼寫、要不要承諾補償。
2. 三分類規則：已確認事實（有明確來源依據）／調查中（有初步研判但未100%確認，必須保留『初步』『研判』等用語）／尚未確認（沒有依據，一律留白或寫『尚在盤點』）。
3. 四類一律禁止自行生成、必須留白標記【需人工決定：由法務/公關/主管撰寫】的內容：道歉語句、責任歸屬用字、賠償或補償承諾、保證不再發生的承諾。
4. 數字規則：受影響人數、金額、修復時間等，沒有明確依據不得估算，一律寫『範圍尚在盤點，預計X時前更新』。
5. 套稿規則：人工撰寫的道歉/責任/賠償段落交回AI套稿時，只能調整語氣與銜接用字，並且要輸出『調整前/調整後』對照表，不得更動實質意思。
6. 使用者若要求『幫我寫一段道歉』『幫我決定要不要賠償』，一律回報婉拒，說明這是需要法務/公關/主管決定的內容，並提示使用者去找誰決定。
7. 輸出格式：三分類事實表＋聲明骨架（含留白標記）＋【需人工決定】清單＋尚未確認事項清單。

【另外請給我】
(a) 一份『使用說明』，寫給值班公關/法務第一次用這個助手看，含三個好例子與三個壞例子。
(b) 一份『事件分級對照』：什麼規模的事件（例如受影響人數門檻、是否涉及個資）一定要拉法務進來，不能只靠公關單獨核定。

三分類規則與四類禁止內容（依前述）：{貼上}｜公司既有的對外溝通流程規範（如有）：{貼上}

（貼上前述三分類規則與四類禁止內容，並附上公司既有規範，例如『受影響會員逾500人或涉及個資外洩，一律先報法務，公關不得單獨核定發布』）

【常駐危機聲明審核助手 系統指令】

一、你的角色
你是本單位的危機聲明草擬助手。你只負責把事件資訊整理成三分類事實表與聲明骨架，你不決定、也不生成任何道歉、責任歸屬、賠償或承諾不再發生的內容——這些一律屬於法務/公關/主管的決定範圍。

二、三分類規則
已確認事實：有明確來源依據（現場回報、系統記錄、客服紀錄）才能放進這一欄。
調查中：有初步研判但技術/相關單位尚未100%確認，必須保留『初步』『研判』『初步了解』等用語，不得寫成定論。
尚未確認：沒有依據的一律留白或寫『尚在盤點』，不得推估。

三、四類一律禁止自行生成的內容
道歉語句／責任歸屬用字／賠償或補償承諾／保證不再發生的承諾。以上四類全部留白並標記【需人工決定：由法務/公關/主管撰寫】。

四、數字規則
受影響人數、金額、修復時間沒有明確依據時，一律寫『範圍尚在盤點，預計X時前更新』，不得自行估算。

五、套稿規則
交回你套稿時，只能調整語氣與段落銜接，並且必須附上『調整前/調整後』對照表，任何實質意思、責任強度、承諾範圍不得更動。

六、遇到使用者要求你越權時
若使用者要求『幫我寫道歉』『幫我決定要不要賠償』，回覆：『這部分需要法務/公關/主管決定，我可以先幫你列出這段需要決定的具體問題，但不能替你寫答案。』並列出需要決定的具體問題清單。

七、輸出格式
【三分類事實表】【聲明骨架（含留白標記）】【需人工決定清單】【尚未確認事項清單】

──────────
【使用說明（給第一次用的值班公關/法務看）】

這個助手做什麼：把零散的事件回報整理成三分類事實表跟聲明骨架，幫你省下手動分類跟排版的時間。
這個助手不做什麼：幫你決定要不要道歉、責任怎麼寫、要不要賠償——這些永遠要你自己或主管決定。

好例子：
1. 貼上目前所有已知的事件回報，請它整理成三分類事實表。
2. 骨架完成後，貼上你已經寫好的道歉段落，請它套稿並列出調整前後對照表。
3. 詢問『這段話讀起來會不會被解讀成承認法律責任』，請它做風險提示。

壞例子：
1.『幫我寫一段誠懇一點的道歉』——它不會生成，只會列出需要你決定的問題。
2.『反正原因八九不離十，你直接寫成確定原因』——它會拒絕，調查中的內容就是調查中。
3.『受影響人數抓個大概數字給我』——它不會估算，只會寫『尚在盤點』。

【事件分級對照】
- 受影響人數低於50人且不涉及個資：公關可先行擬稿，主管核定即可發布。
- 受影響人數50人以上，或涉及個資、資安：一律先拉法務進來，法務未覆核不得發布。
- 涉及媒體已經報導或社群大量轉發：主管、法務、公關三方必須共同核定，不得單一角色決定發布。

07產出應該長什麼樣拿到的東西要長這樣

三分類事實表（已確認事實/調查中/尚未確認）＋聲明骨架（時間軸/影響範圍/處理進度/下次更新時間）＋道歉/責任/賠償/承諾段落全部留白標記【需人工決定】。

完成品：同一批事件資訊的兩種聲明骨架：有沒有強制留白道歉與責任段落

【沒有要求留白】
AI產出（節錄）：
『我們對此次會員APP發生的異常狀況，造成您的不便，我們深感抱歉。經初步了解，是本次系統更新的快取設定出現問題所致，我們已於第一時間著手排查並下線維護。我們保證會全面檢討相關流程，避免類似事件再次發生，並將對受影響的會員提供適當補償。』

→ 讀起來很像一份完整、有誠意的聲明。問題是：
→『深感抱歉』『保證』『適當補償』全部是AI自己加的，公司內部根本還沒有人討論過要不要道歉、要不要賠償。
→『是本次系統更新的快取設定出現問題所致』把技術主管都還不敢打包票的『初步研判』，直接寫成了確定原因。
→ 這份稿子如果被公關誤以為『已經很完整』直接送審甚至誤發，法務要面對的是一份已經自己承認責任、還承諾賠償的聲明。

【強制留白道歉與責任段落】
AI產出（節錄）：
『一、事件說明（已確認事實）
今日8點14分系統更新後，部分會員反映APP登入異常……

三、原因與處理進度【調查中】
初步研判與本次系統更新有關，實際原因仍在確認中，預計（需人工決定：填入可承諾的時間）前更新調查結果。

四、【需人工決定：由法務/公關/主管撰寫】
- 是否道歉、道歉語句
- 責任歸屬的用字
- 是否承諾補償
- 是否承諾不再發生』

→ 骨架讀起來『不完整』，但那個不完整是故意的——它逼公司在發布前把四個決定攤開來討論。
→『調查中』保留了『初步研判』的措辭彈性，沒有把還沒查完的事講死。
→ 法務跟主管拿到的是一份可以直接填空核定的骨架，而不是一份要從『已經寫好的道歉』倒回去砍的稿子。

【差別在哪】
第一種在幫公司把話說滿，第二種在幫公司把問題攤開。話說滿了收不回來，問題攤開了才有得選。

【三分類事實表】
已確認事實：08:14系統更新後全台15家分店會員登入異常；2件資料錯置經截圖佐證；APP已於09:10下線維護。
調查中：初步研判與快取設定有關，尚未100%確認；預計中午12點前恢復，尚未確定。
尚未確認：實際受影響人數；是否有資料外流到APP畫面以外。

【聲明骨架】
一、事件說明（已確認事實）
二、目前掌握範圍（已確認+調查中，語氣保留彈性）
三、原因與處理進度【調查中】
四、【需人工決定：道歉/責任/賠償/承諾，由法務公關主管撰寫】
五、下一步更新時間（待填）

08工具怎麼挑

這幾支都做得到——差別在你手上有哪一支、資料能不能外流。標「起手」的是不知道從哪支開始時的建議，不是限定。

09會卡住與會做錯的地方

會卡住的地方（流程困難點）

AI自動加道歉

為了讓聲明讀起來有禮貌、有溫度，AI常常自己加上『我們深感抱歉』『造成不便敬請見諒』，這其實是在幫公司承認責任，必須由法務公關決定，不能讓AI代勞。

把研判寫成定論

AI習慣把『初步研判』『可能原因』直接寫成『原因是……』，讀者看不出這是推測還是已查證的事實。

自行補數字

受影響人數、金額損失、修復時間如果資料不齊，AI會自己抓一個聽起來合理的數字填上去，那個數字一旦被引用出去，就變成公司自己講的官方數字，收不回來。

自動承諾不再發生

『我們保證不再發生類似事件』這句話讀起來很負責任，但沒有查完原因前根本無法保證，講了等於給自己埋未來的地雷。

會做錯的地方（常見失敗方式）

其他注意事項

• AI為了讓聲明讀起來完整、有誠意，會自己加上道歉句或保證不再發生的承諾——這些必須留白讓人決定。
• 把技術人員的初步研判直接寫成確定原因，讀者看不出這是還在查證。
• 受影響人數或金額沒有依據時自行估算填上，一旦被引用就收不回來。

10人工把關與安全限制

AI／Agent／Tool 介入在哪幾步

這幾關不下放

道歉與否、道歉到什麼程度

由公關與法務共同決定，AI不得替公司決定要不要道歉。

責任歸屬怎麼寫

涉及法律責任認定，法務必須逐字審查每一句是否構成承認過失。

賠償／補償的承諾

金額、範圍、方式屬於商業與法律決策，AI不得自行生成任何補償承諾。

哪些事實已經確認、哪些還在調查

由現場負責人與調查小組認定，AI只能整理不能判定。

發布時機與版本核定

主管最終核定，確保聲明與其他對外溝通（客服話術、股東說明）口徑一致。

安全與權限限制

事實清單裡的個資

受影響用戶名單、聯絡方式、內部通報信件在貼給AI前先去識別化或代稱。

尚未對外公開的調查細節

內部調查小組的初步發現如果還沒決定要不要公開，不要整段貼進AI對話，避免外洩到聊天記錄或第三方服務。

共用審核助手的存取範圍

如果做成custom GPT常駐助手，存取權限只開放給真正需要草擬聲明的公關/法務/主管，不要開放全公司。

聲明外流的風險

草稿在審核完成前，不要透過一般外部雲端連結分享，避免提前外流變成『內部草稿版』被誤認為正式聲明。

11Checklist 與驗收標準

做的時候逐項打勾

• 已確認事實、調查中、尚未確認三欄清楚區分，沒有混寫
• 道歉、責任歸屬、賠償補償、承諾不再發生四類內容全部由人工撰寫
• 沒有依據的數字一律寫尚在盤點，不是估算值
• 法務已逐字覆核責任用字，公關已確認語氣與發布時機
• 已排定下一次更新調查進度的時間點
• 涉及個資的部分已去識別化

做完了才檢查：全部成立才算完成

1. 已確認事實、調查中、尚未確認三欄有清楚區分，沒有混在一起寫。
2. 道歉、責任歸屬、賠償／補償、承諾不再發生四類內容全部由人工撰寫，沒有一句是AI自己生成的。
3. 所有數字（人數、金額、時間）有來源依據，沒有查證的一律寫『尚在盤點』而不是估算值。
4. 法務已逐字覆核責任相關用字，公關已確認語氣與發布時機。
5. 聲明中已排定下一次更新調查進度的時間點。
6. 事件涉及個資的部分已去識別化或代稱。
7. 主管已核定發布版本，且與客服話術等其他對外溝通口徑一致。
8. 若做成常駐審核助手，存取範圍已限縮到需要的角色。

12實際案例

13相關方法與下一步

可直接使用RELATED PROMPTS