AI 工作交接教學：從檔案清單到可執行、可驗收的交接包

原內容日期：2026-09-28。本文為既有教學內容補發；範例依原文標示使用，實際權限與規則請以所屬組織核定資料為準。

文件都給了，為什麼接手者還是不會做？

很多人準備交接時，第一件事是整理資料夾、列出檔名，再把連結寄給接手者。結果接手後，對方仍然每天來問：哪一份是最新版？這件事決定了嗎？對方沒回要找誰？做到什麼程度才算完成？

原因很簡單：檔案只是資訊載體，不是工作本身。

真正的工作還包含狀態判斷、決策脈絡、外部依賴、例外處理、溝通節奏與權限邊界。如果這些內容只存在於原負責人的記憶裡，再完整的檔案清單也無法讓人獨立接手。

生成式 AI 很適合協助整理分散資訊，但要避免另一個陷阱：它可能把缺少的內容補成「合理故事」。因此，好用的 AI 交接流程必須同時做到兩件事——整理已知資訊，並誠實標示未知。

一、先決定這次交接要交到什麼程度

短期請假代理與永久職務移交，需要的內容不同。短期代理重點是近期任務、例外與緊急聯絡；長期移交則需要完整的決策台帳、權限、例行工作、資料歸屬與撤銷安排。

先寫清楚交接生效日、共同工作時間、納入與不納入範圍，以及交接後是否仍能詢問原負責人。這些條件會直接影響知識移轉的優先順序。

二、盤點工作，而不只是盤點文件

完整交接至少涵蓋五類內容：專案與交付物、例行營運、進行中與等待中事項、決策與核准，以及隱形協調與例外處理。

「每週寄報表」只是任務名稱。接手者還需要知道資料從哪裡來、何時截止、要檢查什麼、寄給誰、失敗時如何處理，以及假日誰代理。

可請 AI 根據任務表、會議紀錄與聊天摘要，找出反覆出現卻沒有被列入正式流程的工作。但 AI 找到的內容應標示來源，個人習慣也不能自動變成公司規定。

三、用證據描述狀態

「快完成」「差不多」「對方知道」都是交接風險。建議將狀態固定為：已完成且驗證、已完成待驗證、進行中、等待外部輸入、阻塞、尚未開始與取消。

每個狀態都要附證據。例如，功能完成的證據可能是測試通過紀錄；決策完成的證據可能是決策者確認的會議紀錄；文件交付則需要可開啟的正式版本。

這能避免接手者把「已經寫完但尚未核准」誤認為正式生效。

四、待辦要寫成交付物

「跟供應商確認」不是完整待辦。較好的寫法是：「取得供應商確認的通訊參數與 I/O 位址表，完成三項測試指令並保存結果；若星期三前未取得，依升級路徑通知專案負責人。」

每項待辦至少要有交付物、負責角色、期限、依賴、完成證據與未完成影響。這樣接手者才知道下一步，而不是只知道曾經發生過什麼。

五、保留決策的有效範圍

交接最常見的失真，是把「曾討論」寫成「已決定」，或把階段性決定寫成永久原則。

決策台帳應保留決策題、結論、決策者、日期、證據、適用範圍、附帶條件與重開條件。以「本階段不納入 GPU」為例，它不等於「產品永遠不支援 GPU」。

AI 可以協助比對不同文件中的說法，但遇到衝突時，應同時列出並要求人工確認，而不是自行挑一個看起來最新的答案。

六、把正常流程以外的世界寫進來

新手最需要的往往不是正常操作，而是例外處理。當資料延遲、系統錯誤、窗口不回、權限不足或輸入格式不符時，應先檢查什麼？哪些處置是安全且可逆的？什麼事情超出接手者權限，必須升級？

例外處理卡可以用固定句型：當某個訊號出現，先檢查哪些項目；若條件成立，採取哪個安全行動；若超出權限，通知哪個角色，不得自行做什麼。

七、權限交接不是分享密碼

交接文件應列出所需系統、權限用途、最小必要層級、申請入口、核准角色、測試方法與舊人員撤銷日。不要把密碼、驗證碼、API 金鑰或私人帳號放進 AI，也不要透過一般交接文件傳遞。

權限拿到了也不代表能用。接手者應實際登入、執行最低風險的測試動作，確認角色與資料範圍正確。

八、用反向操作驗收，不要用「看完了嗎」驗收

好的知識移轉包含兩輪：原負責人操作、接手者觀察；接著由接手者實際操作，原負責人只觀察。

反向操作應包含一個正常任務與一個例外題。驗收重點不是記住所有步驟，而是能找到正式來源、辨識權限邊界、完成產出，並在超出能力時走正確的升級路徑。

交接完成的真正標準

交接文件寄出，只代表資料已傳送。真正完成要等到接手者取得權限、找到正確版本、理解近期依賴、完成關鍵操作，並由驗收者確認未完成項目已有處置方式。

下次準備交接時，不妨用一句話檢查品質：如果原負責人明天無法聯絡，接手者能不能完成下一個關鍵任務、處理常見例外，並知道什麼時候不能自行決定？

如果答案仍不確定，你缺的可能不是更多文件，而是狀態證據、決策脈絡與一次真正的反向演練。

行動呼籲

今天先挑一項只有你最熟的工作，請 AI 幫你整理成四張卡：正式來源、下一個交付物、常見例外、升級邊界。再請同事不問你，照著卡片完成一次。卡住的地方，就是最值得補強的交接缺口。

逐步操作

第 1 步：先定義交接類型與時間邊界

交接類型會決定內容深度：

• 短期代理：重點是近期任務、例外與緊急聯絡。
• 長期移交：需要完整決策脈絡、權限、例行工作與風險。
• 專案階段移交：重點是輸入、輸出、驗收條件與責任切點。
• 離職交接：還需加入帳號撤銷、資料歸屬與知識保存。

先明確記錄：交接生效日、可共同工作的時間、交接範圍，以及交接後原負責人是否仍能提供支援。

第 2 步：盤點工作，不要只盤點文件

用五個面向列出工作：

1. 專案與交付物
2. 例行營運
3. 待辦與等待中事項
4. 決策與核准
5. 隱形協調與例外處理

每一項至少填寫名稱、目的、頻率、投入時間、使用系統、主要窗口與不執行的後果。

第 3 步：建立「唯一可信來源」地圖

不要只貼資料夾連結。每個重要主題應標示：

• 正式來源在哪裡
• 文件名稱與版本或更新日期
• 文件負責人
• 哪些舊檔已失效
• 哪些資訊只存在於聊天或個人筆記
• 發生衝突時，以哪一份為準

AI 可以比對內容矛盾，但不能自行宣布哪份文件正式有效。

第 4 步：用證據標示目前狀態

建議使用以下狀態：

• 已完成且已驗證
• 已完成、待驗證
• 進行中
• 等待外部輸入
• 阻塞
• 尚未開始
• 已取消

每個狀態都要附證據，例如測試紀錄、核准信、會議決議、已交付檔案或系統畫面。避免只寫「差不多」「快好了」。

第 5 步：將待辦改寫成可驗證交付物

模糊待辦：

跟供應商確認通訊。

可執行待辦：

取得供應商確認的通訊參數與 I/O 位址表，完成三項測試指令並保存結果；若星期三前仍未取得，依升級路徑通知專案負責人。

每項待辦至少包含：

• 交付物
• 負責角色
• 期限
• 前置依賴
• 完成證據
• 未完成時的影響

第 6 步：保留決策脈絡，不只留結論

決策紀錄應包含：

• 決策題
• 最終選項
• 決策者
• 決策日期
• 使用的證據
• 適用範圍
• 附帶條件
• 被否決選項及原因
• 何時需要重新打開

「曾經討論」不等於「已決定」；「沒人反對」也不等於正式同意。

第 7 步：分開待辦、等待與依賴

接手者能控制的工作與等待別人交付的事項必須分開。

類型	要記錄的內容
可執行待辦	下一步、負責人、完成證據
等待中	等誰、等什麼、承諾日、上次追蹤日
外部依賴	影響、替代方案、升級條件
待決策	決策者、選項、期限、不決定的後果

這能避免接手者因為「等對方」而失去後續行動。

第 8 步：畫出利害關係人與溝通規則

不要只列姓名。請補上：

• 角色與決策權
• 關心的成果
• 固定溝通頻率
• 偏好的資訊格式
• 需要事前通知的事項
• 可直接處理與必須升級的邊界
• 替代窗口

私人評價或情緒性描述不應寫入正式交接文件。把「很難溝通」改寫成可觀察的互動需求，例如「變更前需提供影響清單與兩個選項」。

第 9 步：把例行工作做成日曆

例行工作至少包括：

• 每日、每週、每月、每季工作
• 啟動條件
• 截止時間
• 所需輸入
• 操作步驟
• 產出與收件人
• 失敗警示
• 假日或人員不在時的替代方式

把「每月做報表」改成接手者能照表執行的任務。

第 10 步：安全處理帳號、權限與憑證

交接文件只能記錄：

• 需要哪些系統與權限
• 申請入口與核准角色
• 權限用途
• 最小必要權限
• 測試方式
• 舊人員權限撤銷日

不要把密碼、驗證碼、API 金鑰或私人帳號直接貼給 AI，也不要用交接文件傳遞機密憑證。

第 11 步：補上例外處理卡

對每項關鍵工作，至少列出三種情境：

• 正常情境
• 常見例外
• 高影響例外

例外處理卡可使用：

當【訊號】出現時，先檢查【項目】；若【條件】成立，執行【安全行動】；若超出【權限邊界】，通知【角色】，不得自行【禁止事項】。

第 12 步：挖出隱形工作與個人判斷

可請 AI 根據資料追問：

• 哪些事情通常要主動提醒才會完成？
• 哪些報表需要人工修正？
• 哪些人不在正式流程中，卻是必要窗口？
• 哪些步驟看似可省略，實際會造成返工？
• 哪些判斷靠經驗，還沒有正式規則？

個人經驗要標示為「實務建議」，不能自動提升為正式政策。

第 13 步：建立接手風險清單

常見交接風險包括：

• 最新版本不明
• 單一窗口或單一權限
• 未完成核准
• 外部承諾沒有書面證據
• 例行工作沒有替代人員
• 未決事項沒有決策期限
• 已知問題沒有處置人
• 接手者沒有足夠時間實作

每項風險要有早期訊號、處置措施、擁有者與檢查日期。

第 14 步：安排影子操作與反向操作

建議分成兩輪：

1. 影子操作：原負責人執行，接手者觀察並提問。
2. 反向操作：接手者執行，原負責人只觀察與補充。

驗證的不是接手者有沒有看完文件，而是能否完成關鍵任務、處理例外並找到正確升級窗口。

第 15 步：用驗收清單正式結束交接

正式完成至少要確認：

• 接手者已取得必要權限
• 關鍵文件與版本可開啟
• 近期工作與依賴已確認
• 關鍵操作已完成反向演練
• 已知問題與風險已接受或指定處置人
• 原負責人的撤銷權限與資料歸屬已安排
• 雙方與主管確認未交接項目

文件寄出不是驗收；沉默不是接受。

可直接複製的完整提示詞

【角色】
你是一位審慎、重視可追溯性的工作交接分析助手。你要協助我把零散資料整理成接手者可以實際執行、主管可以驗收的交接包。你無權把個人經驗改寫成公司規定，也不能替任何人接受責任、承諾期限、授予權限或傳遞密碼。

【任務】
請根據我提供的文件、任務、會議紀錄與補充說明：
1. 盤點專案、例行工作、進行中事項、等待中事項、決策與例外處理。
2. 找出每個主題的正式來源、最新版本、負責人及衝突資料。
3. 將模糊狀態改為「已完成且驗證／已完成待驗證／進行中／等待／阻塞／未開始／取消」。
4. 將待辦改寫成有交付物、期限、依賴與完成證據的任務。
5. 區分已決策、曾討論、建議、假設與待決策事項。
6. 整理例行工作日曆、利害關係人地圖、權限清單與例外處理卡。
7. 找出只存在於個人記憶、聊天或非正式操作中的隱形工作。
8. 產出接手前五天行動計畫、反向操作測試與交接驗收表。

【交接基本資料】
- 交接主題：[職務／專案／流程名稱]
- 交接類型：[短期代理／長期移交／階段移交／離職交接]
- 原負責角色：[角色]
- 接手角色：[角色；未定則填待指定]
- 主管或驗收者：[角色]
- 交接生效日：[日期]
- 可共同工作的期間：[日期或天數]
- 交接後支援方式：[無／有限期間／依約定]
- 納入範圍：[範圍]
- 不納入範圍：[範圍]

【輸入資料格式】
來源編號｜日期｜資料類型｜主題｜內容｜目前狀態｜來源位置｜負責角色
[S01]｜[日期]｜[計畫／會議／任務／SOP／聊天摘要／測試]｜[主題]｜[內容]｜[狀態]｜[連結或路徑]｜[角色]

工作清單：
[貼上工作與任務]

文件清單：
[貼上檔名、版本、日期與位置]

已知決策：
[貼上決策；若未知請填未知]

例行工作：
[貼上每日／每週／每月工作]

已知例外與問題：
[貼上內容]

【限制與判斷規則】
1. 不得捏造狀態、日期、負責人、決策、權限、連結或完成證據。
2. 「快完成」「應該可以」「對方知道」一律標示為待驗證。
3. 沒有決策者、日期或決策證據時，不得標為正式決策。
4. 口頭經驗標示為「實務建議」，不得改寫成正式 SOP。
5. 發現文件衝突時，同時列出，不得擅自選定有效版本。
6. 沉默、被副本或收到文件不代表接受交接。
7. 不得要求或輸出密碼、驗證碼、API 金鑰、私人帳號或完整個資。
8. 權限項目只列申請方式、用途、核准者、測試與撤銷安排。
9. 未指定接手人或負責人時標示「待指定」，不得替任何人指派。
10. 涉及法務、資安、財務、人事、個資或對外承諾時，標示需人工複核。
11. 若資料不足，先完成可確定部分，再提出最多 8 個高價值確認問題。

【輸出格式】
A. 一頁式交接摘要
- 交接目的與生效日
- 前五項必須知道的事
- 未解問題與接手風險
- 本週需要的決策
- 尚未完成交接的項目

B. 交接範圍表
主題｜包含內容｜不包含內容｜交接完成條件｜來源

C. 工作與交付物總表
編號｜工作／交付物｜目的｜狀態｜證據｜下一步｜負責角色｜期限｜依賴｜完成標準

D. 文件與唯一可信來源地圖
主題｜正式來源｜版本／日期｜負責人｜舊版處理｜衝突或缺口

E. 決策台帳
決策編號｜決策題｜狀態（已決策／曾討論／待決策）｜結論｜決策者｜日期｜適用條件｜重開條件｜來源

F. 等待與依賴清單
項目｜等待誰｜等待內容｜承諾日｜上次追蹤｜影響｜替代方案｜升級條件

G. 例行工作日曆
頻率｜工作｜啟動時間｜輸入｜步驟摘要｜產出｜收件人｜失敗警示｜替代人

H. 利害關係人地圖
角色｜決策權｜關心事項｜溝通頻率｜偏好格式｜需事前通知事項｜替代窗口

I. 權限與工具清單
系統｜權限用途｜所需層級｜申請入口｜核准角色｜測試方式｜舊權限撤銷安排

J. 例外處理卡
情境｜可觀察訊號｜先檢查什麼｜安全處置｜不可自行做的事｜升級角色｜完成證據

K. 接手風險清單
風險｜原因｜可能影響｜早期訊號｜處置｜風險擁有者｜檢查日

L. 接手前五天計畫
天數｜優先任務｜預期成果｜需要協助｜完成證據

M. 反向操作測試
測試任務｜前置條件｜接手者應完成步驟｜例外題｜通過條件｜觀察紀錄

N. 交接驗收表
驗收項目｜狀態｜證據｜未完成原因｜處置人｜預定完成日｜驗收者

O. 高價值確認問題
最多 8 題，依「答案最能降低接手失敗風險」排序。

【最後自我檢查】
- 是否把模糊進度寫成已完成？
- 是否把討論或建議寫成決策？
- 是否指出最新版本與文件衝突？
- 是否每項待辦都有交付物與完成證據？
- 是否包含例行工作、例外與隱形工作？
- 是否把密碼或敏感個資放進輸出？
- 是否清楚列出等待、依賴與待決策事項？
- 是否用反向操作驗證接手能力，而不只是確認文件已寄出？

可替換欄位速查

• [交接主題]：例如「智慧機上盒整合專案 PM 工作」
• [交接類型]：短期代理、長期移交、階段移交或離職交接
• [共同工作期間]：決定影子操作與反向操作能做幾輪
• [交接後支援]：需明確說明期限、管道與可支援範圍
• [來源位置]：只放經授權的文件位置，不放密碼與機密憑證

實際教學範例

專案背景

公司準備將多套工廠軟體整合成智慧機上盒。AIE 團隊負責 AIoT／EAP、RPA 與 RCM；AZL 團隊負責 SPC。產品以 Machine PC 加 KVM 為基礎，作業環境為 Windows，資料庫使用 PostgreSQL。

目前資料如下：

• S01：RPA 現有產品只有 WinForm 版本，重寫成本高。
• S02：其他產品是否採 WinForm 精簡版仍在評估。
• S03：SPC 後端規劃使用 Python。
• S04：GPU 目前不納入本階段範圍。
• S05：功能清單包含登入、設定、警報、匯出匯入、串接、報表、圖表、看板、自動化、設備維護與權限。
• S06：KVM、硬體規格、共同介面與整合測試環境仍有待確認項目。
• S07：已有 WBS 與產品規劃文件，但部分內容建立於技術方向調整前。

AI 整理後的一頁式摘要

交接目的： 讓新 PM 在不重做既有討論的前提下，接手產品範圍、技術依賴、跨團隊協調與近期決策。

五項必須知道的事：

1. RPA 現況為 WinForm，任何重寫方案都要先估工與核准。
2. SPC 後端使用 Python 是目前規劃方向，但仍需以正式架構決策紀錄確認範圍。
3. GPU 不在本階段，除非有新的需求與正式變更決策。
4. 功能清單是產品範圍候選，不等於每項皆已排入首版。
5. KVM、硬體、共同介面與測試環境是跨團隊依賴，需有擁有者與期限。

目前接手風險：

• 舊版文件可能仍包含 GPU 或不同技術假設。
• 功能清單與首版範圍尚未完全對齊。
• 共用介面若未先定義，AIE 與 AZL 可能各自開發後才發現不相容。
• 整合測試環境與共同設備可能成為排程瓶頸。

工作與交付物總表示例

編號	工作／交付物	狀態	下一步	完成證據
T01	首版產品範圍基準	進行中	將候選功能分成必要、延後、待決策	經核准的範圍表
T02	共用介面規格	等待跨團隊確認	AIE、AZL 對齊資料契約與錯誤處理	雙方確認的介面文件與範例
T03	RPA 技術方案	待決策	比較沿用 WinForm、精簡版與重寫的成本及風險	架構決策紀錄
T04	SPC 後端規劃	已完成待驗證	確認 Python 模組邊界、部署與維運責任	架構評審紀錄
T05	GPU 範圍	已排除本階段	在範圍基準標示重開條件	已核准範圍文件
T06	整合測試環境	尚未完成	指定環境擁有者、可用日與預約方式	測試環境檢查表

決策台帳示例

決策題	狀態	目前結論	不可誤寫成
GPU 是否納入首版	已決策／需保留來源	本階段不納入	永久不做 GPU
SPC 後端技術	規劃方向／待正式證據	使用 Python	所有 SPC 功能均已完成設計
其他產品 UI 技術	待決策	可能採 WinForm 精簡版	已決定全部改用 WinForm
首版功能範圍	待決策	已有候選清單	清單上的功能都會在首版交付

例外處理卡示例

情境：跨團隊介面定義不一致

• 訊號：同一欄位名稱、型別、單位或錯誤碼在兩份文件中不同。
• 先檢查：文件版本、更新日期、資料擁有者及最近決策紀錄。
• 安全處置：列出差異與受影響模組，建立最小測試範例。
• 不可自行做：不能由 PM 猜測技術定義後直接宣布生效。
• 升級角色：介面擁有者、AIE 與 AZL 技術負責人。
• 完成證據：雙方確認的資料契約與整合測試結果。

接手前五天計畫

天數	優先任務	預期成果
Day 1	確認範圍、文件地圖與關鍵角色	知道去哪裡找正式資料
Day 2	逐項核對決策、假設與待決策	不把技術方向誤寫成正式結論
Day 3	檢查共用介面、硬體與測試環境依賴	找出近期阻塞與升級門檻
Day 4	主持一次跨團隊追蹤會議	由接手者更新狀態與下一步
Day 5	完成反向操作與主管驗收	確認能獨立維護專案節奏

反向操作測試示例

接手者應能在沒有原 PM 主導的情況下：

1. 找出最新產品範圍文件。
2. 說明 GPU 為何不在本階段，以及何時需要重開。
3. 區分 RPA 已知現況與仍待決策方案。
4. 找出共用介面的擁有者與下一個確認點。
5. 針對測試環境延遲，提出影響與兩個可選方案。

若只能回答「文件有寫」卻找不到來源，仍不算通過。

常見錯誤、隱私與使用注意事項

常見錯誤

1. 把資料夾連結當成交接

接手者需要的是來源地圖、有效版本與使用情境，不是一堆未分類檔案。

2. 狀態只有完成百分比

「完成 90%」沒有說明剩下的是排版還是關鍵核准。改用狀態、剩餘交付物與完成證據。

3. 只交接做什麼，不交接為什麼

沒有決策脈絡，接手者很可能重複走過已被否決的路。

4. 把個人習慣寫成正式流程

「我通常會先問某人」可能是實務建議，不一定是組織規定。

5. 忽略等待中事項

「等供應商」仍要有承諾日、追蹤日、影響與升級條件。

6. 交接沒有例外

只會正常流程的接手者，遇到第一個錯誤就會停擺。

7. 直接分享密碼

正確做法是列出所需權限、申請方式、核准人與撤銷安排。

8. 文件寄出就算完成

真正驗收是接手者能執行、能處理例外、能找到決策與升級窗口。

9. AI 把缺口補成合理故事

看到不完整資料時，AI 應標示未知與待確認，不得為了文字流暢自行補齊。

10. 沒有列出未交接項目

完整交接不代表所有事都已完成；未交接部分應透明列出並指定處置方式。

資料隱私與資安

送入 AI 前，請移除或代碼化：

• 客戶、員工、供應商個資
• 密碼、驗證碼、API 金鑰、Token、憑證
• 未公開報價、合約、財務與薪資資料
• 安全架構、內網位址與系統弱點
• 個人績效、申訴、醫療或人事紀錄
• 未公開產品策略與上市日期

正式交接文件應放在公司核准的位置，並依最小權限原則分享。

使用注意事項

• AI 產出的責任分工必須由真人確認。
• 過期文件不要直接刪除，應依組織規則封存並標示失效。
• 權限移轉與撤銷要由系統管理者或正式流程處理。
• 涉及法務、資安、財務、人事或客戶承諾的內容，要由對應負責人複核。
• 若共同工作時間不足，優先交接高頻、高影響、難逆轉的工作。
• 短期代理也要明確標示可決策範圍，避免代理人被迫承擔未授權風險。