什麼是驗證矩陣 (Verification Matrix)？讓 AI 從需求端守護品質

當「測試左移」撞上「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 先把需求轉成 User Stories、驗收準則與驗證矩陣，經過 PO 在人為閘門審核確認後，才放行到架構設計與實作。

仔細看上面的流程，AI 除了寫 User Stories，輸出中最引人注目的是建議驗證矩陣（Propose Verification Matrix）。

什麼是驗證矩陣 (Verification Matrix)？

驗證矩陣是一個二維的檢查表，用來確保「所有功能點」在「所有測試維度」下都被妥善考慮。

傳統上，PM 或 SA 寫出來的 Acceptance Criteria（驗收準則）通常是一條條的清單：

• 「密碼必須大於 8 碼」
• 「輸入成功後導向首頁」

這種條列式的寫法非常容易出現人類思維盲區：我們往往只記得寫正常情境（Happy Path），卻忘記邊界值或異常情境（Negative Path）。

驗證矩陣將思維立體化了。它的列（Row）是你的「功能點 / 業務規則」，行（Column）是「測試維度（如：正常、異常、邊界、效能、資安）」。

要求 AI 在寫 Code 前先為這個功能畫出這張表格，有兩個好處。

1. 強迫全面性思考：格子空在那裡，就代表某個維度的測試沒被考慮到。
2. 防呆與抓漏：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，我們就能打造出開發神速又堅不可摧的軟體系統。