> ## Documentation Index
> Fetch the complete documentation index at: https://data-machi.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Day 02｜知識工作到底在做什麼？用 FUDAT 拆解五個關鍵步驟

> 把抽象的「知識工作」拆解成 Find、Understand、Decide、Act、Track 五個階段，理解 AI 應插入哪個環節才能提升效率。

<Frame>
  <img src="https://mintcdn.com/data-machi/Hyfs0AhNXMsF2W1V/day02.png?fit=max&auto=format&n=Hyfs0AhNXMsF2W1V&q=85&s=a3bd4a9e68044da9143c4232fcab5846" alt="Day02" width="1672" height="941" data-path="day02.png" />
</Frame>

<p align="center">
  *圖 1 知識工作從找資料到追蹤成果的完整旅程*
</p>

我們常說 AI 可以提升知識工作效率，但如果進一步追問「知識工作到底是什麼」，答案通常沒有想像中清楚。很多人會把它理解成查資料、寫報告或做簡報，但真正的工作往往是一段從資訊取得到後續追蹤的完整流程。

如果沒有先把這段流程拆開，AI 導入很容易只自動化最後的文字產出。表面上看起來速度變快了，實際上前面的資料查找、定義確認、計算與決策仍然全部靠人工。這也是為什麼我會先用 FUDAT 框架，把常見的企業知識工作拆成五個階段。

## FUDAT：一段知識工作是怎麼完成的？

**Find** 是找到正確的資料來源。資料可能散落在 Google Sheets、Confluence、PDF、專案看板或資料庫裡，真正困難的往往不是「公司有沒有資料」，而是「哪一份才是正確而且最新的版本」。

**Understand** 是理解定義與背景。即使找到資料，如果不知道欄位代表什麼、分類規則是否有改過、哪些資料應該排除，後面的分析仍然可能全部建立在錯誤基礎上。

**Decide** 是決定該怎麼回答問題。主管問「今年工單表現如何」，可能是在問數量趨勢、主要市場、問題分類，也可能真正想知道的是哪個議題最需要優先處理。這一步需要把資訊轉換成分析方向。

**Act** 才是我們最熟悉的輸出，例如整理報告、產生結論、建立任務或提出建議。最後的 **Track** 則是追蹤這個結果有沒有真的被使用，以及後續工作是否完成。

## 用 Data Machi 的情境走一次

假設使用者問：「今年哪一類需求最多，相關改善專案目前進度如何？」Data Machi 不應該直接讓模型憑文字理解產生答案，而是依序完成幾件事：先從結構化資料找到今年的工單，接著從文件確認分類定義，再計算各類別的數量，最後才去專案工具查改善進度。

這個例子也說明不同工具其實對應 FUDAT 的不同階段。Google Sheets 比較適合「尋找資料（Find）」與精確計算，Confluence 或 PDF 協助「理解（Understand）」，協調者（Coordinator）負責「判斷（Decide）」，而 Trello 類工具則能補上「追蹤（Track）」。

## 為什麼不要從「用哪個模型」開始？

很多 AI 專案一開始會討論 Gemini、GPT、Claude，或 LangChain、LlamaIndex 哪個比較好。但如果連原本的工作流程都還沒有畫清楚，技術選型其實很容易變成倒果為因。

更好的順序是先問：這項工作目前怎麼完成？每一步需要什麼資料？哪一步最耗時間、最常出錯？哪些部分需要判斷，哪些部分可以交給程式？當這些問題有答案後，才比較知道 AI 應該出現在哪裡。

這也是 Data Machi 後面所有設計的基礎。不是先決定「我要做 Agent」，再找一個情境塞進去，而是先看工作本身需要什麼能力，再逐步加入 RAG、Tool Use、Agent 與 Workflow。

<Info>
  今天先記住一件事：先拆工作，再選 AI。真正值得自動化的，通常不是最後那段文字，而是整條工作流程中最耗時間、最容易出錯的環節。
</Info>

下一篇，我們會進一步看一個更根本的問題：為什麼通用 AI 明明知道很多事情，卻不知道你公司昨天才更新的資料？
