AI 生成代碼驗收清單：用證據核實結果

能跑通一次演示，只是一條觀察。驗收要回答的是：這個具體版本，是否在約定條件下完成了用戶任務，結論是否有可複查的證據？

本清單適用於獲授權環境中的小型應用功能、API 改動或缺陷修復。從用戶正常入口開始，檢查到最終可持久保留的結果。清單可以手動使用；相關 Skill 用來組織工作，並非填寫模板的前提。

適合與不適合的範圍

適合審查範圍明確、基線和需求可識別、能夠訪問相關運行環境的改動。檢查深度由行為風險決定，不由修改文件數決定。

它不替代滲透測試、無障礙合規評估、受監管系統認證或生產壓測方案。支付、身份、敏感數據、破壞性遷移和安全關鍵系統需要額外的專業審查。打勾不構成法律或安全保證。

1. 固定驗收對象

記錄基線、候選提交或構建產物、環境、瀏覽器或運行時、角色、獲準的數據來源及副作用範圍。存在未提交修改時，還需保存差異快照或哈希。先附上需求來源並分配 REQ/AC 編號，再看測試結果。

每項需求都寫成獨立於代碼實現的可觀察結果。「執行了 Save 處理函數」不夠；「有權限的用戶重新打開記錄後仍看到新值」才是結果。關鍵規則缺失時標為 BLOCKED，不從生成代碼反推正確需求。

使用 PASS、FAIL、BLOCKED、NOT RUN 或 N/A。N/A 必須說明为何確實不適用，不能用來掩蓋工具缺失。沒有證據不能判 PASS。例外應記錄決策人、範圍和後續事項，不可悄悄改成通過。

2. 執行適用檢查

• [ ] 需求: 將每項 REQ/AC 對應到實現入口、用例和結果。檢查差異中完全缺失的承諾，記錄已同意的排除項，並確認沒有擅自增加業務規則或權限。

• [ ] 核心功能與持久化: 從對應角色的正常入口完成任務。寫入後刷新或重新打開，在允許的訪問範圍內讀回權威狀態，並關聯同一對象和請求。成功提示不能單獨證明保存成功。

• [ ] 邊界與狀態: 按實際規則檢查缺省、空值、非法值及上下界兩側，確認計數單位。按風險覆蓋合法和非法狀態轉換、重複點擊、舊頁面及並發更新。

• [ ] 錯誤與恢復: 僅在獲準的隔離環境測試超時、拒絕、部分失敗和中斷。確認用戶能理解錯誤並恢復操作；重試不重複產生副作用，遲到響應不能覆蓋更新的操作。

• [ ] 安全基礎: 檢查實際動作及對象的服務端授權，包括歸屬不同的第二個測試賬號。拒絕请求不得改動數據；按攻擊面檢查輸入校驗、輸出編碼及構建文件或日誌中的憑據洩露。只做授權檢查，不攻擊無關系統。

• [ ] 可訪問性與交互: 用鍵盤完成受影響流程，檢查焦點、名稱和標籤、錯誤及彈窗關閉。檢查縮放、窄屏、可讀對比度和有意義的替代文本；按產品需要增加輔助技術檢查。這些基礎檢查不等於合規評估。

• [ ] 性能: 先約定操作、數據規模、設備和網絡條件、測量方法與閾值。測完整用戶操作，不只測 API 耗時；同條件比較基線並保留樣本及資源觀測。無閾值時報告測量結果並等待決策，不自設及格線。

• [ ] 回歸與審查: 運行受影響的現有檢查及倉庫要求的 lint、類型、構建和測試。覆蓋共享調用方及相鄰合法和非法路徑，審查最終差異是否遺漏需求或削弱斷言。修復要保留修復前失敗、修復後通過的信號。

• [ ] 證據與交付: 每個結論都關聯被測版本、實際步驟或命令、預期、實測及原始證據。明確標註 Mock、固定樣本、合成數據及靜態審查；確認最終差異沒有使證據過期。本地驗證、部署和目標運行環境驗收分開報告。

3. 保存可複查的小型證據記錄

每例記錄：CASE 編號 → REQ/AC → 角色和數據來源 → 精確步驟 → 預期 → 實際 → 狀態 → 通過或失敗證據 → 環境及版本 → 缺口與負責人。

截圖只能證明可見狀態，不能證明持久化；200 響應不能證明目標對象正確變更；Mock 測試通過不能證明真实依賴可用。證據必須匹配結論，隱去秘密，只分享給獲準查看的人。

可使用配套 Markdown 模板，或複製下方記錄格式。模板包含九個起始檢查項及可複製的用例記錄；每行是覆蓋提示，不代表整個類別已通過。

• CASE / REQ / AC: ____
• 角色 / 初始狀態 / 數據來源與替代數據許可: ____
• 可複現的精確步驟或命令: ____
• 預期結果與規則來源: ____
• 實際結果: ____
• 狀態（PASS / FAIL / BLOCKED / NOT RUN / N/A）: ____
• 通過證據：產物或脫敏日誌、時間、版本: ____
• 失敗證據：準確差異及產物、時間、版本: ____
• 持久化 / 外部最終狀態讀回: ____
• N/A 理由或剩餘缺口 / 負責人 / 下一步: ____
• 修復前結果 / 修復後結果 / 受影響回歸: ____
• 最終差異審查證據: ____

4. 合成演示：保存顯示名稱

以下僅為合成教學演示。輸入和觀察結果均為說明記錄方式而虛構，未在用戶生產項目或任何真實驗收會話中執行。

假設已明確約定：去除首尾空白後，顯示名稱允許 1–40 個 Unicode 碼點，用戶只能修改自己的名稱。這只是示例規則，不是通用推薦限制。

CASE-NAME-01 / AC-NAME-01：從正常菜單打開個人資料，保存「River」，重新打開。預期：名稱仍為「River」，獲準的讀回結果屬於同一賬號。假設觀察：成功提示出現，但重新打開顯示舊名稱。演示狀態：FAIL。真實執行時應採集修改前後畫面、脫敏請求及同賬號同版本的權威讀回證據；本文並未提供這些運行證據。

CASE-NAME-02：嘗試去空白後為空，以及 1、40、41 個碼點的輸入。按假設規則，空值和 41 應拒絕，1 和 40 應接受。這些僅為計劃用例，狀態 NOT RUN；使用前先核實樣本實際計數，碼點、位元組和用戶感知字符並不相同。

CASE-NAME-03：在授權測試環境用賬號 A 嘗試修改賬號 B。預期拒絕且 B 不變。CASE-NAME-04：中斷保存，按約定恢復規則重試並檢查最終狀態。未使用授權測試賬號和故障條件執行前，兩項均保留 NOT RUN。

5. 決定哪些部分真正就緒

分別報告倉庫規範、需求覆蓋和運行時驗收。約定範圍內仍有 FAIL、BLOCKED 或 NOT RUN 的驗收項，就不能宣稱整體完成。「本次差異未發現可證明的缺陷」只是限定範圍的審查結果，不是無缺陷保證。

失敗後保留證據，區分產品、測試、環境、數據或需求問題。不要削弱斷言、刪除用例或反覆重跑碰運氣。僅在授權範圍內修復，再跑原始用例及受影響路徑，審查最新差異。

用準確交付狀態：已實現、本地已驗證、已部署、真實路徑已驗收。本地驗證不授權部署； deployed 也不能單獨證明用戶任務可完成。

選擇相關工作流程

• talking-us: 成功規則不明確或產品決策待定：澄清需求，不修改產品。
• write-design-doc: 需求已確認，但 API、數據或狀態契約不清：整理可直接實施的設計。
• test-case: 由需求推導用例。design 用於規劃，validation 用於已授權的現有檢查；模式名不授予修復或替代數據權限。
• bug-fixing: 已有可複現失敗：追蹤首先破壞規則的地方，獲準後修復並驗證相關路徑。
• code-review-multiagent: 對照需求和調用方審查最終差異。默認深入 Solo；獨立智能體按風險和宿主能力啟用。
• develop-closed-loop: 將已授權且規格明確的改動推進至實現、測試、修復、回歸、審查和交付證據。所需配套流程須另行安裝。

已知局限與參考資料

本文是基於六個工作流程包整理的原創實用指南，不是它們跨模型行為的測試報告。Skill 不提供賬號、瀏覽器、數據、 deployed 訪問或權限；單個下载不等於完整合集。部分界面設計分支依賴未打包的外部 frontend-design-lab。

模板用於記錄證據，不能自行發現缺陷。抽樣需要說明等價依據及未覆蓋分支；合成示例不能替代要求的真實業務數據。訪問缺失時，保留待驗收狀態，繼續不依賴該條件的安全檢查。

安全基礎可參考 OWASP 關於逐请求權限校驗及在正確可信邊界執行授權的建議：OWASP Authorization Cheat Sheet。基礎可訪問性檢查及其局限見 W3C WAI Easy Checks。這些參考不意味著本清單構成完整審計。

下载 Markdown 模板