我們走到了終點。所以在這篇文章中，讓我們回顧整個系列，看看我們現在的位置。三十天的驗證工作產出了一本手冊、實用的測試產物，以及一套更清晰的方式來評估軟體與 AI。但完成這個系列並不代表所有問題都已解決。真正的成果，是知道我們能驗證什麼、已經觀察到什麼，以及還有哪些不確定之處。

這最終篇文章回顧這段工作、指明尚未解決的問題，並確立如何維護這本手冊。目標不是宣告成功，而是把結果及其限制說清楚。

1. 回顧：三條工作線，三套產物

第一條線，驗證 AI 撰寫的程式碼（第 07–14 天），關注驗收標準、突變測試、假綠燈、測試資料與 API 合約。這些產物有助於確立測試是否能偵測缺陷，而不只是通過而已。

第二條線，驗證 AI 驅動的功能（第 15–21 天），引入了可接受範圍、黃金集、評分準則（rubric）、評審校準與對抗性案例。

第三條線，將驗證接入交付流程（第 22–27 天），把測試與 CI 管線、品質閘門、回歸分診、發佈清單以及生產環境監控連結起來。這個順序很重要：期望不明確，評估就不可靠；評估不可靠，發佈決策就會被削弱。

2. 誠實列出仍然未解的問題

第一個未解的問題是證據是否足夠廣泛以支持結論。只包含十個案例的黃金集太小，不足以對整體品質提出強而有力的主張：只改變其中兩三個案例的結果，通過率就可能大幅變動。長尾輸入與多重意圖的對話也未獲充分涵蓋，因此目前在這套資料上的好結果，並不能證明較少見的使用者旅程也會正常運作。成本與延遲的取捨同樣懸而未決。更準確的答案可能更慢、更貴，但若沒有一個明確、可審查的產品門檻，我無法說明多少額外的品質值得付出多少額外的成本。這些不是無關緊要的附註；它們定義了目前的結果能在多大程度上被信任。

其餘的問題則關乎治理與長期可靠性。LLM 評審已與人工評分做了校準，但其偏差尚未被充分量化，而且模型或評審提示詞的改動可能改變它的行為。維護的權責仍未確定：沒有指定的負責人與審查節奏，評估產物可能一邊過時、一邊繼續顯得權威。閘門例外也需要審視。每一個例外單獨來看或許都有合理的解釋，但它們的累積效應可能悄悄削弱整個發佈流程。記錄這些缺口不是承認工作失敗。這是我區分「已承認的限制」與「隱藏的假設」的方式——也是我防止一份成文的方法被誤認為「所有風險都已被控制」的證明的方式。

3. 維護節奏：避免手冊腐爛

維護計畫有三個部分。每當黃金集變動，立即更新其 schema 文件與變更日誌。每兩週，審查生產環境回饋與閘門例外。每季，重新檢視已知限制，決定哪些可以解決、哪些需要上報、哪些保持開放。

每一項職責都應在交接文件中記錄一名指派負責人與一名後備人選。這樣可以避免關鍵更新取決於單一個人的在與不在，也能在流程需要關注時，讓權責清楚明確。

驗證手冊 v1

這張表把整個系列整理成六個章節：策略與範圍、AI 撰寫的程式碼、AI 驅動的功能、交付整合、交接與技能，以及已知限制。每個章節記錄了它的時間範圍與產出的產物。最後一章尤其重要，因為它保留了尚未回答的問題，而不是把「時程走完」當作「工作完成」的證明。這本手冊既是一本實用的參考，也是一份記錄，寫明團隊已建立、以及尚未建立什麼。

這三十天教會我的事

從電子工程轉入軟體 QA 與 AI 驗證，讓我看到有些工程原則可以順利遷移，但產品知識與測試方法仍須從頭學習。量測、校準與公差提供了有用的基礎；而 API 合約、機率性評估、回歸設計與發佈管控則需要額外的練習。

最重要的一課是：測試結果的價值，取決於它背後的問題與證據。一個通過的測試並不能證明覆蓋率足夠，一個高分也並不能證明測試集能代表真實使用情形。驗證也意味著把決策記錄下來，讓另一個人能夠理解、質疑並重現它們。

這本手冊仍然是從一個專案、一個團隊、一個演練（rehearsal）環境中發展出來的方法，而不是放諸四海皆準的規則。第 5 章的技能水準是我自己的評估，對另一個產品而言，權重會有所不同。最重要的是，每一個數字都是演練資料：方法可以帶走，結論不會自動跟著走。其他團隊必須在他們自己的系統、風險與限制下驗證這套做法。

一份簽署過的校準報告，不代表誤差為零；它代表誤差已被記錄。同樣地，完成三十天不代表每一個風險都已被消除。這個系列的價值，是一份成文的方法、一份已檢視過什麼的記錄，以及一份對仍需證明之處的誠實交代。

感謝你看完!