可信賴交付作業與驗收證據

一項交付作業只有在組織接受交付後的產品狀態時，才算完成。程式可能已經成功編譯，測試套件可能全部通過，AI 程式開發代理也可能報告工作完成；這些結果能證明的，只限於實際經過測試或檢查的條件。

需求、結構化討論與交付作業把交付作業定義為針對一項連貫產品變更的完整交付循環。它由需求開始，經過討論和適用規格，再進入實作、驗證、驗收和發佈。本文集中討論最後這部分：實作完成後，組織如何取得足夠證據、審查整體結果，並決定是否接受為可信賴交付作業。

測試是驗收證據的重要來源，包括單元測試、整合測試、使用者驗收測試和壓力測試。規格優先交付把測試結果與其他適用證據一併納入驗收決定。

驗收基礎早在正式驗證之前已經開始建立。產品、架構、安全、可靠性、資料、品質、工程和其他相關職能，會在規格體系形成的過程中，分別訂立自己有權決定的條件。技術規格再把這些條件寫得足夠具體，讓工程人員可以實作；測試規格則說明哪些條件應以測試、量度、檢查或其他方式驗證。條件的表達會逐步變得具體，但原有含義和決策權威必須貫穿整條鏈路。

一項涵蓋六家公司的案例研究訪問了 30 名從業人員，發現需求變更若未充分傳達給測試人員，新需求可能未經驗證，已失效的舊需求卻仍被錯誤驗證，因而造成軟件品質問題、浪費工時和延誤。¹

AI 應用往往需要更多種類的驗證方法。有些條件可以用單元測試或整合測試作確定性驗證；模型行為則可能需要已標註資料集、評估指標、多次執行或人工抽樣。架構、程式碼結構、安全控制、營運行為、效能、成本和可維護性，亦各有適合的證據形式。

三個概念共同構成交付作業的最後階段。

可信賴交付作業是已經完成驗收的交付作業。組織持有足夠而且可供審查的證據，支持交付後的產品狀態符合已審查的意圖和適用要求；交付過程中產生的重大知識，也已完成收斂，成為日後可以直接使用的現況知識。

這裡的「可信賴」，是指組織能夠解釋並捍衛自己接受目前產品狀態的決定，包括採用了哪些證據，以及仍然承認哪些限制。缺陷相關證據仍然重要，但只是整體驗收基礎的一部分。

返回頁頂

1. 規格體系中的驗收條件

驗收條件是適用需求、規格或交付成果在獲得驗收前必須滿足的條件。對簡單改動而言，幾項條件可能寫在使用者故事（user story）或工程工單便已足夠；影響較大的變更，通常需要更廣泛的驗收基礎。

產品行為只是其中一部分。視乎交付內容，組織還可能需要檢查架構、安全、可靠性、私隱、資料語義、相容性、效能、可支援性、可觀測性、無障礙、成本，以及整個程式碼儲存庫適用的工程要求。這些條件來自不同職能，分別承載各自的專業判斷和決策權。

規格體系負責把這些判斷帶入實際交付。

條件進入工程階段後，來源仍然重要。安全要求由工程實作，並不會因此變成工程偏好；QA 為功能成果設計驗證方法，也不會因此取得功能決策權；正常流程運作順利，更不會令可靠性要求失效。驗證若揭示產品、架構、安全、可靠性或其他方面仍欠缺重大決策，問題便要交回真正有權決定的角色。驗證要令早前的決定可以接受檢查，不能在最後階段代替上游作出新決定。

返回頁頂

1.1. 範例：個人日程規劃工具

假設產品是一個包含行事曆和 AI 規劃器的個人日程規劃工具。使用者可以提出：

把我的健身安排移到下午 4:00 會議之後。

或者：

找出明天下午一個空閒小時，安排專案檢討時間。

規劃器可以讀取使用者的行事曆、提出或執行受支援的變更，並解釋結果。產品只負責個人行事曆規劃，不承擔一般用途 AI 助理的功能。

其中一種合理實作，是由 LLM 解讀使用者請求，伺服器端邏輯決定哪些操作獲准，領域服務負責讀取和修改行事曆，客戶端則以串流方式顯示執行進度和結果。本文的驗收模式不取決於特定模型供應商或代理框架。

一項擴充規劃器能力的交付作業，可能同時要滿足以下條件：

有些條件描述使用者直接看到的行為，有些則規定系統責任或決策權應放在哪裡。安全和可靠性要求尤其可能訂下一些即使模型判斷錯誤也必須成立的規則。效能和成本只有在組織事先說清楚工作負載和門檻後，才具備明確的驗收意義。

這個例子也顯示不同職能如何直接參與交付。產品職能定義規劃器的用途和預期成果；架構職能界定系統責任和控制點；安全職能決定哪些寫入操作獲准；可靠性職能定義失效和復原行為；工程把這些決定轉化為可執行工作；品質專業人員則選擇真正能暴露問題的驗證方法。驗收必須綜合這些判斷，一份下游檢查清單無法取代各職能的決策。

返回頁頂

2. 驗收條件如何轉化為可驗證要求

交付愈接近實作，驗收條件便要表達得愈具體。不同規格各自處理不同問題，因此表達方式會改變；原有決定的含義和權威則必須完整保留。

按照需求、結構化討論與交付作業所述的相稱原則，並非每項條件都要經過完整鏈路。一項確定性的業務規則，可能由功能規格直接落到一份技術規格和一個單元測試；一項會同時改變系統行為、授權方式和營運風險的 AI 能力，則可能需要多份專項規格，工程人員才有足夠資訊妥善實作。

返回頁頂

2.1. 範例：AI 產品範圍與行事曆寫入

假設產品的 AI 常設要求是：規劃器只能協助處理個人行事曆規劃請求。同一項要求到了不同規格層級，會被寫成不同形式。

這裡包含兩個問題。第一，模型能否正確理解請求，作出合理的範圍判斷；第二，即使模型判斷錯誤，系統能否阻止未獲授權的行事曆寫入。第一個問題可以用機率性方法評估；第二個問題則應在實務可行的情況下，由明確而確定的系統控制保護。

QA 或測試規格可以準備一組已標註資料，包括明確屬於範圍內的請求、明確超出範圍的請求、應要求澄清的模糊請求、同時包含行事曆和無關指示的混合請求、試圖誘導系統執行不支援操作的對抗性請求，以及必須參考較早對話才能理解的後續請求。然後再為這組資料訂立評估指標和發佈門檻，例如：

行事曆範圍評估資料集：
- 關鍵範圍外案例獲得寫入權限：0
- 範圍內請求辨識率：>= 已議定驗收門檻
- 已標註模糊案例中按要求作出澄清的比例：>= 已議定驗收門檻
- 混合意圖案例執行不受支援操作：0

這些門檻應在驗收設計時訂立，反映產品預期行為和風險容忍程度。團隊不能根據目前模型得分，把門檻調至足以通過。

一個模型分數不足以證明關鍵執行規則一定成立。團隊可以在已知行事曆狀態下執行被阻止的請求，確認沒有任何寫入；架構審查可以確認授權仍由伺服器端控制；工具呼叫和審計紀錄則可以確認被阻止的請求從未真正發出行事曆寫入。

兩類證據回答不同問題，驗收時必須分開判斷。

返回頁頂

2.2. 範例：可靠性要求與重試安全性

如果要求本身是確定性的，從要求走到證據的路徑可以簡單得多。例如可靠性規格可能訂明：

重試同一項已接受的行事曆寫入，不得建立重複的行事曆項目。

技術規格可以規定由行事曆寫入服務負責冪等（idempotency）機制，並說明如何識別重複請求。測試規格再直接演練這項保證：

1. 從已知行事曆狀態開始。
2. 使用請求識別碼 X，提交一項已獲授權的建立行事曆項目請求。
3. 使用相同請求識別碼 X 重試同一項寫入。
4. 讀取形成的行事曆狀態。
5. 驗證只存在一個對應項目。
6. 驗證重試結果符合已議定的回應契約。

這條證據鏈很直接：可靠性要求先變成技術責任，再由整合測試情境和儲存狀態比較驗證。方法雖然與前面的 AI 產品範圍例子不同，原有要求仍可一路追溯至實作和證據。

返回頁頂

3. 驗證方法與驗收證據

驗收證據的價值，取決於它究竟能證明甚麼。單元測試可以有力證明一項確定性的函式規則，卻幾乎無法回答系統有沒有維持指定的依賴方向；螢幕截圖可以證明某個 UI 狀態曾經出現，卻不能證明授權正確；模型評估分數可以描述一組資料上的模型表現，卻不能證明伺服器端控制無法被繞過；成功建置只代表軟件能夠編譯，不代表預期產品行為已經實現。

結構化保證論證（assurance case）透過明確推理把主張和證據連接起來。這種模型要求證據可以追溯至來源及產生方式；證據可以包括測試結果、形式分析、模擬、檢查，以及確定性、機率性或定性資訊。²

驗證方法應直接檢查要接受的條件。失敗後果愈重大，證據就愈需要直接而獨立，不能只依賴同一類檢查。

返回頁頂

3.1. 自動化行為驗證

當驗收條件可以表達為輸入、系統狀態和預期結果之間可重複的關係時，單元測試、整合測試、端到端測試、回歸測試、契約測試和性質為本測試（property-based testing）都能提供有力證據。自動執行固然有價值，更重要的是同一項主張可以隨實作改變而以一致方式反覆檢驗。

以個人日程規劃工具為例，自動化驗證可以涵蓋：

• 標準時間格式的解析和驗證；

• 新增、移動、更新和刪除行事曆項目後的狀態轉移；

• 獲准和禁止行事曆寫入時的授權結果；

• 冪等重試和重複項目預防；

• 請求被判定為需要阻止之後，行事曆狀態保持不變；

• 回退、取消和復原操作的行為；

• 規劃器、行事曆服務和客戶端之間的 API 與序列化契約；

• timeout 和例外處理；以及

• AI 規劃器變更後，既有手動行事曆操作仍然正常。

測試層級要與主張相配。單元測試可能足以驗證一項確定性的時間解析規則；但要證明被阻止的請求經過模型解讀、伺服器授權、工具選擇、資料寫入和事件發佈後，仍然不會改變行事曆，就要跨過真正負責保護該規則的多個元件，以整合測試或更高層級的方法驗證。

如果上游規格明確指出某項既有行為必須保持不變，回歸測試便直接成為本次驗收的一部分。它要證明這項交付作業確實保留了規格指定的行為，而不只是籠統地防止舊功能損壞。

測試的預期結果能夠追溯至已審查條件時，證據才最有價值。執行者可以圍繞自己的實作選擇產生大量測試，但涵蓋很多內部細節，不等於證明組織原本要求的行為已經得到正確理解和實現。

返回頁頂

3.2. AI 評估

要把 LLM 行為納入驗收，團隊需要先設計評估方法，說清楚要量度哪些產品行為，以及如何量度。評估設計可以包括具代表性的情境、版本化評估資料集、指標或評分準則、模型與重大配置、驗收門檻、按需要重複執行、失敗類別，以及足以讓審查者理解結果如何產生的紀錄。

HELM 為這類工作提供一個可參考的語言模型評估框架。它以 16 個核心情境和 7 項指標評估語言模型，並加入針對特定能力與風險的評估。³ HELM 把「測哪些情境」和「用哪些指標判斷」分開，讓多個行為面向可以同時接受觀察，毋須壓縮成一個總分。

在規格優先交付中，這些評估選擇屬於驗收鏈的一部分。需求與規格先決定哪些產品行為需要驗收，評估設計再把適合量度的行為轉化為證據，符合性審查最後把證據納入具明確責任歸屬的驗收決定。

同一類評估能力也可以直接建立在現有產品和測試基礎設施上。團隊可以把版本化驗收資料集存放在程式碼儲存庫，由一般測試程式或指令碼執行模型呼叫並計算已議定指標；需要專業判斷的部分，則使用有明確準則的人工審查；最後把結果保存為驗收證據。HELM 等專用語言模型評估框架可以改善可重複性、可比較性或證據管理，但框架本身並非必要條件。真正需要的是完整的評估設計和證據鏈。

對規劃器而言，AI 評估可以檢查模型是否：

• 正確辨認明確屬於行事曆規劃範圍的請求；

• 拒絕或重新引導明確超出範圍的請求；

• 遇到真正模糊的請求時要求澄清，而不是自行猜測並修改行事曆；

• 為下游執行產生有效的結構化規劃結果；

• 在多輪對話中保留相關資訊；

• 令使用者看到的解釋和實際執行操作保持一致；以及

• 當不存在唯一正確日程安排時，建議品質仍符合已議定的評分準則。

像 93% 這樣的數字，如果沒有說明量度基礎，本身幾乎沒有意義。當評估結果會影響驗收，交付紀錄至少應讓人查到資料集或版本、模型和重大配置、評估器方法、驗收門檻，以及主要失敗類別。

如果用 LLM 評分，這個評估模型本身也成為量度系統的一部分。Zheng 等人發現，LLM-as-a-judge 會受答案位置和答案長度影響，也可能偏向自己產生的答案，並受到推理能力限制。⁴ 模型抽樣若會造成明顯波動，團隊還可能需要重複量度。

驗收門檻是需求或評估設計的一部分，應在看到目前模型得分前訂立。新的證據有時會顯示原有門檻確實不合理，團隊可以修改，但那是一項規格決策，必須按正常程序審查，不能為了讓目前版本過關而調整數字。

機率性證據應如實保留其統計性質。它能支持的是「在這組樣本和這套配置下，模型表現如何」，而不是保證所有未來輸入都一定得到正確結果。

返回頁頂

3.3. 結構與架構驗證

有些驗收條件關心的不是輸出，而是責任配置、元件之間可否通訊、哪個來源可作最終權威依據，以及某個動作執行前必須經過哪個控制點。這些都是架構問題，單看執行結果未必能判斷實作是否真正符合要求。

軟件架構研究已有多種靜態符合性檢查方法。Knodel 和 Popescu 比較了 reflexion models、relation conformance rules 和 component access rules 三類方法，並從 13 個適用性維度分析各自用途。⁵

例如，規劃器的架構規格可能要求：

客戶端不得直接呼叫模型供應商。

可以用來支持這項條件的證據包括：

• 檢查瀏覽器或客戶端網絡流量，確認 AI 請求只會前往應用程式伺服器的端點；

• 檢查依賴，確認模型供應商的介接元件只存在於伺服器端；

• 確認模型供應商憑證不會出現在客戶端套件、瀏覽器儲存空間或客戶端配置；

• 檢查路由和服務，確認任何由模型觸發的寫入之前都會先經過伺服器端授權；以及

• 進行架構審查，確認不存在繞過預期控制點的替代路徑。

如果架構規格訂明行事曆寫入必須由行事曆領域服務負責，驗證就應檢查路由、代理或 UI 處理器有沒有直接寫入儲存層，或者在其他地方重新實作領域規則。即使責任放錯層級，正常流程的整合測試仍然可能全部通過。

實際方法可以包括依賴圖分析、匯入檢查、schema 與介面比較、網絡流量檢查、路由追蹤、最終權威依據審查，以及針對真正執行架構決定的程式碼路徑作重點檢查。

這類架構符合性在 AI 輔助實作中特別重要。AI 或其他執行者可以很快做出表面行為正確的功能，同時加入繞過既定責任或削弱控制點的捷徑。這種實作即使通過功能測試，仍然不符合架構規格。

返回頁頂

3.4. 靜態品質與程式碼結構驗證

管治指示和技術規格也可以訂明與驗收有關的程式碼品質或結構要求。這些要求必須有明確依據，不能等到最後審查時，才由審查者按個人喜好決定甚麼叫「寫得好」。

相關證據可以包括：

• lint 和 typecheck 結果；

• 靜態安全或正確性分析；

• dependency 和 import rule 檢查；

• 在指標確實有意義時，檢查重複程度或複雜度；

• 模組和服務責任歸屬審查；

• 命名和契約一致性；

• 確認領域行為仍然位於預期的服務層；

• 確認共用型別或 schema 被直接重用，而不是在本地重新定義；

• 確認沒有引入規格明確禁止的 hardcoded routing、fallback logic 或特殊案例；以及

• 審查本次交付會否把新的技術債務變成產品狀態的一部分。

例如，程式碼儲存庫的管治指示可能要求路由處理器只負責宣告和轉接，業務邏輯則由服務負責。一項功能上完全正常的變更，如果把行事曆業務規則直接寫進 HTTP 路由，即使所有端點測試都通過，仍然可能違反這項要求。

靜態檢查可以把部分結構要求變成可重複驗證的規則，但無法取代所有專業判斷。某項抽象設計是否容易理解、責任是否合理分開、設計會否造成無法以單一指標捕捉的維護負擔，仍然可能需要具經驗的人審查。

如果某項程式碼品質要求足以阻止驗收，它的來源便應能在管治指示、架構、技術規格或既定審查政策中找到。驗收由此依據共同工程標準，而非審查者臨時提出的新要求。

返回頁頂

3.5. 安全、可靠性與營運驗證

安全和可靠性要求經常關心正常流程以外的情況：系統被攻擊、依賴中斷、請求重試、操作只完成一部分，或者服務完全不可用時會發生甚麼。因此，驗收證據也要實際演練保護和失效行為，不能只證明正常流程成功。

對規劃器而言，相關證據可以包括：

• 由不同使用者或不同行事曆發起寫入嘗試，確認授權確實生效；

• 工具呼叫和 payload 驗證，包括 schema rejection 和不支援欄位；

• 驗證冪等和避免重複項目的重試情境；

• 部分執行後的取消和回退；

• 模型、工具和資料寫入路徑上的 timeout 行為；

• 受控的模型供應商或其他依賴失效情境；

• 確認失敗操作不會被錯誤回報為已成功完成；

• 能夠識別被阻止和已執行操作的審計紀錄；以及

• 日誌或追蹤紀錄顯示失敗、重試、復原或被阻止的操作仍然可以被營運人員發現和診斷。

安全規格也可能要求證明某項密鑰永遠不會傳送到客戶端、使用者身分會在真正寫入資料之前再次驗證，或者工具本身的權限比模型可以提出的操作集合更窄。這些主張通常要結合靜態檢查和實際執行情境才能證明。

營運證據和程式碼檢查回答不同問題。程式碼審查可以確認程式已經加入遙測呼叫；受控失敗演練則可以確認這些呼叫實際上有沒有產生足夠資料，讓營運人員診斷問題。如果可觀測性本身就是驗收條件，兩方面都需要檢查。

返回頁頂

3.6. 效能、容量與成本驗證

當適用規格已訂明效能或成本要求，它們就會成為驗收條件。可驗收的要求應有清楚的工作負載和量度方式，不能停留在「夠快」或「夠便宜」這類模糊描述。

規劃器的交付作業可能訂立：

在已定義的一般規劃請求工作負載下，首次向使用者顯示進度事件的 p95 時間必須低於已議定門檻。

或者：

在已定義的驗收資料集和模型配置下，每次完成規劃請求的平均供應商成本不得超過已議定門檻。

證據可以包括受控效能測試、token 和模型使用量紀錄、供應商成本計算、基礎設施量度、併發測試、百分位分析，或與已議定基準比較。

數字必須連同量度脈絡一起保存。只有一個 p95 數字，卻沒有環境、工作負載、資料形狀和併發假設，便很難知道它代表甚麼。供應商成本如果沒有模型、計價基礎、工具使用量、重試情況和驗收工作負載，也同樣容易被誤解。

成本上限應在上游訂立，不能在實作完成後突然成為新的驗收條件。如果上游從未訂立上限，審查者不能只因為量度結果看來偏高，就在最後一刻新增一個。相反，如果成本本來已經寫進規格，功能測試全綠也不能成為忽略成本的理由。

返回頁頂

3.7. 專業人員審查

有些重大條件仍然最適合由具資格的人作出專業判斷。架構是否一致、系統是否容易維護、遷移風險是否可接受、威脅影響是否處理妥當、無障礙和可用性是否達標，以及某項抽象設計是否合理，都未必能充分化約成一個自動化指標。

專業審查要成為有用的驗收證據，審查對象和結論必須說得清楚。一句「架構已審查」提供的證據很弱，因為日後沒有人知道究竟檢視過哪項決策。較完整的審查紀錄應指出適用條件、審查者或負責角色、重大觀察，以及最終結論或需要跟進的事項。

專業審查仍應針對明確的驗收問題。規格優先交付保留專業判斷，並清楚呈現它在驗收中的角色與權限。當程式碼由 AI 程式開發工具協助產生時，專業審查的重點放在驗證證據、符合性審查和驗收決定；逐行程式碼審查可以在適當情況下作為其中一種證據，與其他所需證據一起使用。

返回頁頂

3.8. 知識一致性驗證

獲驗收的產品狀態包括程式碼，也包括能準確描述產品的共享知識系統。知識系統必須足夠準確，讓下一位具資格參與者毋須重新翻查舊對話和提交紀錄，便能理解、營運和繼續修改產品。

一項以 GitHub 程式碼儲存庫為對象的大型研究，專門檢查 README 與 wiki 內已過時的程式碼元素引用。在其 GitHub top-1000 資料集中，28.9% 的程式碼儲存庫在分析時至少有一個過時引用；研究再追蹤其中 800 個儲存庫的完整歷史，發現 82.3% 曾經出現過這類引用。⁶

因此，驗證也要檢查這項交付作業有沒有令以下現況知識變得過時：

• 目前架構文件；

• 產品常設要求；

• 交付後仍然具有權威的功能規格或專項規格；

• 介面契約和資料語義文件；

• 管治指示；

• 營運和支援指引；

• README 內容和配置範例；

• 未來交付仍會重用的測試說明或驗收資料集；以及

• 對日後實作理解有重大影響的 inline comments。

聲稱描述目前產品，而且日後仍會被其他人依賴的來源，都需要保持同步。歷史交付紀錄則可以保留原貌，因為它們記錄的是當時的交付歷程。

例如，如果日程規劃器把寫入授權移到新的伺服器服務，而未來工程師會依賴現有架構文件理解系統，那份具權威的架構資料就應同步更新。新的重試保證可能要補到相關可靠性或介面文件。如果某項過往支援的行為現在刻意改為不再支援，產品常設要求或功能知識也不應繼續把舊行為描述成現況。

交付作業生命週期中的知識收斂說明實作所得知識和不同專業判斷如何取得清楚的適用範圍與權威。知識一致性驗證則在驗收前確認，需要保留的更新是否已經回到日後交付會依賴的持久來源。

程式碼和現況知識若互相矛盾，組織便會留下兩套不同版本的目前產品。即使軟件本身運作正常，這仍然是符合性問題。

返回頁頂

3.9. 與 Test-First Development 的關係

測試驅動開發（Test-Driven Development，TDD）和其他測試先行實務有一個重要原則：先寫清楚預期結果，再編寫滿足結果的實作。當已審查的驗收條件適合寫成可執行測試時，先寫測試可以同時約束人類和 AI 執行者。

兩項以大學生為參與者的實驗發現，在文字需求加入 Fit 驗收表格後，參與者對需求的理解有所提升，而且沒有顯著增加理解需求所需的工作量。⁷

即使驗收證據並非自動化測試，團隊也可以在實作前設計驗收方式。當模糊程度、風險、依賴或失敗後果值得這樣做時，應先想清楚日後憑甚麼證據判斷變更是否可以驗收。證據可以是自動化測試，也可以是 AI 評估、架構檢查、效能量度、成本計算或專業審查。

AI 能像產生程式碼一樣快速產生測試，令這項要求更加重要。如果把一項模糊需求交給同一個代理，它可以自行選擇一種解讀、為自己的解讀寫測試、再寫出能通過這些測試的程式碼，最後報告工作成功。整套結果可以前後一致，卻仍然建立在一項從未由真正有權決定的人確認過的假設之上。

因此，驗收基礎必須來自已審查的意圖和規格。執行者有能力產生一套彼此一致的實作和測試，並不足以建立驗收基礎。

返回頁頂

4. 已交付作業的符合性審查

驗證逐項檢查具體條件；符合性審查則把這些結果放回整項交付作業，判斷交付後的產品狀態整體上是否符合適用的規格體系。

因此，所有已執行測試都全綠，仍然不代表一定可以驗收。可能有一項架構要求從未被檢查、成本門檻沒有量度、產品常設安全要求沒有對應的實作責任，或者現況知識仍然描述舊產品狀態。

對一項重大交付作業而言，審查通常會涵蓋幾個範疇。

符合性審查按照所有適用要求檢視，而不只限於已執行的檢查。這樣才能看見證據缺失，也避免某一類證據十分完整時，掩蓋另一類完全沒有處理的缺口。如果架構符合性屬於驗收基礎，再完整的整合測試套件，也不能補償一項從未審查的架構偏離。

返回頁頂

5. 證據可追溯性與驗收涵蓋程度

如果團隊不知道一項證據究竟證明甚麼，證據再多也沒有太大意義。可追溯性把每項重大驗收條件連接至其來源、實作責任、驗證方法、證據和最終狀態。

一項嵌入式駕駛輔助系統研究，把 443 項已標註的自然語言需求連接至 1,300 次模擬執行和 53 次有人駕駛實車測試，藉此比較不同測試階段及測試案例與需求的對應程度。⁸

可追溯關係可以記錄在規格、測試紀錄、議題系統、自動產生的報告，或其他適合現有交付工具的地方。規格優先交付不限定一份固定格式的可追溯矩陣；重點是日後有資格的人仍能找回重大條件與實作、驗證、證據之間的關係。

以重試要求為例：

AI 產品範圍要求則需要多種證據來源：

這些連結合起來，就是驗收涵蓋程度：組織能夠為每項重大驗收條件找出相應的實作責任，以及足以判斷符合性的驗證方法和證據。程式碼覆蓋率（code coverage）衡量的是另一件事。它仍然有價值，卻只屬於驗收涵蓋程度的一部分。

當一項重大驗收條件由要求走到證據的路徑不完整，就會出現驗收涵蓋缺口。例如安全規格訂明：

使用者不得修改另一名使用者的行事曆。

這項規格還要有完整的實作和證據路徑。交付紀錄應讓人查到哪個元件負責執行限制、團隊如何驗證，以及最後有哪些證據證明限制真的有效。

縮小

100%

放大重設縮放和位置

如果其中一環缺失，驗收涵蓋程度就不完整。例如，安全要求已經存在，卻沒有任何元件被指定負責執行；又或者程式碼裡確實有授權檢查，但沒有任何測試或其他證據證明整條寫入路徑都受到這項控制保護。

因此，通過測試的數量本身並不代表驗收涵蓋程度。系統其他地方即使有數千個綠色測試，只要沒有任何證據直接回答使用者能否修改另一名使用者的行事曆，那些測試都不能證明這項安全要求已經滿足。

即使只看傳統軟件測試，程式碼覆蓋率也不能完整代表測試有效性。Inozemtseva 和 Holmes 分析五個大型 Java 系統的 31,000 個測試套件；控制測試套件大小後，覆蓋率與故障偵測有效性之間只有低至中度相關，因此作者認為不應把覆蓋率本身當成品質目標。⁹

一項交付作業即使有大量 lint、單元測試、程式碼覆蓋率、效能檢查和其他有用的工程控制，仍可能留下一項重大要求沒有任何證據。驗收涵蓋程度關心的是每項重大驗收條件有沒有實作路徑和合適證據，而非總共執行了多少項檢查。

返回頁頂

5.1. AI 行為的機率性證據

AI 評估需要另外處理，因為很多模型品質本身就是統計性的。驗收紀錄不但要說明有沒有證據，也要交代每種證據究竟能支持多強的主張。

對日程規劃器而言，範圍分類評估器可以顯示模型在一組具代表性資料上的表現，但不能保證未來每一個請求都分類正確。因此，只要架構和執行階段的控制機制可以更直接保護某項關鍵規則，就不能只靠一個機率性分數維持該項規則。

不同條件可以採用不同量度方式。未獲授權寫入可以要求在已定義情境中零違規，並配合確定性授權控制；分類品質可以用 precision、recall、false-negative rate 或其他已議定指標；建議品質可以用 evaluator rubric 配合人工抽樣；延遲可以用 p95 或 p99；成本可以看平均值、百分位或整個已定義工作負載的總成本；可靠性則可以把確定性故障情境和營運觀察結合起來。

證據本身也可能過時、薄弱或令人誤判。審查者需要知道證據是否來自準備驗收的實作和配置，測試或資料集是否真正代表所量度條件，重要的負面和例外案例是否包括在內，以及重大配置是否可以識別。門檻不能只因目前實作未能達標，就被隨意調低。

返回頁頂

6. 驗收責任與可信賴產品狀態

驗收代表組織正式接受一次交付所形成的產品狀態。實際流程上，驗收可以和合併審批、發佈審批或部署流程結合，但所作的仍是一項獨立決定：具相關責任歸屬的參與者，是否願意根據現有證據接受這個狀態？

不同範疇可以由不同角色承擔驗收責任，決策權取決於組織的運作模式和規格體系。產品負責人可以對產品行為負責；架構師對重大架構決策負責；安全專業人員對必要安全控制負責；工程對技術符合性負責；服務負責人或發佈負責人則可以對部署準備狀態負責。誰有權決定必須事先清楚，不能默默落到執行者或自動化管道身上。

AI 幾乎可以支援所有驗收準備工作。它可以執行測試和評估套件、檢查依賴、計算成本、比較實作與規格、整理證據，並找出驗收涵蓋缺口；也可以揭示需要重新檢討規格的矛盾。但這些能力不會令 AI 取得組織的驗收決策權。

返回頁頂

6.1. 證據失敗或不足

當某項驗證失敗或證據不足時，應先找出真正需要改的是哪一層，不能直接把標準調低。

驗證可能揭示早前無法得知的新資訊，因而合理地改變交付作業，但驗收標準不能在過程中悄悄改寫。執行者不能為了取得通過結果而降低門檻、把測試改成迎合目前行為、繞過架構控制，或者把原本必須處理的路徑重新列為範圍以外。

返回頁頂

6.2. 驗收結果

符合性審查通常會得出三類結果。

組織可以把驗收嵌入自己的審批工作流程。規格優先交付要求驗收依據、決策權限和未解決事項都必須可以查明。

返回頁頂

6.3. 證據深度應與風險相稱

需要多少驗收證據，應視乎變更的模糊程度、新穎程度、依賴、風險和失敗後果。目標是取得足以支持實際驗收決定的證據。

證據太少，重大條件可能完全未經檢查；流程過重，則會增加低風險變更的成本，卻沒有改善判斷品質。

返回頁頂

7. 可信賴交付作業的成果

一項可信賴交付作業，是整個交付循環中各項決定和證據匯合的結果。需求和持續適用的知識說清楚產品需要甚麼；專項規格加入相關專業要求；技術規格分配具體實作責任；測試規格定義如何驗證；實作產生產品變更和可供檢查的結果；符合性審查判斷整體是否符合規格；最後由具明確責任歸屬的人決定是否驗收。

實際需要哪一種證據組合，取決於這項交付作業適用的條件。它可以包括單元測試和整合測試、AI 評估器指標、架構檢查、程式碼品質審查、安全和可靠性檢查、營運觀察、效能與成本分析，以及知識一致性審查。

完成驗收後，組織應能說明重大條件從哪裡來、實作如何滿足它們、使用了哪些證據、誰有權接受結果，以及哪些現況知識描述目前產品。

這就是可信賴交付作業的實際價值。下一項交付作業可以按照需求、結構化討論與交付作業所述的需求與結構化討論模式展開，以組織已經審查、理解且願意承擔的產品狀態為起點。這個起點不再只是一個上次通過測試的程式碼庫。