- Published on
什麼是驗證矩陣 (Verification Matrix)？讓 AI 從需求端守護品質
Table of Contents
🧭 系列文章導讀
在見識過 Agentic Testing 自動點擊畫面的威力後，我們將鏡頭拉回軟體開發的最源頭：「需求定義（Inception）」。本篇探討在 AI-Driven Life Cycle (AIDLC) 中，如何確保寫出來的程式碼不會是一場「需求理解錯誤的災難」，並介紹核心法寶： 驗證矩陣 (Verification Matrix)。
當「測試左移」撞上「AI 寫 Code」
前面我們提過「測試左移（Shift-Left）」：越早發現 Bug，修復成本越低。但在 AI 時代，AI 寫 Code 的速度實在太快了。
如果你給 AI Agent 一行模糊的需求：「幫我寫一個登入功能」。它可能在幾秒鐘內就拋出了一個包含驗證碼、OAuth、忘記密碼的巨型 PR 給你。結果？你發現它完全漏了「如果帳號被停權該怎麼辦」的邏輯。
這就是為什麼在 AWS Labs 提出的 AIDLC（AI-Driven Development Life Cycle） 中，特別強調了 Inception Phase（規劃與設計階段）。在開發者與 Agent 開始瘋狂產出程式碼前，我們必須先釐清「要蓋什麼，怎麼驗收」。
圖說：在 AIDLC 框架中，需求描述輸入後，AI Agent 必須先生成「驗收準則」與「驗證矩陣」，經過人為閘門審核後，才放行至下一步的架構設計與實作。
仔細看上面的流程圖，這不是單純請 AI 寫 User Stories 就結束了，在它的輸出中，最引人注目的就是 建議驗證矩陣 (Propose Verification Matrix)。
什麼是驗證矩陣 (Verification Matrix)？
簡單來說：它是一個二維的檢查表，用來確保「所有功能點」在「所有測試維度」下都被妥善考慮。
傳統上，PM 或 SA 寫出來的 Acceptance Criteria (驗收準則) 通常是一條條的清單：
- "密碼必須大於 8 碼"
- "輸入成功後導向首頁"
這種條列式的寫法非常容易出現人類思維盲區：我們往往只記得寫正常情境 (Happy Path)，卻忘記邊界值或異常情境 (Negative Path)。
驗證矩陣將思維立體化了。它的行（Row）是你的「功能點 / 業務規則」，列（Column）是「測試維度（如: 正常、異常、邊界、效能、資安）」。
| 功能點 / 業務規則 | 正常情境 (Happy) | 異常情境 (Negative) | 邊界值 (Boundary) | 資安考量 (Sec) |
|---|---|---|---|---|
| 使用者登入 | 正確帳密可登入 | 錯誤密碼拒絕 | 連續錯 5 次鎖定帳號 | 預防 SQL Injection |
| 密碼長度驗證 | 10 碼正常通過 | 缺少特殊符號阻擋 | 剛好 8 碼 (過) / 7 碼 (擋) | 拒絕極長密碼 (DOS攻擊) |
當我們要求 AI 在寫 Code 前，先為這個功能畫出這張表格，意義非凡：
- 強迫全面性思考：格子空在那裡，就代表某個維度的測試沒被考慮到。
- 防呆與抓漏：PO (Product Owner) 或開發者在「人為閘門」審核時，看著矩陣一眼就能發現：「咦？我們根本沒定義帳號被鎖定後怎麼解鎖啊？」
如何用 AI Agent 產出驗證矩陣？
在實戰中，你可以將這段 Prompt 加入到你團隊的架構設計指南 (如 .cursorrules 或 instructions.md) 中，在專案啟動時呼叫：
你是一個資深的 QA 架構師與系統分析師。
請閱讀我剛剛給你的功能需求草案（或 User Story）。
在我們開始撰寫任何程式碼之前，請為這個功能產出一個「驗證矩陣 (Verification Matrix)」。
請以 Markdown 表格呈現，必須包含以下欄位：
1. 功能點 / 動作 (Feature / Action)
2. 正常路徑 (Happy Path)
3. 負面測試 (Negative Cases / Errors)
4. 邊界測試 (Boundary Values)
5. 狀態轉換與相依性 (State Transitions / Dependencies)
如果需求描述中有模糊地帶，或者有任何格子你認為缺乏定義，請在表格下方以粗體字向我（PO）提出反問，直到我們釐清所有邏輯為止。透過這個簡單的 Prompt，AI 從一個「盲目聽從指令的代碼產生器」，進化成了一個「能幫你盤點漏洞的 QA 專家」。
矩陣的後續：從需求直達自動化測試
一旦這個驗證矩陣被 PO 審核通過（通過 Human Gate），它就成為了團隊無可爭議的 Single Source of Truth（唯一事實來源）。
接下來：
- 工程師：照著矩陣上的每一格實作邏輯。
- Agent Test 自動化：直接把矩陣丟給 AI，命令它：「為矩陣上的每一格，用 Playwright 寫出對應的 E2E 測試」或者是「用 Jest 寫出單元測試」。
這就是真正意義上的測試左移：我們把原本要到系統上線前才由 QA 拉 Excel 表格做的全方位驗證，拉到了在 IDE 剛打開、一行程式碼都還沒寫的需求規劃會議上。
當我們將「測試」從事後補救變成了事前規劃的基石，再搭配強大的 AI Coding Tools，我們就能夠打造出不僅開發神速，且堅不可摧的軟體系統。