一句話解釋

設計 AI 工作流程，是在「AI 做什麼、人做什麼、資料怎麼流動、哪裡要檢查」這幾個問題都想清楚之前，先不要把 AI 接上正式的生產流程。

白話解釋

大部分團隊導入 AI 的方式，是先有人發現 ChatGPT 或 Claude 很好用，接著開始把工作丟進去，效果不錯就繼續用，慢慢地整個部門的日常作業裡到處都是 AI 的痕跡，卻沒有人講得出來這個流程裡 AI 到底負責哪一段、出錯了誰要扛。

這跟工程師寫程式沒有架構設計、想到什麼寫什麼，最後系統變成一團難以維護的程式碼是同一個道理。AI 工作流程也需要架構設計，差別在於這裡的風險不只是難維護，還包含資料外洩、錯誤資訊被當真使用、以及沒有人發現問題已經發生。

以下這套六步驟框架，把「AI 要怎麼安全地被用在工作裡」拆成六個可以逐一檢查的關卡，設計一次之後，之後每個新流程都可以照著走一遍。

六步驟框架

步驟一：定義任務邊界

先回答三個問題，AI 負責哪一段、人負責哪一段、交接點在哪裡。

任務邊界沒定義清楚，最常見的後果是 AI 做了它不該做的判斷。比如原本只是請 AI 幫忙草擬客戶回信，因為草稿寫得不錯，慢慢變成直接發送，沒有人再檢查內容裡的承諾是不是公司真的能兌現。

寫任務邊界的時候，具體列出 AI 的輸入是什麼、輸出是什麼、輸出之後誰接手、接手的人要做什麼決定。如果講不清楚這一步之後換誰負責，代表邊界還沒定義好。

步驟二：資料分類

送進 AI 的每一份資料，先分類再決定用哪個工具。公開資料，例如已發布的內容、開源文件，可以用任何 AI 服務。內部資料，例如會議紀錄、非敏感原始碼，只能用企業方案，像是 ChatGPT Team、Enterprise，或關閉資料保留的 Claude。機密資料，例如客戶名單、財報、策略文件，盡量只在本地部署的模型上處理，或乾脆不用 AI。

這個步驟常被忽略的原因是省事，同事習慣把整份文件丟進免費版 ChatGPT 問問題，沒有意識到免費版預設會把對話拿去改善模型。資料分類要在流程設計階段就決定，不要等到出事才回頭補做，詳細的分類架構可以參考另一篇文章《AI 時代的資料分類》。

步驟三：Prompt 設計

好的 Prompt 除了讓輸出品質穩定，也要把限制寫進 Prompt 本身，而不是事後靠人力補救。具體做法包含明確要求 AI 在不確定的地方標註不確定，而不是硬掰答案；要求輸出固定格式方便後續驗證；把不該做的事情寫進 Prompt，例如不要虛構任何數據或引用來源，不要對外承諾任何折扣或優惠條件。

Prompt 裡的限制不是萬無一失的護欄，AI 仍有機率不遵守，但它能降低出錯機率，並且讓後面的輸出驗證步驟有明確的檢查標準可以對照。

步驟四：輸出驗證

AI 產出的內容送到下一關之前，要有人或有系統確認過。驗證方式大致分三種，人工審核適合創意內容、對外溝通、有法律責任的文件；自動化檢查適合確認格式是否正確、是否包含禁用詞彙、是否超過長度限制，這些可以寫程式做；交叉比對是拿 AI 給的數據跟原始資料源核對，特別是數字、日期、人名這類容易產生幻覺的內容。

輸出驗證最容易流於形式，人工審核如果變成看一眼就按確定，等於沒有驗證，這在後面反模式的部分會再說明。

步驟五：安全關卡

在整個流程裡標出幾個明確的檢查點，而不是相信大家會自己注意。常見的三個關卡位置，資料送進 AI 之前，確認資料分類正確、沒有夾帶不該送出去的內容；拿到 AI 輸出之後，確認內容符合預期、沒有明顯錯誤；正式發布或執行動作之前，這是最後一道關，一旦按下發送、部署、對外公告，就無法收回。

關卡的重點是位置要固定、有人負責、而且真的會被執行，不是寫在文件裡但沒人照做的形式流程。

步驟六：回饋迴圈

工作流程不是設計一次就結束，要追蹤哪裡出錯、多久修正一次。具體做法包含記錄每一次 AI 輸出被人工改掉的地方，改了什麼、為什麼改，定期回頭看這些記錄找出常見的錯誤模式，再根據錯誤模式調整 Prompt 或調整任務邊界。

如果團隊發現 AI 常常在某個特定情境下出錯，比如回答台灣在地的法規問題時常常引用其他國家的規定，這就是該回到步驟一重新畫邊界的訊號，可能代表這一類問題應該保留給人工處理，或是要求 AI 一定要附上資料來源方便查核。

三個實際工作流程範例

內容產製工作流程

研究，人工蒐集資料來源、確認官方資訊，到大綱，人工或 AI 協助排列文章結構，到 AI 草稿，依照大綱和資料寫出初稿，到人工編輯，調整語氣、補充第一手經驗、刪掉聽起來像 AI 的內容，到事實查核，核對草稿裡的每一個數據、日期、產品名稱是否正確，到發布。

這個流程裡最容易被跳過的是事實查核，因為草稿讀起來很通順，容易讓人以為內容也是對的。通順和正確是兩件不同的事。

程式開發工作流程

需求確認，人工釐清要解決的問題，到 AI 產生程式碼，到人工審查，讀懂 AI 寫的邏輯而不是複製貼上就跑，到安全掃描，用靜態分析工具檢查常見漏洞，例如 SQL Injection、硬編碼的密鑰，到測試，單元測試與整合測試，到部署。

Vibe Coding 讓寫程式的速度變快，但如果跳過安全掃描和測試直接部署，等於把 AI 沒看過的邊界情況和潛在漏洞一起帶進生產環境。AI 寫的程式碼一樣需要走完整套開發流程，不會因為是 AI 寫的就可以少一關。

客服工作流程

客戶訊息進來，到 AI 草擬回覆，到人工審核，確認回覆內容符合政策、沒有做出公司無法兌現的承諾，到人工核准後才發送。

如果客服量大到人工審核每一則都來不及，可以改成分級處理，常見問題、低風險的回覆由 AI 直接發送，但保留隨機抽查機制；牽涉退款、投訴、法律責任的回覆一律要人工核准。分級的標準要事先定義清楚，不是遇到狀況再臨時決定。

常見反模式

先射後不理，把內容丟給 AI 之後直接發布，中間沒有任何人看過。這種做法在流量小、內容不重要的時候看起來沒事，但只要出現一次錯誤的醫療建議、錯誤的法規資訊，或是帶有偏見的內容被公開，付出的代價會遠高於前面省下的審核時間。

把 AI 當神諭，遇到不確定的問題就問 AI，把答案當作事實使用，不去查證。AI 模型在訓練資料涵蓋不到的範圍，或是需要即時資訊的問題上，經常講得很有把握但內容是錯的。判斷一個答案對不對，不能只看語氣有沒有自信。

安全劇場，流程圖上畫了審核關卡，實際執行時審核的人根本沒有認真看，只是走個形式簽名。這種情況比完全沒有審核更危險，因為團隊會誤以為風險已經被控管住，反而降低了警覺心。

如何把工作流程寫下來

一份簡單的工作流程文件應該包含幾個欄位，每個步驟的名稱、這個步驟由誰或哪個工具執行、輸入是什麼、輸出是什麼、下一步交給誰、如果出錯要通知誰。

不需要用很複雜的流程圖工具，一張表格就夠用。重點是寫下來之後，新加入團隊的人看得懂整個流程，而且能一眼看出哪裡是安全關卡、責任在誰身上。

台灣企業情境：對齊公司 AI 政策

如果公司已經有 AI 使用政策，工作流程設計要對齊政策裡的規定，而不是自己另外訂一套。常見需要對齊的項目包含哪些 AI 工具是核准使用的、資料分類的規則是不是跟公司既有的資訊分類一致、發生資安事件的通報流程由誰負責。

如果公司還沒有正式的 AI 政策，把自己團隊設計出來的工作流程當作草案，提交給資訊安全或法遵部門討論，往往是推動公司建立正式政策的一個實際起點，比空談需要一份 AI 政策更容易讓討論落地。

安全與限制

這套框架能降低出錯的機率，但沒辦法保證零風險，有幾個地方需要注意。

框架本身不會自己執行，落實程度取決於團隊有沒有真的照著做。寫了完整的流程文件，如果沒有人力去落實審核關卡，文件只是紙上談兵。

流程設計需要跟著工具和風險演化調整，AI 模型改版、新的攻擊手法出現、公司業務型態改變，都可能讓原本設計好的邊界不再適用。步驟六的回饋迴圈就是用來因應這件事，但如果沒有人固定去看回饋，這一步也會形同虛設。

過度設計會拖慢團隊，如果每一個小任務都要走完整套六步驟和多層審核，團隊可能會為了省麻煩而繞過流程。安全設計要跟風險程度成比例，低風險的任務可以用比較輕量的版本，高風險的任務才需要完整的關卡。

知識檢測

讀完文章後，測試一下你對這個主題的理解。

常見問題

六個步驟都要做齊全才能開始用 AI 嗎？

不用一次做到位。可以先從任務邊界和資料分類這兩步開始，這兩步能避免最常見的資料外洩風險，其他步驟可以在流程跑起來之後慢慢補齊。

小團隊也需要這麼正式的流程嗎？

規模小不代表風險小，一個人也可能不小心把客戶資料貼進免費版的 AI 工具。流程可以簡化，比如審核關卡可以是自己養成習慣，發布前重新讀一次草稿並核對關鍵資訊，但六個步驟背後的邏輯每個規模的團隊都適用。

這套框架跟公司既有的 SOP 有什麼不同？

差別在於 AI 工作流程多了資料分類和輸出驗證這兩個傳統 SOP 通常沒有涵蓋的環節，因為傳統 SOP 假設每個步驟的執行者都懂得判斷內容對不對，AI 的輸出需要額外的查核機制去確認。

怎麼知道自己的工作流程設計得夠不夠好？

一個實際的測試方法是刻意丟一個有問題的輸入進去，看流程能不能在正式發布前被攔下來。如果每個關卡都形同虛設，問題直接流到最後一步才被發現，代表流程需要重新設計。

AI 工作流程要多久檢討一次？

沒有固定答案，但建議至少每季檢討一次，或是每次發生明顯的錯誤事件之後立刻檢討。如果團隊換了新的 AI 工具或模型版本，也是檢討流程的好時機。

相關文章

參考資料