要用 AI 建立數據驗證清單，先向模型提供經核實的 schema、業務規則登記冊、數據集用途、處理階段和失敗成本。請它為結構、類型、數值範圍、必填值、唯一性、引用完整性（referential integrity）、容許值、跨欄位邏輯、時效、完整性和對帳草擬明確的控制，然後以合成的通過和失敗例子測試每條規則。只有每項檢查都有負責人、嚴重程度、阻斷（blocking）政策、證據路徑和失敗分流路徑（failure route），清單才可運作。

安全輸入和審批邊界見一般的 AI 使用指南。如果來源數據已經出錯、任務是修正它，請改用雜亂試算表清理流程；驗證只界定和偵測失敗，不會悄悄修正。

關鍵要點

界定數據集、用途、階段、負責人、使用方和失敗成本。

使用權威的 schema 和業務規則；不要按欄位名稱推斷規則。

為每項控制編配穩定的 Check ID 和確定性的測試方法。

涵蓋行、表、關係、批次和匯總各個層級。

區分阻斷性失敗、警告和僅供參考的觀察。

以合成的正例、反例和邊界例子驗證清單本身。

把失敗交給負責的人處理；AI 不批准例外，亦不發放數據。

甚麼才是可執行的驗證？

含糊的清單會寫「檢查日期」「移除重複」或「確保總數看來沒問題」。可執行的清單則寫明確切的欄位或關係、容許的條件、如何測試該條件、哪些紀錄在範圍內、保存甚麼證據，以及測試失敗後怎樣處理。

驗證不等於真實。一個有效的日期仍可能描述錯誤的事件，一個對得上帳的總數仍可能包含分類錯誤的行。清單能偵測已界定的違規，並揭示未解決的語意問題；它無法保證每個數值都準確反映現實。

把驗證與清理、審批分開。偵測應產生證據；更正應依循獲授權、可追溯的程序；發放則應由人或受管治的系統按既定政策決定。

第 1 步：定義用途、階段與失敗成本

由一份數據契約開始。記錄數據集代表甚麼、誰產生和使用它、它支援哪項決定或流程、驗證在生命週期哪個環節執行，以及缺陷漏網時可能出甚麼問題。

英國政府數據質素框架把質素視為「切合用途」，並描述貫穿數據生命週期的質素管理。［1］匯入時重要的規則，可能不同於報告、模型訓練、遷移或發佈前所需的規則。

契約欄位	記錄內容
數據集 ID／版本	穩定名稱和 schema 修訂版
用途	所支援的決定、服務、報告、遷移或分析
階段	匯入、轉換、儲存、匯出或發佈
產生方／使用方	系統和負責的團隊
單位與粒度	一行代表甚麼
更新	預期頻率、截數點和延遲
敏感程度	分級和存取限制
失敗成本	對客戶、財務、法律、安全或營運的影響
負責人／批准人	對規則和發放政策負責的人

同一數據集服務多個用途時，分開記錄規則設定。某欄位在探索性分析中可以選填，在開發票時卻可能必填。

第 2 步：收集權威規則

不要讓 AI 按一個樣本檔案編造清單。收集 schema 定義、數據字典、來源系統契約、業務政策、參考表、轉換規格、使用方要求和已知事故紀錄，並記錄每個來源的負責人和版本。

定義欠缺或互相衝突時，為數據負責人開立一項待辦事項。使用 unknown rule，而不是按欄位名稱或觀察到的分佈去猜。現有數據只證明發生過甚麼，不證明甚麼獲准許。

如果仍未有可靠的數據字典，先使用數據字典流程。如果規則以 SQL 實作，SQL 核實流程有助審查語法和查詢風險，而執行仍保持唯讀和受控。

第 3 步：用 AI 建立數據驗證清單的統一控制記錄

為每項驗證編配穩定的 Check ID，並把定義保存為可審核的格式，例如有版本號的表格或設定檔。

控制欄位	必填內容
Check ID	穩定識別碼，例如 `VAL-023`
規則來源	有版本號的 schema、政策或負責人決定
範圍	數據集、表、行、欄位和排除項目
規則	確切的通過條件
測試方法	查詢、斷言、解析器或對帳程序
預期結果	布林值、計數、容差或已批准的集合
嚴重程度	嚴重、高、中、低或僅供參考
執行方式	阻斷、警告、隔離或觀察
負責人	對規則負責的人
證據路徑	輸入版本和結果的存放位置
失敗分流	隊列、團隊、回應時間和升級路徑
例外	已批准的範圍、理由、到期日和批准人
覆核觸發條件	schema、政策、事故或使用方的改變

把嚴重程度和執行方式分開。遷移期間，嚴重缺陷可能在已批准的例外下暫時只作觀察；而一個看似細微的格式違規，卻可能阻斷某個機器介面。由政策負責人決定；模型只草擬選項。

第 4 步：結構與類型

結構檢查確認預期的物件存在並可解析。核實檔案類型、編碼、分隔符、標題名稱、表和欄是否存在、合約訂明的欄位次序、紀錄形態和 schema 版本。多出的欄位帶來洩露或相容性風險時，予以拒絕。

類型檢查應測試實際的契約，而不只是軟件能否強制轉換某個值。要決定 "0012" 是識別碼還是數字、空字串是否有別於 null、小數精度如何處理、時間戳使用哪個時區，以及布林值是否只接受一種既定表示方式。

明確記錄類型轉換。靜默轉換可能刪去前置零，或以錯誤時區解讀時間戳。解析成功並不足夠；要把結果與預期的語意類型比較。

第 5 步：欄位檢查

欄位檢查通常包括：

必填： 在指定的紀錄類型中，該值必須存在。
範圍： 數值或日期落在已批准的閉區間或開區間內。
長度與格式： 識別碼、代碼或文字符合訂明的模式。
容許值： 該值存在於有版本號的參考集合中。
唯一性： 該值或複合鍵在指定範圍內只出現一次。
精度： 貨幣、量度值或百分比保持容許的小數點後位數。
條件必填： 只有在另一狀態成立時，該欄位才必填。

加入邊界例子。如果年齡範圍是 18 至 120，便測試 17、18、120、121、null、文字和小數。如果時間戳不得遲於批次截數點，便測試恰好等於截數點的情況和時區轉換。

不要讓 AI 按現有的最小值和最大值推導容許範圍。歷史數值可能有錯，亦可能未涵蓋合法的極端值。使用權威規則，或詢問負責人。

第 6 步：鍵與關係

唯一性和引用完整性跨越多行或多張表。界定候選鍵、主鍵、複合鍵、父子關係、基數和刪除行為。檢查重複的業務鍵、孤立的子紀錄、意外的多對多連接，以及子紀錄狀態不可能成立的父紀錄。

PostgreSQL 文件區分了檢查、非空、唯一、主鍵和外鍵約束，並解釋外鍵用來維持相關表之間的引用完整性。［3］資料庫約束很有價值，但清單可能還需要載入前檢查、跨系統關係、時間規則，或無法安全地編成簡單約束的條件。

就每種關係寫明快照和鍵的標準化方式。分別報告匹配、未匹配、多重匹配和被排除的數目。

如果主要任務是比較兩個數據集並處理未匹配的紀錄，請使用專門的試算表對帳流程。驗證清單可以引用其結果，而不必吞併整個對帳程序。

第 7 步：跨欄位及時間規則

跨欄位規則反映業務含意。例如 end_date >= start_date、退款金額不超過已收款金額、國家與郵遞區號格式相符，或已結束的紀錄必須填寫結束原因。把每條規則寫成明確的謂詞，並訂明 null 的處理方式。

時間檢查應區分事件時間、匯入時間、更新時間和批次截數點。測試到達太遲的事件、未來的時間戳、不可能的先後次序、重疊的生效期、必需區間中的空檔，以及過時的參考數據。

避免編入偏見或未經批准的代理變數的規則。在舊數據中觀察到的相關性並不是業務約束。如果某條擬議規則會影響資格、存取、定價、僱傭或其他有後果的結果，便要按情況進行相應的專業、法律、私隱和公平性審查。

第 8 步：完整性與及時性

完整性不只是欄位非空。要界定預期紀錄數目、預期分區、必需的實體、涵蓋時段和強制關係。如有權威的控制總數，便把接收到的紀錄與之比較。

時效檢查應界定預期到達時間、容許的延遲、時區、假期、重試時段，以及怎樣才算完整批次。把「遲到」與「缺失」分開：一個批次可能準時到達，卻只包含預期總體的一部分。

W3C 的數據質素詞彙（Data Quality Vocabulary）提供了一種方式，用來表達數據集的質素量度、指標、註解和相關出處資料。［2］不必採用這套詞彙亦可運用其原則：保存量度了甚麼、用哪個指標、針對哪個數據集版本、何時量度，以及由誰或哪個程序完成。

第 9 步：匯總與不變條件

加入跨層級的檢查：行值應能匯總為分組總數；分組總數應與批次控制數一致；在該範疇界定了這個不變條件時，期初結餘加變動應等於期末結餘。寫明四捨五入、貨幣換算、容差和被排除的狀態。

對帳規則絕不能寫成「總數差不多」。要界定絕對和相對容差、訂定的理由，以及該規則是阻斷還是警告。同時報告差額及其組成，方便審核人調查。

盡量使用獨立的控制總數。同一有缺陷轉換的兩份輸出可能彼此吻合，所以要記錄它們共用的依賴。

第 10 步：失敗處理

每項失敗的控制都需要失敗分流路徑。決定是阻斷批次、隔離受影響的紀錄、向使用方發出警告、在已批准的例外下繼續，還是停止下游流程。寫明負責人、回應時間、所需證據和升級路徑。

失敗欄位	必填內容
執行 ID／Check ID	確切的驗證執行和規則
數據集版本	輸入快照和流程修訂版
失敗數目	受影響的行數和百分比
樣本證據	最少量、受存取控制的例子
嚴重程度／執行方式	對這次失敗適用的政策
負責人	負責分流處理的人或團隊
控制措施	阻斷、隔離、警告或分隔
解決方式	修正、來源更正、接受例外或修改規則
批准	具名的獲授權審核人和時間戳
重新執行證據	更正或例外之後的結果

例外必須範圍狹窄、有時限而且可覆核。記錄誰批准、為何批准、涵蓋哪些紀錄，以及何時到期。絕不讓模型豁免失敗的控制。

第 11 步：合成測試

為每條規則最少建立一個通過例子、一個失敗例子和相關的邊界例子。合成紀錄不應包含任何真實個人數據或正式環境數據。給它們穩定的 ID 和預期結果。

例子包括：重複的複合鍵、孤立的子紀錄、結束日期早於開始日期、只對某一紀錄類型必填的 null、恰好等於最大值的數值、遲到但獲准許的事件，以及超出容差的批次。確認每個例子只令預定的那項檢查失敗；否則該測試數據可能未能隔離規則。

模型可以按規則表建議例子，但審核人必須核實涵蓋範圍和預期結果。NIST 的生成式 AI 設定檔指出了虛構內容和其他需要受管理核實的風險。［4］看似合理的生成測試，不能證明控制正確。

第 12 步：試行與版本化

在非正式環境中，以合成測試數據和一份已批准的歷史快照執行清單。把結果與已知事故和人手審核比較。意外的通過與意外的失敗同樣要認真調查。

為數據集契約、規則來源、清單、實作、測試數據和執行政策做版本管理。在 schema、政策、來源、使用方、轉換或風險改變後重新審查。

不要只因 AI 產生的草稿看來完整，便在正式環境啟用阻斷。數據負責人批准語意，工程師審查實作和運作行為，安全和私隱負責人審查敏感數據的處理，發放權限方決定執行方式。

簡明提示詞契約

告訴模型：只使用所提供的 schema、規則來源和數據集用途；每項檢查輸出一行，包含 Check ID、確切謂詞（predicate）、範圍（scope）、null 處理方式、測試方法、預期結果、嚴重程度（severity）選項、執行方式（enforcement）選項、負責人（owner）、證據（evidence）、失敗分流路徑（failure route）和合成例子；衝突或欠缺的規則標為 owner decision required；不得根據樣本分佈推斷約束，亦不得批准例外、修正或發放。

最終檢查清單

已記錄數據集用途、粒度、生命週期階段、使用方、敏感程度和失敗成本。
每條規則都指向權威來源和負責人。
涵蓋結構、類型、欄位、唯一性、引用完整性、跨欄位、時間、完整性、時效和匯總檢查。
每項檢查都有確定性的邏輯、null 處理方式、預期結果和證據路徑。
嚴重程度與阻斷、警告、隔離或觀察政策互相獨立。
合成的通過、失敗和邊界例子都產生預期結果。
已界定失敗分流、負責人、升級、例外、到期日和重新執行證據。
正式環境的執行已經機構一般的發佈程序批准。
版本和覆核觸發條件把 schema、規則、實作和測試數據連繫起來。

常見問題

驗證和清理有甚麼分別？

驗證偵測既定條件是否成立並記錄證據；清理會改變數據。讓更正過程獲得授權、可重現，並與偵測結果分開。

AI 可以從樣本推論規則嗎？

它可以提出問題，但觀察到的模式並非權威規則。每項約束都要經 schema、政策、使用方要求或數據負責人確認。

哪些檢查應該阻斷流程？

由已批准的執行政策按用途和失敗成本決定。把嚴重程度與阻斷行為分開，並記錄例外。

資料庫約束足夠嗎？

不足夠。資料庫約束是支援範圍內不變條件的強控制，但生命週期、跨系統、時效、匯總和載入前的檢查，可能仍需額外驗證。

如何驗證 null？

就每個欄位和紀錄類型，界定 null、空值、零、未知和不適用是否彼此不同，並測試每種容許和禁止的情況。

甚麼是好的引用完整性檢查？

使用來自同一既定快照、經標準化的確切父鍵和子鍵，然後分別報告匹配、孤立、多重匹配和被排除的紀錄。

可以用生產行做 fixture 嗎？

優先使用合成的測試數據（fixture）。如果試行確實需要一份已批准的歷史快照，便把它最小化、保護存取權限，並遵守保留和刪除規則。

多久審核一次清單？

在 schema、政策、來源、轉換、使用方、事故紀錄或失敗成本改變時覆核，並按既定週期定期覆核。

誰批准例外？

由具名的政策或數據負責人，在所需的專業、私隱、安全、法律或發佈審查支援下批准。例外應有範圍、有理由，並設有到期日。

來源

UK Government — The Government Data Quality Framework — https://www.gov.uk/government/publications/the-government-data-quality-framework/the-government-data-quality-framework
W3C — Data on the Web Best Practices: Data Quality Vocabulary — https://www.w3.org/TR/vocab-dqv/
PostgreSQL — Constraints — https://www.postgresql.org/docs/current/ddl-constraints.html
NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 2026 年 9 月 4 日。

用 AI 建立數據驗證清單：Check ID、阻斷規則與失敗分流