提出 AI 使用案例前，先看懂真實工作如何發生

抱怨只能先當作研究線索，不能直接命名為 AI 使用案例；憑記憶畫出的流程圖，也不等於工作真正發生的樣子。某家 B2B 服務公司的營運團隊認為客戶上線摘要寫得太慢，因此要求導入 AI 摘要工具；但查看已完成案件後，研究人員發現困難案件多半卡在尚未確認的商務決策與互相矛盾的欄位，事實補齊後還得重寫。若只自動化看得見的撰寫步驟，等待與返工仍會留在原處。

觀察流程前，必須先界定哪些範圍？

觀察前要先界定流程的觸發點、結束條件、產出、下游使用者、參與角色，以及一般與例外案件，但這個邊界可以隨證據修正。不要先問團隊「AI 可以用在哪裡」，而要鎖定反覆發生的工作、拿出真實產出，說清楚工作何時開始、交給誰、何時算完成，以及研究這一輪究竟要釐清哪幾個問題。若觀察發現關鍵依賴其實位於上游或下游，就應把範圍調整並留下理由。

在客戶上線案例中，範圍可定為「已核准的業務交接送達」到「交付主管接受上線摘要」，並納入一般、資料不完整及範圍變更案件。這樣研究者會看見交接品質、補問、核對、撰寫、退回與接受，而不是只計算打字時間。研究計畫也應先寫出要理解的流程與技術，以及所需證據；本文提出的是多種方法的實務綜合，並非要求每個團隊執行一套固定、完整的標準協定。

• 觸發點：哪個事件或輸入讓案件正式進入流程。
• 結束條件：什麼產出由哪一位下游使用者接受。
• 角色：誰提供資料、執行工作、做判斷、接手或退回。
• 案件組合：一般、資料不全、範圍變更及其他重要例外。
• 研究問題：這一輪需要定位的等待、重工、資訊缺口或判斷負荷。
• 證據計畫：選擇能回答問題的最小方法組合，並記錄尚未涵蓋之處。

近期案件訪談，如何還原實際經過？

近期案件訪談應鎖定一件已完成的具體案例，從觸發到被接受的產出依序重建，而不是請受訪者概括「平常怎麼做」。先問案件如何開始、收到哪些資料，再追問下一步、判斷依據、交接對象、當時不確定之處及偏離預期的環節；談到表單、訊息、草稿或清單時，請對方展示實際使用的項目。開放且中性的追問能讓經驗保留原貌，也避免把訪談變成請員工設計 AI 功能的需求會議。

1. 請回想最近一次完成的具體案件，確認其觸發事件。
2. 盤點一開始收到的資料、工具與工作產物。
3. 逐步追問「接著發生什麼事？」及「什麼線索讓你這樣判斷？」
4. 標出每次交接、補問、等待、替代方案與困難決定。
5. 詢問哪裡不確定，以及案件何時偏離原本預期。
6. 請參與者展示當時真正使用的表單、訊息、草稿或清單。
7. 確認最後由誰接受什麼產出，以及是否曾退回或修改。

可用「誰通知你？」「你如何知道資料足夠？」「還考慮過什麼做法？」等問題補捉資訊線索、判斷與不確定性；這只是精簡的認知需求追問，不是正式 ACTA。共同提供服務的人員可以成對或小組受訪，訪談也能接著觀察任務，但須留意角色權力關係。在上線摘要案例中，至少應比較一件一般案件與一件困難案件，並涵蓋營運協調、業務營運及交付主管；單一案例只能說明可能的機制，不能代表所有案件。

工作在日常環境發生時，該觀察什麼？

現場觀察要看工作如何與日常設備、資料、文件、干擾及其他角色一起發生，特別留意切換來源、等待、核對、重工、交接、變通方式，以及資訊不完整或互相衝突時的判斷。研究者也要事先選定並記錄觀察模式：靜默觀察較能保留自然節奏，卻可能不知道行動原因；偶爾提問可補脈絡但會造成些許中斷；持續請參與者解說最深入，也最可能改變原本的工作方式。

• 案件脈絡與當下可用資訊
• 實際觀察到的動作與所用產物
• 判斷依據、不確定性與替代方案
• 交接、補問、等待及工作中斷
• 對時間、品質、重工或風險的可見後果
• 研究者的解讀，另欄記錄而不冒充觀察事實

這項工作應明確定位為研究流程，而不是評量個人表現。參與者須知情並自願參與；研究者應降低自身影響，新增錄音或錄影前再次確認同意，安全保管個人資料，並只蒐集研究問題真正需要的內容、限制存取。若涉及員工、客戶、機密或受規範資訊，應視情況讓隱私、資安、法務、勞資、無障礙或領域負責人參與。觀察結束時，請參與者確認或修正流程重建；小型情境樣本仍是帶有詮釋的局部證據，不是整體員工的客觀寫照。

哪些證據能補上訪談或現場觀察的盲點？

工作產物、短期任務日誌與營運紀錄可以補上訪談回憶及排定觀察時段看不到的部分，但每一種都只是局部視角。範本、清單、試算表、訊息、草稿、紙本筆記與佇列畫面，可能承載流程圖未記載的狀態、優先順序、記憶提示和協作方式；研究者必須請實際使用者說明它在該案件中的意義，不能只憑格式推論。若事件間歇發生，可請參與者在真實任務當下或剛完成後留下簡短日誌，再安排追問。

若有可用的案件、活動與時間戳記，可檢查等待、重工、重複處理、流程偏離、未達期限及反覆的品質問題；但紀錄可能跨系統分散、漏掉線下澄清，案件定義也可能不一致。較少出現的例外不能只因頻率低就刪除，應先看它消耗的工作量與造成的後果。在上線摘要案例中，可比對交接表、來源紀錄、訊息、清單、草稿版本及修正意見，再查看佇列時間、退件與缺漏欄位原因，但不能從時間戳記直接宣稱延誤原因。

什麼時候，痛點才足以形成可信的瓶頸假設？

痛點在多個相關案件、角色或證據來源中指向同一限制，能定位它進入流程的位置，並連到可觀察後果時，才足以形成可信的瓶頸假設。研究者還要提出可能的作用機制，請實際工作者確認或修正，主動保留沒有發生問題的案件、缺漏範圍與替代解釋，最後判斷該位置是否真的可以介入。這是一套六問的編輯判斷規則，用來提高下一步測試的辨別力，不是統計檢定，也不會證明因果。

1. 反覆性：同一限制是否出現在不只一件相關案件、角色或證據來源？
2. 位置：能否指出等待、佇列、重工迴圈、資訊缺口或判斷負荷從哪裡進入？
3. 後果：是否連到可觀察的延誤、重複處理、修錯、漏接、不一致、額外投入或風險？
4. 機制：限制如何造成後果的解釋是否合理，並經實際工作者確認或修正？
5. 反例：哪些案件避開問題、差異在哪裡，還有哪些資料缺口與替代解釋？
6. 可行介入點：改變這一點是否可能影響結果，AI 是否優於規則、權責釐清、流程改善、訓練、資訊補強或不介入？

上線摘要的證據會把假設從「摘要寫得太慢」改為「困難案件缺少商務決策，且來源欄位互相矛盾，導致等待與重寫」。一般案件能很快完成，篇幅較長也不一定較慢；系統時間戳記又漏掉線下澄清，因此現有證據只能支持瓶頸假設。若反覆性、位置或後果仍不清楚，就把痛點留在待研究清單；若證據方向一致但因果尚未確定，則設計能區分替代解釋的最小測試。

在能指出限制反覆出現的位置、造成的後果與尚未釐清之處前，先別問 AI 要放在哪裡。

有證據的 AI 機會卡應該記錄什麼？

有證據的 AI 機會卡應記錄工作邊界、觀察樣本、痛點來源、實際模式、營運後果、證據索引、反例、限制、替代方案及下一個最小測試，而不是只寫一個功能名稱。先分開「誰說什麼很困擾」與「研究看見什麼反覆模式」，再用田野筆記編號、去識別化的產物編號、日誌項目或紀錄查詢支持實質陳述；尚未驗證的內容應明確標成假設，不要用單一綜合分數掩蓋不同意見。

• 流程邊界：觸發點、結束條件、產出、下游使用者與參與角色。
• 觀察範圍：期間、案件類型、代表角色、採用方法及未涵蓋部分。
• 痛點與模式：痛點由誰提出；觀察到哪些步驟、判斷、交接、變通及變體。
• 後果與證據：等待、投入、重工、修錯、不一致或風險，以及對應證據識別碼。
• 反例與不確定性：避免問題的案件、資料缺口、分歧及其他可能解釋。
• 機會陳述：哪一種角色需要協助完成哪項有邊界的任務，以及想改善的結果。
• 限制條件：資訊可得性、資料品質、權限、資安、隱私、勞資、無障礙、領域要求及人類監督。
• 替代方案：AI 輔助、確定性規則、流程或權責改變、訓練、較佳資訊與不介入。
• 下一個測試：要排除哪項假設、適用哪些案件、何為成功或失敗證據，以及負責人與檢視日期。

NIST AI RMF Playbook 的 Map 指引要求團隊記錄目的、使用者、營運環境、價值、限制、影響、應用範圍與人類監督，也要求考量非 AI 及非技術替代方案；它是自願、依情境調整的風險管理指引，不會替團隊決定答案。機會卡最後只能導向四種結論：測試 AI、測試非 AI 改變、蒐集更多證據或停止。每個選項都要用同一組案件、後果與限制衡量，不能因為專案一開始以 AI 命名，就預設 AI 獲勝。

在上線摘要案例中，較合理的第一步是測試必填交接欄位、明確的業務交接負責人與可見的例外佇列，觀察等待和重工是否改變；只有在事實完整的案件上，才另行測試有邊界的 AI 撰稿輔助。若任務邊界、反覆限制、可觀察後果、資訊條件、人類監督或相較簡單方案的可測優勢仍不清楚，就應補證據或停止。處理敏感工作與員工、客戶、機密或受規範資訊前，應請適當組織負責人及合格專業人員確認義務與高風險決策。