經過三天的實踐，採用我在 FB 社團分享所提及的 ChatGPT + Codex 協作模式，完成了 PuppyMart 寵物購物系統第一版。
整體分工是：
- ChatGPT（Sol 中級模式）負責文檔、規劃與 Review
- Codex（Luna 極高模式）負責實作、測試與驗證
- 兩者再透過第三方 Bridge 橋接，使用的是
codex-with-chatgptskill
最後完成的系統已涵蓋多個業務功能模組，包括訂購、庫存、出貨、付款 Mock、基本資料維護等。
整個過程使用 Plus 帳戶，5 Hrs 限制一次都沒有觸發，週額度總共也只用了約 30%！
這次實踐更加證明了：
「AI Agent 開發真正重要的，不只是模型有多強，而是怎麼有效規範它。」
我會先依據專案性質制定 Agent 行為規範，例如 AGENTS.md 與相關細部規範（技術堆疊、前端 UI、分層架構、測試，乃至資料庫設計等）；再定義專案文件結構，包括調研、需求、架構、追蹤與交接記錄；程式本身則先確立基本分層，例如前後端分離，以及後端採簡化 DDD 分層。
接下來的工作流程大致是：
- 我先把需要討論的議題交給 ChatGPT，由它整理成需求、架構或設計文件，再進一步轉成具體可執行的計畫與 Prompt，交給 Codex 照表實作。
- Codex 在執行過程中同時負責測試與自我驗證，完成後回報執行成果，再交回 ChatGPT Review。
- Review 通過後，再整理工作日誌；如果工作有切分階段，則建立 hand-off 交接記錄；最後才交由 Codex Commit 並 Push 到 GitHub Repository。
也就是：
ChatGPT 負責思考、規劃與審查，Codex 負責執行與驗證。
不過，我並不會在專案一開始，就把所有目錄、規範與文件結構設計得非常龐大。
我的做法反而是先採用自己過去累積下來的「最小模板」，再視專案需要安裝必要的 Skill，例如前端開發、需求規格整理、UI 驗證等，通常不會超過 10 個。
之後再隨著開發進度，逐步調整目錄、規範與文件。
我認為這比一開始就建立一套規範龐雜、流程繁瑣，卻不一定符合實際需求的 AI 開發治理架構，要實際得多。
這次 PuppyMart 的開發方式，我採用的是「跨業務模組的水平切分」加上「技術層級的垂直切分」。
技術層級主要分成：
- 中間層 API
- 前端 UI（React）
- 後端邏輯與資料存取
每一層完成後（一次會執行多個功能模組的開發），先使用 Mock 做隔離，讓它可以獨立驗證與測試；等各層都穩定後，再進行全端整合。
最後則跑整合測試、接受度測試，再加上 UI 自動化操作驗證，確認完成一個 Release。
這種方式確實不算快。
但如果拿我過去帶領約 5 人以上團隊開發同等規模系統的經驗來比較，正常至少也會需要兩個月左右。
現在是一個人，加上 AI Agent，在三天內完成第一個可運作版本。
當然，如果全部工作都直接丟進 Codex，使用高階模型一次一路跑到底，速度當然會更快。
但我目前更重視的是：
可控性，以及品質。（當然還有 AI 開發成本的考量）
例如整合測試完成後，我覺得 UI 風格還不夠理想，而且發現一些操作細節缺失，如商品頁面沒有提供購買數量選擇。
這時我只需要把問題交給 ChatGPT，請它分析並制定修正計畫，再交由 Codex 實作。
ChatGPT 在規劃時還會明確指出：這次修改只屬於前端 UI 與互動機制，不需要變更後端 API，也不應牽動後端邏輯。
因此整個修改範圍非常清楚，實作與驗證也很快就能完成。
這種「先界定影響範圍，再讓 Agent 動手」的方式，是我目前認為 AI 輔助開發非常重要的一環。
接下來，我打算再把 PuppyMart 修整得更完整一些，之後會放到 GitHub，包含完整程式碼與可執行環境。
後續也預計製作 C#、Java / Spring 版本，甚至延伸到微服務架構版本。
至於 ChatGPT 與 Codex 到底要怎麼透過 Bridge 協作，包括：
- Bridge 如何安裝與設定
- ChatGPT 與 Codex 如何分工
- Agent 規範如何設計
- 專案文件與目錄如何安排
- Skill 如何選擇與安裝
- 如何建立一套可以重複使用、持續擴充的 AI 開發專案模板
個人也已整理成一堂大約 3 小時的實務經驗分享講座，提供給苦於 Codex 開發額度一下就被耗光的使用者，以及希望更有效規範 AI Agent 開發流程的開發者，分享如何透過一套可控、可驗證的協作方式，大幅降低 AI Agent 開發成本，並提升整體開發品質的實務經驗。
P.S. 首頁圖檔是我的小狗堡貝與玄鳳粉圓 😄