Day 01 我提到，DAP 的第二代不是從 Agent 或複雜流程開始，而是先用 Vibe Coding 把 Notebook 的人工作業搬到 Web。
今天，我想分享一個當時很實際的情況：為什麼 AI 能幫我們把功能做出來，業務邏輯也是正確的？

當時我和同事要把原本在 Jupyter Notebook 中處理的申請流程搬到 Web。前端使用 Vue 與 Element Plus，後端使用 FastAPI。這九個月裡，我們逐步完成了 12 項功能的移轉。

我當時的開發想法很直接：把功能頁面需求告訴 AI，再根據畫面、按鈕與 API 串接結果反覆調整程式碼。對一個沒有太多前端經驗的人來說，這很有幫助。原本要慢慢摸索的元件、表單與串接，現在能很快做出可操作的版本。

不過，Vibe Coding 能順利在這階段完成，不只因為 llm 模型會寫程式，也因為我們不是把所有問題都交給它猜。

API 是我們共同確認的邊界

第二代的後端 API 並不是一開始就全部存在。前端與後端都是用 Vibe Coding 協助開發；我負責前端與需求整理，另一位同仁負責後端。我們會先討論 API 的 input 與 output，再各自往前實作。

API 規格以 Swagger 呈現，並透過口頭討論或每週專案會議確認。這讓前端、後端與 AI 對「資料要怎麼交換」有共同參照。

以選擇專案的畫面為例，前端需要知道：選定專案後，應該呼叫哪一支 API、要帶什麼輸入、回來的資料有哪些欄位。後端則負責依這些輸入取得該專案的使用者、PM 等資訊，再回傳給前端。

這種切分看起來很普通，但這讓我在和 AI 協作時少了一個大問題：每次修改前端，不需要同時猜後端資料會長什麼樣子。

有些規則放在資料庫 function，AI 不必從頭推測

DAP 有不少資料庫相關的業務規則。部分查詢與資料處理，原本就已經封裝在資料庫 function 中；例如取得目前資料庫帳號或資料表資訊時，後端會呼叫既有 function，即時取得結果。

這大幅減少 SQL 或 JSON 出錯的機率。雖然人工撰寫的 function 一樣可能有邏輯問題。只是當大部分規則已經被包在 function 裡，AI 不必拼湊 SQL 規則；它主要把注意力放在組合 input、呼叫 API，以及處理回傳結果。

我後來才更清楚地理解：AI 寫程式時，真正有價值的不是把每一層都交給它，而是先讓它知道每一層的責任邊界。

個資資料表抄寫：畫面流程不會自己產出

不過，API 接得起來，不代表畫面功能就會符合我的預期。

資料表抄寫就是一個例子。同仁先選擇一張要抄寫的資料表，系統會判斷這張表是否包含個資。接著，同仁要勾選哪些欄位需要抄寫：如果勾選的是個資欄位，還要決定要做 hash 還是留空白；如果不是個資欄位，則保留原始資料。

欄位清單可以由 API 提供，但「全選」該怎麼作用、選到個資欄位時畫面該要求什麼、哪些欄位要保留原值，都是產品與業務邏輯的決策。

我和 AI 為了畫面位置、排版、按鈕行為來回調整了好幾次，才得到想要的效果。這段經驗讓我發現，API 規格可以描述資料怎麼交換，而畫面流程需要詳細溝通。

這些來回溝通後才釐清的邏輯，如果沒有被留下來，過幾天我自己可能忘記，下一次 AI 也只能重新猜一次。這也是我後來開始重視 Spec、Scenario 與文件的原因；它們不是為了讓流程看起來完整，而是把已經釐清過的判斷留下來。

我從這段經驗得到的分工

• 人與團隊討論需求，確認 API 的資料交換方式。
• 後端把可重用的資料處理與既有規則封裝在 API 或資料庫 function。
• AI 協助實作表單、串接、畫面與功能細節。
• 人持續確認畫面行為與業務規則是否真的是自己要的結果。

這和 Anthropic 對 agent 工具設計的提醒有相通之處：當模型要和確定性的系統協作時，輸入、輸出與使用邊界越清楚，模型越不需要靠猜測補齊缺失資訊。它們都反映同一件事：讓 AI 接到清楚的介面，比要求它從模糊需求中猜出所有系統細節更可行。(Anthropic, 2025)

今天可以做的：替一個既有功能寫下邊界

今天不用急著建立 Agent，也不用改掉既有架構。請從自己的 Repository 選一個已經在運作的功能，寫一張簡單的「功能邊界卡」。

# 功能邊界卡

- 這個功能讓使用者完成什麼事？
- 前端需要收集哪些輸入？
- 會呼叫哪些 API 或服務？
- 每個呼叫預期回傳什麼？
- 哪些規則由後端／資料庫處理？
- 哪些是畫面或業務決策，不能只靠 API 自行推測？
- 哪個地方還需要人確認？

這張卡不用完美。它的目的不是建立另一份文件負擔，而是先找出：AI 現在到底在哪裡必須猜，哪些事情其實可以先說清楚。

小結：介面降低猜測，業務邏輯需要被保存

第二代的 DAP 讓我看見，Vibe Coding 很適合拿來快速把已知流程做成可用功能。當前後端的 input、output 與責任邊界已被確認，AI 就能協助把功能往前推。

但我也從個資資料表抄寫的互動細節裡看到另一面：介面規格不是功能規格。真正讓功能難以維護的，常常是藏在按鈕、例外情況與使用流程裡的業務判斷。

下一篇，我會回到第二代完成 12 項功能後出現的另一個問題：當你改了 A，怎麼知道 B 沒有被改壞？這讓我們開始用 Python 比對輸出的 JSON 與 SQL，也帶出 AI 開發不能只看「有沒有產出」，還要看「如何驗證」。

參考資料

• Anthropic. (2025-09-11). Writing tools for agents.