為什麼我想開始這個專案？

這幾年，我在工作中持續接觸資料分析、自動化、生成式 AI 與企業知識管理，也開始反覆思考一個問題：

除了回答問題之外，AI 能不能真正參與企業的日常工作？

現在已經有許多教學示範如何串接大型語言模型、建立聊天機器人，或快速完成一個 RAG Demo。這些示範通常可以在短時間內完成，也很容易讓人感受到生成式 AI 的潛力。

但當我們真的想把這些技術放進企業環境時，問題往往才正要開始。

企業文件可能分散在 Google Drive、Confluence、Notion、PDF 與不同資料庫中，格式不一致，更新頻率也不同。AI 即使找到了資料，也不代表它理解公司的欄位定義、縮寫與作業規則。單純的 RAG 可以讀取知識，卻未必能進一步操作企業工具；而 Agent 雖然能呼叫工具，它的決策過程又可能成為難以理解的黑箱。

當工具執行失敗時，系統還需要處理 Timeout、Retry 與 Fallback；當任務涉及敏感資料或高風險操作時，也必須加入人工審核。一個可以展示的 Demo，距離真正可以被企業採用的產品，往往還有很長一段距離。

我逐漸發現，真正困難的地方通常不是「怎麼呼叫一個模型」，而是如何把模型、企業知識、工具、流程與人的判斷整合在一起。

因此，我開始建立 Data Machi。

這套 30 天系列只有一條主線：從一個只能聊天的模型開始，逐步加入企業資料、工具、決策、流程控制與產品化能力，最後完成可以實際部署的 Data Machi。 觀念與實作會交錯進行，讓每個技術概念都能回到真實工作問題中理解。

每五天是一個階段。每個階段都先回答「為什麼需要這個能力」，再把它放進同一套系統裡。這樣不需要先讀完大量理論才開始動手，也不會完成一堆 API 設定後，仍不知道它們在整體架構中的位置。

第一階段｜Day 01–05：從聊天到企業 AI

先從企業知識工作的問題開始，而不是從框架開始。這五天會釐清聊天機器人與企業 AI 的差異、FUDAT 知識工作框架、模型的企業知識邊界，以及為什麼提示詞（Prompt）無法取代工作流程（Workflow）。Day 05 會把這些觀念收斂成 Data Machi 的完整產品地圖。

第二階段｜Day 06–10：讓 AI 找到企業知識

第二階段集中處理檢索增強生成（RAG）。從基本概念開始，接著理解 PDF 如何經過解析（Parse）、文件切割（Chunking）、向量化（Embedding）與建立索引（Index），並比較關鍵字搜尋與語意搜尋。Day 09 會處理掃描 PDF、表格與圖片等真實文件問題，Day 10 則完成第一個能引用來源的 PDF RAG。

第三階段｜Day 11–15：從文件檢索走向工具使用

RAG 可以查文件，但無法自然處理最新數字與外部系統狀態。這五天會從 RAG 的能力邊界進入工具使用（Tool Use），理解 LangChain 在工具整合中的角色，再實際建立 Google Sheets 資料工具。最後畫出企業知識地圖，並完成一次試算表與文件的跨來源查詢。

第四階段｜Day 16–20：從工具走向代理

當工具變多，就不可能永遠靠固定條件判斷。這一段會說明什麼時候工具使用才真正變成代理（Agent），再用推理與行動（ReAct）理解「判斷 → 行動 → 觀察」的循環，並釐清路由器（Router）與協調者（Coordinator）的差異。Day 19 會建立 Data Machi 協調者，Day 20 再加入多來源、平行與順序執行的設計。

第五階段｜Day 21–25：把代理變成可控工作流程

代理可以自主決策，但企業不能只追求自主性。這五天會依序加入記憶（Memory）、問題釐清（Clarification）與答案驗證（Verification），再說明黑箱式代理循環為什麼難以控制。接著介紹 LangGraph 的狀態（State）、節點（Node）與連線（Edge），最後把協調者改造成一條可以觀察、驗證與重試的工作流程。

第六階段｜Day 26–30：從展示原型走向產品

最後五天不再增加更多代理名詞，而是處理真正上線會遇到的問題。逾時（Timeout）、重試（Retry）與備援（Fallback）讓系統在外部服務失敗時有退路；代理使用者體驗讓使用者知道系統正在做什麼；安全與治理則處理 API 金鑰、權限與資產所有權。Day 29 會把後端部署到 Render、前端部署到 Vercel，Day 30 再回顧整套系統並完成驗收與交接。