*圖 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。 | 問題 | 要釐清什麼 | | -------------------------- | --------------------------------------------------- | | **1. Job** | 使用者真正想完成的工作是什麼？ | | **2. Workflow** | 現在這件事怎麼完成？哪些步驟最耗時、最容易錯？ | | **3. Knowledge** | 需要哪些文件、結構化資料、即時系統與外部來源？ | | **4. Intelligence** | 哪些步驟需要 LLM 的語意理解、摘要或判斷？ | | **5. Deterministic Logic** | 哪些計算、驗證、格式與流程一定應該由程式保證？ | | **6. Risk** | 哪些資料或動作需要權限隔離、人工確認或稽核？ | | **7. Evaluation** | 怎麼知道答案正確、路由正確，而且任務真的完成？ | | **8. Recovery** | Tool、模型或資料來源失敗時，系統如何 Retry、Fallback、Resume 或讓使用者接手？ | 這張 Canvas 也可以拿來判斷「要不要加新技術」。如果新的 Agent、Tool 或 Framework 沒有解決上述任何一個具體問題，就不一定值得加入。反過來，只要某個工作痛點清楚落在其中一格，就能回頭找到這 30 天對應的設計能力。 最後用一句話定義第一版： > 我要為＿＿提供一套企業 AI，使用＿＿取得可驗證資訊，依照＿＿完成工作；遇到＿＿時追問或停止，涉及＿＿時必須取得人工批准。