把 AI 納入軟體工藝：用 Codex Skills 與 Multi-Agent 賦能 Java 團隊協作與交付

演講題目：把 AI 納入軟體工藝：用 Codex Skills 與 Multi-Agent 賦能 Java 團隊協作與交付

基本資料

欄位	內容
Conference	JCConf
年份	2026
日期	2026-09-11
時間	15:00–15:45
地點	臺大醫院國際會議中心
演講題目	把 AI 納入軟體工藝：用 Codex Skills 與 Multi-Agent 賦能 Java 團隊協作與交付
講者	Samson
狀態	`delivered`
官方連結	JCConf 2026 議程頁
投影片連結	Google Drive

演講摘要

這場分享從金融業的軟體交付情境出發，討論 AI Agent 進入團隊後，如何維持規格、責任邊界與驗證證據。內容以 Java Library Console 的借書功能為案例，先把 requirements、acceptance criteria、architecture 與 OpenAPI 等 artifacts 保存成 spec-ready commit，再由新的 Backend branch 與 Codex session 使用 BE Skill 完成 Spring Boot 實作。整個流程串起 SDD、Codex Skills、Multi-Agent、Workflow State，以及測試與 API response，示範 Agent 如何在可理解、可檢查的工程流程中協作。

演講內容

這場分享想處理的問題

AI coding 工具可以很快產生程式，但速度本身沒有回答幾個更現實的問題：規格由誰維護？Agent 為什麼要這樣實作？換一個 session 能不能接手？程式完成後，團隊要用什麼證據確認它真的符合需求？

這場分享把焦點放在交付流程，而不是單次 prompt 的效果。SDD 保存需求、設計決策、API 契約與驗收條件；Codex 依照這些 artifacts 工作；Skills、script 與 tool 把團隊的方法固定下來；Workflow State 則記錄目前階段、交付物、阻塞點與 handoff。

演講重點

金融業的文件與流程可以成為 Agent 的工作邊界：SA、Archi、SD、PG 與 QA 等階段，不只是組織分工，也可以轉成每個 Agent 必須讀取與產出的 artifacts。
SDD 把規格接到程式碼與測試：requirements、acceptance criteria、architecture 與 OpenAPI contract 共同形成可追蹤的輸入，避免實作和設計各自漂移。
Codex Skills 固化重複的工程方法：Skill 可以定義要讀哪些文件、能修改哪些區域、要執行哪些驗證命令，以及什麼情況應該回報上游 rework。
Multi-Agent 的價值在責任分工與上下文隔離：SA、SD、PG、QA 等角色各自處理一段工作，透過 Workflow State 和 artifacts 交接，不把所有背景都塞進同一個 Agent session。
完成宣告不能取代交付證據：Demo 會把 acceptance criteria 對應到 JUnit／MockMvc 或 integration test，再檢查成功與庫存不足的 API response，確認結果符合 OpenAPI 契約。

Java Demo：從 `spec-ready` 到可驗證交付

案例使用 Library Console 的借書功能。SA、Archi 與 SD 階段先完成 requirements、acceptance criteria、architecture、OpenAPI、generator config、SD handoff 與 Workflow State，並提交成 spec-ready 起點。這個 commit 不包含 Backend 實作，讓現場可以從新的 branch 與新的 Codex session 接手。

Backend 由 BE Skill 讀取凍結的 OpenAPI，產生 Java interface 與 DTO；Agent 只能在 handwritten 區域實作 Controller、Service、repository adapter、validation 與 error mapping。完成後，依照 acceptance criteria 執行測試與 API 驗證，同時保留 Frontend 從相同 spec-ready commit 平行開發的結果。

內容流程

flowchart TD
    A[Requirements + Acceptance Criteria] --> B[SA／Archi／SD artifacts]
    B --> C[OpenAPI contract + generator config]
    C --> D[spec-ready commit]
    D --> E[新的 Backend branch／Codex session]
    D --> F[Frontend branch]
    E --> G[BE Skill：產生 interface／DTO]
    G --> H[Spring Boot handwritten implementation]
    H --> I[Unit／Integration tests + API response]
    F --> J[Generated client／model]
    I --> K[Integration Gate]
    J --> K

問答

如果 PG 開發到一半發現需求矛盾，該如何退回 SA？需要使用同一個 session 嗎？

透過 Workflow State 管理退回。Workflow State 是一份檔案，記錄目前階段、交付物與阻塞點；PG 發現需求矛盾後，將問題與狀態寫回檔案並 commit，再切換 branch 回到 SA 階段處理。不必依賴原本的 session，後續工作以 commit 後的 Workflow State 和 artifacts 作為交接依據。

哪些工作可以同步執行？

目前實務上只有 PG 開始前後端開發時會平行進行。前面的階段有依賴性，仍要依序完成；等 spec-ready commit 建立後，Backend 與 Frontend 才能從同一個起點平行開發。