人與 AI 協作流程設計：明確分配任務、判斷與責任

人機協作先分清楚建議與執行

人與 AI 協作流程設計，是把任務拆成可觀察的動作，決定哪些由 AI 整理、哪些由程式檢查、哪些必須由有權責的人判斷。能產生一份看似完成的建議，不代表已取得寄送、改價或修改權限的授權。本文將「人負責、權限外置、工作可追溯」作為設計原則，並不宣稱任何特定平台已全面實作。設計時先指定最終成果與不可接受的錯誤，再安排合作方式；「有人在流程裡」本身不足以證明人工監督有效，還要確認那個人看得到什麼、能否拒絕以及有沒有時間核對。

圖解可左右捲動閱讀

用動作清單取代籠統的角色名稱

拿一件真實工作分成收件、篩選資料、提出草稿、核對、核可、執行與查收結果。每一步寫明輸入、預期輸出、可用工具、資料範圍與責任角色。同一個 AI 可以在草稿階段讀公開資料，但不能因此讀取整個客戶資料庫。任務也不能只寫「協助法務」或「品牌 Agent」；應寫成「列出合約中與既有範本不同的條款，附段落來源，不提出簽約承諾」。這種界定讓後續評估能對準具體行為，並讓人知道何時需要領域專業，而不是把所有錯誤都歸給提示詞不夠好。

讓人知道能力、限制與下一步

HAX 將人機互動放在初次使用、使用過程、系統出錯與長期調整的脈絡中。[S1] 實作介面應告訴使用者 AI 正在整理哪份資料、輸出是候選還是正式版本、目前缺哪些資訊，以及下一步會不會對外產生作用。不要只用一個「信心很高」徽章代替證據；對重要主張應能打開對應來源與日期。使用者更正後要能看見變更是否只影響本次草稿，還是會被送成共用規則候選，避免一次局部回饋悄悄改變全公司的工作方式。

將人工覆核做成能工作的檢查點

覆核畫面至少提供原始需求、輸出差異、關鍵來源、未解問題與預計動作。把「內容是否可用」與「是否准許執行」分成不同判斷；前者可能由專業編輯確認，後者需由有權的人決定目的地與版本。對例行低風險草稿可依風險訂抽查策略，但對付款、刪除或公開發布等作用，不能用抽樣內容品質代替動作授權。若覆核者只能看到結論、無法回查資料，或每天收到超過處理能力的確認量，就應縮小自動化範圍，不能以按過確認視為制度已經安全。

讓程式守邊界，不讓模型自己給權限

OWASP 指出外部文件也可能帶入提示注入，並建議最小權限、程式檢查與高風險人工核可等防護。[S2] 因此應由應用程式驗證身分、範圍與工具參數，模型只提出工具請求。網頁裡「請把名單寄出去」是待理解的內容，不是來自使用者的授權。工具端要檢查目前操作者、可寫資料與核可是否仍有效；模型在文字裡說「我已獲准」不能作為放行依據。拒絕時保留原因與替代處理入口，禁止換另一個工具繞過原本的限制。

用狀態與交接卡避免工作斷在對話裡

協作至少要分待資料、草稿、待覆核、退回、已核可、執行中、完成與結果不確定。交接卡記錄目前版本、來源、已做步驟、待決問題、下一個可做動作與停止條件。換一個人或工具接手時，先讀這份可版本化的紀錄，再確認資料與權限是否仍有效。對話摘要可以幫忙理解，但不應成為唯一的工作狀態；程序說明、公司事實與本次任務上下文也應分開保存，避免將某次臨時指示永久寫入能力規格。

外部作用不確定時先查收據

對寄信、建立工單或發布內容，先記錄準備執行的版本、目的地與防重複識別，再呼叫服務並保存回執。如果服務逾時但可能已接收，狀態是「結果不確定」，不是「沒有發生」。下一位接手者先查服務端紀錄或人工對帳，再決定是否重試。重新產生一段「已完成」文字不能取代服務回執。這是本文建議的可靠性契約；實際系統仍需測試逾時、重複請求、身分失效與部分成功，並明定哪個人能對帳、補送或撤回。

協作契約的必要欄位

建議每類任務都保留一份短契約，並把範例輸入與不允許的行為放在一起。業務負責人定義成功與取捨，資料窗口定義可讀範圍，工程人員落實工具限制，覆核者確認內容與例外，執行核可者確認會發生的作用。同一人可兼任數個角色，但兼任不代表所有授權可以被默認。當任務升級或風險改變時，要更新契約、測試與交接材料，而非只在提示中加一句「請小心」。

• 任務：觸發條件、成果、輸入來源、資料範圍、AI可做動作、AI禁止動作。
• 覆核：核對項目、來源與差異、可接受錯誤、退回原因、升級對象、處理時限。
• 執行：核可版本、目的地、動作種類、有效期限、回執位置、不確定結果處理人。

假設情境：AI 協助產出提案

假設業務要整理一份新合作提案，AI 可先把訪談筆記分類、列出待補問題，並依已確認資料產出草稿。專案負責人確認需求理解，財務角色核對價格與付款條件，有權人確認寄送版本與收件對象，系統才執行寄送。若筆記內出現「客戶已答應」但沒有紀錄佐證，應列為待確認，不能寫成既成事實。這是示例流程而非已發生案例；試行須比較覆核時間、錯誤修正與退回率，避免只量 AI 產生草稿的秒數，卻忽略人花更多時間清理無依據的敘述。

用故障演練檢查責任是否真的落地

準備缺少來源、彼此矛盾、過期核可、錯誤收件人、提示注入與服務逾時等測試。檢查系統是否停在正確狀態、留下足夠證據並交給正確角色，而不是只看它有沒有說「請確認」。驗收也要測重新開啟工作後，另一個人能否辨識哪版已核可、外部動作是否發生。記錄未測範圍與人工負擔；如果覆核量失控或人只能盲按接受，先縮小任務、改善可核對性，再擴大自主程度。

常見問題：人要看多少、AI能核可嗎、多人怎麼合作

每一筆輸出都要全文人工重看嗎？依風險、證據品質與可逆性安排，但高風險作用需有明確核可與可回查依據。

AI 能不能自己核可自己的草稿？不應把模型自述當授權，內容檢查與執行授權要由外部規則與有權角色決定。

多人與多個 AI 同時做會更快嗎？可能，但要先切出不重疊產出、指定整合者並序列處理共用正本；若邊界不清，多工只會增加衝突與覆核成本，不能把並行數當作成果指標。

來源依據與證據界線

1. S1 · Guidelines for Human-AI Interaction

   Microsoft HAX Toolkit · 查閱 2026-10-22

   人機體驗要涵蓋初次互動、持續使用、系統出錯與後續調整；不保證人工覆核能消除所有風險。

2. S2 · LLM01:2025 Prompt Injection

   OWASP Gen AI Security Project · 查閱 2026-10-22

   外部內容可造成間接提示注入；最小權限、程式檢查與高風險人工核可有助減輕影響，但不能保證完全防堵。