Day21_架構都想好了，我們可以開始叫 Agent 上工了

前言

前面的文章一路整理了 User Story、UI 草圖、流程圖、資料庫 Schema、API 契約與測試方式。Day19 準備好 SQL Server，Day20 也先用規劃模式確認實作方向。現在終於可以開始寫程式了。

這次要做的是前後端分離的網站。Vue 3 前端負責接住使用者的操作，ASP.NET Core Web API 後端負責權限、業務規則與資料存取。若把整套系統交給同一個 Session 一口氣完成，內容一多，前後端的責任很容易混在一起。因此，我把工作拆成前端與後端兩個 Session，讓它們各自專心處理自己的範圍。

可以把這兩個 Session 想成兩張工作桌。前端桌上放的是畫面、路由與操作流程；後端桌上放的是 API、權限與資料庫。兩張桌子中間擺著同一份規格，避免各做各的。之後還會再開一個全端調整 Session，負責檢查雙方的 API 契約並完成串接。

多個 Agent 可以分頭工作，卻不代表人可以離開現場。規格衝突要由人決定，規劃內容要由人確認，最後的 Git diff、測試結果與實際畫面也都要檢查。

先替三個資料夾分工

我先建立一個 Codex 專案，將 ProjectManagementWeb 資料夾設為來源資料夾。這樣每個 Session 都能讀到同一個工作區，但實際修改時仍要明確指定目標資料夾。

專案主要分成三個資料夾：

1. ProjectManagementWeb_FrontEnd：Vue 3 前端專案。
2. ProjectManagementWeb_BackEnd：ASP.NET Core Web API 後端專案。
3. ProjectManagementWeb_Spec：前後端共同參考的開發規格。

ProjectManagementWeb
├── ProjectManagementWeb_BackEnd
├── ProjectManagementWeb_FrontEnd
└── ProjectManagementWeb_Spec
    ├── C4
    │   ├── ProjectManagementWeb_C4_Level1_Level3.md
    │   ├── ProjectManagementWeb_Level1_Context.mmd
    │   ├── ProjectManagementWeb_Level2_Container.mmd
    │   ├── ProjectManagementWeb_Level3A_Frontend_Component.mmd
    │   ├── ProjectManagementWeb_Level3B_Backend_Component.mmd
    │   └── ProjectManagementWeb_Level3C_Frontend_Controller_Mapping.mmd
    ├── Flowchart
    │   ├── E-mail 任務到期提醒.md
    │   ├── Task Item 留言.md
    │   ├── 刪除 Task Item(後台使用者).md
    │   ├── 建立與修改專案.md
    │   ├── 從詳細頁修改 Task(前台使用者).md
    │   ├── 批次修改 Task 狀態(前台使用者).md
    │   ├── 新增與修改 Task Item(後台使用者).md
    │   ├── 管理專案成員.md
    │   ├── 管理系統角色與帳號狀態.md
    │   └── 註冊、Email 驗證與登入.md
    ├── TestCases
    │   └── ProjectManagementWeb-TestCases.md
    ├── UIMock
    │   ├── ProjectDetail.png
    │   ├── ProjectList.png
    │   ├── SignIn.png
    │   ├── SignUp.png
    │   ├── TaskItemDetail.png
    │   ├── TaskItemList.png
    │   ├── UserList.png
    │   └── UserSetting.png
    ├── ImplementationBacklog.md
    ├── Schema.md
    ├── Spec.md
    ├── StaticData.md
    └── UserStory.md

規格資料夾像兩組開發人員共用的施工圖。前端不能只看 UI Mock 就自己猜 API，後端也不能只看 Schema 就忽略使用者操作。兩邊都要閱讀 User Story、流程、架構與資料規則，才有機會做出能接在一起的結果。

接著我建立三個 Session：

ProjectManagementWeb 前端開發
ProjectManagementWeb 後端開發
ProjectManagementWeb 全端調整

這一篇先看前兩個 Session 如何工作。全端調整會留到 Day22，再用雙方產出的文件完成串接。

前端 Session：先把畫面與操作流程做起來

接下來的 Prompt 區塊是我當時實際輸入的內容。為了保留操作情境，裡面的大小寫、空格與原本用字都不修正；補充說明與注意事項則放在區塊外。

Step 1：建立前端開發規範

第一個 Prompt 只要求 Agent 建立 AGENTS.md：

請先在ProjectManagementWeb_FrontEnd的Folder 建立AGENTS.md，幫我建立開發規範，並且我想用Vue3進行開發

畫面中可以看到，Agent 除了列出 Vue 3、TypeScript、Vite、Vue Router 與 Pinia，也把 lint、type-check、單元測試、端對端測試及 build 寫進驗證要求。AGENTS.md 就像貼在工作桌旁的作業規則，後續修改同一個專案時，都能回來查看。

Step 2：建立第一個 Git 存檔點

接著替前端建立公開的 GitHub Repository，保存目前的 AGENTS.md。當時我的介面已經連接 GitHub，因此 Prompt 中直接使用 GitHub 來源：

[@github](plugin://github@openai-curated-remote) 請先幫我把整個專案現做一次commit，並且push到遠端，專案名稱為“ProjectManagementWeb_FrontEnd”，專案設定為公開的

這一步有兩個重點。第一，公開 Repository 代表任何人都能看到內容，push 前一定要先檢查秘密。第二，commit 只在本機建立版本紀錄，push 才會把它送到 GitHub；兩個動作不能混為一談。

Step 3：建立 develop 分支

我沒有直接在 main 上開發，而是請 Agent 建立 develop 分支。當時輸入的是：

請幫我在 [@github](plugin://github@openai-curated-remote)JJDing-Louis/ProjectManagementWeb_FrontEnd這個專案裡面， 開一個分支，分支名稱為“develop”並且幫我Checkout

可以把分支想成另一張工作桌。main 先保留初始版本，開發中的內容則放在 develop。不過，分支只是把修改隔開，不會自動保證程式正確；測試與審查仍然不能省略。

Step 4：開啟規劃模式，再開始實作

切到 develop 後，我依照 Day20 的方式開啟規劃模式，再輸入當時的前端需求：

請讀取/Users/louisding/Desktop/ProjectManagementWeb/ProjectManagementWeb_Spec裡面的所有文件，並且幫我做一個前端的網頁，需求如下
1. 此專案只做前、後端分離的前端應用程式開發
2. RWD網頁的設計，整個畫面預設是桌面瀏覽器的使用為主
3. 網頁的名稱叫ProjectManagementWeb
4. 導覽列 要有Project List、User List 與 Logout
5. Project List可以展開目前現有的專案

Agent 讀完文件後提出 Vue 3 前端 MVP 計畫。這時先別急著按下「執行」。我會檢查它是否只修改前端、畫面能否對回 User Story、權限狀態有沒有遺漏，以及 Mock API 是否被誤寫成正式契約。

確認計畫後才讓 Agent 實作。畫面中的執行結果顯示，前端使用 Vue 3、TypeScript、Vite、Pinia 與 Vue Router，資料暫時由 Mock API adapter 和瀏覽器本機資料庫提供。格式檢查、ESLint、型別檢查、Vitest、Playwright 與 production build 也都有執行。

這裡要注意：前端測試通過，代表 Mock 環境中的畫面與操作符合目前設計，還不能證明正式後端一定接得上。真正的 API 路徑、欄位、狀態碼與錯誤格式，仍要等 Day22 逐項比對。

Step 5：建立 commit

Agent 回報完成後，我請它建立一筆 commit。當時輸入的 Prompt 很短：

[@github](plugin://github@openai-curated-remote)請先幫我下一次Commit，內容是“V1 開發完成，待串接”

這段 Prompt 只明確要求 commit，沒有寫出 push。若要確認遠端也收到這個版本，還要另外檢查遠端分支與 commit SHA，不能把 commit 自動當成 push。

後端 Session：把規則、資料與 API 接起來

後端的操作順序和前端相同，但工作內容不同。前端關心使用者怎麼操作；後端更像站在櫃檯後方的承辦人，要檢查身分、權限、資料規則與交易是否成立。

Step 1：建立後端開發規範

請先在ProjectManagementWeb_Backend的Folder 建立AGENTS.md，先幫我建立開發規範就好，並且我想用ASP.NET Core進行開發

後端規範除了 ASP.NET Core Web API，也包含分層責任、REST API、DTO、Problem Details、SQL Server、交易、並行控制與測試要求。這些內容比單純寫一句「使用 ASP.NET Core」更有用，因為它同時說明程式要怎麼分工，以及交付前要怎麼檢查。

Step 2：建立後端 Repository

Step2
[@github](plugin://github@openai-curated-remote) 請先幫我把整個專案現做一次commit，並且push到遠端，專案名稱為“ProjectManagementWeb_BackEnd”，專案設定為公開的

Step 3：建立 develop 分支

Step3
請幫我在 [@github](plugin://github@openai-curated-remote)JJDing-Louis/ProjectManagementWeb_BackEnd這個專案裡面， 開一個分支，分支名稱為“develop”並且幫我Checkout

Step 4：先規劃後端 MVP

後端牽涉的規則比較多，所以我在當時的 Prompt 中列出技術與安全需求。以下同樣保留原文：

Step4(規劃模式)
請先讀取以下檔案
/Users/louisding/Desktop/ProjectManagementWeb/ProjectManagementWeb_Spec裡面的所有文件
然後我想要的專案需求如下:
1. 專案為ASP.NET Core WebAPI 前、後端分離的後端專案
2. 專案的登入權限要有JWT的登入設計
3. 資料庫的ORM 請用EntityFramework
4. 權限的設計部分，一個帳好有多個角色，每個角色可以有多個Function的功能
5. 撰寫測試案例時，請用Moq產生模擬物件、Bogus產生模擬資料做單元測試
6. 單元測試使用Nunit搭配FluentAssertions進行撰寫
7. 我需要DockerFile搭配MSSQL進行開發
8. 資料庫Schema要進入版本控制
9. WebAPI 要有CSRF的防護
10. 需搭配Swagger與OpenAPI
11. 專案的Program.cs不要用 **Top-level statements**

這次 Agent 在規劃途中找到幾個不能靠猜測決定的問題，例如系統角色與 Function 的關係、專案角色的責任，以及專案狀態有哪些值。這正是規劃模式有用的地方：在程式還沒長出來以前，先把規格缺口攤在桌上。

確認這些決策後，Agent 產生後端 MVP 計畫。畫面右側列出 .NET、EF Core、SQL Server、Identity、JWT、測試與 OpenAPI 等技術，也將帳號、角色、專案、Task、留言與 Email 的實作範圍分開。

執行完成後，畫面顯示後端已通過格式檢查與 build，單元測試為 8 項通過，整合測試為 4 項通過；SQL Server、Migration、API 與多個 smoke test 也有實際啟動驗證。這些數字是該次畫面的執行紀錄，不代表未來每次修改後都會自動保持相同結果，程式一變就要重新測試。

畫面也誠實留下限制：當時尚未用真實 Gmail SMTP 帳密驗證寄信，高競爭情境也還可以增加壓力測試。這類「尚未驗證」不能算成通過。Agent 願意列出缺口很好，但是否接受這個交付範圍，仍由人決定。

Step 5：替後端建立可追查的版本

[@github](plugin://github@openai-curated-remote)請先幫我下一次Commit，內容是“V1 開發完成，待串接”

後端這段 Prompt 同樣只明確要求 commit，沒有寫出 push。是否已經同步到遠端，要再查看遠端分支或比對本機與遠端的 commit SHA。

到這裡，前端與後端都有自己的 develop 分支和版本紀錄。之後若串接時發現問題，可以從 Git diff 找出是哪一端改了契約，不必只靠記憶追查。

兩個 Agent 並行時，最容易踩到的坑

並行開發很像請兩位工程師同時施工。速度可能變快，溝通成本也會跟著出現。

第一個風險是前後端各自發明契約。前端可能把欄位叫 taskId，後端卻回傳 id；前端用字串表示狀態，後端則回傳數字。兩邊單獨測試都會通過，接起來才一起出錯。

第二個風險是 Agent 把「看起來合理」當成需求。規格沒寫舊資料預設值、角色權限或錯誤狀態時，它可能依常見做法補上一個答案。這個答案也許能執行，卻不一定符合我們的系統。

第三個風險是把工作回報當成驗證。build 通過不代表權限正確，單元測試通過也不代表瀏覽器真的能操作。每種證據只能回答一部分問題，所以要一起看 Git diff、自動化測試、API 回應與手動操作結果。

比較安全的做法，是讓兩端共用同一份規格、限制每個 Session 的修改範圍，遇到規格缺口先停下來問，完成後再保留可以重跑的驗證結果。

小結

這一篇開了前端與後端兩個 Session，讓 Codex 依照同一份規格分頭實作。前端先以 Mock API 完成可操作的 Vue 3 MVP；後端則完成 ASP.NET Core Web API、資料庫與自動化測試。兩邊都能各自運作，但現在還像兩位使用同一張施工圖、尚未接管線的工人。

下一篇會請前後端依照實際程式產生 API 清單與契約文件，再交給全端調整 Session 比對。若路徑、欄位或錯誤格式對不上，就先列出差異，不讓 Agent 偷偷挑一邊當答案。等契約說得通，前端才能拿掉 Mock，真正呼叫後端 API。

專案連結

• ProjectManagementWeb Vue 3 前端
• ProjectManagementWeb ASP.NET Core 後端