本篇由 AI 協作整理。 內容整理自 a11y-moda 的開發與驗收經驗，由作者與 Codex 協作編排，發布前由作者確認。協作模式見 Day 01。

如果你已經熟悉某個領域，想請 AI 把反覆檢查的工作做成工具，可以從這份手冊開始。

你需要能準備案例、解釋預期結果，並確認產出是否符合用途。實作語言不熟悉的地方可以找 AI 協助；判準有歧義、結果無法確認的地方，仍然需要你或能覆核的人處理。

這份手冊是〈前端不寫 Python，照樣 ship 一把網頁無障礙 CLI〉系列的附錄。你可以獨立使用，需要看實際案例時，再沿著各節的連結回到文章。換到其他領域，仍需準備自己的驗證資料。

先挑一個你能驗收的問題，把預期答案寫下來，再交給 AI 實作。

這份手冊怎麼用

第一次使用，依照下面的順序走一遍。之後新增規則時，可以直接複製規則卡，從填卡開始。

先選一個你能驗收的問題

挑一件經常重做、有可查來源、做錯能被發現的工作。第一版縮到一個輸入、一種判斷、一份輸出。

例如，先檢查一種表單標籤，或一個匯入欄位是否符合約定格式。選題時就寫清楚第一版的範圍，避免實作途中一路長成整套稽核平台。

若你現在還說不出「怎樣算對」，先把判準與案例整理出來，或找熟悉這項工作的人確認。把整份規範交給 AI，不會自動產生驗收標準。

複製這張規則卡，填完再開工

每條規則各填一張。保留來源的版本與日期，之後需求或規範改了，才知道哪些判斷需要重新確認。

【規則卡】

問題：這條規則要回答什麼？
來源：條文或規格的位置、版本與日期。
範圍：哪些輸入、狀態或情境適用？哪些不適用？
操作定義：轉成程式時，哪些閾值或假設是我自己選的？
證據：需要讀資料、操作介面、看畫面，還是做語意判斷？
測例：已知符合、已知不符合、邊界條件、證據不足。
停止條件：什麼情況必須留下未知，不能給通過或修法？
驗收者：誰能確認上述判斷？

其中最容易漏的是「操作定義」。規範寫得抽象時，程式仍需要具體條件。你自行選的閾值要標明，讓接手的人能分辨它與原始要求的關係。

實際案例：Day 07：六個魔術數字都是我拍板的，所以我把程式碼送出去。

準備四種測例，先寫預期答案

每種先準備一個，之後隨實際遇到的問題補充。這是起點，並不代表四個例子就足以涵蓋整條規則。

可以用這個格式保存每個例子：

【測例】

名稱：
輸入與前置條件：
預期結果：
判斷依據：
執行方式：
實際結果：
差異與後續處理：

預期答案先寫好，再請 AI 實作。 不要只讓同一輪 AI 同時生程式、猜答案，然後用兩者一致證明正確。

如果連預期答案都無法確定，就先回到規則卡補來源、縮小範圍或找人確認。

每次交給 AI 一條可驗證的路徑

把規則卡、必要來源、測例與現有介面一起交給 AI，並寫清楚允許修改的範圍。下面這段可以當作任務說明的起點，再補上你的專案條件。

請依附上的規則卡與測例，完成這一條判斷路徑。

修改範圍：〈填入允許修改的模組或功能〉
執行與驗證方式：〈填入專案實際使用的指令或操作步驟〉

開始前列出假設；判準有歧義時先提出問題。
實作後執行測例，保留實際結果與差異。
必要證據缺失時，回報無法判定的原因。
若認為預期答案有誤，提出依據，交由驗收者確認後再更動。
完成後說明改了什麼、如何驗證、還有哪些限制。

選最容易取得可靠證據的方法。結構可判的先讀結構，需要狀態就操作，需要語意才交模型。使用模型時，保留必要的輸入與原始回覆，工具不能把無效回覆猜成通過。

若採自動載入規則，也要確認規則確實被載入與執行。「沒有報錯」不足以證明這件事。相關取捨見 Day 03；給 agent 的使用界線見 Day 20。

驗收結果，也追查結果怎麼來

先跑準備好的測例，再跑有授權的真實案例。逐筆確認：

• 規則是否真的執行？
• 拿到的是判斷所需的證據嗎？
• 結果是否符合預期？
• 如果漏報或誤報，問題出在輸入、取證還是判定？

修之前存一份基準，修之後用相同條件重跑，逐項對照已解決、仍存在與新出現的問題。

項目識別方式也需要檢查。本專案的片段內容如果改變，同一個問題可能同時出現在「已解決」與「新出現」，仍需人工覆核。只看總數下降，會漏掉這種情況。

實際案例：Day 23：我沒教 AI 怎麼修，我教它怎麼證明修好了。

工具判不了時，留下可接手的紀錄

先確認缺少哪種證據，再安排補證據的工作。以下是本系列的網頁檢查例子，供你理解如何拆解；它不是工具內建分類，也不能涵蓋所有未知。

原始輸出保留不動，覆核結果另外記。你可以把下面的格式放進團隊工作單：

【覆核與交接】

原始結果的位置：
適用範圍與環境版本：
目前缺少的證據：
補查步驟與取得的證據：
覆核者與日期：
結論及適用限制：
未完成事項與下一步：
接手者：〈尚未確認時，寫待指派〉
重驗時機：

提醒數量歸零不是結案條件。讓接手的人知道結論適用在哪裡、什麼改變之後需要重驗，才有辦法繼續處理。

實際案例：Day 29：工具說「我不知道」的時候，你該怎麼辦。

交付前，請另一個人照紀錄走一次

交付時，至少確認這幾項：

• 工具取得方式與操作說明可用。
• 使用範圍、已知限制與版本交代清楚。
• 測例、預期答案與驗收結果留得下來。
• 未完成事項有下一步，接手狀態明確。
• 另一個人能照文件重做，遇到差異時知道去哪裡查。

工具更新時，文件與指令也一起驗證。第一次換到另一個網站或領域，重新跑反例與邊界案例；作者自己的環境能跑通，只證明那個環境成立。

相關經驗：Day 27：發版清單九步，我漏的那一步是使用者第一眼看的那頁。

你現在就能開始的第一步，是挑一條熟悉的規則，複製上面的規則卡，把四種測例的預期答案填好。等這個小問題能驗收，再決定下一條要做什麼。

回到完整系列，或接著讀 Day 08：人的架構與驗收工作、Day 26：把失敗寫成規矩。