圖 1｜企業 AI 從回答問題，逐步演進到能可靠交付工作成果的六階段成熟度
30 天走到最後，如果只回頭看名詞，這個系列似乎學了很多東西：RAG、Tool Use、LangChain、ReAct、Coordinator、Memory、LangGraph、Retry、CORS、Service Account。但如果把這些名詞全部拿掉，其實我們只做了一件事：把一個只會回答問題的模型，逐步改造成能可靠完成企業知識工作的產品。 這也是 Data Machi 最重要的主線。從聊天（Chat）開始，但不要停在聊天
最早的版本只有模型。使用者提出問題，模型根據既有知識產生回答。這個版本很適合展示生成能力，卻不知道公司內部文件、最新數字與工作進度。 於是我們加入 RAG，讓 AI 回答前先找文件；再加入 Google Sheets Tool，讓精確計算交給程式；接著用 Coordinator 讓系統自己決定該查哪個來源；當決策愈來愈複雜，再用 LangGraph 把流程變成可觀察、可重試、可加入人工審核的 Workflow。 最後，我們處理的已經不只是模型能力，而是可靠性、UX、權限、部署與交接。這才真正跨進 Product。六個階段，其實代表六種不同問題
Chat 解決「模型能不能理解並生成內容」；RAG 解決「模型如何取得企業文件」；Tool Use 解決「如何取得即時、精確或結構化資料」；Agent 解決「有多個能力時，下一步該做什麼」；Workflow 解決「如何控制、驗證與觀察 Agent」；Product 則處理「如何讓真實使用者長期使用」。 這六層不是互相取代。走到 Product 之後，底層仍然有 Chat、RAG 與 Tools。成熟的企業 AI 系統，通常只是把這些能力放在對的位置，而不是找到一個可以包辦全部事情的神奇框架。正式驗收：不要只問「能不能回答」
上線後可以從幾個面向驗收。功能上，測一般對話、文件檢索增強生成（RAG）、結構化數據、跨來源問題與多輪追問；可靠性上，測工具逾時、錯誤憑證、查不到資料與備援（Fallback）；安全上，確認程式碼儲存庫沒有機密資訊、權限符合最小原則；部署上，確認前後端、跨來源資源共享（CORS）、環境變數與健康檢查都正常。 另外也要從使用者角度測一次：他是否知道系統正在查什麼？資料不足時會不會被誤導？錯誤發生後知不知道下一步？這些問題往往比模型 benchmark 更直接影響實際採用。 真正的驗收不會只做一次，也不該只由開發者自己心裡默默確認。比較可靠的做法，是建立一份可追蹤的驗收紀錄——用 GitHub Issue、試算表或專案管理工具，列出測試項目、預期結果、實際結果、負責人與測試日期，並依序跑過功能、失敗、安全、使用體驗與交接五個層次。失敗驗收可以刻意製造問題：移除或填錯 Gemini Key、把測試 Sheet 取消分享、上傳無法解析的 PDF、使用失效 Token、關掉 Render 或改錯 Backend URL——每一種都應該結束 Loading、顯示明確原因，並提供下一步建議，而不是讓畫面卡住不動。交接：讓系統不只屬於開發者本人
正式產品除了功能完成，也需要把營運與交接納入設計。正式產品需要知道 GitHub Repository 誰管理、Render 與 Vercel 誰有管理權限、Google Cloud Project 屬於誰、API Key 如何輪替，以及如果主要維護者離開，下一個人要去哪裡找到設定。 至少應該留下三份資訊：系統架構圖、資產與 Secret 清單、部署與回復流程。Secret 清單不是把密碼寫在文件裡，而是記錄「有哪些憑證、由哪個系統管理、如何輪替」。 交接是否真正完成，最可靠的驗證方式不是「文件寫了沒有」，而是請第二位管理者實際操作一次：讓對方用自己的帳號登入，在沒有原開發者口頭提示的情況下找到 GitHub Organization、Render Workspace、Vercel Team 與 Google Cloud Project；依文件重新部署前後端；找到環境變數名稱與存放位置，但在文件裡看不到完整明文 Secret；建立一組測試 Token、切換環境變數並撤銷舊 Token；最後模擬移除原開發者帳號，確認系統仍能正常運作。只要其中任何一步只有原開發者做得到，就代表交接還沒真正完成，應該回到 Day 28 補齊資產清冊與備援管理者。版本回復也是維護能力的一部分
因為 GitHub 是 source of truth，所以每次修改最好有清楚 commit。當某次更新導致 Production 異常時，可以回到上一個已知穩定版本，而不是直接在線上不停修改。 實務上可以依情況選擇回復方式：小型錯誤直接建立修正 Commit；尚未合併的 PR 可以關閉或修正 Branch；已合併且部署失敗的修改，建立 Revert Commit 或 Revert Pull Request，讓回復也留下正式紀錄；如果問題出在部署平台本身，先查看 Log，避免在不確定原因時連續亂改設定。不要只依賴平台介面上的「重新部署」按鈕反覆嘗試——GitHub 中的程式版本才應該是唯一正式來源。 這也是自然語言輔助開發（Vibe Coding）尤其需要注意的地方。AI 程式開發助手（AI Coding Agent）可以讓開發速度變快，但不代表版本管理可以省略。修改愈快，反而愈需要小步提交（Commit）、測試與可回復性。適合透過雲端 Coding Agent 遠端處理的項目，通常是 Prompt 文案、錯誤訊息、README 或環境變數範例這類小型修正；大型架構調整、PDF／音訊處理與跨服務除錯，則比較適合回到本機完整測試。如果要繼續做，下一步不是再加更多 Agent
完成 30 天後，很容易想繼續加入 Multi-Agent、更多模型或更多資料來源。但下一步應該回到 Day 02 的 FUDAT：你的真實工作流程還有哪些瓶頸？哪一段最常人工切換系統？哪一種答案最需要查核？ 如果新的 Tool 能解決真實痛點，就接；如果 Multi-Agent 只是讓架構看起來更先進，卻沒有改善任務結果，就先不要拆。Data Machi 的方向應該始終從工作問題出發，而不是從框架清單出發。30 天後，你真正完成的是什麼？
你完成的不是一個「會聊天的網站」，而是一個企業 AI 知識工作流的完整骨架：它知道文件去哪裡找、數字交給誰算、多來源如何協調、何時需要追問與補查、流程怎麼控制、服務失敗怎麼處理，以及最後如何安全部署給其他人使用。 這個骨架未必只能用在 Data Machi。未來換成客服助手、內部知識助理、分析 Agent、會議工作流或其他企業場景，核心設計問題仍然非常接近。階段實作六｜完成你的 Enterprise AI Blueprint
現在把前五個階段保存的問題定義、知識驗證集、跨來源流程、Agent 決策邊界與 Workflow 規格放在一起。這一階段不要求你完成 Data Machi，也不要求系統已經部署；目標是形成一份能指導下一步原型、Vibe Coding 或工程開發的設計藍圖。 先用下面八個問題檢查是否還有缺口。這不是另一份框架清單，而是一張從需求、資料、風險到驗收都能走完的設計 Canvas。
這張 Canvas 也可以拿來判斷「要不要加新技術」。如果新的 Agent、Tool 或 Framework 沒有解決上述任何一個具體問題，就不一定值得加入。反過來，只要某個工作痛點清楚落在其中一格，就能回頭找到這 30 天對應的設計能力。
最後用一句話定義第一版：
我要為＿＿提供一套企業 AI，使用＿＿取得可驗證資訊，依照＿＿完成工作；遇到＿＿時追問或停止，涉及＿＿時必須取得人工批准。
最終交付物不是 Data Machi 的複製品，而是你的 Enterprise AI Blueprint：Problem、Knowledge、Tools、Agent Boundary、Workflow、Risk、Evaluation 與 MVP Scope。
延伸實作｜把前面累積的測試變成長期回歸測試
六個階段累積的不只是設計文件，也包含可以持續驗證系統的案例：Day 10 檢查知識與證據，Day 15 檢查跨來源依賴，Day 20 檢查 Agent 是否遵守決策邊界，Day 25 檢查 Workflow 的成功與失敗路徑；如果選擇實際部署，Day 29 再加入正式環境驗收。 Day 30 不需要重新發明一批題目，而是要做更高一層的事情：把前面已經走查的案例保存下來，變成每次修改系統後都能重跑的回歸測試（Regression Test）。 可以依照六階段成果整理測試資料：
真正重要的是不要每次修改系統就重新發明一批題目。固定題目才能比較前後差異。例如更換模型、修改提示詞、調整文件切割、修改工具描述或重構 Workflow 後，都重新跑同一組案例，再觀察哪些題目改善、哪些題目退步。
什麼時候應該重跑？
以下幾種修改都值得重新執行對應測試：- 調整文件切割、向量化或檢索方式 → 重跑 Day 10 的知識與證據測試。
- 新增資料來源或改變查詢順序 → 重跑 Day 15 的跨來源測試。
- 修改工具描述、路由規則或 Agent 停止條件 → 重跑 Day 20 的決策邊界測試。
- 修改 State、Node、Edge、Retry 或 Approval → 重跑 Day 25 的 Workflow 路徑。
- 更新環境變數、權限、部署設定或正式版本 → 選擇實際部署時，重跑 Day 29 的上線驗收。
- 更換核心模型或大幅調整架構 → 所有相關案例都要重跑。
最終完成清單
完成這 30 天後，可以用這份清單確認你的架構是否已經收斂：- 已定義明確的使用者、工作成果與現行 FUDAT 流程
- 已選定第一版要解決的單一核心問題
- 已列出文件、結構化資料、即時系統與各自的 Source of Truth
- 已區分哪些需求使用 RAG、Tool、Workflow 或 Agent
- 已畫出跨來源問題的順序、平行與資料依賴
- 已定義 Agent 可使用的工具、最大步數與停止條件
- 已定義何時回答、追問、重查、部分回答、拒答或轉人工
- 已把流程整理成 State、Node、Edge 與 Failure Path
- 已標記需要最新資料、不可沿用 Memory 的資訊
- 已定義 Timeout、Retry、Fallback 與錯誤訊息
- 已完成角色權限、Secret 與 Human-in-the-loop 邊界
- 已建立固定測試題目、預期證據與驗收標準
- 已把宏大的構想縮成可以驗證的第一版 MVP
30 天的主線不是複製 Data Machi，而是理解一套企業 AI 為什麼需要知識、工具、決策與可控流程，並把這些方法延伸到自己的工作情境。