產品術語與資料語義

每個軟件產品都依賴詞語與資料，而它們的含義通常比名稱本身更具體。例如一個名為 country 的欄位，可能是法定受僱國家、居住地、國籍，或某項計算採用的司法管轄區。組織術語可以有一個全企業共用的定義，產品卻可能採用較窄的解讀；同一個系統也可能公開一百個員工欄位，卻只對其中部分業務事實擁有決策權。

產品術語界定團隊理解產品時採用的概念、慣例和來源角色；資料語義則說明內部或外部來源提供的結構化資料代表甚麼。資料值有時會建立、限定或導向某個產品術語概念，兩類知識因而互有關聯，但承擔的責任不同。將兩者分開，合資格的人員和 AI 程式設計代理才能在規格、實作、驗證、審查與營運工作中有可靠依據。

規格優先交付把產品術語與資料語義視為共享知識系統中的持久產品脈絡。所需成果是現行且可透過日常存取路徑找到的含義，讓參與者在依賴術語或資料相依性之前先正確理解。

縮小

100%

放大重設縮放和位置

返回頁頂

1. 產品術語及其所有權

產品術語是參與者用來一致理解產品概念的現行詞彙，涵蓋使用者、業務事實、狀態、責任、工作流程、類別及其他會影響交付的概念。術語表是實用的表示方式：合資格參與者應能在需求、規格、資料解讀、實作和審查中使用同一術語，毋須從私人記憶重新推斷其含義。

若獨立系統必須在共享領域中交換資訊並據此推理，正式本體論能將詞彙、關係與限制明確表示。Gruber 把本體定義為共享論述領域的表述詞彙規格，使已表述的知識得以在 AI 系統之間共享。² 產品術語通常採用較輕量的表示方式，但只要一般語言容許多種會實質改變交付的解讀，產品仍應明確說明概念、含義、關係與限制。

規格優先交付區分組織脈絡與產品脈絡。組織可以在術語表、知識圖譜、資料目錄、內部入口網站或其他受管來源維護企業定義；產品可以採納符合其取用情境的定義，也可以記錄自身所需的解讀，並保留通往組織來源的路徑。

產品術語具有明確的所有權和維護生命週期。每一項術語表條目都要標示一個或多個負責職能，由這些職能建立現行含義、審查實質變更，並處理既有紀錄無法解答的交付問題。常見的所有權模式包括：

• **由產品負責的術語：**產品負責人或相當的產品決策權擁有界定產品目的、使用者可見結果、產品慣例，以及外部系統在本產品中角色的術語。

• **由領域負責的術語：**領域負責人擁有依賴領域判斷的業務概念、分類、政策與區分。

• **共同交付術語：**若某個術語同時影響產品、領域、資料、架構、工程、品質或營運決策，各負責職能應校準含義，並形成與共同責任相稱的共識。

• **依使用者校準的術語：**當產品必須按照使用者理解來使用某個術語時，產品負責人應先與代表性使用者和工程團隊校準含義，再將其納入現行產品術語。

所有權標籤會隨術語表條目保留，讓人員或 AI 參與者能把變更提案導向正確職能。發現歧義的參與者可以蒐集證據並草擬提案，最終由已列出的負責職能決定何種含義成為現行產品知識。產品術語增多後，團隊可按所有權或領域拆分成聚焦的 Markdown 檔案或文件；術語表仍是發現入口，而各聚焦紀錄負責保存其範圍內的現行含義和所有權。

以薪資使用者介面為例，產品可以把一個名為 HR Go 的系統定義為薪資資料來源，把 LDAP 定義為員工資料來源。即使這個產品也能從 HR Go 員工資料，對這個產品而言也不是員工資料的取用來源。這些產品專屬的來源角色屬於產品術語，並與本文稍後說明的指定取用來源決策相關。

返回頁頂

2. 內部與外部資料語義

資料語義說明結構化資料的含義，而不只依賴原始碼、資料庫綱要、型別宣告或欄位名稱。它要指出某個結構、欄位、值或關係所代表的現實事實、狀態或條件，以及重要的表示方式、生命週期、有效性或相容性條件。原始碼、綱要、限制條件和測試可以表達並執行部分知識；可維護的語義來源則讓人員或 AI 參與者毋須從實作證據逆向推論，即可找到並套用其含義。

內部與外部資料語義的來源決策權不同：

內部或外部來源提供的含義描述的是來源本身的模型；產品術語則記錄這些資料所支持的產品概念、慣例或來源角色。Kashyap 和 Sheth 將資料庫物件之間的語義接近性置於比較情境下建模，說明情境是理解語義相似性與綱要對應的要素。³ Context Interchange 也把來源端和接收端情境納入異質系統的語義解讀。⁴

以薪資使用者介面為例，LDAP 會回傳員工的群組成員資格結構和 company 值。資料語義可確立：加入 Payroll-Externally-Managed 群組，表示該員工的薪資由外部供應商管理。在此條件下，company 是受控的薪資供應商識別值，並非泛指雇主公司的名稱。薪資使用者介面會依此識別值選取核准的供應商薪資目的地，並提供通往該系統的連結；供應商系統則透過其 B2B Entra 連線驗證使用者。

這個例子中的 externally managed payroll employee 和 payroll vendor 是產品術語概念；LDAP 群組和 company 欄位則是結構化資料，其語義分別說明前者何時成立，以及產品應使用哪一個供應商。

這也說明取用情境為何是正確解讀的一部分。群組與欄位值之所以對此產品重要，是因為它們決定薪資流程應走哪一條路徑，而不只是因為 LDAP 提供了這些值。Wang 和 Strong 將脈絡資料品質界定為資料是否適合其使用者正在執行的工作。⁵ 產品術語記錄的是這個薪資脈絡，資料語義則說明在該脈絡中使用的結構化值代表甚麼。

B2B Entra 連線、供應商目的地和連結行為屬於架構、介面與安全性議題。本文只記錄它們與含義的關係，不定義其技術設定。

外部來源仍對自身的結構和值負有決策權。產品透過供應商文件、API 契約、綱要中繼資料、資料目錄、MCP 介面或其他支援的路徑取得其語義；當結構化資料會建立產品概念、來源角色或某項決策時，產品再把資料語義紀錄連結至產品術語。

舊有外部平台可能需要不同的處理方式。若在交付工作中無法取得、取得不完整，或難以實際檢索其權威語義，產品可以在受管的外部資料紀錄中內化這些語義。該紀錄保留可取得的來源脈絡、標示負責職能，並說明為何必須內化。舊平台的變更可能緩慢，但整合方式改變、供應商契約修訂或產品出現新的用途時，仍須重新評估本地解讀。

返回頁頂

3. 資料的結構與語義表示

有用的資料契約會把結構和解讀該結構所需的業務含義一併說明。型別、格式、列舉值、描述、範例、單位、生命週期含義和其他限制條件都能提供這些資訊；所需深度則取決於資料的歧義程度和誤解後果。

對 HTTP API 而言，OpenAPI 是這項原則成熟的實例。它定義與程式語言無關的介面描述，讓人員和軟件能發現並理解服務能力，也支援結構化模型、說明欄位與範例並存。¹ 規格優先交付採用這項原則來處理實質影響產品的外部資訊，但不要求使用 OpenAPI 或任何特定文件技術。

例如，LDAP 回應可能包含：

memberOf: Payroll-Externally-Managed
company: Alder Payroll Services

這些值本身尚未決定產品應如何使用它們。資料語義會確立該群組成員資格代表外部管理的薪資，並說明在此條件下 company 用來識別薪資供應商；產品術語則界定相應的產品概念，包括薪資供應商和外部管理的員工。時間戳記也是同樣道理，必須說明它代表事件時間、生效時間、處理時間、紀錄更新時間，還是另一個會影響產品行為的生命週期時點。

Wand 和 Wang 將資料品質問題視為資訊系統表示現實世界系統時可能出現的失真，包括歧義與欠缺意義。⁶ 因此，欄位即使在結構上有效，只要參與者無法判斷它代表哪項事實、狀態、單位或生命週期時點，仍不足以支持負責任的交付。

返回頁頂

3.1. 外部系統的語義介面

所有會實質影響交付的外部資訊，都需要可理解的語義介面。實作機制可配合系統和組織情況：

• API 可以公開 OpenAPI、等效的機器可讀文件，或另一份持續維護的契約。

• 資料庫可以公開綱要中繼資料、欄位描述、資料目錄、受管文件，或產品層面的語義紀錄。

• 事件串流或檔案介面可以連同綱要和相容性規則，維護事件和欄位語義。

• MCP 伺服器可以提供 AI 用戶端在工作期間可檢索的工具、參數和結果描述。

• 知識圖譜可以公開組織概念，同時由產品記錄適用於其取用情境的解讀。

AI 工具使用研究也顯示，來源資訊必須可取得。Gorilla 指出，檢索 API 文件有助於因應文件變更，並降低虛構 API 用法；ToolLLM 則利用檢索在 16,464 個真實 REST API 中選取工具。⁷⁸ 找到並正確呼叫介面只是交付的一部分，參與者仍須套用現行產品含義，並把未解決的語義問題導向能作出決定的負責職能。

語義介面必須能透過參與者實際使用的存取路徑取得。規格優先交付的知識系統就緒度一文要求知識必須同時可取得，並且對所執行的責任具有權威性。人員可進入供應商入口網站，不表示 AI 程式設計代理也能取得同一來源；AI 能檢索資料，也不表示它知道哪一項產品解讀主導當前決策。

返回頁頂

4. 資料決策權、指定取用來源與來源脈絡

語義紀錄的所有權、業務決策權和指定取用來源彼此相關，卻各有責任。語義紀錄的負責職能維護紀錄，並在其職能範圍內作出決定；業務決策權決定某個情境下的底層事實或判斷；指定取用來源則指明本產品應從哪個介面取得該事實。來源脈絡記錄為了負責任解讀取用值而需要知道的來源或重要轉換路徑。

假設某項服務公開一百個員工欄位，其中二十個由服務所屬領域直接維護，另外八十個則經由 ETL 從其他系統取得。這項服務仍可成為本產品取用全部一百個欄位的指定介面，同時多數事實的業務決策權仍在其他地方。因此，指定性是對特定事實及特定取用情境所作的判定。

資料整合實務長期把異質來源資料、綱要轉換與資料清理視為相關責任。Rahm 和 Do 指出，整合異質資料來源時尤其需要資料清理，且應與綱要相關的資料轉換一併處理。⁹ 資料語義紀錄能讓工程師或 AI 參與者在轉換時有共同依據，例如採用指定表示方式，或區分業務含義不同的供應商值。

返回頁頂

5. 建立與維護現行含義

產品術語與資料語義應從目前交付所依賴的術語和資訊開始建立。可用的基準聚焦於當前決策，並在後續工作發現新的歧義或語義責任時逐步擴充。

初次建立時，應優先處理任何合理替代解讀都可能改變行為的概念。常見對象包括一詞多義的業務術語、具有生命週期意義的狀態、唯一性範圍不同的識別碼、隱含單位的量測、國家或司法管轄區代碼、時間戳記、外部提供的類別、計算值，以及因廣泛公開而看似權威的欄位。

既有語義若充分且可取得，應優先重用。組織術語表若已依產品採用的方式定義某個術語，產品可以採納該定義並保留通往來源的路徑；API 契約若已充分說明某個資料結構，產品也可直接引用。當產品需要說明欄位或值、它與產品術語的關係、某種表示方式，或指定取用決策時，才建立聚焦的資料語義紀錄。

任何參與者一旦發現可能改變預期行為的歧義，就形成一項就緒度缺口。在依賴未經支持的答案繼續工作前，必須把問題交由已列出的產品、領域、資料或專業負責職能處理。後續增量在引入或揭露新概念時，會擴充這個語義基準。

語義紀錄屬於現行知識。未來參與者需要不同的含義、來源關係、所有權安排或使用條件時，就必須修訂。受影響的負責職能應審查對規格、介面、實作、測試、分析、營運程序和下游取用者的影響。修訂完成時，現行紀錄及所有必須表達核准含義的產品表面都應同步更新；重要理由則可保留於決策歷史。

返回頁頂

6. 選用的語義紀錄工作模式

規格優先交付不要求特定檔案配置、YAML 標頭、Skill 或以儲存庫為中心的知識系統。團隊可以透過 OpenAPI、綱要中繼資料、外部資料目錄、知識圖譜、受管文件、儲存庫檔案或其組合來履行語義責任。以下參考模式可協助人員和 AI 找到現行語義。

小型產品可以維持精簡。術語表記錄產品術語；一份資料語義文件則記錄權威介面尚未充分表達的重要資料含義：

語義範圍擴大後，產品可以依資料語義類型、所有者、來源或載入需求拆分紀錄。每一份聚焦的 Markdown 紀錄可使用小型 YAML 標頭，讓參與者找到其識別碼、類型和所有者，而不強迫填寫未必適用的通用欄位：

---
id: ldap-payroll-routing
kind: external-data
owners:
  - identity-data-owner
  - payroll-domain-owner
---

# LDAP 薪資路由

`memberOf` 中的 `Payroll-Externally-Managed` 表示員工薪資由外部管理。出現此成員資格時，`company` 會識別本產品核准供應商目的地所對應的薪資供應商。

紀錄本文說明該概念真正需要的資料語義。上述例子建立了 externally managed payroll employee 產品術語概念，並在該條件下識別供應商目的地。必要時，紀錄也可以連結供應商來源、說明表示方式，或記錄舊有系統的限制；不相關的細節應保持省略，不要為了配合範本而填入 N/A。

採用這個工作模式的團隊，可以在根目錄 AGENTS.md 要求貢獻者和 AI 程式設計代理在相關變更中使用 semantic-record Skill。Skill 會識別適用的紀錄類型、找到權威來源，並在適當位置準備有證據支持的更新；若證據不足或變更牽涉重要語義決定，則交由已列出的負責職能處理。Skill 支援可追究責任的維護，不會自行取得推斷定義或核准語義決定的權限。

返回頁頂

7. 語義就緒度的驗證

語義就緒度可依規格優先交付的知識系統就緒度一文的陌生參與者方法進行測試。讓一名沒有產品歷史的合資格參與者，透過正常的知識系統存取路徑解讀一個具代表性的產品術語或資料相依性。參與者可以是人員，也可以是使用交付期間相同授權產品脈絡的 AI 系統。

當陌生但合資格的參與者能取得現行含義、套用到相關取用情境、找出工作所需的負責職能與來源細節，並正確導向未解決問題時，該語義範圍才算就緒。AI 版本的測試必須使用交付工具實際可用的脈絡路徑。若必要含義雖存在卻無法由 AI 取得，或多項可檢索定義之間沒有清楚的產品解讀，知識系統仍有語義就緒度缺口。

驗證失敗後，團隊應產生具體的後續行動：找出原因是缺少語義、來源無法取得、定義互相競爭、關係不清、資訊過時，還是缺少所有權；更新現行語義來源或導向機制，以正確負責職能記錄重要決定，然後透過相同的人員或 AI 存取路徑再次測試。