我們常聽到「AI 可以提升知識工作效率」，但很少有人停下來問：知識工作本身到底是什麼？
它並不只是打字、做簡報或查資料，而是一連串需要理解情境、判斷資訊、執行任務與追蹤結果的活動。如果沒有先搞清楚知識工作的組成，AI 導入計畫往往只會自動化最容易展示的那一段，卻漏掉真正費時、容易出錯，也最需要判斷的核心環節。
為了更具體地拆解這個問題，我把常見的企業知識工作整理成五個階段，分別是 Find、Understand、Decide、Act 與 Track，簡稱 FUDAT 框架。
知識工作的第一步，是找到完成任務所需要的資料、文件、專案紀錄或負責人。
這一步真正的挑戰，通常不是「有沒有資料」，而是「知不知道去哪裡找」。企業內部的資訊往往分散在 Google Sheets、Confluence、Trello、PDF、Email、資料庫與各種共用資料夾中，同一份資料還可能同時存在多個版本。
因此，Find 階段需要回答的不只是：
如果一開始找到的資料不完整或已經過期，後面的分析做得再精準，也可能建立在錯誤的基礎上。
找到資料後，下一步不是立刻開始計算，而是先理解資料代表的意思。
企業資料中充滿欄位名稱、縮寫、分類規則與例外條件。同一個詞語，在不同團隊中可能有不同的定義；同一個欄位，也可能因為系統改版或業務調整，在不同時期採用不同邏輯。
例如，看到一個名為 Status 的欄位時，還需要確認：
Understand 是最容易被低估的階段，卻直接決定後續分析是否站在正確的基礎上。
當資料與定義都確認後，接下來需要判斷應該如何回答問題。
同一句「今年的需求工單有什麼趨勢」，可能有很多種分析方向，例如：
這些分析都可能合理，但不一定都符合提問者真正想知道的事情。因此，Decide 階段需要根據問題背景，選擇適合的分析維度、方法與呈現方式。
這是整個流程中最需要業務判斷的環節，也是目前 AI 最需要與人類協作的地方。
Act 是將前面幾個階段的成果轉化成實際輸出。
這個輸出可能是一份分析報告、一段摘要、一張圖表、一組建議，也可能是更新專案狀態、建立待辦事項、寄出通知或修改系統中的資料。
許多人談到生成式 AI 時，最先想到的就是這個階段，因為它最容易被看見。AI 可以協助撰寫文字、整理摘要、產生圖表說明或提出行動建議。
但 Act 的品質高度取決於前三個階段。如果資料找錯、定義理解錯誤，或分析方向選錯，即使最後寫得再流暢，也只是把錯誤包裝得更漂亮。
知識工作通常不會在報告完成或訊息送出後就結束。
還需要確認結果是否被閱讀、建議是否被採用、專案是否持續推進，以及是否需要補充新的資料。很多企業流程在 Act 之後就失去追蹤，導致分析做完了，卻沒有真正轉化為決策或行動。
Track 階段可能包含：
真正的價值，往往不是出現在報告完成的那一刻，而是在後續行動被落實時才產生。
假設主管問：
「今年的需求工單有什麼趨勢？」
這個問題看似簡單，但實際上需要完整走過 FUDAT 的五個階段。
首先，需要確認需求工單存放在哪一份 Google Sheets，分析期間應該從哪一天開始，以及是否需要同時參考去年同期資料。
如果公司內部有多份相似的工單表，也要先確認哪一份才是正式來源，以及是否包含所有市場與所有需求類型。
找到資料後，還需要查閱 Confluence 或其他文件，確認「需求工單」的分類規則、各欄位的含義，以及哪些資料應該排除。
例如，測試工單、重複工單、取消需求，是否應包含在統計中？某些分類是否曾在不同季度修改過定義？這些問題都會直接影響結果。
接下來，需要判斷主管口中的「趨勢」究竟指的是什麼。
可能的分析方向包括：
這時不能只是把所有數字都丟進報告，而應選擇最能回答問題的角度。
完成分析後，可以將各分類件數、月度趨勢、市場分布與關鍵異常整理成一份摘要，搭配必要的圖表與洞察。
例如：
今年需求工單總量較去年同期增加 18%，主要由日本與台灣市場帶動，其中資料分析類需求成長最明顯。不過，需求量增加的同時，平均處理天數也上升，顯示團隊資源可能開始吃緊。
這才是一個能支持決策的結論，而不只是數字列表。
報告送出後，還需要確認主管是否有進一步問題，分析結果是否帶動資源調整，以及後續是否需要持續追蹤。
例如，主管可能要求進一步拆分日本市場的需求來源，或希望每月自動更新同一份分析。這些都屬於 Track 階段。
一位有經驗的分析師不會立刻開始寫結論，而是會先花時間處理 Find 與 Understand，確保資料與定義正確。AI 系統也應該如此。
如果在設計 AI 系統時沒有先拆解工作流程，最常見的結果就是：只自動化了最後的「寫答案」，前面的資料取得、定義確認、分析判斷與結果查核仍然由人工完成。
這會造成一種假象：
例如，一位分析師原本需要三小時完成一份報告，其中兩小時花在找資料與確認定義，四十分鐘用來分析，最後二十分鐘撰寫摘要。
如果 AI 只把最後二十分鐘縮短成五分鐘，看起來效率提升很多，但整體工時其實只從三小時下降到兩小時四十五分鐘。真正的瓶頸並沒有被解決。
許多企業 AI 導入計畫失敗，不是因為選錯模型，而是因為只自動化了最容易展示的部分，卻忽略工作流程中真正的瓶頸。
因此，設計企業 AI 時，應該先問：
只有先完成這個拆解，才知道 AI 應該被放在哪裡。
Data Machi 的設計思路，是讓不同工具分別支援知識工作的不同階段，而不是期待單一模型完成所有任務。
| 工具或元件 | 主要支援階段 | 功能說明 |
|---|---|---|
| Google Sheets | Find、Act | 取得結構化資料，執行統計、彙整與比較 |
| Confluence | Find、Understand | 查詢文件、欄位定義、業務規則與背景資訊 |
| Trello | Find、Act、Track | 確認任務狀態、負責人、截止日期與後續進度 |
| PDF 知識庫 | Find、Understand | 取得規範、報告與非結構化文件內容 |
| Coordinator | Decide | 判斷問題類型、工具選擇與執行順序 |
| 語言模型 | Understand、Decide、Act | 整理語意、輔助判斷並產生可讀的結論 |
| 人工審核 | Decide、Track | 處理高風險決策、確認結果並推進後續行動 |
這個架構的重點不是讓 AI 取代所有人，而是讓每個工具負責自己擅長的工作，再由系統把它們串成完整流程。
例如，Google Sheets 擅長提供即時數字，Confluence 擅長提供業務定義，Trello 擅長追蹤專案狀態，語言模型則擅長理解問題與整理內容。
只有將這些能力整合起來，AI 才可能真正支援一段完整的知識工作。
你可以把 AI 想成一位新進的專案助理。
一位真正有用的助理，不只是把你交給他的資料整理得很漂亮。他還需要知道資料是否完整、缺少什麼、去哪裡找、哪些地方需要向你確認，以及工作完成後還有哪些待辦事項。
一個只會 Act 的 AI，就像一位打字很快，卻不知道自己正在整理什麼內容的助理。你必須先把所有資料、定義與結論準備好，再交給他改寫。
這樣的工具當然仍然有價值，但它支援的只是知識工作中的最後一小段。
下次評估一套 AI 工具時，可以問：
這個工具支援 FUDAT 的哪一個階段？
如果答案只有 Act，代表它可能擅長產出內容，卻無法真正處理資料取得、定義理解、判斷與追蹤。
很多團隊開始導入 AI 時，第一個問題是：
「我們要用哪個模型？」
或是：
「要用 LangChain 還是 LlamaIndex？」
這種思考順序很容易讓團隊先選擇工具，再試圖尋找可以套用的情境。最後做出的系統可能技術上很完整，卻沒有解決真正的工作問題。
更合理的順序應該是：
這項工作目前是怎麼完成的？
把現有流程完整畫出來。
每一步需要什麼資料？
確認資料來源、格式、權限與更新頻率。
哪一步最常出錯或最耗時間？
找出真正的流程瓶頸。
哪些部分適合交給 AI？
區分可自動化、需人機協作與必須人工處理的環節。
最後才選擇模型與技術。
根據工作需求選擇 RAG、Tool Use、Agent 或工作流框架。
只有先畫出流程，才知道 AI 應該放在哪裡。
對熟悉業務的人而言，很多定義已經內化成直覺，因此不會特別意識到自己每天都在進行 Understand。
例如，一位資深分析師看到 Priority = P1 時，可能立刻知道這代表高優先級需求，也知道哪些例外情況不適用。但對 AI 而言，這些背景知識並不存在。
如果企業沒有清楚記錄：
AI 即使找到資料，也不一定能正確理解。
因此，Confluence、企業 Wiki、資料字典與流程文件的整理品質，會直接影響 AI 最後能給出多準確的答案。
這也是為什麼企業 AI 專案往往不只是技術專案，同時也是一項知識治理與文件治理工作。
今天只需要記住一件事：
先拆工作，再選 AI；不要先選工具，再硬找使用情境。
知識工作不是單一步驟，而是一條從找到資料、理解定義、做出判斷、產出結果到追蹤後續的完整旅程。
FUDAT 框架可以幫助我們更清楚地判斷：
下一篇，我們會說明為什麼通用 AI 知道很多，卻偏偏不知道你公司的事情，以及模型的通用知識與企業私有資料之間，存在什麼樣的知識邊界。
iThome鐵人賽
看影片追技術