六月底那一天，我把需求文件裡的 11 項分完類、安排執行順序後，回頭想，指揮中心能把工作分批、判斷誰跟誰能平行做，是使用我定義好的 Agent —— Frontend、API、QA、資安、文件這五個角色。

順序是這樣：我先把這五個角色定義出來，各自的技術範圍、禁止事項、輸入來源、輸出目標、完成後怎麼回報都寫清楚；後來需求量變大，才設定指揮中心，讓它照這份角色清單去安排哪些工作可以平行做。這篇先講角色怎麼被定義；指揮中心怎麼分派、怎麼判斷能不能平行，留到後面幾篇。

• DAP 現在用的五個 Agent 定義檔，寫的是技術範圍、硬性規範、輸入來源、輸出目標、完成後怎麼回報——角色是靠這五件事定義出來的。
• 前端角色的輸入來源，直接寫死「由 api-integration-agent 產出」——這條邊界的用途是讓下一棒知道要去哪裡接。

先看這五個角色

DAP 現在用的五個角色，對應的是 Day 06 到 Day 13 那條 8-Step 的不同階段：

這張表的右欄說明一件事：Part 2 講的那條 Spec → Plan → Task →（API、頁面、Scenario、資安）→ 文件，這條流程還在。這五個角色是把八個步驟分工出去——frontend-agent 一個人包了 Step 1 到 3（寫 spec、plan、tasks）加上 Step 5（實作頁面），其餘各步交給對應的角色。

spec.md、plan.md、tasks.md 這幾份檔案現在的身分是角色之間傳工作的媒介：frontend-agent 在 tasks.md 裡標好 [API層]、[頁面]，api-integration-agent 只挑 [API層] 的項目做，做完的 API 函式再回頭當 frontend-agent 實作頁面的輸入。

角色是固定的職位定義，實際派幾個上場由當天的工作決定。六月底那一天，frontend-agent 被叫出來跑了八次（不同任務、各自獨立的 context），documentation-agent 三次，qa-agent 一次都沒有——那天多數是 bug fix，依規則跳過了 Step 6。

前端角色的定義檔，從頭到尾長這樣

Agent 的定義，以 frontend-agent 這份檔案為例，裡面是一條一條可以照做的規格：

• 一行說明：負責 Vue 3 組件開發、路由、狀態管理、UI 實作，什麼時候該用它。指揮中心就靠這行判斷「這個工作要不要找它」。
• 技術棧：Vue 3、Composition API、Element Plus、Pinia、Vue Router、Vite、Tailwind、TypeScript。它會用到的工具一次列清楚。
• 硬性規範：API 呼叫一律走同一支 HTTP 封裝函式，不直接 import axios；UI 用 Element Plus；圖示用固定寫法；不安裝新套件；mock 相關的程式碼只能待在指定資料夾。
• 輸入來源：spec.md、plan.md，還有 API 函式——而且註明這些函式「由 api-integration-agent 產出」。
• 輸出目標：只能改 src/views、src/components、src/store 這一類前端目錄。
• 每個任務開始前：先讀 spec 和 plan，逐一執行 tasks 裡的項目、完成一個打勾一個，做完回報改了哪些檔案、每個項目的狀態。

整份檔案就這六段，講的都是用什麼工具、守什麼底線、讀哪裡、寫哪裡、做完交代什麼。

Claude Code 官方文件講 Subagent 的時候，也是同樣的邏輯：Subagent 收到的是這份定義檔裡寫的系統提示，加上基本的環境資訊，範圍就這麼多——連 Claude Code 原本的系統提示都不會帶進去。（Claude Code, Subagents）

一個 Agent 表現得像不像某種前端工程師，是靠這份檔案裡的技術棧、封裝規範、可改範圍決定的。

五個角色，同一個骨架

前端這份檔案濃縮一下，會看到五個每個角色都有的部分：

前四項合起來，決定了一個 Agent 的動作範圍；最後一項決定了人要看什麼才能確認它做完了——這正好接上 Day 08 講過的：checkbox 打勾只是進度回報，我真正要看的是它回報了什麼。

同一條底線，出現在三份不同的檔案裡

最讓我意外的是「不安裝任何新 npm 套件」這條規則。它同時出現在前端、API、資安三份定義檔裡，一字不差。QA 角色的寫法不太一樣：測試規範直接指定要用既有的 MSW 做 mock，等於用另一種方式劃出同一條底線。

這件事讓我理解：角色邊界的作用，是把整個系統共同的硬性規則，重複刻進每一個會動到程式的角色裡。角色越多，越需要有幾條所有人都不能碰的底線，系統的一致性就是靠這幾條共用規則撐住的。

一個角色的輸入，是另一個角色的輸出

另一個具體的細節：前端角色的定義檔裡，「輸入來源」寫的是 API 角色產出的檔案，並且註明這是「由 api-integration-agent 產出」。

這句話看起來只是技術細節，但它其實在說一件重要的事：角色契約讓下一棒知道要去哪裡接，同時也保護了每個 Agent 自己的工作範圍。前端 Agent 不用猜 API 怎麼呼叫、型別長什麼樣——它只要照定義檔的指示，去讀 API 角色已經產出的檔案。

Day 14 提到的三處衝突，能被抓出來，靠的也是同一件事：每個角色的輸出目標都寫死在固定的目錄裡（前端只碰畫面相關的檔案、API 只碰型別跟串接函式、文件只碰文件頁面）。範圍先被寫清楚，才有辦法檢查誰會撞到誰。

今天可以做的：替一種反覆出現的工作寫契約

今天不用建立完整的 Agent 系統。從你的專案裡挑一種反覆出現的工作類型——前端頁面、API 串接、測試、資安檢查，或文件——寫一份最小契約，先不要交給 Claude Code 執行。

# Role Contract｜角色名稱

## 範圍
- 這個角色需要知道哪些技術／框架：

## 禁止事項
- 不能做什麼（例如：不裝新套件、不改其他角色負責的檔案）：

## 輸入來源
- 要先讀哪些檔案／文件：
- 有沒有依賴別的角色先產出的東西：

## 輸出目標
- 只能新增或修改哪些路徑：

## 完成後回報
- 做完要交代哪些項目，讓人可以確認：

寫完後檢查一件事：找兩個會同時動手的角色，把它們的「輸出目標」放在一起比對。能馬上看出會不會撞到同一個地方，代表範圍寫清楚了；看不出來，代表還要再收斂。

小結：Agent 守備範圍清楚，各角色順利接力

DAP 的五個 Agent，靠的是技術範圍、禁止事項、輸入來源、輸出目標、回報格式這五件事串連。
這也是 Day 14 那天能把工作分批、抓出衝突的前提：角色的輸出範圍以先分工好，當 11 項功能同時進行時，就能去判斷衝突與先後順序。

下一篇接著寫：把這些反覆出現的流程寫成 Skill 之後，它跟「把常用的 Prompt 存起來」差在哪裡。

參考資料

• Claude Code. Subagents.