AI Engineering 實戰｜Day 01
從真實專案回看：一套 AI 開發流程是怎麼長出來的
我原本主要做資料庫管理，沒有寫過前端架構。
這篇是我第一次用 AI，把既有 Notebook 流程搬到 Web 的經驗。
現在談 AI Engineering，很容易從 Agent、MCP、Skill、Multi-Agent 開始。這些名詞很吸引人，也確實是我現在日常使用 Claude Code 開發時的一部分。
但回頭看 DAP 權限管理平台（以下簡稱 DAP）的演進，我不是從這些東西開始的。
我一開始遇到的問題其實很單純：有一套既有的 Notebook 工具，協助處理資料表與權限申請。使用者選好內容後，系統會產生結構化資料與後續要處理的 SQL。它可以運作；只是功能變多以後，Notebook 愈來愈不適合處理大量點選式操作，維護也愈來愈辛苦。剛好原本的開發平台準備下線，我們決定把這段流程搬到 Web。
第一代 Notebook 不是我開發的，而是同事留下的前代工具。因此，這個系列真正屬於我的故事，從第二代開始。
第二代的目標很明確：把 Notebook 中「使用者操作頁面到產生 JSON」的流程，搬到一個更容易使用與維護的 Web 介面。
我當時主要做資料庫管理，熟悉 API 與後端資料庫，但沒有寫過前端架構。要開發一個 Web 系統，對我來說也是一項挑戰。當時剛好接觸到 Vibe Coding，我想試試它能做到什麼程度。
後端選用團隊熟悉的 FastAPI 架構；前端選擇 Vue 與 Element Plus。選型沒有追求炫技，而是希望用相對輕量、同事也有使用經驗的技術，先把基本功能做出來。我的工作主要在前端與需求細節，另一位同仁負責後端；我們之間最重要的交界是 API 規格。
這個挑戰前後花了九個月，大致走過三個里程碑：
第一個功能是資料表抄寫申請。它會牽涉多個環境、遮罩欄位、保留期限、抄寫頻率，以及不同環境的權限。這不是拿一個空白頁面來練習前端，而是把一段已有業務規則的工作搬到 Web。我的任務是規劃 Web 畫面與操作流程，讓使用者更順暢地完成申請，同時讓產出的結果維持與原本 Notebook 一致。
使用者選擇申請內容
↓
Web 收集結構化資料
↓
後端產生 JSON／SQL 結果
↓
既有後續作業接手處理
現在回頭看，當時的做法很接近大家說的 Vibe Coding。
我會先把需求說給 AI 聽，讓它協助做出功能；接著看畫面、看按鈕行為、看 API 串接結果，再補充細節，請它繼續修改。原本沒有前端開發經驗的我，第一次明顯感覺到這種方式的不同：我可以先用熟悉的業務語言描述「這個功能要做什麼」，再一步一步把頁面推進。
例如，權限表格裡的勾選位置，看起來只是小事，但實際上我和 AI 反覆調整過很多次。按鈕要往哪裡移、文字要大一點還是小一點，這些通常不是一開始就能講清楚。先看到結果，再修正描述，是當時很自然的開發節奏。
描述功能
↓
AI 實作
↓
看畫面與結果
↓
補充細節
↓
再修改
如果只看表面，這段經驗像是我把需求丟給 AI，AI 就把 Web 做出來了。老實說，當時我覺得這個工具真的很神奇。
不過，這裡的 Vibe Coding 和「完全不看程式碼、只看結果能不能用」並不完全一樣。Martin Fowler 對 Vibe Coding 的嚴格定義，就是幾乎不看 AI 產生的程式碼。我的經驗沒有那麼極端：我仍然要確認需求、和後端同仁討論 API 規格，也會依結果調整方向。本文所說的 Vibe Coding，比較接近「自然語言主導、反覆看結果調整」的開發方式。Martin Fowler 對 Vibe Coding 的說明
真正支撐這段開發的條件，很多在 AI 出場前就已經存在。
開發環境可以讀到 API 規格，input 和 output 有明確定義。後端也先把產生 SQL 與 JSON 的業務邏輯包成 function，AI 主要協助把既有能力組合、串接到前端流程，而不是自己發明資料規則或 SQL 邏輯。再加上前後端分工與 API 討論，AI 並不是面對一張白紙。
| 看起來像是 | 實際上已存在的工程邊界 |
|---|---|
| 我描述一個功能，AI 開始寫頁面 | Vue、Element Plus 與既有系統架構 |
| 按鈕送出申請 | 已定義的 API input／output |
| AI 協助串接流程 | 後端已封裝的業務 function 產出 JSON／SQL |
| 功能完成 | 前後端分工、試用與後續的產出比對 |
因此，我不會說 Vibe Coding 天生就穩。在 DAP 的這個階段，AI 進入的是一個已有 API、既有 function 與人類分工的改造任務；這些邊界讓它能協助我快速把功能往前推。
這也和 Anthropic 對 Claude Code 的建議相呼應：工具不會強制唯一的工作流；任務變複雜時，先探索與規劃，再實作與驗證，通常比直接一路寫到底更有幫助。Claude Code Best Practices
Thoughtworks 的實驗也提出相近提醒：自由產生可運作的雛形很有價值，但隨著修改、回歸與維護要求增加，架構、測試、回饋與人類監督會變得更重要。Can vibe coding produce production-grade software?
這些公開資料只能幫我理解自己的經驗，不能替 DAP 證明品質。我沒有一組對照實驗，也沒有足夠數據證明 API contract 讓正確率提升多少。我只能說，回頭看，這些是我早期沒有立刻卡住的重要條件。
第二代後來累積到十二項功能。這時候，問題開始不只是一個頁面能不能做出來，而是修改後的 JSON／SQL 產出有沒有改壞。於是我們開始用 Python 比對結果，也在持續開發中加入 pipeline。
之後，新的單據管理流程、畫面重整與跨角色協作，才讓我走向第三代：用 Spec、Plan、Task 來處理更大的範圍，再逐步發展成今天由 /orchestrate 協調的工作流程。
我不把 SDD 視為 Vibe Coding 的反面。Vibe Coding 讓我先跨過前端門檻、把已知流程搬到 Web；系統複雜度提高後，我才開始看見哪些工程機制必須慢慢長出來。
流程不是我一開始設計好的答案，而是系統變複雜後，逐步長出來的回應。
今天先不要急著建立 Agent、Skill 或完整 8-Step。請選一個接下來 29 天會使用的既有 Git repository，再挑一個真實的小流程或功能，寫下這四件事：
1. 我想改善的一個真實流程／功能：
2. 它現在的輸入與預期輸出：
3. 哪些既有程式、API、資料或同事是它的真相來源：
4. 我不希望 AI 自行猜測或修改什麼：
這還不是 Spec，也不需要改程式。它只是幫你找到一個 AI 可以先協作、而不是必須從零猜測的工作起點。
下一篇，我會拆開問一個更具體的問題：同樣是直接描述需求，為什麼 DAP 在第一階段相對順？API contract、function 邊界與輸入／輸出規格，到底怎麼影響 AI 的協作品質？
iThome鐵人賽
看影片追技術