假設一間旅館每天收到訂房詢問、旅客留言與平台評論。員工已經會用 AI 整理文字，卻仍要自己複製資料、確認房況、查找規則，再把答案貼回原來的平台。
AI 參與了工作，但員工還是負責把每個環節接起來。
接下來可以改善什麼？也許是將詢問自動分類，也許是讓回覆草稿附上規則來源，或把需要主管處理的問題送進待辦清單。每往前走一步，都會碰到新的問題：資料是否即時、誰有權操作、結果如何確認，以及系統出錯時由誰接手。
AI 進入行業，會沿著這些具體工作發生。導入的範圍愈深，企業要處理的事情，也愈接近原有流程與組織分工。
一個行業裡，有很多不同的 AI 題目
製造業想導入 AI，可能是希望員工更快查到設備文件，也可能是辨認產品表面缺陷、找出設備運轉的異常，或改善生產排程。這些工作都與工廠有關，卻需要不同的資料、技術與驗證方式。
文件搜尋主要處理語言與知識檢索；外觀檢查涉及影像辨識；設備預警需要時間序列與歷史紀錄；排程則常牽涉產能限制、交期與最佳化。把它們都寫成「導入 AI」，還不足以讓團隊開始工作。
比較實際的起點，是選出一項反覆發生的任務：輸入從哪裡來？現在由誰判斷？判斷後會採取什麼行動？最後又由誰確認完成？
| 行業 | 可評估的工作 | 需要準備的資料 | 結果怎麼確認 |
|---|---|---|---|
| 零售電商 | 整理商品資料、產生上架草稿 | 商品規格、圖片、通路欄位與禁用詞 | 規格可追溯、必填欄位完整，經確認後上架 |
| 製造 | 辨識外觀可疑品、協助查找設備文件 | 檢驗影像、標註標準、設備型號與文件版本 | 與人工檢驗對照，記錄漏判、誤判及查找正確性 |
| 餐飲旅宿 | 分類詢問、整理需求與回覆草稿 | 服務規則、訂單、即時房況或訂位資訊 | 回覆符合規則，承諾能被現場履行 |
| 物流倉儲 | 整理配送異常、安排追蹤事項 | 訂單、掃描事件、配送狀態與異常原因 | 狀態對得回原始事件，追蹤工作有人接手 |
| 顧問專業服務 | 整理訪談、搜尋文件、比對需求 | 授權文件、訪談紀錄與專案範圍 | 引述可核對，重要結論由負責人確認 |
以上是工作設計的示例，並非已實測的客戶成果。相同的行業名稱下，公司規模、資料成熟度與分工不同，適合先做的事情也會不同。
OECD 在中小企業 AI 採用報告中，將連線能力、資料與運算資源、技能及資金列為重要基礎。這提醒企業：選擇工具之外，也要盤點現有條件是否支撐得起預期用途。[1]
行業知識，要能影響系統的判斷
把一批文件交給模型，不代表系統已經理解這間公司。文件可能有不同版本，同一個名詞在不同部門有不同意思，也可能缺少現場人員長年累積的判斷。
例如「急件」究竟是客戶要求今天交付、距離交期剩一天，還是已經影響下一道製程？如果三個部門採用不同定義，AI 再熟悉這個詞，也無法代替公司決定優先順序。
能辨認的對象。客戶、訂單、設備、商品與批次，需要有可對照的識別方式。只有名稱，容易把同名或近似項目混在一起。跨系統串接時，應先釐清使用哪個識別碼，以及對不到資料時如何處理。
可以對照的來源。規則要有生效日期與適用範圍，文件要有版本。舊文件可以保留供查閱，但不能在沒有提示的情況下，當成目前的操作依據。
寫得清楚的規則。退款期限、訂單狀態、可用額度與操作權限，適合交給明確條件檢查。模型可以協助理解詢問，但不應自行改寫這些限制。
需要保留給人的判斷。資料衝突、特殊客訴、例外承諾與無法分類的狀況，需要有指定接手者。系統應把原始資料、已完成的檢查與待決問題一起交出去。
整理行業知識時，可以請資深同事回顧幾個近期案例：當時看到哪些訊號？為什麼沒有照一般流程？新人最容易忽略什麼？這些細節，比一句「依經驗處理」更能成為系統設計的依據。
從旅館詢問，看一條流程如何接起來
以下是一個假設情境：旅客來訊詢問，明天能否提早入住，以及入住前能不能寄放行李。表面上只有兩個問題，背後卻牽涉訂單、房務、服務規則與回覆紀錄。
收件時，先保留原始訊息
系統先保存訊息內容、來源平台、收到時間與訊息識別碼，再辨認旅客想詢問的事項。摘要可以方便閱讀，但不能取代原始訊息。若摘要漏掉日期或人數，接手者仍要能回頭核對。
接著確認這則訊息對應哪一筆訂單。如果只能依姓名猜測，或查到多筆可能紀錄，就應要求補充資訊或交由員工確認，避免把別人的訂房狀態帶入回覆。
查詢規則，也查詢即時狀態
行李寄放可能有固定服務時段；提早入住則還要看當天房間是否清潔完成。前者可以查規則，後者需要查詢即時狀態。系統不能只因為文件寫著「視房況提供」，就替旅客保證房間可用。
若房況系統暫時無法連線，回覆應清楚表達尚待確認，並留下需要追蹤的工作。能夠流暢地生成句子，並不等於已經取得可承諾的資訊。
回覆之前，讓人知道判斷依據
員工審閱草稿時，應同時看到適用規則、房況查詢時間與尚未確認的部分。只顯示一段看似完整的答案，會讓審閱者重新查一遍，也更難發現錯誤。
涉及特殊承諾或費用調整時，應由具備相應權限的人批准。模型負責草稿，系統負責限制操作範圍，審閱者負責確認承諾是否成立，各自的責任要能辨認。
回覆之後，工作還要有結果
訊息送出後，需要記錄送出時間、內容與執行者。若已答應稍後確認房況，就建立追蹤事項，設定接手人與期限。不能因為訊息已回覆，就把整件事視為完成。
同一則訊息可能因平台重送而收到兩次。系統應利用來源識別碼辨認重複事件，避免建立兩張待辦或傳送兩次相同回覆。若傳送失敗，也應區分未送出、等待重試與需要人工處理。
走完這一條流程，才看得出 AI 適合協助哪些步驟，以及哪些地方仍需要資料查詢、系統控制與人的決定。
製造業的難題，常在「什麼才算異常」
再看一個假設例子：工廠希望透過相機找出產品表面的可疑痕跡。模型訓練之前，團隊需要先確認什麼算缺陷、哪些變化可以接受，以及誰有權決定標準。
如果兩位檢驗員對同一張影像給出不同答案，就要先討論差異。標準尚未一致時，把更多影像送進訓練，也可能只是讓系統學到彼此衝突的判斷。
拍攝條件同樣會改變結果。光源、鏡頭角度、產品位置、材質反光與批次差異，都可能讓影像和原來的樣本不同。測試資料應涵蓋這些工作現場會遇到的變化，並保留未參與調整的樣本來檢查。
| 情況 | 可能增加的工作或影響 |
|---|---|
| 合格品被判為可疑 | 增加人工複檢，可能延長等待時間或占用檢驗產能 |
| 缺陷品未被辨認 | 問題可能流入後續製程，增加重工或交付風險 |
這兩類錯誤的代價不同，不能只看一個整體正確率就決定是否上線。團隊需要知道哪些缺陷漏掉最麻煩，哪些誤判會造成大量額外工作，並分別觀察。
對於不確定的結果，可以先送往複檢，而不是強迫系統每次都判定合格或不合格。這個設計需要搭配複檢人力與等待時間；如果可疑品太多，流程仍可能塞住。
設備、原料或產品規格變更後，也要重新檢查原先的驗證是否仍適用。模型曾經通過測試，不代表它在所有後續條件下都能維持相同表現。
讓模型進入系統，還要補上哪些工作
展示時可以把資料貼進對話框，正式使用時卻需要知道每筆資料從哪裡來、結果存在哪裡，以及誰可以操作。這些工作可以分成四個層次來檢查。
資料層。確認欄位定義、資料來源、更新時間、版本與存取範圍。缺值要有處理方式，來源中斷要有提示，不能讓舊資料默默繼續當成即時資料使用。
模型層。界定輸入、輸出格式、可使用的工具與不能自行決定的事項。對重要欄位做格式和內容檢查，不符合條件的結果要能退回、重試或交由人處理。
系統層。由後端檢查身分、權限、操作條件與目前狀態，再執行寫入。模型說「已完成」，不能作為資料庫已更新或通知已寄出的證據；必須讀取實際執行結果。
操作層。讓使用者看見目前狀態、來源依據與需要採取的下一步。遇到失敗時，要知道能否重試、是否已產生部分結果，以及找誰接手。
外部服務可能逾時，網路可能中斷，同一個任務也可能被重送。系統需要保留任務紀錄，並依操作設計去重與重試方式。建立訂單、寄送通知或開通權限等操作，尤其要確認重試不會造成重複寫入。
此外，測試環境與正式環境應有清楚區別。使用測試資料驗證流程後，再逐步開放真實資料和操作權限；不要只因為草稿看起來合理，就同時開放所有寫入能力。
如果每次異常都靠同一個人私下修正，也應把這段工時記錄下來。否則表面上的自動化率很高，維運成本卻藏在看不到的地方。
導入成果，要從整段工作計算
原本需要二十分鐘的工作，現在十秒鐘就能產生草稿，看起來改善很大。但如果事前還要花時間整理輸入，事後又要逐句確認、修正格式與補回漏掉的資訊，就不能只比較生成速度。
評估時，應從收到任務開始，算到結果真的能用為止。也要觀察這些工作是否轉移給其他人，例如由第一線員工節省時間，卻讓主管增加審核負擔。
| 指標 | 需要記錄什麼 |
|---|---|
| 完整處理時間 | 收件、準備資料、生成、審閱、修改與交付各花多久 |
| 成果採用程度 | 哪些輸出直接使用，哪些需要修改，哪些最後放棄 |
| 錯誤類型 | 漏掉資訊、引用錯誤、規則不符與系統操作失敗分別發生多少 |
| 人工介入 | 什麼情況需要接手，由誰處理，花多少時間 |
| 系統成本 | 模型、儲存、外部服務、維護與支援的實際投入 |
| 使用行為 | 誰持續使用，在哪一步離開，是否另外保留手動流程 |
NIST AI RMF 1.0 將情境中的衡量、人員角色與人類監督列入風險管理工作。對導入團隊來說，這意味著測試標準應對應實際用途，也應讓熟悉工作的人參與判斷。[2]
草擬一段宣傳文案、更新一筆庫存與決定是否放行一批產品，後果不同，驗收條件也應不同。團隊可以先整理一組固定案例，涵蓋一般情況、資料缺漏、規則衝突與服務中斷，之後每次修改模型、提示或資料來源，都重新跑過。
測試紀錄還要保留當時的版本與條件。只知道某次結果很好，卻不知道用了哪批資料、哪個模型與哪些規則，就很難在發生問題時追查。
擴大使用前，先安排好接手的人
試作階段，開發者可以隨時調整資料與規則。正式使用後，需要有人持續維護：誰更新服務政策？誰確認新欄位的意思？誰處理帳號離職、權限變更或外部工具停用？
模型與工具更新，也可能改變原本的輸出。正式更換前，應用既有測試案例比對，確認影響範圍，並保留回復到可用版本的方法。
擴大使用時，可以分開增加使用人數、資料範圍與操作權限。先讓小組使用草稿功能，確認採用情況與錯誤類型；再開放更多資料；最後才考慮哪些操作可以在明確條件下自動執行。每一步都留下觀察結果，比一次開放所有能力更容易查出問題。
也要看下一道流程是否承受得住。詢問分類更快，可能讓待辦量突然增加；檢查更敏感，可能讓複檢人員忙不過來；產出更多內容，也可能讓審稿成為新的等待點。改善一個步驟後，需要再看整條流程。
因此，一個導入專案完成後，應該留下幾樣可繼續使用的東西：資料與版本說明、操作權限、測試紀錄、異常處理方法，以及能接手的負責人。
下一次遇到相同任務，團隊知道如何開始；條件不成立時，也知道在哪裡停下來。這樣的工作方式能持續運作，AI 才有機會真正留在行業裡。