把 AI Agent 融入開發流程：從專案打地基、建立 Skill 到用 Obsidian 管理專案

這段時間一直在思考一件事：

AI Agent 到底要怎麼真正融入日常開發，而不是只是偶爾叫它幫忙寫幾段程式？

現在幾乎沒有人在開發時完全不用 AI 了。Copilot、Cursor、Claude Code、Codex、Gemini CLI，各種工具一個接一個出現，模型能力也一直在進步。

從一年多前大家還在討論 Prompt Engineering，到現在 AI Agent 逐漸成熟，重點已經不只是「怎麼下 Prompt」，而是 怎麼設計一套能讓 Agent 穩定工作的流程。

不是要說這套方法一定最好，也不是什麼標準答案。比較像是把我這段時間跟 AI 來回協作、踩坑、修正後，慢慢整理出來的工作方式記錄下來。

AI 協作不是一次生成完整專案，而是先打地基
#

我一開始對 AI 協作開發的期待其實很簡單：

能不能讓 Agent 快速融入團隊既有的開發規範，然後協助我們更快把一個專案建立起來？

但真正做下去後會發現，AI 很強沒錯，可是如果一開始什麼都沒給清楚，它也很容易走偏。

AI 最可怕的不是不會做，而是猜得很有自信。

所以我後來比較傾向把整個流程拆成幾個階段，第一步不是直接叫 AI 開始寫功能，而是先建立「專案地基」。

這個地基大致包含幾個部分：

把使用者零碎的需求整理成條列式 Spec。
把團隊已經 Code Review 過、品質穩定的程式碼整理成 Skill，讓 AI 知道團隊規範。
讓 AI 參考相似度高的既有專案，理解架構與實作細節。
透過 Figma MCP 來回溝通前端頁面與 UI 細節。

這些東西看起來只是文件整理，但對 AI 來說其實非常重要。

AI 不會自動知道團隊的習慣，沒有被寫下來的規則，就只能靠猜。

Agent 並不是人類同事，它不會自動知道團隊平常怎麼命名、後端 API 怎麼分層、前端元件放哪裡、資料庫 migration 怎麼管理。這些如果沒有被明確整理出來，它就只能靠猜。

用 Code Review 過的程式碼產生 Skill，讓 AI 先學團隊規範
#

我覺得讓 Agent 融入團隊最重要的一步，就是讓它先理解團隊已經認可的程式碼。

也就是：

團隊已經 Code Review 好的程式碼 → 讓 Copilot 或 Agent 分析 → 產生 Skill → 讓 AI 之後開發時遵守

這裡的 Skill 不只是 coding style，更像是一份團隊開發規範，告訴 AI：

前端元件應該放在哪裡
後端 API 應該怎麼分層
Service、Controller、Repository 的責任怎麼切
命名規則是什麼
哪些寫法是團隊常用模式
哪些設計不要亂改
哪些檔案或設定不能碰

這樣做的目的，不是要把 AI 綁死，而是 先幫它畫出邊界。

我覺得 AI 寫程式最有效率的狀態，不是什麼都讓它自由發揮，而是：

大方向、架構、規範要清楚； 細節實作可以讓 AI 自由發揮。

這有點像帶新人。如果新人剛進團隊，你不可能只跟他說「幫我做一個會員系統」，然後期待他自動符合團隊所有規範。你會先給他看既有專案、說明架構、介紹 SOP，再慢慢讓他接任務。

AI Agent 其實也是一樣。

初期模板只是房子的基底，不可能一開始就很穩
#

有了 Skill 之後，下一步就是讓 AI 根據初期模板與 Spec，建立一個專案基底。

我的做法通常是把現有 codebase、團隊 Skill、大方向 Spec 和初期程式碼模板一起交給 AI，讓它先建立一個「房子的基底」。

這個 Spec 一開始不用非常細，可能只要先定義大方向，例如：

這個頁面需要哪些主要模組
後端大概要有哪些 API
資料庫有哪些主要資料表
角色權限大概怎麼切
前端頁面流程大概長什麼樣子

但這個基底一開始通常不會太穩，實際上常常會遇到一些很現實的問題：

前端啟動不起來
後端設定檔有問題
資料庫連線設定不完整
migration 還沒整理好
deploy config 需要調整
環境變數缺漏
package 或 dependency 版本不一致

所以我覺得 AI 協作開發比較真實的樣子，不是一次就把完整專案生出來，而是：

先讓 AI 快速搭出基底，再透過多次迭代，把基底修穩。

地基如果不穩，後面功能做越多，問題只會越滾越大。

AI 很會堆功能，但如果底層架構歪掉，後面修起來會更痛苦。

AI 可以做很多，但工程師不能完全放手
#

我現在已經不太會手寫那麼多程式碼了，更多時間是花在拆任務、寫 Spec、分配工作給 Agent、決定系統架構、Review AI 產出的 Code，以及判斷 AI 有沒有走偏。

有趣的是，很多時候 bottleneck 反而還是在我這裡。Agent 一下就把東西做完了，真正花時間的是確認它做得對不對，以及下一步要讓它做什麼。

Agent 寫得很快，真正花時間的是確認它做得對不對。

有人說現在 Agent 產出的程式碼品質已經很好，甚至可以不用看，或者再丟給另一個 Agent Review 就好。我某種程度上同意，現在 AI 的表現真的已經很強，大部分時候不會犯太低級的錯。

但可能還是有一點工程師的堅持吧，我還是會想看一下。

不是不信任 AI，而是我覺得：

Review AI 產出的程式碼，本身也是一種重新理解系統的過程。

有時候它寫出來的東西還會讓我學到新的寫法。與其說我在監督 AI，不如說我也在跟 AI 一起學習。

哪些工作適合交給 AI？
#

在目前的開發流程裡，我覺得有幾類工作特別適合交給 AI。

第一種是依照 Skill 產生程式碼。只要團隊規範、檔案結構、命名方式和架構邊界定義清楚，AI 很適合負責重複性高、模式明確的實作。

模式明確、重複性高的工作，最適合先交給 AI。

例如：

後端 CRUD API
Service 基礎邏輯
DTO、Request、Response 類別
前端頁面模板與表單欄位
基礎驗證邏輯
單元測試草稿

第二種是 Terminal 錯誤與 Log 分析。以前看到一長串 error log，可能要自己慢慢找關鍵字、查 Stack Overflow、確認版本和設定。現在可以直接把 log 丟給 Agent，讓它分析可能原因，甚至幫忙修改設定檔。

第三種是前後端模板與 API 對接。例如前端頁面大致完成後，可以讓 AI 根據後端 API 規格產生串接邏輯；或是根據前端需求反推後端需要補哪些欄位。這種跨檔案、跨層級的修改，Agent 其實很適合做。

但有些事情我還是不會完全交給 AI：

核心決策可以讓 AI 提供建議，但最後的放行權仍然在人。

核心資料模型設計
權限與安全邏輯
資料庫 migration 放行
系統架構方向
重要商業邏輯
最終 Code Review

這些地方 AI 可以協助分析、提出建議、產生初稿，但最後還是需要人來判斷。

要怎麼放心讓 AI 去做？
#

要把任務交給 AI，前提是要有安全邊界。不然 Agent 的權限太大，其實也滿可怕的。

讓 AI 放手做之前，先把不能做的事情定義清楚。

我目前會用幾種方式降低風險。

第一個是 WSL 沙盒環境。我會在 WSL 裡開 VS Code，讓 Agent 在相對隔離的環境中操作。這樣即使它做錯事，也比較不會直接影響主系統。

第二個是 Hooks 或 IDE Agent mode 的指令限制。有些指令我不希望 AI 自己執行，例如危險的刪除指令、直接操作正式環境，或修改敏感檔案。這些我會透過 Hooks 或 Agent 設定限制。

第三個是 checkpoint 和 Git Rollback。如果只是想回到 Agent 某次對話前的狀態，可以使用 Agent 本身的 checkpoint；但如果整個專案要回到前幾個版本，我還是比較信任 Git。

Git Rollback 比 Agent checkpoint 更穩定，也更適合處理專案層級的版本控制。

簡單來說，我會讓 AI 放手去做，但不是毫無防護地放手。

我讓你在遊樂場裡自由奔跑，但圍欄、出口和危險區域都先設好了。

Obsidian：讓 AI 真的看得懂專案管理
#

如果要讓 AI 協作穩定，我覺得 給 AI 吃什麼，比怎麼下 Prompt 更重要。

我目前很依賴 Obsidian 做專案管理。原因很簡單：Obsidian 本身就是 Markdown，對 AI 非常友善。

它的好處是人和 AI 都看得懂。對人來說，可以透過資料夾、連結、Kanban 和圖形化套件管理專案；對 AI 來說，這些文件都是文字格式，可以很自然地放進 Context Window 裡。

我會把專案相關文件整理在 Obsidian 裡，例如：

User Spec
專案規格書
前端頁面設計
後端 API 規格
資料庫設計
任務清單
問題追蹤
Agent 執行紀錄

其中我很常用的是 Kanban 套件，會把任務分成 ToDo、Doing 和 Done。當我要讓 Agent 執行某個任務時，就把它丟到 Doing。Agent 可以根據任務內容，對照 Obsidian 裡的 Spec 和相關文件來執行。

這樣做有一個很大的好處：

AI 比較不容易走歪路。

因為任務不是孤立的一句話，而是可以連回規格書、API 文件、資料庫設計和相關上下文。

Obsidian 的資料夾階層和文件連結，本身就像一張知識地圖。透過 Skill 定義好資料怎麼分類、哪些文件對應哪些功能，Agent 就能更快找到需要的內容，放進 Context Window 裡。

它不是只有人看得懂的專案管理工具，也不是只有 AI 能吃的文字檔，而是兩邊都能使用的橋樑。

用 Figma MCP 讓設計與前端來回對齊
#

前端畫面是另一個很適合透過 MCP 協作的地方。

以前只用文字跟 Agent 說「這裡放一張卡片、下面加一個按鈕」，它確實做得出來，但間距、顏色、字體和元件結構，常常還是會跟設計稿有一段差距。

文字可以描述畫面，但很難完整描述 UI 細節。

所以我會透過 Figma MCP，讓前端 Agent 直接參考實際設計稿。它不只是看一張截圖，而是能進一步理解頁面結構、元件層級、版面配置、色彩、字體和互動細節，再轉成可以運作的前端程式碼。

這個過程也不是單向把 Figma 轉成 Code。Agent 在實作時如果發現元件不好拆、互動方式不清楚，或設計在前端實作上有限制，也可以把問題整理出來，再回頭調整 Figma 或補充 Spec。

也就是在 Figma 與前端程式碼之間來回確認：

Figma 提供完整的視覺設計依據
Agent 根據設計稿拆元件、接邏輯並產生可運作的畫面
工程師確認實作結果、元件可行性和前端限制
有落差就回頭調整設計或程式碼，再繼續下一輪

這樣 Agent 就不需要只靠文字猜 UI，產出的畫面也會更貼近設計規格。

Figma MCP 比較像設計與程式之間的溝通橋樑，不是按一下就能完美還原的轉換器。

MCP 很方便，但不能為用而用
#

MCP 可以讓 AI 取得外部系統的資訊，甚至直接操作工具，確實很方便。但不同系統的風險不一樣，適合拿來讀取設計稿，不代表也適合讓它直接修改重要資料。工具好用，不代表什麼都該交給它直接做。

MCP 解決的是取得資訊與操作工具的問題，不是替人做最後決策。

資料庫就是我會特別小心的地方。我不太會讓 AI 直接透過 MCP 去改資料庫，原因很簡單：

改壞的風險太高。

我的做法是讓 AI 產生 Liquibase migration script，再由人來 Review。如果任務需要修改資料庫，我會請 AI 根據需求、既有 migration 歷史、後端程式碼與 SQL 使用情境，規劃應該產生什麼 migration script，但不會讓它直接連線到資料庫動手改。

AI 產出 migration 後，我會人工確認：

SQL 是否正確
欄位型別是否合理
是否會影響既有資料
是否需要 Rollback
是否符合命名規範
是否有潛在資料遺失風險

確認沒問題後，才會在部署時執行 migration。

AI 產生 migration，人類 Review 後才放行。

Liquibase 本身也有安全機制，例如 migration 檔案檢查、已執行檔案的 checksum 驗證，這些都能幫助維持資料庫環境的穩定性。更重要的是，migration 歷史也會成為未來 AI 的 Context。

之後 Agent 在規劃新功能時，可以參考過去資料庫是怎麼演進的，而不是每次都從零開始猜。

AI 協作的完整流程：掌握方向，再放手去做
#

整理下來，我目前的做法其實可以濃縮成幾個階段：

先把零碎需求整理成 Spec，再用既有專案、Skill 和 Figma MCP 把架構、規範與畫面方向定清楚。
讓 AI 搭出初期專案基底，先處理啟動、環境、資料庫和部署設定，確定地基可以正常運作。
用 Obsidian 管理規格與任務，透過 Kanban 把工作拆成 ToDo、Doing、Done，讓 Agent 知道現在要做什麼，也找得到相關 Context。
把模式明確、重複性高的實作交給 AI；架構、權限、資料模型和重要商業邏輯則由工程師掌握。
Agent 完成後再 Review，發現方向不對就即時修正。需要反悔時用 checkpoint 或 Git Rollback，資料庫異動則由 AI 產生 migration，人類確認後才放行。

這個流程不會跑一次就結束。需求會改、Spec 會補、AI 可能會做錯，架構也會跟著調整。每次來回都把程式碼、文件和 Skill 再整理得更完整，專案才會慢慢收斂成穩定、可維護的狀態。

可控迭代，比一次生成完整專案更接近真實的開發流程。

這段時間實作下來，我覺得 AI 協作真正改變的，不是工程師從此不用寫程式，而是工作的重心開始移動。以前花很多時間手寫程式碼、查錯誤和補模板，現在可以把這些工作逐漸交給 AI，工程師則把時間放在定義問題、拆解任務、設計架構、控制風險和 Review 結果。

但如果什麼都自己控制，AI 的效率發揮不出來；什麼都放手，又很容易變成一直 Review、一直修、一直把它拉回來。

所以我目前比較習慣的方式是：