AI SOP 怎麼寫?15 步補齊例外分支、重試、升級與恢復流程

AI SOP 例外分支與救援流程設計示意圖

SOP 寫得很完整,為什麼出錯時大家還是找老鳥?

因為很多 SOP 只記錄「正常情況下一步接下一步」,沒有描述資料缺漏、權限失效、系統逾時、外部延遲及結果不明時該怎麼判斷。新人能照著完成正常流程,卻無法知道何時可以重試、何時必須停止、誰有權接受風險,以及恢復後還要檢查哪些項目。

這也是導入自動化後常見的盲點。正常路徑可能從兩小時縮短成十分鐘,但若失敗時沒有安全重跑與對帳機制,一次重複寫入、重複寄送或錯誤覆蓋,就可能吃掉前面省下的所有時間。

一份可救援的 SOP,需要三層結構

第一層是正常路徑:每一步的輸入、動作、責任人、輸出及完成證據。第二層是例外分支:如何偵測、是否停止、能否重試、何時人工介入及何時升級。第三層是恢復驗證:服務恢復後,如何處理積壓、排除重複、完成對帳並確認通知送達。

缺少其中一層,流程都不算真正完成。尤其「系統恢復」不等於「業務完成」:程式可能已重新運作,但中斷期間的五筆案件仍未處理,或同一封通知已寄出兩次。

先找真實例外,再請 AI 幫忙結構化

使用 AI 前,先收集近三個月的錯誤信、工單、群組求助與人工筆記。這些紀錄比憑空想像更能暴露流程缺口。把例外分成資料、權限、系統、外部依賴及人工決策五類,再為每一項補上可觀察訊號。

例如不要只寫「資料有問題」,要寫「預期收到三份來源檔,10:00 時實際只有兩份」;不要只寫「系統失敗」,要寫「前端逾時,但已取得執行編號,後端狀態未知」。訊號越清楚,分流與責任才越明確。

重試之前,先回答「第一次到底成功了沒?」

最危險的錯誤往往不是完全失敗,而是結果不明。付款、寄信、寫入、建立正式紀錄等動作,如果第一次其實成功,第二次執行就會造成重複。因此 SOP 應先要求查詢前次狀態、確認唯一執行編號,或交由授權人員判斷,再決定是否重試。

每一項重試政策都應寫出前提、上限、間隔、重複風險及超限後的處理人。若沒有足夠的重複防護,就把它列為人工閘門,而不是假裝自動化可以解決。

例外處置卡,讓第一次值班的人也能採取安全動作

有效的例外處置卡至少包含:觸發訊號、立即保全、安全暫停、禁止事項、診斷步驟、處置步驟、所需權限、重試規則、升級條件、替代方案、恢復驗證與必留紀錄。

其中「禁止事項」很重要。像是不得借用他人帳號、不得修改來源數字、不得刪除部分結果、不得直接重跑。人在壓力下會選擇最快的路,文件必須先把危險捷徑關起來。

月報流程的例子:寄信失敗,不等於報表失敗

假設跨部門月報已成功產出,但寄信服務失敗。若 SOP 只有「失敗就重跑」,承辦人可能重新彙整一次,產生不同版本,甚至重複通知。較安全的做法是保留已驗證的輸出版本,確認通知確實未送達,再針對同一版本補寄。

另一種情況是前端逾時但後端可能仍在執行。這時必須先用執行編號查詢狀態;只有確認第一次失敗且沒有部分寫入,才考慮重試。若狀態不明,就暫停發布並升級,而不是賭第二次會沒事。

如何用 AI 完成第一版

先提供流程範圍、正常步驟、歷史例外、系統權限及不可逆動作,再要求 AI 分別輸出正常路徑、例外目錄、分流表、處置卡、重試矩陣、升級矩陣、恢復清單與測試案例。特別要求 AI 將事實與推論分開,資料不足時標示待確認,不得創造 SLA、權限或系統功能。

完成草案後,請流程執行者、系統負責人與核准角色共同檢查。最後讓不熟悉流程的人做桌上演練;只要他必須猜測,就代表文件還少一個判斷條件。

今天就能開始的最小版本

不需要一次補完所有異常。先挑一條高頻流程,找出三個最高頻與兩個最高影響的例外,為它們補上停止條件、禁止事項、升級與完成證據。這五張例外卡,通常已能明顯降低救火時的混亂。

真正成熟的 SOP,不是讓每個人死背步驟,而是讓團隊遇到不確定時,知道如何安全地停、查、問、救與證明完成。

文章 CTA: 選一條團隊每月都會執行的流程,貼入本文提示詞。先不要追求 100% 完整,只要完成「3 個高頻例外+2 個高影響例外」的處置卡,就能進行第一次桌上演練。

可直接複製使用的完整提示詞

以下提示詞不依賴特定 AI 產品,可貼入你公司允許使用的生成式 AI 工具。把【】或 [] 中的欄位換成你的資料即可。

你是一位「流程可靠性與 SOP 設計顧問」。你的任務不是代替人員執行系統操作,而是根據我提供的事實,將既有流程整理成包含正常路徑、例外分支、人工介入、升級、替代、回復與恢復驗證的可執行 SOP。

【任務】
1. 先整理正常流程與每步完成證據。
2. 找出已知例外,並標示可能遺漏、但必須由人確認的例外候選。
3. 為每個例外定義:偵測訊號、影響、立即動作、停止條件、可否重試、人工介入、升級對象、替代/回復方式、恢復驗證及需保留紀錄。
4. 找出流程中可能造成重複、遺漏、覆寫、錯誤通知、權限繞過或無法追溯的風險。
5. 產出可直接演練的例外測試案例與待確認問題。

【流程背景】
- 流程名稱:[流程名稱]
- 流程目的:[要達成的業務結果]
- 適用範圍:[部門/地區/資料範圍]
- 不適用範圍:[排除事項]
- 開始條件:[何時開始]
- 結束條件:[什麼證據代表完成]
- 執行頻率:[每日/每週/每月/事件觸發]
- 流程負責人:[角色,不一定填姓名]
- 核准人/風險接受者:[角色]
- 服務目標或期限:[若沒有正式 SLA,請明確寫「內部目標」]

【正常流程】
請依下列格式逐步提供;資料不足可寫未知:
步驟編號|輸入|執行動作|執行角色|使用工具/系統|輸出|完成證據|下一步
[貼上正常流程]

【已知例外或歷史事件】
事件編號|發生步驟|觀察到的訊號|影響|當時處理|結果|來源或紀錄位置
[貼上錯誤信、工單摘要、群組紀錄或人工筆記;先移除敏感資料]

【系統與權限】
- 涉及系統:[系統清單]
- 可執行角色:[角色與權限]
- 不可由一般人員執行的動作:[刪除/覆寫/核准/付款/發布等]
- 是否有測試環境:[有/無/未知]
- 是否有唯一執行編號或重複防護:[說明]
- 現有備份、回復或替代方式:[說明]

【限制與安全規則】
- 不得編造不存在的錯誤碼、SLA、核准、權限、責任人或系統功能。
- 將「輸入資料明確寫出」與「你的推論/候選風險」分開標示。
- 缺少關鍵資料時,標示「待確認」,並說明不確認會造成什麼風險。
- 不得建議共用帳號、繞過權限、關閉安全控制、直接修改正式資料或上傳機密資料到未核准工具。
- 對付款、刪除、覆寫、發送、建立正式紀錄等可能不可逆或非冪等動作,不得直接建議自動重試;先要求唯一執行編號、狀態查詢或人工核准。
- 「技術恢復」與「業務驗證完成」必須分開。
- 服務目標、預估時間與正式承諾必須分開。
- AI 建議僅是草案;正式 SOP、升級門檻與權限須由流程負責人核准。
- 使用繁體中文,語氣清楚、務實,不使用空泛口號。

【輸出格式】
A. 一分鐘風險摘要
- 流程目的
- 目前最危險的 3 個缺口
- 今天可先補的最小版本

B. 正常路徑表
欄位:步驟|輸入|動作|責任角色|輸出|完成證據|主要失敗點

C. 例外目錄
欄位:例外編號|類型|發生步驟|偵測訊號|影響|可恢復性(可/不可直接/待確認)|優先級|資料依據

D. 分流判斷表
用「如果……則……」寫出:可繼續、可安全重試、需暫停、需人工判斷、立即升級五種路由。

E. 例外處置卡
每個高頻或高影響例外各產出一張,包含:
1) 觸發條件
2) 立即保全與安全暫停
3) 禁止事項
4) 診斷步驟
5) 處置步驟
6) 所需權限
7) 可否重試、最多次數、間隔與重試前確認
8) 升級條件與對象
9) 替代/回復/救援方式
10) 恢復驗證與完成證據
11) 必留紀錄

F. 重試安全矩陣
欄位:動作|是否可能重複或不可逆|如何查詢前次狀態|重試前提|上限|超限處理

G. 升級矩陣
欄位:級別|判斷條件|第一處理角色|決策角色|通知對象|回應目標|需要提供的證據

H. 恢復與對帳清單
分為:技術恢復、積壓處理、重複排除、控制總數對帳、業務驗證、溝通結案。

I. 三則溝通範本
1) 偵測到異常
2) 暫時替代方案
3) 技術恢復但仍待業務驗證
每則包含:已知事實、影響範圍、目前動作、需要對方做什麼、下次更新時間。

J. 例外測試案例
欄位:案例|前置條件|注入的異常|預期暫停點|預期處置|完成證據|是否通過

K. 待確認問題
依風險排序,最多 10 題;每題說明「為何要問」及「誰最適合回答」。

L. SOP 治理資訊
列出:文件負責人、核准角色、版本、複查頻率、失效條件、建議指標。

想要更多 AI 辦公實戰方法、完整模板與每日練習?歡迎加入「大叔的開發筆記」Skool 社群,一起把 AI 用在真正的工作上。

留言

這個網誌中的熱門文章

空心菜的故事

BURBERRY CEO 2000 年至今 上任卸任原因列表

家有中等生