本議程將分享我如何在個人開源專案 EAP（Event-Driven Auction Platform for Electricity Markets）中，使用 AI 協作工作流，將一個原本功能導向的 Spring Boot 微服務專案，逐步重整成具備一致性驗證、冪等處理、效能量測與技術文件的工程案例。

 EAP 是一套以 Java、Spring Boot、RabbitMQ、PostgreSQL、Redis Lua 建構的事件驅動交易系統，核心流程包含訂單提交、資產保留、撮合、成交事件持久化、訂單狀態套用、錢包結算與完成標記收斂。專案初期雖然已具備基本功能，但在進行高併發壓測時，逐漸暴露出多個真實後端系統常見問題：訊息重送下的冪等性、跨服務最終一致性、Outbox 寫入放大、Queue backlog、觀測成本，以及「API 成功」與「完整業務完成」之間的落差。

我在這個過程中建立了一套 AI 協作工作流，讓 AI 不只是產生程式碼，而是依照不同角色參與工程流程：架構評估、效能分析、實作拆票、QA 驗證、code review 與文件整理。每一次修改都必須經過測試、壓測、RabbitMQ queue 指標、PostgreSQL statistics、應用程式 metrics 與正確性 gate 驗證，避免只接受「看起來合理」但無法證明有效的 AI 建議。

 演講將分享以下實戰內容：

 1. 如何把 AI 從單純 coding assistant，調整成架構師、效能分析師、實作負責人、QA 與 reviewer 的協作流程。

 2. 如何用 AI 協助盤點事件驅動系統中的服務邊界、狀態 ownership、Transactional Outbox 與冪等消費策略。

 3. 如何重整交易完成語意，明確區分 accepted input throughput、TradeExecuted reach throughput、wallet settlement throughput 與business-completed throughput。

 4. 如何透過 AI 輔助分析 PostgreSQL、RabbitMQ、Redis 與應用程式 metrics，定位 DB write amplification、Outbox relay 成本與 queue drain tail。

 5. 如何驗證 AI 建議是否真的改善系統，而不是只是把瓶頸轉移到其他 queue、consumer 或資料庫操作。

 6. 如何將兩週以上的調校過程整理成 ticket、benchmark report、架構文件與履歷可用的工程案例。

 本議程的重點不是展示 AI 讓我「更快寫完程式」，而是分享一個後端工程師如何用 AI 建立可追蹤、可驗證、可拒絕錯誤建議的協作流程，並將個人專案推進到能討論一致性、可靠訊息處理與效能瓶頸的工程案例。

聽眾收穫：

參與本議程後，聽眾將能：

 1. 理解如何把 AI 工具從程式碼產生器，轉化為架構討論、效能分析、測試設計與 code review 的協作夥伴。

 2. 學會用角色分工的方式設計 AI 工作流，例如 Architect、Performance Analyst、Implementation Lead、QA Lead 與 Reviewer，降低單一 AI 回答直接進入程式碼的風險。

 3. 了解事件驅動系統中，冪等性、Transactional Outbox、Manual ACK、DLQ 與 completion marker 如何影響一致性與效能。

 4. 學會用 benchmark、queue metrics、SQL statistics 與 final correctness gate 驗證 AI 提出的效能建議是否真的有效。

 5. 從實際案例理解，為什麼增加 concurrency、batch 或觀測指標不一定會改善 TPS，甚至可能造成測試失真或系統退步。

 6. 了解如何將個人專案整理成可被面試、技術分享與履歷使用的工程案例，而不是只停留在功能展示。