先看懂整張產品地圖
整個系統可以先簡化成五層：使用者透過前端提出問題；後端接收請求並管理工作流程；語言模型理解問題與整理答案；不同工具負責取得企業資料；協調者（Coordinator）則負責決定何時呼叫哪一個工具，以及結果不足時下一步怎麼做。
圖 1｜Data Machi 的開發流程與正式產品架構
這裡有一個很重要的區分：Claude Code、Codex 或其他 AI 程式開發助手（AI Coding Agent）是幫你「開發 Data Machi」的工具，不是 Data Machi 正式運作時的一部分。 真正上線後持續服務使用者的，是前端、後端、模型與各資料來源。 實際動手前，可以先用一張表記住每個服務的角色與必要程度，之後申請帳號、設定環境變數時才不會漏掉重要的一步：階段實作一｜定義你的企業 AI 問題
從這一天開始，我們會在 Day 05、10、15、20、25、30 累積六份設計成果，最後組成一份屬於你自己的 Enterprise AI Blueprint。這條主線不要求你複製 Data Machi，也不要求一開始就寫程式；Data Machi 只是一個用來理解架構如何落地的案例。 先選一段你熟悉、重複發生，而且需要在多個資訊來源之間切換的工作。不要從「我想做一個 Agent」開始，而要從「誰正在完成什麼工作」開始。
最後用一句話收斂：
我要為＿＿建立一套企業 AI，協助他們從＿＿取得資訊，完成＿＿；當＿＿發生時，系統必須停止、追問或交由人工處理。
保存這份「問題定義」。Day 10 會從這個情境挑出一項知識來源，建立第一份可以驗證的企業知識測試。
動手寫程式前，先選好你的 Vibe Coding 方式
建立 Data Machi 不代表要先精通所有語法。更實際的做法是先描述目標，再讓 AI Coding Agent 協助閱讀 Repository、修改檔案、執行測試與說明錯誤——這就是 Vibe Coding。實務上大致分成三種方式：本機開發
適合第一次啟動、修改多個模組、測試 PDF／音訊，以及查看完整 Terminal 錯誤。
雲端開發
適合透過桌機或手機進行 Prompt、文案、設定與小型修正，再建立 Commit 或 Pull Request。
混合式開發
大型修改在本機完成，臨時調整使用雲端環境，GitHub 保存唯一正式版本。
GitHub 為什麼會成為整個流程的中心？
如果後面要把專案部署到 Vercel 與 Render，就不能把本機電腦視為唯一正式版本。實務上更合理的方式，是把 GitHub 程式碼儲存庫視為單一正式來源（Source of Truth）：本機或雲端的 AI 程式開發助手都從同一個儲存庫修改程式，完成後提交（Commit）、推送（Push），再由部署平台從 GitHub 取得最新版。 因此 Repository、Commit、Branch 與 Pull Request 並不是額外的工程知識負擔，而是確保這個專案不會因為換一台電腦、換一個開發者或部署失敗就失去控制。可以先弄清楚這四個名詞各自的責任：Repository
一個專案的中央資料夾，包含程式碼、設定、文件與版本紀錄。
Commit
一次有意義的修改快照。好的 Commit 應該能說明這次改了什麼，以及必要時如何回復。
Branch
從主要版本分出的獨立修改線，適合讓 AI Coding Agent 在不影響正式版本的情況下工作。
Pull Request
把 Branch 的修改提交給主要版本前，用來檢查 Diff、測試結果與風險的審查入口。
main 的流程，而不是直接改正式分支。這能避免雲端 Agent 一次改壞正式版本，也讓你手機上臨時修改的內容，回到電腦時仍能清楚看到變更範圍再決定要不要合併。
開始實作前，先建立自己的專案副本
如果你是從 Data Machi 的開源版本開始，第一件事情不是直接修改正式設定，而是先建立自己的副本。你可以 Fork 或複製 Repository，移除不屬於自己的品牌名稱、正式資料來源與環境設定，再建立自己的.env。這樣後面所有 API Key、測試資料與部署設定才不會和原專案混在一起。
去識別化不只是改名稱。除了品牌文字，也要優先檢查以下位置，把可以推回真實組織的資訊換成中性範例：
- README、頁面標題、Logo 與前端文案
- Agent 使用的 Prompt 與資料描述
- 預設 Spreadsheet Key、Board ID、Space URL
- CORS 中的正式網域
- 部署設定檔、範例資料與測試截圖
.env.example，讓後面每一天新增的服務都能對應到同一張環境變數地圖：
本機開發：先確認前後端骨架
Data Machi 採前後端分離架構。React 前端負責畫面與互動，FastAPI 後端負責模型、資料工具與工作流。實作時應該先個別確認兩邊都能啟動，再測試前端是否能透過 API 找到後端。http://localhost:8000/docs 確認 FastAPI 已正常啟動。接著另開一個 Terminal 啟動前端：
http://localhost:5173，確認畫面能載入，且輸入問題後請求真的送到了後端。如果 localhost:5173 打得開卻不能聊天，通常是後端未啟動、API Base URL 設錯或 CORS 問題；如果 /docs 打不開，先回頭看後端 Terminal 的套件或環境變數錯誤。
這裡不要急著一次把 RAG、Sheets、Coordinator 全部接上。如果前端連不到後端，你卻同時在檢查 Gemini、向量搜尋與 Google 權限，除錯會非常痛苦。實作系列後面會反覆使用同一個原則：一次只驗證一層。
我們接下來會怎麼把它做出來？
接下來 25 天不是另外一套「實作篇」，而是會直接把功能逐步加入這張架構圖。Day 06–10 先建立文件 RAG；Day 11–15 加入結構化資料工具與跨來源查詢；Day 16–20 讓系統開始自主選擇工具；Day 21–25 處理記憶、查核與 LangGraph 工作流；最後 Day 26–30 再處理可靠性、UX、安全、部署與交接。 換句話說，從今天開始，每學到一個概念，我們就會知道它實際放在 Data Machi 的哪一層，而不是把觀念與實作拆成兩套彼此平行的內容。實務補充｜Demo 和真正能用的產品，差在哪裡？
真正把 Data Machi 從展示原型推向可使用產品時，會遇到四個很典型的問題：明明有資料卻第一次查不到、模型說「我幫你查」卻沒有真的呼叫工具、同一份資料到底要不要重新查，以及任務花十幾秒時使用者不知道系統是不是壞了。 這四件事看起來都不是炫目的 AI 技術，卻正是展示原型與可使用產品之間最常見的落差。 對非工程背景的讀者，可以把它理解成：模型能力只是「員工本身會不會做事」，產品能力還包括「資料找不找得到、流程有沒有真的執行、資訊是否過期，以及使用者是否知道進度」。後面的 Retrieval、Memory、Verification、UX 與 Workflow，其實都在逐步解決這四種真實問題。延伸理解：好的企業 AI 也需要清楚說明邊界
延伸理解：好的企業 AI 也需要清楚說明邊界
系統定位不應該是「什麼都能回答的 AI 助理」，而應清楚說明它能做什麼、不能做什麼，以及超出能力範圍時會如何處理。能處理的問題要有可靠來源；不能處理的問題要明確承認資料不足。明確的邊界不是缺點，而是建立信任的起點。
今天只要記住一件事：Data Machi 不是一支 AI 程式，而是一組被 GitHub、前後端、模型、資料工具與工作流串起來的服務。先看懂整張圖，後面的每一個實作才知道自己正在改哪一層。