Day 10 我先處理 AI 改程式時的範圍：哪些檔案可以動、哪些 API 與 payload 不動，完成後再看 Git diff 和頁面。

為了讓這次驗收完後，下一次也可以用相同的標準驗收，所以在 Spec、Plan、Task 之後，我也開始把驗收方法留下來。DAP 裡，這份文件叫做 Scenario。

• Scenario 是驗收情境：把 Spec 的 AC 寫成前置條件、操作與預期結果。
• 它和 spec.md、plan.md、tasks.md 放在同一個功能資料夾的 scenarios.md，讓下一次仍能知道怎麼驗。
• DAP 目前由 LLM 依 AC 產生 Scenario，再用 Playwright MCP 依情境操作頁面與回報。

Scenario：把「應該符合」改寫成「怎麼確認」

Spec 裡的 AC，通常描述需求應該達成什麼。例如這次的 AC 可以是：送出後，要顯示新增與移除成員清單。

至於要「怎麼驗」，Scenario 會再往下把驗收過程寫出來：先準備什麼環境、資料或登入角色，接著做哪些操作，最後要看到什麼結果。

所以 Scenario 較像把「這次完成的定義」寫成操作說明，讓人和 LLM 能用同一份依據驗收。

Anthropic 在談 agent eval 時，也把「先定義成功」視為重要起點。DAP 的 Scenario 還不是完整的 agent eval；不過它先讓「成功」不再只是一句模糊的感覺。Demystifying evals for AI agents

057：一個小 UI 改動，為什麼要寫三種情境？

057 的 Scenario 至少要完成三條情境。

第一條是新增兩位、移除一位成員，確認多筆資料都能被列出，不再只是「2 人／1 人」。第二條是只新增、不移除，確認空的一邊明確顯示 —，而不是留下一塊不知道代表什麼的空白。第三條則是送出時確認，原本新增與移除成員的資料結構仍維持不變。

需求：摘要從人數改成成員清單
  ↓
Scenario 1：新增與移除成員都要正確列出
Scenario 2：只有新增時，移除欄要清楚顯示空值
Scenario 3：送出資料要維持原本結構

同一個功能不是只有「有沒有成功」；它至少還有邊界情況與既有行為要守住。

把 Scenario 留成文件中

Scenario 在 DAP 不是貼在某一次對話的最後，而是和這個功能的 Spec、Plan、Task 放在一起：

web/specs/<功能名稱>/
├── spec.md       # 要做什麼、驗收條件
├── plan.md       # 怎麼做、改動範圍
├── tasks.md      # 具體工作
└── scenarios.md  # 怎麼操作與驗收

這個安排跟我第二代做 Vibe Coding 的經驗有關。那時需求會不斷來回，哪個欄位要補、哪支 API 要呼叫、畫面要怎麼呈現，過幾天很容易只記得最後一次改動，忘記原本為什麼要這樣做。

現在把 scenarios.md 留在功能資料夾，一樣是要把最容易忘記的一段留下來：這個功能當初預計怎麼驗？下一個 LLM session、QA Agent 或接手的同事，都能從同一個地方找到答案。

這份檔案不是只有一串待辦事項。DAP 的既有格式會把 Scenario 寫成結構化情境，包含固定的測試帳號、要選擇的專案或資料前置，以及對應哪一條 AC。這樣 LLM 不必每次重新猜測「要用誰登入、在哪一頁、準備什麼資料」，驗證才有相對一致的起點。

Anthropic 在 Claude Code 的實務建議中，也提到清楚的測試或視覺目標，能讓 agent 有可以反覆核對的目標。對我來說，Scenario 就是在程式旁留下這個目標。Claude Code: Best practices for agentic coding

LLM 怎麼用 Playwright MCP 驗證 Scenario？

第三代目前的流程是：LLM 先根據 Spec 的 AC 協助產生 Scenario；Scenario 裡會保留固定測試帳號、專案或資料前置，以及 AC 對照。接著 LLM 使用 Playwright MCP 啟動本機頁面，依前置與操作步驟執行檢查，最後回報它看到的結果。我在開發完成後，再確認需求、畫面與流程是否符合預期。

這樣做省掉的是每次人工重複下指令、重新描述操作步驟的時間。

我會把這三種東西刻意分開看：

DAP 的 Scenario 驗證使用 Playwright MCP，讓 LLM 能依結構化情境操作瀏覽器。這次跑過，代表功能曾被實際操作驗證；至於把每份 Scenario 都轉成能隨部署流程反覆執行的測試程式，則是後續可以逐步補上的工作。

Anthropic 對 Claude Code 實際使用情況的研究指出，人多半決定要做什麼，agent 多半負責怎麼執行。放回我的流程裡，LLM 可以幫我跑 Scenario；但這些 Scenario 是否夠、哪些結果可以接受，仍要由我用業務理解來判斷。Agentic coding and persistent returns to expertise

今天可以做的：替一條 AC 寫三個 Scenario

這一天不要求你建立完整測試框架。挑 Day 10 的同一個小改動，先替它寫三種 Scenario：正常路徑、一個邊界條件，以及一個「不能被這次改動弄壞的既有行為」。

把它放在自己的 Repository：specs/<功能名稱>/scenarios.md。

# Scenarios｜功能名稱

## 前置
- 環境／登入角色：
- 必要資料或 mock：
- 進入頁面：

| # | 對應 AC | 情境 | 操作 | 預期結果 |
| --- | --- | --- | --- | --- |
| S1 | AC1 | 正常流程 | ... | ... |
| S2 | AC2 | 邊界情境 | ... | ... |
| S3 | AC3 | 既有行為不變 | ... | ... |

接著可以請 Claude Code 讀 Spec、Plan、Task 和相關頁面，協助產生這份檔案：

請讀取這次的 spec.md、plan.md、tasks.md 與相關頁面。
依每條 AC 產生 scenarios.md，至少包含前置、操作與可觀察的預期結果。
請另外列出：哪些情境只能在真實後端或特定角色下驗證。
不要把「功能已完成」當成預期結果，也不要自行發明業務規則。

產出後，先不要急著叫 AI 寫更多程式或測試。先看另一位同事照這份 Scenario 操作，能不能判斷對或不對。若做不到，通常應該先修的是驗收條件，而不是 prompt 長度。

小結：先把完成寫下來，驗證才不只靠記憶

057 把人數改成成員清單，需要正常情境、邊界情境和既有 payload 不變三種驗收。Scenario 讓這些條件不再散在對話過程中，讓 LLM 有可以依循的檢查目標。

現在 DAP 做到的是先把「要驗什麼」留下來；可重跑的測試、資安檢查與正式環境證據，仍要逐步補上。

下一篇會從這裡接下去：畫面與流程符合 Scenario 後，為什麼我還要停下來做資安審查？

參考資料

• Anthropic. Claude Code: Best practices for agentic coding.
• Anthropic. Demystifying evals for AI agents.
• Anthropic. Agentic coding and persistent returns to expertise.