要用 AI 草擬數據字典，先盤點實際存在的欄位，收集關於其含義及限制的證據，再只把這些已核實的輸入交給模型。讓 AI 統一措辭並指出缺口，然後在發佈任何版本之前，由數據負責人驗證每一項定義、類型、單位、允許值、缺失值規則、敏感度標籤及數據血緣說明。

這是一套文件流程，不是根據欄位名稱反推真相的方法。較通用的負責任使用 AI 指南解釋了為何來源證據及人工覆核必須始終主導。

關鍵要點

記錄欄位之前，先凍結數據資產、系統、環境及版本。

根據結構定義、匯出檔案、程式碼及負責人訪談建立欄位清單，而不是依賴模型記憶。

把物理類型與業務含義、格式、單位及允許值分開。

為缺失值賦予明確含義，不要把每個空白都當作同一種狀態。

用 AI 統一及質疑草稿，絕不讓它編造定義或數據血緣。

發佈版本之前，以合成例子及負責人進行驗證。

一份可用的數據字典應包含甚麼？

數據字典是一份受管治的數據元素目錄，包含解讀這些元素所需的規則。它把 order_status_cd 這類技術欄位，與精確的業務含義、有效的表示方式、問責負責人及變更歷史連繫起來。結構定義可能只說明某欄是可為空的字串；數據字典則解釋字串代表甚麼、容許哪些值、為何可能為空及誰可批准變更。

NIH 的元數據指引把元數據視為令數據可理解、可重用的資訊，NIDDK 的指引則強調要準備好定義及編碼值，讓另一個人也能解讀數據集。［1］［2］NIMH 數據庫提供了一個具體模型：其元素列表區分名稱、數據類型、大小、是否必填、條件、說明、取值範圍、備註及別名。［3］

使用穩定的行結構，而不是只有文字說明的詞彙表：

欄位	應記錄的內容
字典 ID 及版本	穩定身份及發佈編號
資產及欄位	系統、數據集、表或檔案，以及準確的物理名稱
業務定義	單一含義，不用循環措辭
物理及邏輯類型	儲存類型，加上日期、貨幣或代碼等概念類型
格式及單位	格式模式、時區、貨幣、比例或計量單位
允許值	枚舉、範圍、代碼集版本及大小寫規則
缺失值含義	空白代表未知、未收集、不適用還是無效
來源及數據血緣	權威來源及獲批的轉換
責任歸屬	數據負責人、數據管理員及技術保管人
敏感度及用途	分類、存取限制及獲批用途
品質規則	可測試的有效性、完整性、唯一性或核對規則
狀態及覆核	草稿、已批准或已停用，覆核人、日期及變更說明

這張表刻意比「欄位說明清單」更詳細，因為團隊常在邊界處失去含義：沒有時區的時間戳記、沒有分母的百分比、沒有代碼集版本的代碼。

步驟 1：凍結資產及文件範圍

寫明要記錄的確切對象：來源系統、環境、數據集或介面、表或檔案、提取日期、結構定義版本及字典負責人。確定字典描述的是來源欄位、轉換後的模型、介面載荷，還是跨系統的標準概念。不要在未展示對應的情況下把這些層級混在同一行。

排除項也要寫明。例如，客戶訂單字典可能排除衍生的財務指標及事件遙測數據。這能防止 AI 以看似合理卻無關的欄位填滿草稿。

建立一個簡單的範圍表頭：

範圍欄位	合成例子
字典 ID	`DD-ORDERS-07`
資產	`analytics.orders_curated`
來源版本	`schema-2026-09-01`
環境	已批准的生產定義，不含數據行
納入對象	只含訂單表頭欄位
排除對象	付款代碼及事件記錄
數據負責人	商務營運角色
覆核觸發條件	結構定義、政策或代碼集變更

資產在此期間仍在變化時，記錄截止點並另開變更項。暗中混用兩個結構定義版本的字典無法可靠覆核。

步驟 2：從權威證據盤點真實欄位

從獲批來源收集欄位名稱及結構事實：資料庫目錄匯出、介面規格、檔案表頭、轉換程式碼、驗證規則、代碼集儲存庫、現有管治紀錄，以及與數據負責人的訪談。為每個來源保存參照，而不是貼上敏感的數據行。

如果你由一份試算表開始，先清理試算表而不丟失證據。清理重複表頭或不一致的格式，與界定欄位含義是兩回事。

就每個欄位區分四類證據：

**觀察到的結構：**準確名稱、儲存類型、可否為空、長度或位置。
**強制執行的規則：**資料庫約束、驗證程式碼或獲批代碼集。
**負責人陳述：**經覆核的業務含義、用途及問責歸屬。
**工作假設：**尚未解決、必須標為 VERIFY 的解讀。

切勿只為協助模型辨認模式便提供生產紀錄。使用只含結構的匯出及合成例子。如果確實需要逼真的例子，便刪除或泛化識別資料，並確認所得的樣本已獲准用於所選工具。

步驟 3：為每個欄位寫一份可測試的契約

好的定義會說明概念、範圍，以及決定該值的事件或規則。「客戶類型」是循環定義；「開戶時由已批准的開戶規則指派的分類」更有用，前提是引用了該開戶規則並由負責人確認。

可使用以下行範本：

屬性	合成值
欄位	`delivery_window_start`
業務定義	客戶已確認送貨時段的開始時間
物理類型	時間戳記
格式及時區	ISO 8601，以 UTC 儲存
可為空	是
缺失值含義	尚未選擇送貨時段
來源	排程服務事件 `window_confirmed`
數據血緣	不作時間運算，直接複製到整理後的訂單表
負責人/數據管理員	履行 / 數據管治角色
敏感度	內部營運數據
品質規則	兩者都存在時必須早於 `delivery_window_end`
狀態	草稿——須負責人覆核

不要根據欄位名稱推斷定義。名稱可能是歷史遺留、縮寫、被重複使用或具誤導性。欄位 active 可能描述帳戶、訂閱、流程或裝置的最後已知狀態；只有證據才能確定其含義。

步驟 4：用 AI 草擬數據字典，把它限定為有邊界的整理任務

提供範圍表頭、獲批的欄位證據、輸出欄位及明確的禁止編造規則。要求逐行轉換並附上問題，而不是一份掩蓋不確定性的精美文件。

把所提供的欄位證據整理到指定的數據字典欄位。
只使用所提供的來源，並保留每個來源 ID。
不得根據欄位名稱推斷定義、類型、單位、允許值、負責人、敏感度、
數據血緣、預設或缺失值含義。
缺乏支持的儲存格寫 [VERIFY]，並說明欠缺甚麼證據。
互相衝突的陳述分開保留。回傳一份驗證問題清單。
不得包含或索取生產數據行或個人資料。

要求模型原樣保留識別碼。只有在已提供縮寫全寫時，它才可以在說明文字中展開縮寫。這種有邊界的用法比叫模型「為這個資料庫建立一份字典」更安全，後者容易引出虛構欄位及空泛的含義。NIST 把虛構內容、私隱、資訊完整性及人機協作配置列為生成式 AI 的重要風險。［4］

步驟 5：處理單位、代碼集及缺失值

覆核那些技術上有效、語義上卻仍可能出錯的地方。

單位及格式

記錄貨幣、比例、時區、地區設定、精度，以及區間是否包含邊界。0.15 可能代表比率、15%、稅率或某個量度值。沒有曆法說明的日期、沒有時區規則的時間戳記，都可能令分析結果不一致。

枚舉及範圍

準確列出允許值，包括大小寫、保留值、生效版本及已棄用代碼。如果清單由其他地方維護，便連結權威的代碼集 ID，而不是複製一份沒有版本的快照。

缺失值含義

區分未知、未收集、不適用、尚未可用、已刪節及無效。如果來源把它們全部摺疊成空值，便如實寫明。不要讓 AI 製造來源本身並未保留的區分。

預設

區分資料庫預設、業務預設及顯示後備值。介面在值缺失時顯示「標準」，並不能證明儲存欄位的預設就是它。

步驟 6：映射負責人、敏感度及數據血緣

指派一名可批准含義及允許用途的數據負責人、一名維護文件的數據管理員，以及一名可核實實作情況的技術保管人。一個角色可兼任多職，但職責必須明確。

敏感度標籤必須來自機構的分類政策。不要讓模型根據欄位名稱決定它屬公開還是機密。一個看似無害的識別碼，與另一個數據集連結後可能變得敏感。

數據血緣應在覆核所需的層級寫明權威來源、轉換及目的地。避免「來自數據倉庫」這類含糊說法。如果數據血緣由程式碼產生，要與已部署的轉換及負責人的認知核對。證據衝突時，列出兩條路徑並提交決定，而不是挑選較順暢的說法。

在探索性工作中，用 AI 分析試算表可協助找出格式不一致，但它不能確立語義上的負責人或真源層面的數據血緣。

步驟 7：由負責人和合成例子驗證草稿

進行三輪覆核：

**結構覆核：**每個真實欄位恰好出現一次，識別碼一致，已停用欄位有標記。
**語義覆核：**數據負責人確認定義、業務規則、允許用途及缺失值含義。
**技術覆核：**技術保管人把類型、約束、格式、代碼集及數據血緣與已實作的資產比對。

然後以合成例子測試字典。覆核人應可單憑書面規則，判斷每個例子值屬有效、無效、缺失還是超出範圍。例子要包括邊界情況，例如閏日、零、空字串、已停用代碼、最大長度，以及附有已聲明含義的空值。

檢查失敗時，修正定義或上報底層數據規則，不要反覆改寫例子直至它剛好符合含糊的文件。如果某項說法仍欠缺證據，便為 AI 輔助草稿作事實查核，並保留 VERIFY，直至負責人提供來源。

步驟 8：版本化、發佈及維護

發佈一個已批准的唯讀版本，附上範圍、證據參照、覆核人、批准日期及變更紀錄。給用戶一個穩定的識別碼，讓報告、轉換及品質檢查可以聲明自己採用的是哪一版定義。

訂明覆核觸發條件，而不是只依賴日曆：

結構定義遷移、介面版本或檔案版面改變；
代碼集新增或停用代碼；
業務政策、計算方法或保留規則改變；
數據血緣中出現新的來源或轉換；
發生品質事件或用戶反覆提出同一問題；
分類、存取規則或問責負責人改變。

封存舊版本，而不是覆寫歷史。傳達某個欄位的變更時，說明改變的是物理表示、業務含義，還是兩者皆有。這項區分有助下游評估影響，也避免文件修改被誤當作數據遷移。

哪些檢查最容易找出常見問題？

使用發佈檢查清單：

如果字典要為圖表或報告提供數據，請在定義穩定後才把數據視覺化。精美的圖表無法修補含糊的分母或代碼。

總結

由凍結的資產及經核實的欄位清單開始。
把儲存事實與業務含義及管治決定分開。
用 AI 作整理、一致性檢查及提問，而不是推斷。
記錄單位、代碼集、空值語義、負責人、敏感度及數據血緣。
與負責人一起以合成邊界例子驗證。
發佈有版本的成果，並在其輸入改變時觸發覆核。

常見問題

數據字典和資料庫結構定義是同一回事嗎？

不是。結構定義描述已實作的結構，例如表、欄位名稱、類型、約束及關係。數據字典還加入人能理解的含義、單位、允許值、缺失值語義、負責人、敏感度、數據血緣、品質規則及變更背景。

數據字典最少應包含哪些欄位？

最少記錄資產、準確欄位名稱、定義、類型、格式或單位、允許值、空值規則、權威來源、負責人、狀態及版本。當用戶需要它們來解讀或控制用途時，再補充敏感度、數據血緣、品質規則、別名及例子。

草擬數據字典時，AI 可以安全地做甚麼？

AI 可以統一已提供的措辭，把證據對應到固定範本，找出不一致的術語，提出驗證問題，並比較各行是否欠缺屬性。它不能確立機構特有的含義，也不能證明文件與已實作的系統一致。

可以上載樣本數據來改進草稿嗎？

優先使用只含結構的元數據及合成例子。即使刪除了明顯的識別資料，真實數據行仍可能包含個人、機密、受規管或類似憑證的資料。只有在獲批環境中、目的有紀錄且設有存取控制時才使用真實數據。

沒有人知道某個欄位的定義時怎麼辦？

把定義標為未解決，記錄互相競爭的解釋及證據，並指派數據負責人作出決定。不要挑選看似最合理的措辭，也不要讓下游的反覆使用把假設變成已批准的定義。

枚舉及缺失值應如何記錄？

記錄準確的允許值、大小寫規則、代碼集版本、保留代碼及已停用代碼，以及空值、空白及哨兵值的含義。如果來源無法區分不同的缺失狀態，便記錄這項限制，而不是編造分類。

合成例子如何驗證數據字典？

它們檢驗書面契約是否足夠具體，能在不披露真實紀錄的情況下判定邊界值。例子應包括有效、無效、缺失、最大長度、已棄用代碼、日期及跨欄位一致性等情況，再請技術及業務覆核人解釋結果。

數據字典應多久更新一次？

同時採用定期覆核及事件觸發。當結構定義、代碼集、政策、轉換、分類、負責人或品質表現改變時進行覆核；封存上一版本，並讓用戶看到生效日期。

來源

NIDDK Central Repository, Preparing Data Dictionaries — https://repository.niddk.nih.gov/static/webinar_media/pdf/NIDDKCR_Office%20Hours_Data%20Dictionaries_20240112.pdf
NIH, Workbook of Metadata Fundamentals — https://datascience.nih.gov/sites/g/files/mnhszr336/files/2025-06/workbook_of_metadata_fundamentals_v1.1_10-25-2024_508.pdf
NIMH Data Archive, Data Dictionary — https://nda.nih.gov/ndar_data_dictionary.html?short_name=ldps01
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 草擬數據字典：由欄位證據到負責人驗證及版本發佈