一個好的 AI 交接應該是甚麼樣子

一個好的 AI handoff，應該令下一位接手的人更有能力，而不是更混亂。

這聽起來很明顯，但很多 AI output 都是差的 handoff。它們會 summary、draft 或 recommend，卻沒有展示用了甚麼、假設了甚麼、缺少甚麼、誰擁有下一步，或者哪些事沒有批准就不應發生。

在專業工作裏，這不夠。

Handoff 不只是一段文字。它是 context 和 responsibility 的轉移。

這也是為甚麼 handoff 不應只追求「讀起來完整」。讀起來完整但沒有來源、假設和邊界，反而可能令接手的人過早信任 output。好的 handoff 要讓人知道可以接着做甚麼，也要讓人知道哪些部分仍然不可接着做。

為甚麼交接會失敗

交接失敗，通常是因為下一個人看不出：

• 甚麼改變了；
• 哪些來源重要；
• 哪些內容沒有支持；
• 哪些已經檢查過；
• 誰擁有決定；
• 甚麼最急；
• 甚麼需要升級；
• 哪些 action 是被允許的。

AI 可以減少這個問題，也可以令問題更嚴重。

如果系統產生一個 polished answer 但沒有 trail，reviewer 可能要由零開始重建工作。如果系統建立一個 accountable handoff，reviewer 就可以從更清楚的起點繼續。

Handoff Note

一個實用的 AI handoff 應包括：

這個格式是刻意簡單的。它給下一個人最低限度但足夠的 context，讓他可以檢查、修正和繼續。

表格裏每一欄都對應一種常見失敗。沒有 work object，交接容易漂浮。沒有 sources used，reviewer 要重做 evidence search。沒有 assumptions 和 missing context，未驗證內容會被當成事實。沒有 approval boundary，AI output 可能被誤用成 action instruction。

例子：Associate 交給 Partner

一個由 AI 支援的 matter review handoff 可能會寫：

• 工作對象：Smith matter，disclosure review。
• 目前狀態：星期一後新增三份文件；下星期有一個 deadline。
• 已用來源：document register、client email、draft chronology。
• 缺失 context：未有確認的 settlement posture 指示。
• 建議下一步：partner 在 client update 前 review issue list。
• 邊界：沒有 partner approval，不可發送 client communication。

系統沒有提供法律意見。它準備了 handoff。

有用的分工，是把 evidence assembly 和 professional judgment 分開。Document register、最近 emails 和最新 chronology 可以變成一份小 issue list，顯示上次 review 後有甚麼變化。但它不應該變成自信的 recommendation，因為真正決定可能取決於 settlement posture、client appetite，或某段未被記錄的對話。

Partner 需要三層東西：短的 state summary、有 source 支持的 changes，以及 open questions。每個新 issue 都應該指向文件、email 或 chronology entry。open-question layer 要坦白處理 uncertainty：「settlement instruction not confirmed」比一個沒有基礎的 polished conclusion 更有用。

這解決真正的 handoff 問題。Partner 不需要另一段聽起來完整的 summary。Partner 需要看見哪裏已經準備好、哪裏仍然不確定，以及哪個 decision 仍然屬於他。

例子：Finance 交給 Budget Owner

一個 renewal review 可以這樣寫：

• 工作對象：design software renewal。
• 目前狀態：收到 renewal notice；開支增加 18%。
• 已用來源：invoice、contract、usage export、budget owner note。
• 缺失 context：未確認 external contractors 的使用量。
• 建議下一步：budget owner 確認依賴程度和 negotiation position。
• 邊界：未經 finance review，不可批准續約或通知 vendor。

這個 handoff 避免 decision 變成一串含糊 email。

有用的 pattern 不是一個「approve or reject」按鈕，而是一個令 budget question 可檢查的 renewal workspace。Renewal notice、contract term、previous invoice、current usage export、owner history 和 team notes 都應該在同一個 view。Budget owner 於是可以用幾個實際角度檢視決定：cost change、actual usage、business dependency、cancellation risk 和 negotiation options。

這可以由簡單做起。輕量版本可以是在 monthly review 前，向 finance 和 budget owner 發一份 renewal brief。較完整版本可以維持一條 queue，包含 status fields：source complete、usage missing、owner confirmed、negotiation posture needed、approval pending。更 integrated 的版本可以連接 finance records 和 identity 或 usage data，讓低使用量續約在 vendor notice 到達前已被標記。

每個版本裏，spend decision 都留給人，但圍繞它的霧氣會減少。Finance 看得見升幅是否 material。Budget owner 看得見工具是否真正需要。Procurement 看得見是否仍有時間 negotiate。AI 的角色是澄清 decision surface，而不是假裝 budget authority 可以由模型輸出。

例子：Project Manager 交給 Consultant

一個 site decision 可以這樣寫：

• 工作對象：關於 ceiling clearance 的 RFI。
• 目前狀態：contractor photo 和 latest drawing 有衝突。
• 已用來源：RFI、site photo、drawing revision、meeting note。
• 缺失 context：未收到 consultant comment。
• 建議下一步：準備 consultant question，並暫緩回覆。
• 邊界：未經 design lead approval，不可指示 contractor。

價值不是 AI 決定 site issue。價值是下一位專業人士能清楚看見問題。

這種 handoff 最好是一份 decision packet，而不是一段自由文字。RFI、最新 drawing revision、相關 photo、meeting note 和 consultant 之前的 comments 應該放在一起。衝突於是變得可見：photo 看來和 drawing 不一致，但 consultant 尚未確認 site condition。

一個版本可以草擬 consultant question，附上 evidence，並加入 hold boundary：未經 design lead approval 不可指示 contractor。另一個版本可以在 project review 建立一個細小 status object：「site evidence conflicts with drawing; consultant response missing; contractor instruction blocked。」這個 status 很重要，因為項目工作常常是在多個會議裏反覆重新發現同一個 uncertainty。

價值在於保留問題的活狀態。分散的 project artifacts 變成一個可 review 的 decision point：已有甚麼 evidence、缺少甚麼、誰需要回答，以及哪些 action 在此之前被 blocked。

甚麼令 handoff 可負責

Accountable handoff 要有 trail。

Trail 應該顯示：

• 系統讀過甚麼；
• 它產生了甚麼；
• 如有，它改變了甚麼；
• 誰 review 過；
• 之後作出甚麼 decision；
• 仍然 open 的是甚麼。

這不需要重型 bureaucracy。它需要足夠紀錄，讓團隊理解工作怎樣流轉。

在實際團隊裏，這種 trail 可以很輕：一個 packet、一段 log、一個 status object，或者 review screen 裏幾個清楚欄位。重點不是增加 paperwork，而是避免重要工作在 polished text 之後失去來龍去脈。

NIST SP 800-53 把 audit and accountability 視為 security 和 privacy control 的關注。在 AI-supported work 裏，同一原則會變成營運原則：如果軟件準備的工作會影響決定，組織應該知道發生過甚麼。

Handoff 與 autonomy

好的 handoff 也是管理 autonomy 的方法。

系統在被允許行動之前，應該先能夠 hand off。如果它無法解釋用了甚麼、假設了甚麼、正在要求甚麼，就不應被信任去取得更廣 authority。

這配合 AI readiness 的分階段做法。先 draft。再連 evidence recommendation。再經 approval 行動。只有當 handoff pattern 可靠，才自動化狹窄工作。

這不是甚麼

Handoff note 不應變成一面文字牆。

目標不是記錄所有東西。目標是保留會影響 responsibility 的 context。一個好的 handoff，要短到真的有人用，也要具體到值得信任。