AI工作交接教學:從待辦表升級成SOP、例外與決策界線
原內容日期:2026-09-01。本文為既有教學內容補發;範例依原文標示使用,實際權限與規則請以所屬組織核定資料為準。
為什麼寫了交接文件,休假時還是一直被找?
大部分交接文件只記錄工作名稱、日期及檔案位置。這些資訊可以幫人找到資料,卻不足以讓接手者做出判斷。
真正讓原工作者一直被叫回來的,通常是例外:資料沒到、數字不一致、客戶臨時改要求、系統重試仍失敗。
待辦表不是交接包
一個能執行的工作卡,至少要有觸發條件、輸入、正式來源、步驟、檢查點、輸出及完成證據。
如果只寫「星期五做周報」,接手者仍不知道星期四要向誰收資料、什麼可以引用,以及資料不完整時如何標示。
盤點固定、觸發與臨時判斷工作
固定工作通常容易想起來;事件觸發及臨時判斷卻常存在原工作者腦中。
AI可以透過訪談問題協助挖掘:你怎麼知道該開始、哪一步最容易錯、什麼情況一定不會自行決定,以及上次異常時真正有效的處理是什麼。
把「視情況」變成判斷條件
「資料有問題就視情況處理」不是可操作指示。
更好的方式是列出情況、先檢查什麼、可自行處理的範圍,以及什麼條件下必須停止或升級。
這些界線能保護接手者,也能避免代理人為了趕時間做出超出權限的承諾。
正常流程之外,還要有停止條件
異常SOP如果只寫重試、重啟或重新送出,接手者可能不斷重複操作。
應同時記錄最大嘗試次數、每次操作前要保存的資訊、不可復原的風險,以及看到哪些訊號應立即停止。
數字若沒有正式規則,應保留待確認,不能由AI自行填入。
決策界線分成三層
可自行決定的事情應有明確規則、風險低且可復原;特殊情況先諮詢;涉及範圍、成本、時程承諾、品質或客戶的事情則必須核准。
交接文件不是把責任全部丟給代理人,而是讓他知道合理權限到哪裡。
密碼不是交接資料
帳號權限可以記錄所需角色及申請方式,但密碼、API金鑰、驗證碼與私鑰不應出現在交接文件。
敏感資料應透過公司的正式權限與秘密管理機制提供,並在交接結束後檢查是否需要回收。
交接一定要實作
可以使用「我做你看、你做我看、你說我聽」三個階段。
最後再用資料缺漏、數字衝突、客戶催促、系統異常及權限不足等情境題,確認接手者是否理解判斷原則。
如果接手者答不出來,首先應檢查交接文件是否缺少資訊,而不是直接認定對方能力不足。
交接文件也需要負責人
流程、系統與人員一變,交接包就可能失效。因此文件應標示版本、最後更新日、維護角色、下次檢視時間及觸發更新條件。
好的交接不是一次性的離職手續,而是組織降低單點風險的日常能力。
結語
真正的工作交接,不是證明原工作者寫得很多,而是讓接手者知道何時開始、如何完成、遇到例外怎麼判斷,以及哪條線不能跨越。
AI可以幫忙訪談、整理與產生情境測試;正式流程、權限與責任,仍必須由真正的流程負責人確認。
逐步操作
第一步:先決定交接範圍
先寫清楚:
- 交接原因:休假、離職、輪調或備援訓練
- 起訖時間
- 接手者角色
- 原工作者是否仍可聯絡
- 緊急聯絡的條件
- 哪些工作暫停、延後或不在本次範圍
短期代理不需要接下所有長期改善計畫;離職交接則要包含歷史背景與維護責任。
第二步:盤點三種工作
不要只從行事曆找工作。至少分成:
- 固定週期: 每日、每週、每月或每季執行。
- 事件觸發: 收到客戶資料、系統告警、主管核准後才開始。
- 臨時判斷: 異常、客訴、資料不一致或跨部門協調。
交接最容易漏掉的,通常是後兩種。
第三步:先排「不做會出事」的工作
可依下列順序排序:
- 法規、品質、資安、人身安全
- 客戶、付款、出貨、正式里程碑
- 會阻擋其他人的前置工作
- 有固定期限的例行工作
- 可延後的整理與改善
不要讓AI自行判定風險等級;請提供業務影響與現有規則。
第四步:讓AI用訪談方式挖出默會知識
請AI逐項追問:
- 你怎麼知道該開始了?
- 完成後長什麼樣子?
- 哪一步最容易做錯?
- 你會先檢查哪三件事?
- 數字或說法衝突時,你依什麼判斷?
- 哪些事情你平常會做,但文件裡沒寫?
- 什麼情況你一定不會自己決定?
- 上次出問題時,真正有效的處理是什麼?
這一輪先收集,不急著美化文字。
第五步:每項工作使用同一張工作卡
建議欄位:
| 欄位 | 說明 |
|---|---|
| 工作名稱 | 使用動詞+交付物 |
| 觸發條件 | 何時開始,不只寫日期 |
| 頻率/期限 | 每週五、收到資料後兩天內等 |
| 輸入 | 資料、核准、範本、系統狀態 |
| 正式來源 | 哪裡的資料具有權威性 |
| 操作步驟 | 依實際順序列出 |
| 檢查點 | 哪些數字、狀態或版本必須核對 |
| 輸出 | 最終要交付什麼 |
| 完成證據 | 寄件紀錄、核准、系統狀態或檔案 |
| 例外 | 常見錯誤與處理方式 |
| 決策界線 | 可自行決定與必須升級的事情 |
第六步:把「視情況」改成判斷表
不要寫:
如果資料有問題,視情況詢問相關人員。
可以改成:
| 情況 | 先檢查 | 可自行處理 | 必須停止/升級 |
|---|---|---|---|
| 欄位空白 | 確認來源檔及前一版 | 若屬非必填欄,依規則標示 | 關鍵欄位缺漏不得自行補值 |
| 數字不一致 | 比對正式來源與基準時間 | 僅修正已確認的格式錯誤 | 涉及金額、數量或驗收需請負責角色確認 |
| 收件人催促 | 確認已核准範圍 | 回覆目前狀態 | 不可代替負責人承諾新日期或範圍 |
第七步:建立三層決策界線
- 可自行決定: 已有明確規則、低風險、可復原。
- 先諮詢再做: 規則存在,但本次情況有差異。
- 必須核准: 涉及範圍、金額、時程承諾、客戶、品質、法規或不可逆變更。
接手者需要知道的不是「你要小心」,而是哪條線不能跨過去。
第八步:寫出異常處理的停止條件
異常SOP除了處理順序,還要寫:
- 最多嘗試幾次
- 每次操作前要保存什麼
- 哪些動作可復原
- 看到什麼訊號要停止
- 何時需要通知維運、主管或供應商
- 升級時要附哪些畫面、時間、錯誤碼及已做步驟
沒有停止條件,接手者可能不斷重試,反而讓問題擴大。
第九步:建立「休假期間日曆」
依日期排列:
- 固定截止日
- 重要會議
- 預計收到的資料
- 需要主動確認的事項
- 可能出現的系統或客戶事件
- 延誤會影響的下游工作
日期若尚未確認,清楚標示暫定或待確認,不要讓AI自行補上。
第十步:建立檔案與工具入口
只提供必要資訊:
- 正式資料位置
- 範本與範例
- 操作系統或工具名稱
- 權限申請方式
- 文件負責角色
- 最後確認日期
不要將密碼、API金鑰、驗證碼、私鑰或個人帳號寫進交接文件。應使用公司的正式密碼與權限管理機制。
第十一步:讓接手者實際做一次
使用三段式驗證:
- 我做你看: 原工作者示範並說明判斷點。
- 你做我看: 接手者實際操作,原工作者只在必要時提醒。
- 你說我聽: 接手者用自己的話解釋流程、例外及升級條件。
能背出步驟,不代表遇到例外時知道怎麼辦。
第十二步:用情境題確認理解
例如:
- 關鍵資料在截止日前仍未收到,你會先做什麼?
- 報表總數與正式系統不一致時,哪一個可以修改?
- 客戶要求提前交付,但原負責人沒有確認,你能答應嗎?
- 系統重試兩次仍失敗,下一步是什麼?
答案應回到規則與權限,而不是猜原工作者會怎麼做。
第十三步:交接完成後設定維護者
文件至少標示:
- 版本
- 最後更新日期
- 維護角色
- 下次檢視時點
- 哪些變更會觸發更新
交接文件若沒有人維護,很快會變成另一份不敢相信的舊文件。
可直接複製的完整提示詞
你是一位資深知識移轉顧問、SOP設計師、專案經理與營運持續管理人員。你擅長透過結構化訪談,把原工作者腦中的默會知識整理成接手者可以實際執行的工作交接包,包含正常流程、例外處理、決策界線、升級條件、完成證據與接手驗證。
【任務】
請根據我提供的工作資料建立完整交接包。你的工作是忠實整理現有做法、正式規則與待確認事項,不得為了讓文件完整而自行發明步驟、期限、權限、聯絡人、核准規則或系統行為。
【交接基本資料】
交接原因:[休假/輪調/離職/備援訓練/其他]
交接期間:[開始日期至結束日期]
原工作者角色:[填寫]
接手者角色與熟悉程度:[填寫]
原工作者期間是否可聯絡:[是/否/僅緊急事件]
緊急聯絡條件:[填寫]
本次交接範圍:[填寫]
不在本次範圍:[填寫]
敏感資訊限制:[填寫]
【工作清單】
請使用以下格式:
工作ID|工作名稱|類型|頻率或觸發條件|期限|不完成的影響|目前負責角色|備註
類型使用:固定週期、事件觸發、臨時判斷、改善工作
[貼上工作]
【每項工作的現有做法】
工作ID|輸入資料|正式來源|操作步驟|檢查點|輸出|完成證據|常見例外|現有文件或範本
[貼上;不知道處填待確認]
【已知判斷經驗】
工作ID|情況|平常怎麼判斷|判斷依據|是否為正式規則|需要誰確認
[貼上]
【休假/交接期間事件】
日期或期間|預計事件|需要行動|延誤影響|目前狀態
[貼上]
【權限與決策】
事項|可自行決定|需先諮詢|必須核准|核准角色
[貼上;不知道處填待確認]
【工具與文件】
用途|工具或文件名稱|正式位置|所需權限|權限申請方式|維護角色|最後確認日期
[貼上]
【限制與整理規則】
1. 將資訊分類為正式規則、目前慣例、個人經驗、建議做法及待確認事項。
2. 不得把個人習慣改寫成公司正式政策。
3. 不得自行創造未提供的步驟、日期、期限、權限、責任人、核准人或聯絡方式。
4. 沒有來源的判斷標示為經驗或待確認,不得包裝成唯一正確做法。
5. 每項工作必須包含觸發條件、輸入、正式來源、步驟、檢查點、輸出及完成證據。
6. 工作名稱應使用動詞與交付物,但不得擴張原工作範圍。
7. 區分固定週期、事件觸發、臨時判斷及可延後改善工作。
8. 排序需依使用者提供的業務影響,不得自行判定法規、財務或品質風險。
9. 「視情況、確認一下、處理、追蹤」需轉成具體判斷問題;資料不足則提出待確認問題。
10. 區分正常流程、常見例外、重大異常及未知情境。
11. 例外處理需列出先檢查什麼、可自行做什麼、何時停止及向誰升級。
12. 不得建議接手者在沒有授權下變更正式資料、承諾日期、價格、範圍或驗收結果。
13. 決策界線分為可自行決定、先諮詢再做、必須核准。
14. 可自行決定的事情應具備明確規則、低風險且可復原;不符合時標示待確認。
15. 異常處理不得建議無限制重試;需保留最大嘗試次數與停止條件欄位。
16. 未提供重試次數時填[待確認],不得自行設定。
17. 完成狀態需有證據;寄出、上傳或口頭回覆不一定代表已驗收。
18. 所有日期區分已確認、暫定、希望期限與待確認。
19. 文件或連結需保留來源與最後確認日期,不得假設仍有效。
20. 不得要求將密碼、API金鑰、驗證碼、私鑰、個人帳號或完整個資寫入交接包。
21. 帳號與權限僅整理正式申請方式及角色,不顯示秘密值。
22. 涉及客戶、合約、法規、品質、資安、財務、人事或個資時,標示需由專業角色確認。
23. 情境測試應檢查流程與判斷,不對接手者進行人格或能力評價。
24. 使用繁體中文,步驟簡潔、明確、可操作。
【輸出格式】
一、交接摘要
以150字內說明交接期間、最高優先工作、重大未結事項、權限缺口及緊急聯絡條件。
二、工作地圖
| 優先序 | 工作ID | 工作 | 類型 | 觸發/頻率 | 期限 | 不完成的影響 | 接手狀態 |
三、資訊身分與待確認
| 項目 | 內容 | 身分 | 來源 | 待確認問題 |
身分使用:正式規則、目前慣例、個人經驗、建議做法、待確認。
四、工作卡
每項工作使用:
| 欄位 | 內容 |
包含目的、觸發條件、期限、輸入、正式來源、前置權限、步驟、檢查點、輸出、完成證據、常見例外、文件連結及維護角色。
五、例外處理矩陣
| 工作ID | 情況/症狀 | 先檢查 | 可自行處理 | 最大嘗試 | 停止條件 | 升級角色 | 應附資訊 |
六、決策權限表
| 事項 | 可自行決定 | 先諮詢再做 | 必須核准 | 判斷依據 | 核准角色 |
七、休假/交接期間日曆
| 日期 | 事件 | 需要行動 | 前置資料 | 完成證據 | 未完成影響 | 日期狀態 |
八、未結事項
| 事項 | 目前狀態 | 下一步 | 需要誰決定/提供 | 期限狀態 | 風險 |
九、工具與文件入口
| 用途 | 名稱 | 正式位置 | 所需權限 | 申請方式 | 維護角色 | 最後確認 |
十、接手者第一天與第一週清單
分成:先確認權限、先讀、先觀察、第一次獨立操作、需安排演練。
十一、三段式交接演練
針對高優先工作設計:我做你看、你做我看、你說我聽。
十二、情境測試題
提供10題,涵蓋資料缺漏、數字衝突、期限變更、客戶催促、系統異常、權限不足及升級判斷;每題附判斷重點,不自行創造正式答案。
十三、交接完成確認
| 項目 | 原工作者確認 | 接手者確認 | 主管/流程負責人確認 | 證據 | 待補 |
十四、文件維護資訊
列出版本、最後更新日、維護角色、下次檢視時點及觸發更新條件。
實際教學範例
工作情境
專案經理休假五天,代理人需要處理每週進度彙整,以及自動化系統偶發的遠端畫面連線異常。
只有待辦表的交接
- 星期五做周報。
- 系統有問題先重開。
- 急事找主管。
這份文件幾乎無法執行,因為沒有資料來源、完成標準、重開對象、嘗試次數與升級條件。
AI協助整理後的工作卡
工作 A:產出每週專案狀態摘要
| 欄位 | 內容 |
|---|---|
| 觸發條件 | 每週四下班前完成資料收集;星期五發布 |
| 輸入 | 各工作項目最新狀態、完成證據、阻礙及下週計畫 |
| 正式來源 | 專案追蹤表及已確認更新;聊天內容只能作線索 |
| 檢查點 | 狀態與完成證據一致;希望日期不可寫成正式承諾 |
| 輸出 | 主管摘要、完成、進行中、受阻及需決策事項 |
| 完成證據 | 已發布周報連結與收件紀錄 |
| 例外 | 關鍵資料未收到時標示待確認,不自行補進度 |
| 決策界線 | 可整理現況;不可代替負責人承諾新期限 |
工作 B:處理遠端畫面連線異常
| 項目 | 內容 |
|---|---|
| 症狀 | 自動化程序無法取得遠端設備畫面 |
| 第一檢查 | 記錄時間、設備代碼、畫面、錯誤訊息及影響範圍 |
| 處理順序 | 依已核准Runbook執行,不由AI新增重啟步驟 |
| 最大嘗試 | [待維運負責人確認] |
| 停止條件 | 影響擴大、出現不同錯誤、可能影響資料或安全時停止 |
| 完成證據 | 連線恢復、程序重新執行成功及事件紀錄 |
| 升級資訊 | 時間、設備、錯誤、已執行步驟、每步結果及目前影響 |
接手情境題
問題一: 星期四仍有兩個部門沒更新進度,能否沿用上週百分比?
判斷重點:不能把舊資料當本週事實;應標示最後確認時間、待更新狀態及對本週摘要的影響。
問題二: 客戶要求下週完成,但原負責人尚未確認資源。
判斷重點:代理人可以回覆目前狀態與確認流程,不可代替負責人接受新期限。
問題三: 系統重試後錯誤訊息改變。
判斷重點:不要繼續套用原異常流程;先停止、保存證據,依升級條件通知維運角色。
AI不能做的事
- 不可自行指定系統可重啟幾次。
- 不可把個人經驗寫成正式維運政策。
- 不可替接手者增加原本沒有的系統權限。
- 不可用預計期限取代正式承諾。
- 不可把密碼或遠端登入資訊放入交接文件。
常見錯誤、隱私與使用注意事項
工作名稱太空泛:「處理客戶、做報表」無法判斷完成。 - 只記時間,不記觸發條件: 有些工作要等資料、核准或事件發生。 - 只寫正常流程: 真正需要交接的常是例外與判斷。 - 把經驗當制度: 個人做法需標示身分及來源。 - 使用「視情況」: 應補上可觀察條件與權限界線。 - 代理人權限過大或不足: 都可能造成停工或誤決策。 - 沒寫完成證據:「已寄出」不一定代表對方已收到或驗收。 - 異常流程無限重試: 可能擴大系統或資料風險。 - 升級只寫找主管: 應寫明觸發條件及需附資訊。 - 文件連結很多,沒有先讀順序: 接手者容易迷失。 - 交接文件塞入密碼: 應使用正式權限及秘密管理機制。 - 完整個資與客戶資料貼給AI: 先去識別化並遵守公司政策。 - AI補齊空白步驟: 看起來完整,實際可能造成錯誤。 - 只做口頭說明: 應讓接手者實際操作並回述。 - 交接測試變成考績: 目的是找文件缺口,不是羞辱接手者。 - 沒有文件維護者: 流程一變,交接包就會失效。
留言