產出的人不能驗自己:AI 時代的驗收設計
楊騏 (Ci) · WaCare 數位健康 Tech Lead
· A 會議室 · 分堂議程
官方場次介紹 ↗
🕒 錄音長度 38:5211,360 字26 張照片
Ci 分享 AI 驅動開發的驗收設計:核心不在讓 AI 寫得更快,而是當 AI 宣稱完成時,能否以獨立驗證、明確規格與可追溯證據判斷是否可交付。當 AI 可在一晚完成大量工作,人類應將有限審查時間集中在規格、閘門與例外結果。
SDDHarnessAcceptance CriteriaConstitutionContract DrivenHuman in the loopCode ReviewEnd-to-End Test
會議重點
- AI 自產自驗容易形成「球員兼裁判」:同一個 session 或 Agent 同時開發與 Review,較可能忽略自身錯誤。
- SDD 以規格作為開發依據,但規格存在不代表已生效;必須將 AC、測試與驗證證據納入可執行的 Harness。
- 驗收應分層進行:先確認規格與 AC 是否被實測,再由獨立驗證者檢查實作、測試與最終自檢報告。
- 自動化程度須依風險與可逆性調整;低風險、可逆的 POC 可放手執行,高風險或不可逆操作必須保留 Human in the loop。
- 閘門不必複雜。實務上可用簡單的 shell 與 grep 產生 exit 0 或 exit 2;關鍵在於定義哪些界線必須阻擋、哪些僅警示。
Ci 以現場受眾角色調查開場,說明工程師、PM 與設計師皆可參與 AI 驗收流程。SDD 與 Harness:讓規格成為可驗證的約束
SDD 的基本流程為規格、計畫與實作;Ci 主張再加入驗證與交付確認。AI 可協助撰寫規格,但人員需先確認需求與 AC,避免 AI 在錯誤或不完整的目標上高效率產出。Harness 則是在工程系統外層設置的監督與限制機制,要求 AI 以測試、檢查表與證據證明完成度。
以 AI 常宣稱「做完了」但實際未完成的情境,帶出 Harness 必須要求可查驗證據。
同一個 AI session 兼任開發與 Review 容易漏錯;採用新的 reviewer 可提高問題發現率。
SDD 流程以規格驅動開發,並在實作後補上驗證與交付確認階段。
Harness 將 AC、契約、TDD、End-to-End Test 等控制點納入 AI 開發流程。
說明 AC、Constitution、契約、QA 視角驗證與自檢報告,是本次驗收設計的主要構成。Human in the loop 應置於兩個關鍵點:第一,AI 完成規格與 AC 後,由人確認是否符合團隊真正需求;第二,AI 完成工作並提交自檢報告後,由人審查其做過哪些驗證、哪些項目仍未確認。中間若發現偏差,可回饋 hints 要求重做或更新。
Human in the loop 聚焦於規格與 AC 核准,以及最終自檢報告的人工判讀。AC 與 Constitution:把「完成」寫成可測條件
AC 應明確描述需求完成條件及驗證方式,而非僅寫抽象目標。撰寫後至少檢查三點:是否有邊界、是否能清楚驗證、是否足以判定完成。AI 後續可依 AC 撰寫 Unit Test、TDD 與 End-to-End Test,並回到 AC 檢驗結果。
以可驗證的 Acceptance Criteria 示範如何將需求、限制與預期結果具體化。Constitution 是專案不可違反的規矩,應在 SDD 每個階段持續載入,例如禁止修改特定區域、必須遵循特定規範。為降低幻覺與虛構完成狀態,驗證輸出必須標示來源與實測證據;若無法確認,應明確回報未驗證,而非補寫推論。
自動化授權依風險與可逆性區分:低風險、可逆的 POC 可高度自動化;高風險或不可逆操作需人工介入。
以小 bug 被拆成過多 Story 與 AC 的案例提醒:SDD 應依專案情境調整粒度,避免流程過度膨脹。實務上,規格是否真的被執行比規格文件是否存在更重要。講者曾讓迴圈整晚執行且每輪皆顯示成功,事後才發現流程根本未走過既定規格;因此,規格應透過可執行檢查與明確 exit code 連結到實際閘門。部分檔案可先採 warn 而非阻擋,但必須清楚管理例外。
Prototype 與契約:縮短落差、支援前後端並行
AI 可快速產生 Prototype,但 Prototype 不等同可交付產品。為降低其與既有產品的落差,AI 應取得產品元件與文件作為參考;Ci 以 Storybook 與 MCP 為例,讓 AI 可讀取既有 component 資訊,優先重用既有元件而非任意生成。
Storybook 可提供既有產品元件資訊,協助 AI 產生更貼近正式產品的 Prototype。
以產品元件與文件作為 AI 輸入,縮小快速 Prototype 與實際產品設計之間的落差。
前後端分離開發以共享規格與 API Contract 協作,避免各自依不同假設實作。前後端可各自使用獨立 repo 與 Agent,但共同讀取同一份專案規格;後端先產出 API Contract,前端即可依契約並行開發,不必等待後端完整實作。契約中的授權、欄位與相容性問題應先確認,避免整合時衝突。
共享規格專案串接前端與後端各自的 SDD 流程,讓兩側 Agent 依同一來源工作。
驗收報告可標示內容是已實測、已取得來源、推論或未驗證,協助人工快速篩選風險。
驗收採兩層檢查:先驗規格與 AC 是否完成,再驗實作與測試是否確實符合需求。獨立 Agent 分工與驗證環境
開發與驗證應由不同 Agent 負責。Ci 的做法是以 Claude 進行開發、Codex 執行驗證,降低同一上下文或同一模型為自身產出背書的偏誤。獨立驗證者曾發現可能出貨的程式碼錯誤、AI 捏造的引言,以及對產出者有利而容易被忽略的數字。
前後端 Agent 在共享契約下分工:前端進行測試,後端執行 API test,並使用可操作的驗證環境。
開發 Agent 與驗證 Agent 分離,例如以 Claude 開發、Codex 驗證,避免產出者自行判定通過。派工時應明定可使用檔案、工作位置、輸出位置與完成證據。可使用 Git worktree 讓多個 AI 平行工作,但相近功能仍須處理 merge conflict。驗證環境則需讓 Agent 能操作真實或足夠接近真實的情境;若完整帳號、SSO 或權限建置成本過高,可先提供 mock。
以 Git worktree 支援多個 AI 平行執行,並在派工時明確定義檔案範圍與完成證據。Review 閘門:以新鮮上下文驗證完成證據
End-to-End Test 必須限制 Agent 可操作的行為與權限,並要求證明合法身分及成功情境。測試綠燈本身不足以保證正確,仍須回看測試實際驗證的行為,避免只測到數值或與需求無關的條件。
Code Review 應分層處理:可由工具檢查者先自動檢查,再由 AI 與人員處理較高層次判斷。
Code Review 的規範與 Constitution 應提供給 reviewer Agent,使其依專案規則檢驗變更。每個 MR 應使用全新的 reviewer,以避免既有上下文造成盲點;但 reviewer 仍須讀取 Harness 中的共同規範。Review 結果應標示哪些發現來自實測、哪些僅為推論;必要時再交由另一個驗證 Agent 複查。不同 reviewer 亦可分別專注於不同風險面向,提升檢查深度。
每個 MR 由全新的 reviewer Agent 檢查,並以已實測與未證實標記呈現發現結果。
獨立驗證者檢查未看過的開發過程,可發現原開發 Agent 未察覺的實作或行為問題。「我們要負責任。」
— Ci
最終責任仍在人。AI 可產出自檢報告、協助過濾雜訊與指出未驗證項目,但人員應檢視報告與關鍵結果後才交付。驗收工作的轉變不是逐行閱讀所有產出,而是管理 AI 做了什麼、證據是否可靠,以及何處需要調整規則。
完整流程從需求、AC、平行開發到 Harness、Code Review 與驗收,將 AI 產出納入可追溯的交付機制。討論摘錄
- 放手程度取決於邊界設計:規範清楚、驗證者可靠時,可讓 AI 自主執行並於結果產出後集中審查。
- 示範與流程本身也要納入規則;若未明定「示範前必須實際跑過一輪」,即使採預錄影片,仍可能暴露驗收閘門的缺口。
- 現場問答聚焦前後端分離情境下,如何透過共享規格與 Contract 支援協作。
講者以 Harness 實作範例說明:設好邊界與驗證機制後,可將執行工作交由 AI 自主完成。
分享結尾提供後續工作坊、Prospect、Piron USB 與 Try、Discord 社群等延伸交流資訊。