耗時4個月，權限管理平台正式上線，超過 100 位使用者開始使用。

在這過程中，驗證 13 項功能的結果輸出，再用兩輪 UAT、合計 13 個情境檢查跨角色流程與申請人的實際操作。回饋經過修正、重驗與版本取捨，最後形成可以上線的 Release Candidate。

上線後一個月，單據處理量約為既有流程的月平均兩倍，這套系統已經開始承接真實工作。

三十篇寫到這裡，我同時得到一個 Web 平台和一套開發方法。DAP 的開發方式從自然語言驅動的反覆調整，逐步長出 Spec、角色 Agent、Skill、指揮中心、Human Checkpoint、UAT 與文件地圖。第四代則把這些經驗推向使用者端的 Agent 服務設計。

• DAP 的每一代都在解決前一代出現的新瓶頸，工具跟著問題增加。
• Vibe Coding、SDD、角色 Agent 與指揮中心是同一條演進路徑上的不同階段。
• 我現在會用五個動詞整理 AI 開發工作：定界、留痕、分工、排序、驗證。
• 第三代已完成上線；第四代的 Capability、Tool、autonomy matrix 與 Evals 仍是待實作藍圖。
• claude-spec-workflow-kit 公開已經在 DAP 使用過的第三代流程骨架；公開範圍排除 DAP 內部程式與業務資料。

四代 DAP，各自解決一個新的問題

回頭看四代演進，技術名稱一直在變，真正推動下一步的是工作現場出現的新問題。

第二代使用 Vibe Coding 開發，當時很直接：描述功能、讓 AI 實作、查看畫面與結果，再補充細節。使用既有 API input／output、後端 function 與前後端分工。AI 處理頁面與串接。

十二項功能完成後，修改的風險變大。我開始擔心「改 A 壞 B」，所以加入 JSON／SQL 比對。到了第三代，導入 SDD 架構：每一項需求都需要 Spec、Plan、Task、Scenario、資安與文件，六月底甚至同時出現 11 件混合任務。

我先把工作拆成五個角色，再把重複流程寫成 Skill。最後由指揮中心讀取任務、分類、檢查檔案衝突、安排批次，在 Plan 與最終定版保留人工確認。

第三代完成的是一條從需求、開發、驗證到真實使用者的交付路徑。

第四代換了一個位置。Agent 從開發者旁邊移到使用者旁邊，協助理解需求、查詢規則、產生草稿與追蹤狀態。正式送出仍由人確認。Day 26 到 Day 29 完成的是設計文件，實際 Capability、Tool 與 Eval 尚待開發。

每次演進都從瓶頸開始

這四代可以濃縮成一條路徑：

操作太集中在 Notebook
  → 搬到 Web

功能變多，修改範圍開始互相影響
  → 用 SDD 固定需求、方案與驗收

需求同時進來，人工協調開始排隊
  → 用角色 Agent、Skill 與指揮中心分流

系統已上線，使用者仍要理解大量規則
  → 把功能整理成 Capability、Tool 與 Eval

第二代先完成第一個 Web 功能。工作量增加、錯誤成本提高、協調開始塞車之後，我才一層一層加入完整的 Multi-Agent 架構。

這個順序也讓每一層都有明確用途。Spec 解決需求範圍，角色契約解決責任邊界，Skill 解決重複操作，指揮中心解決批次與依賴，UAT 解決真實流程是否可用。第四代的 Tool 與 Eval，則要處理 Agent 對真實系統採取行動時的控制與證據。

我現在用五個動詞整理 AI 開發

如果把工具名稱拿掉，這套方法可以留下五個動詞。

1. 定界

先找出真相來源、可修改範圍與禁止猜測的地方。

第二代的真相來源是 API contract、後端 function 與既有 Notebook 輸出。第三代再把專案結構、業務詞彙與硬性限制放進 CLAUDE.md。第四代則要為每一項使用者服務定義 Capability。

2. 留痕

把一次變更留下可以交接的產物。

Spec：要改什麼
Plan：準備怎麼改
Tasks：工作如何拆開
Scenario：完成後怎麼驗收

對話會結束，檔案可以被下一個 Agent、下一位同事與幾個月後的自己重新讀取。

3. 分工

依工作責任建立角色契約，寫清楚輸入、輸出、可修改範圍與停止條件。

DAP 使用 Frontend、API、QA、Security 與 Documentation 五個角色。角色數量可以依專案調整，責任邊界要能讓下一個工作接得上。

4. 排序

先看依賴與共同檔案，再決定平行或循序。

Agent 數量只代表可以同時啟動多少工作。真正能否平行，取決於功能邊界、檔案衝突、前置產物與人工卡點。指揮中心接手的是這一層協調。

5. 驗證

用與風險相符的證據收尾。

程式修改需要測試與 Scenario；核心輸出需要回歸比對；完整流程需要 UAT；上線需要 Release Candidate 決策。未來的 Agent 服務還要檢查 Tool trace、系統 outcome 與人工確認紀錄。

這五個動詞會形成循環。UAT 找到的問題重新進入 Spec；重複出現的做法被整理成 Skill；線上失敗則回到 Scenario、Test 或 Eval。

Agent 的產出要能交給下一棒

我在第三代最重要的改變，是把 Agent 之間的交接放進檔案。

API Agent 完成型別與呼叫函式，Frontend Agent 再讀取它們實作畫面；QA Agent 根據 Spec 寫 Scenario；Documentation Agent 依最後結果更新文件。指揮中心負責決定順序與提供上下文。

人確認需求與方向
  ↓
Agent 產出可讀取的 artifact
  ↓
下一個角色沿用 artifact
  ↓
測試、審查與使用者驗證留下證據
  ↓
人決定版本是否完成

這條路徑讓我逐漸退出日常分派，把時間放回業務規則、Plan 確認、例外判斷與最終定版。

人仍然負責幾個位置：

• 決定要解決的業務問題。
• 確認技術方案與版本範圍。
• 接受已知限制與上線風險。
• 組織 UAT，判斷回饋優先順序。
• 完成資料移轉與正式開放。
• 決定第四代 Agent 可以取得多少自主權。

AI 加快了產出與整理，人負責方向、責任與風險。

這些數字代表什麼

系列裡出現不少數字。我想在最後把口徑放在一起。

Spec 數量顯示的是變更密度與文件負擔。它也暴露新的問題：舊 Spec 可能與現況不同，Agent 需要文件地圖與可執行規則，才能找到目前有效的答案。

這正是 Day 25 轉向第四代設計的原因。

我把第三代流程整理成 workflow kit

這個系列使用的第三代流程，已整理成公開的 claude-spec-workflow-kit。

它是一個 Claude Code plugin，內容包含：

• Spec → Plan → Tasks → API → 實作 → Scenario → Security → Documentation 的 8-Step。
• Frontend、API、QA、Security、Documentation 五個角色 Agent。
• 讀取任務、辨識角色、分析檔案衝突與安排批次的 orchestrate Skill。
• git-workflow Skill，以及新增 Mock、頁面與更新文件的操作骨架。
• 一份專案 CLAUDE.md 範本。

在 Claude Code 中可以這樣安裝：

/plugin marketplace add https://github.com/goman-jacky/claude-spec-workflow-kit
/plugin install spec-workflow@claude-spec-workflow-kit

安裝完成後，先在專案根目錄準備 CLAUDE.md，至少寫清楚技術棧、目錄結構、硬性限制、Spec 位置與業務詞彙。這份文件提供專案脈絡，plugin 提供流程骨架。

最小使用順序可以從一項功能開始：

1. 在 CLAUDE.md 寫清楚專案邊界
2. 用 spec-workflow 完成一項功能的 8-Step
3. 累積多項任務後，再用 orchestrate 分流與排批次
4. 在 Plan 與最終定版保留人工確認
5. 用專案自己的測試、UAT 與發布規則驗證結果

這個公開套件有明確範圍：

• 它提供技術棧無關的流程與角色範本，專案細節由 CLAUDE.md 補上。
• 分派品質依賴任務檔中的異動範圍、主要檔案與依賴資訊。
• Agent 回報需要搭配 diff、測試與人工確認，才能形成完成證據。
• 套件公開流程與角色方法；DAP 內部程式、帳號、API、單據與業務資料維持內部使用。
• 第四代的 Capability、Tool、autonomy matrix 與 Evals 仍在 roadmap，尚未放進這個套件。

這是我從一個真實專案抽出的第一版，適合拿來理解、修改，再放進自己的工作方式。目前的證據範圍限於 DAP，後續仍需要更多專案與基準測試。

另一條更完整的路線：Prospec

如果你想看更完整的 Progressive SDD 工具，可以延伸閱讀朋友 ci-yang 開發的 Prospec。

Prospec 是 CLI 與 Skills 組成的開發流程，涵蓋既有專案掃描、AI Knowledge、Story、Design、Plan、Tasks、Implement、Verify 與 Archive。它也將規格分成持續維護的 Capability Specs 與單次變更的 Delta Specs，並支援 Claude Code、Gemini CLI、GitHub Copilot 與 Codex CLI。以上定位與功能以專案 README 為準。

兩套工具的出發點不同：

想重現這個系列的第三代流程，可以先從 workflow kit 開始。需要跨 AI CLI、既有專案知識整理與規格同步，再研究 Prospec 的完整設計。

如果重新開始，我會照這個順序

我仍然會從一個真實的小流程開始。

先找出一項有明確輸入與輸出的工作
  ↓
確認 API、程式、規則與人的責任邊界
  ↓
用 AI 完成第一個可驗證版本
  ↓
需求增加後，加入 Spec、Plan、Tasks 與 Scenario
  ↓
重複工作穩定後，整理角色 Contract 與 Skill
  ↓
多項需求同時出現後，再加入指揮中心
  ↓
上線前完成輸出回歸、UAT 與版本決策
  ↓
Agent 要替使用者採取行動時，再建立 Capability、Tool 與 Evals

這個順序把方法放在問題後面。先讓一件真實工作跑通，再為下一個已經出現的瓶頸增加結構。

三十天最後留下的成果

Day 01 我寫下：流程是在系統變複雜後，逐步長出來的回應。

Day 30 回頭看，這句話仍然成立。

Vibe Coding 讓我從資料庫管理跨到前端開發；SDD 讓需求、方案與驗收可以被檢查；五個角色與指揮中心讓大量修改可以分流；兩輪 UAT 讓系統真正交到使用者手上。超過 100 份 Spec 又把我推向下一個問題：系統的功能要如何被 Agent 理解、呼叫與驗證。

這三十篇最後留下兩項成果。

第一項是一套已經跑過 DAP 真實開發、UAT 與上線的 AI 協作流程，現在以 workflow kit 的形式公開。

第二項是第四代 DAP 的可檢查設計：Agent Service Canvas、Capability Contract、Tool Contract、autonomy matrix 與 Eval Set。它們將成為下一段開發的起點。

這次完成的是第三代上線。這三十篇到這裡結束。下一次再回來，我希望帶來第一批真正跑過 Eval 的第四代 Capability。

專案與延伸閱讀

• claude-spec-workflow-kit｜本系列第三代流程的公開版本
• Prospec｜ci-yang 的 Progressive Spec-Driven Development CLI