OKF 開放知識格式（Open Knowledge Format）以 Markdown 與 YAML 保存業務定義、資料說明及操作規則，讓人與 AI 能沿著來源和連結查找知識。
OKF 提供了來源、驗證紀錄、過期時間與計算契約，文件內容與每次計算契約的執行結果仍需要各自確認。OKF 可搭配網站導覽、檢索及工具連接服務使用，權限、發布與更新則由使用端處理。
企業導入時，需要協調定義、補齊未成文的經驗並指定維護責任。可先從常見作業規則、單一指標或方案限制挑選一個場景，以少量文件回答明確問題，再用部門共識、回答品質與一次更新演練驗收，確認新知識能被 AI 正確讀取後再擴大納入範圍。
OKF 的定位與企業知識整理需求
用開放格式保存 AI 所需的業務脈絡
假設產品經理問 AI：「最近七天有多少活躍使用者？」在希望得到 AI 正確回答前，得先確認公司如何定義「活躍」。
開啟應用程式是否計入，或必須完成指定操作？統計期間採用哪個時區？測試帳號是否要排除？這些規則決定了哪些資料應該納入計算，也需要有人將規則寫清楚，讓查詢的人有依據可循。
開放知識格式（Open Knowledge Format，OKF）用於保存及交換這類知識。它以 Markdown 文件搭配 YAML 檔頭，將業務定義、資料說明與操作經驗整理成一組檔案。
Markdown 負責呈現人能閱讀的正文，YAML 檔頭則用固定欄位標記文件類型、摘要與來源等資訊。可以將它理解成「供人與 AI 閱讀的業務說明資料夾」，其中每份文件都描述一項概念，相關內容再透過連結串起來。
人員可以撰寫及審查這些文件，AI 代理人（AI Agent）也能協助產生內容，或在回答問題時讀取。OKF 保存的知識包含資料的意義、使用條件與判斷依據。
以活躍使用者為例，文件可以交代採用的事件、使用者識別方式與排除條件，並連到對應的資料表說明，讓讀取者沿著定義找到計算所需的資料。
分散文件與缺少依據的回答
若企業原本將活躍使用者的定義放在 Notion、報表操作方式記在 Confluence、欄位資訊留在資料庫時，回答一個問題就得跨越多個地方查找。
如果定義曾在會議中修改，更新只留在討論紀錄裡，讀取舊頁面的人還會沿用先前過時的規則。AI 即使找到了名稱相符的文件，也可能取用已經失效的內容。
整理成 OKF 時，可以將概念說明與來源放在同一份文件裡，再連到相關概念，保留查核所需的路徑。
例如活躍使用者文件記錄定義來自哪份業務規則，資料表文件則說明事件欄位的含義。分析師發現數字有差異時，就能先核對規則，再查看查詢使用的欄位，縮小需要確認的範圍。
可追查的來源提供查核依據，回答仍需核對定義與使用情境。
假設行銷報表將「曾造訪網站」視為活躍，產品報表則要求「完成指定操作」，兩份文件各有適用情境。整理時需要寫明各自的適用範圍，否則 AI 即使引用了文件，也可能把行銷的統計邏輯套用到產品報表，算出與提問者預期不同的人數。
跨工具交換與資料整理的重複工作
企業將同一批知識接入搜尋服務、內部問答系統與分析工具時，各個系統都需要讀取標題、內容與來源。若這些資訊只存在某個平台的專用欄位中，搬移資料時就得重新確認欄位如何對應，也要檢查原有的文件關係是否保留。
OKF 使用可直接閱讀的文字檔案，讓團隊能將整理後的知識保存在獨立的目錄中，再交由不同工具使用。知識內容也能納入 Git 版本管理，查看某項定義在何時、由誰修改。
例如團隊更換搜尋工具時，可以保留既有的指標定義、來源欄位與文件連結，由新的匯入程式讀取。文件類型及摘要已經寫在 YAML 檔頭，接收端便有明確欄位可用來分類及建立索引，減少從正文重新猜測文件用途的工作。
接收系統需要處理欄位對應、文字切分、搜尋索引與存取權限。團隊導入時，可以先拿一份指標文件測試，確認工具能讀到正文、保留來源，並沿著連結找到相關資料表。
若匯入後只留下文字內容，來源與連結都被丟棄，就需要調整匯入流程，才能讓使用者從回答結果回查原始定義。
OKF 檔案結構與治理欄位
知識包、概念文件與保留檔名
OKF 將一組相關文件組成知識包（Knowledge Bundle），以目錄為單位保存與交換。知識包裡的概念（Concept）各自對應一份 Markdown 文件，可以描述資料表、業務指標或操作流程。
團隊可依領域安排子目錄，再用文件連結表達彼此的關係。以下是簡化的目錄示意，實際分類應依領域內容調整。
knowledge/
├── index.md
├── log.md
├── metrics/
│ ├── index.md
│ └── active-users.md
└── tables/
├── index.md
└── events.md其中 index.md 提供目錄入口，列出文件連結與簡短說明，讓人或 AI 先知道有哪些內容，再開啟需要的文件。log.md 則依日期記錄該目錄的更新，新紀錄排在前面。兩者都可以出現在不同層級，也是選用檔案，團隊可依閱讀與追蹤需求加入。
例如根目錄的 index.md 可以列出兩個分類入口，讓讀取者依問題選擇要開啟的目錄。
## 知識目錄
- [業務指標](metrics/index.md) - 活躍使用者等指標的定義與計算條件。
- [資料表](tables/index.md) - 事件資料表的欄位與使用說明。根目錄的 log.md 則可以記錄新增或修改了哪些內容，日期採用 YYYY-MM-DD 格式，並連回受影響的文件。
## 2026-10-29
- 更新[活躍使用者](metrics/active-users.md)的測試帳號排除條件。
## 2026-10-28
- 新增[事件資料表](tables/events.md)的欄位說明。
這兩個範例都直接使用 Markdown 正文，無須加入概念文件的 type 檔頭。
index.md 與 log.md 是具有特定用途的保留檔名，不能用來命名一般概念文件。例如活躍使用者的定義應放在 active-users.md，目錄索引只保留通往這份定義的連結與摘要。
知識包可以放在 Git 儲存庫、較大專案的子目錄中，也能打包成壓縮檔交付。
YAML 檔頭與概念的基本資料
每份概念文件由 YAML 檔頭（Frontmatter）與 Markdown 正文組成。檔頭位於檔案最上方，以兩行 --- 包住欄位，正文則接在結束標記之後。
一般概念文件的通用必填欄位是非空的 type，用來說明這份文件屬於哪一類知識。
---
type: Metric
title: 活躍使用者
description: 說明活躍使用者的判定條件與統計範圍。
tags: [product, analytics]
---title 提供顯示名稱，description 是便於搜尋結果或目錄使用的簡短摘要，tags 則讓文件能按主題分類。這些欄位可依需求填寫。
若概念描述的是實體資源，例如一張資料表，還可以用 resource 指向該資源的識別位置。抽象的業務定義可以省略這個欄位，將相關資料表連結放在正文。
OKF 未建立集中管理的類型清單，團隊可以依內容選擇清楚的類型名稱。讀取端遇到未知類型或額外欄位時，也需要保留讀取能力。正文也沒有強制的固定章節和順序，可依內容寫入定義、欄位說明與查詢範例。
若採用可驗證計算等特定類型，就需要遵循該類型的要求，例如提供 runtime，不能只依通用最低條件準備文件。
來源追蹤與文件驗證紀錄
分析師確認活躍使用者定義時，需要知道文件依據哪份規則整理、由誰產生，以及是否有人核對過。
OKF v0.2 分別用 sources、generated 與 verified 保存這些資訊。這三組欄位都是選用項目，未填寫驗證紀錄的文件仍能被讀取，使用端應保留其尚未驗證的狀態。
sources 記錄文件所依據的材料，每筆來源都需要有 resource，指出來源文件、資源位置或資料範圍。來源可以位於知識包內，也可以連到外部文件。
若正文中的某項論述需要對應特定來源，可以為來源設定穩定的 id，再以相同識別碼建立 Markdown 註腳。即使來源清單重新排序，這項論述仍能對應原來的依據。
generated 記錄目前內容由誰產生，generated.at 可標記最後一次有意義的內容變更時間。
verified 則保存驗證者及驗證時間，允許同一份文件留下多次檢查紀錄。人員身分使用 human: 前綴，自動化流程使用 process: 前綴，工具或代理人則採用製作者與版本的識別方式。
以下是活躍使用者文件的檔頭示意，來源路徑、人員識別碼與時間皆為範例設定，應依實際紀錄填寫。
---
type: Metric
title: 活躍使用者
sources:
- id: active-user-policy
resource: /references/active-user-policy.md
title: 活躍使用者統計規則
generated:
by: "human:analyst-chen"
at: "2026-10-26T09:00:00+08:00"
verified:
- by: "human:product-owner-lin"
at: "2026-10-27T14:00:00+08:00"
---這份紀錄表示分析師整理了內容，另一位人員在隔天完成核對。正文若需要引用這項規則，可使用 [^active-user-policy] 註腳，並讓註腳標籤對應來源的 id。
使用端可從 verified 區分未驗證、機器確認與人工審查。這些標記提供判斷依據，存取授權仍需由系統另外處理。
內容更新時間與驗證時間需要分開檢查。例如分析師在週一確認定義，週三有人改了排除條件，週一的紀錄仍存在，讀取者就需要確認週三的修改是否已經重新審查。
文件狀態與過期時間
status 表示文件所處的生命週期。draft 用於尚未審查、內容可能未完整的草稿，stable 表示已準備好可供使用，deprecated 則保留已不再適用的文件，讓舊連結與歷史紀錄仍有對應內容。
省略 status 時，預設值為 stable，因此讀取端還需要查看 verified，才能知道文件是否留下人工審查紀錄。
stale_after 提供內容過期的判斷時間。例如設定為 2026-12-01T00:00:00Z，代表從該時刻開始，使用端應將內容判定為過期。這是包含時區的明確時間，與讀取文件後再計算有效天數的方式不同。使用端可以據此顯示提醒、通知維護人，或依應用規則暫停採用內容。
以下檔頭將文件標為可供使用，並設定複查所依據的過期時間。
---
type: Metric
title: 活躍使用者
status: stable
stale_after: "2026-12-01T00:00:00Z"
verified:
- by: "human:product-owner-lin"
at: "2026-10-27T14:00:00+08:00"
---到達 stale_after 後，即使 status 仍是 stable，使用端也應辨識出內容已過期。先前的人工驗證紀錄仍會保留，後續複查時則需留下新的驗證時間。
假設產品改版後更換了活躍事件，舊文件即使還沒到設定的期限，也需要提前複查。
stale_after 無法自動偵測業務變更，status 也無法替團隊修改定義。負責人應在改版工作中核對受影響的文件，更新事件條件、重新驗證，再決定下一次需要複查的時間。
計算契約與單次執行驗證
指標文件寫清楚定義後，使用端還需要確認每次產出的數字是否依照核准方式計算。可驗證計算（Attested Computation）以獨立概念保存這份約定，其他指標或報表文件可以透過連結引用它。例如同一份營收計算可供月報與儀表板使用，計算規則的驗證紀錄則保留在對應的計算文件中。
這類文件使用 type: Attested Computation，並以必填的 runtime 指定執行環境，例如 BigQuery 或 Python。
parameters 宣告允許提供的參數，讓 AI 代理人（AI Agent）填入期間等數值，計算內容則依核准版本執行。
計算內容可直接放在正文的約定區塊，也能由 computation 指向另一個檔案，並限制代理人在使用時不得自行改寫算式或查詢。
當 AI 能觸發 SQL 查詢或 Python 程式時，執行端也會面臨 SQL 注入（SQL Injection）、越權存取敏感資料表等嚴重資安風險。
使用端應將程式放在受限制的沙盒（Sandbox）環境執行，限制檔案與網路存取，並讓資料庫帳號只取得必要權限。
參數也需採用白名單，檢查名稱、型別與允許範圍，SQL 則透過參數綁定傳值，避免將輸入直接拼接成查詢文字。
AI 只能填入已宣告的參數值，不得動態修改底層程式碼、查詢結構或計算邏輯。這些限制需由執行端強制落實，並禁止代理人寫入核准的計算檔案。
executor 指向執行指示或程式，並透過 executor.receipt 宣告執行後需要回傳哪些證據，例如工作識別碼、實際執行的查詢與結果。
這份執行回條（Receipt）會交給 attester 指向的檢查程式處理。檢查程式按固定規則比對核准計算與實際執行內容，並核對顯示數值是否符合可查證的執行結果。回條屬於執行期間的產物，不存進知識包作為定義的一部分。
以下以年度營收為例，示範將核准計算放在外部檔案的契約寫法。
---
type: Attested Computation
title: 年度營收計算
runtime: bigquery
parameters:
- name: year
type: integer
required: true
computation: /references/computations/revenue.sql
executor:
resource: /references/executors/run-revenue.md
receipt: [job_id, executed_sql, result]
attester:
resource: /references/attesters/check-revenue.py
verified:
- by: "human:finance-reviewer"
at: "2026-10-27T14:00:00+08:00"
stale_after: "2026-12-01T00:00:00Z"
---在這個例子裡，代理人只能提供 year 的值，使用端依執行指示將它綁定到核准的計算。檢查程式再依回條中的工作識別碼查證執行結果，核對實際查詢是否符合核准內容，以及輸出的營收數值是否相符。
文件通過審查與某次計算符合約定，需要分別驗證。verified 記錄定義是否經過確認，單次執行驗證則檢查那一次執行是否照約定計算。
OKF 保存兩者所需的資訊與介面約定，執行、比對及結果處理仍由使用端實作。若實際查詢被改寫或顯示數值與執行結果不符，使用端應攔下該結果並呈現驗證失敗，交由負責人查明原因。
從 GA4 官方知識包看 OKF 的運作方式
從索引掌握資料集、資料表與參考文件
GoogleCloudPlatform 的 OKF 專案提供了 Google Analytics 4（GA4）知識包，以經過混淆處理的 Google Merchandise Store 電商示範資料為題材。
從根目錄的 index.md 開始，就能看到資料集、資料表與參考文件三個入口。每個入口附有摘要，讓讀取者先判斷哪個目錄與問題有關，再往下查找。
若想了解活躍使用者如何計算，可以依序查看資料來源、事件欄位及指標定義。以下列出這條閱讀路徑會用到的檔案，省略其他指標文件。
bundles/ga4/
├── index.md
├── datasets/
│ ├── index.md
│ └── ga4_obfuscated_sample_ecommerce.md
├── tables/
│ ├── index.md
│ └── events_.md
└── references/
├── index.md
└── metrics/
├── index.md
└── n_day_active_users.md這樣的安排讓資料背景與查詢定義各有位置。第一次接觸資料的人可以從資料集讀起，已經熟悉資料的人則能直接進入指標目錄，找到要使用的查詢說明。
從資料集文件找到事件資料表
資料集文件使用 type: BigQuery Dataset，描述整組示範資料的用途，並透過 resource 指向對應資源。
檔頭中的 generated 記錄內容的產生方式與時間，sources 則保留資料集資訊及外部說明文件的來源。正文還提供連結，讓讀取者接著開啟事件資料表文件。
事件資料表文件使用 type: BigQuery Table，描述每天匯出的事件紀錄。
event_name 用來辨識瀏覽頁面或購買等事件，event_params 保存事件的附加參數，使用者識別欄位則供查詢辨認與統計使用者。知道這些欄位的含義後，才能判斷某項指標要取用哪些資料。
概念之間的連結，讓讀取者能從業務問題追查到資料結構。例如資料集文件透過 ../tables/events_.md 連到事件資料表，事件資料表再連到各項受眾指標。沿著這些路徑，就能找到接下來要閱讀的 N 日活躍使用者文件。
讀懂 N 日活躍使用者的定義與查詢
N 日活躍使用者文件將 N 日活躍使用者（N-Day Active Users）定義為：最近 N 天內，至少有一筆事件的 engagement_time_msec 大於零。這個條件讓「活躍」有可檢查的依據，讀取者可以回到事件參數確認哪些紀錄符合要求。
這份文件採用 type: Reference，內容包含查詢模式與來源。正文的結構化查詢語言（Structured Query Language，SQL）範例先展開事件參數，再篩選參與時間大於零的紀錄，最後在計算不重複的使用者識別值。
閱讀這份文件時，可以把自然語言定義與查詢條件逐項對照：活躍行為對應事件參數，統計期間對應時間條件，人數則取決於使用者識別欄位。
若團隊的業務定義另外要求排除測試帳號，就需要補上相應規則、來源及查詢條件，並請負責人確認修改後的計算方式。
將概念說明、查詢範例與來源放在一起
N 日活躍使用者文件採用 type: Reference，將指標定義、查詢範例與來源整理在同一份文件中。檔頭的摘要讓讀取者先知道文件用途，正文則交代「活躍」如何對應事件參數、時間條件及使用者識別欄位。這種安排讓一項指標的文字說明與計算條件能相互對照。
檔頭中的 sources 連到受眾查詢的來源文件，generated 記錄內容的產生方式與時間。讀取者若想進一步了解查詢依據，可以沿著來源連結查看相關說明。搭配知識包內的資料集與事件資料表文件，就能從資料背景一路讀到具體指標，理解 OKF 如何用檔頭、正文與連結組織一組相關知識。
OKF 與 llms.txt、RAG、MCP 的分工
llms.txt 提供網站閱讀入口
通常企業網站裡的產品說明、操作教學與技術文件會分散在不同頁面，AI 代理人（AI Agent）會需要先知道如何找到適合閱讀的內容。
llms.txt 提供一個精簡入口，讓網站維護者整理背景說明、閱讀指引及文件連結。代理人可以先讀這份入口文件，再沿著連結取得細節，減少一開始就載入大量頁面內容的需要。
例如一個產品文件網站，可以在 llms.txt 中列出安裝指南、功能說明與疑難排解入口。OKF 則以多份概念文件組織知識，透過檔頭描述類型、來源與驗證紀錄，再以連結串接相關內容。
llms.txt 安排網站內容的閱讀入口，OKF 約定知識文件的結構與欄位。兩者都可以依部署方式服務公開或內部內容。
若團隊將 OKF 文件發布在網站上，也可以另設 llms.txt 引導讀取者找到相關頁面，但網站維護者仍需安排文件網址、閱讀權限及內容更新。
RAG 檢索知識並支援回答生成
檢索增強生成（Retrieval-Augmented Generation，RAG）將查找資料與生成回答接在一起。使用者提出問題後，系統先從文件或資料來源找出相關內容，再交給模型作為回答依據。檢索到的材料是否切題、是否仍然有效，會影響最後的答案。
以查詢 GA4 的 N 日活躍使用者定義為例，OKF 文件保存判定條件、查詢範例與來源，RAG 系統則負責依問題找出相關段落，提供給模型使用。
建立索引時，團隊可以將檔頭中的類型、摘要與來源一起讀入，保留篩選及回查需要的資訊。這些欄位要如何對應到搜尋系統，需要由匯入流程設定。
若文字切分將查詢範例與適用條件拆開，模型取得的內容就可能缺少日期限制或使用者識別規則。因此，接入 OKF 後需要檢查搜尋結果是否保留足夠的上下文，以及回答引用的是哪個版本。
測試時可以用「最近七天的活躍使用者如何計算」這類具體問題，核對系統是否找對定義，並將期間、欄位與排除條件一併提供給模型。
MCP 連接 AI 應用與外部系統
模型上下文協定（Model Context Protocol，MCP）提供 AI 應用連接外部資料來源與工具的共同方式。服務端可以提供可讀取的資源或可呼叫的工具，應用端再透過協定取得資料或執行操作。例如文件搜尋服務可以讓 AI 應用查找知識，資料查詢服務則可以接受參數並回傳結果。
以 OKF 知識包為例，團隊可以建立一個提供搜尋與文件讀取功能的 MCP 服務。使用者詢問活躍使用者定義時，AI 應用先呼叫搜尋工具，取得概念文件的位置，再讀取定義與相關資料表說明。
OKF 約定傳遞的知識如何表達，MCP 約定應用如何連接提供知識與工具的系統。如果服務端另有檢索流程，也可以用它搜尋 OKF 內容，再透過 MCP 回傳。
服務端需要依使用者身分決定可讀取的範圍，保留來源與版本資訊，讓應用收到文件後，仍能將回答連回使用者有權查看的內容。
企業導入 OKF 的六項挑戰與適用條件
盤點跨部門定義並協調適用範圍
業務、數據與財務部門使用同一個指標名稱時，背後的計算條件未必一致。例如每週活躍使用者（Weekly Active Users，WAU）可能採用不同事件判定活躍，月經常性收入（Monthly Recurring Revenue，MRR）也可能因折扣、退款與合約認列方式而出現差異。
盤點文件時，需要把各版本的公式、來源與使用目的攤開核對，才能知道數字差在哪裡。
建立唯一事實來源（Single Source of Truth），需要讓相關人員確認哪些定義適用於哪些決策，並指定負責解釋與核准變更的人。
OKF 可以保存確認後的內容與來源，協調過程需要各部門參與。討論中出現「這份報表一直都是這樣算」的說法，就要進一步找出原始規則，確認目前業務是否仍沿用相同條件。
同名指標若服務不同用途，文件需要清楚標示各自的適用範圍。例如行銷報表採計造訪網站的人，產品報表採計完成指定操作的人，可以分別命名並保留定義，讓使用者選到符合問題的統計口徑。
若管理面需要統一比較，就由相關部門確認會議使用哪一份定義，並將決議連回指標文件。
將未成文的經驗整理成可讀文件
資料表之間如何關聯、哪些歷史紀錄需要排除、哪個欄位在舊版本曾有特殊含義，這些經驗可能只留在資深人員的記憶裡。
這類隱性知識（Tacit Knowledge）需要透過訪談、案例走查與查詢核對才能整理。直接將舊文件轉成 Markdown，仍會留下原本沒有寫出的判斷條件。
以前面的 GA4 使用者識別為例，文件可以列出 user_id 與 user_pseudo_id，實際採用時還需要確認識別值從哪裡產生、哪些紀錄沒有填值，以及統計結果代表哪些對象。
整理人員可以請分析師拿一份既有報表逐步說明，將選欄位、排除資料及處理例外的理由寫在對應概念中，再用實際查詢檢查描述是否完整。
AI 代理人（AI Agent）可以協助整理試算表、會議紀錄與討論串，產出待確認的文件。規劃工時時，還要納入找回來源、釐清衝突與請熟悉業務的人審查所需的時間。
若某項例外僅有口頭說法，應先記下待確認事項與負責人，等找到依據後再補進正式規則。
指定維護責任並追蹤內容過期
產品改版後，事件名稱與資料表欄位已經修改，知識文件若仍沿用舊內容，AI 就可能產生無法執行的查詢，或套用已停用的計算條件。
內容的有效期限取決於業務與系統變動。有些文件在下一次部署後就需要重查，有些定義則能使用較長時間，複查安排應跟著變更風險調整。
stale_after 提供過期判斷時間，verified 保存驗證者與時間，這些資訊需要接上有人處理的工作流程。
每個知識領域應指定維護人與備援負責人，並約定哪些事件會觸發檢查，例如資料欄位改名、退款政策生效或指標公式調整。收到提醒後，負責人需要確認內容、完成修改，並留下新的驗證紀錄。
文件可以透過 Git 提交變更，再由持續整合（Continuous Integration，CI）檢查 YAML 格式、連結與到期文件。
自動檢查能找出格式錯誤或需要複查的項目，業務定義是否正確需要由熟悉內容的人確認。
若變更已經影響現有回答，就應將文件修正與使用端更新一起排入處理工作，確認搜尋服務讀到的是修正後版本。
訂定內部欄位與分類規範
OKF 允許團隊自訂類型與額外欄位，導入時需要約定相同概念如何命名。
假設同樣是業務指標，一個部門標成 Metric，另一個部門標成 KPI，兩份文件都能被讀取，搜尋工具若只篩選其中一種類型，就會漏掉另一份。欄位名稱不同也會帶來類似問題，匯入程式需要額外判斷哪些欄位代表相同資訊。
內部規範可以先約定常用類型、標籤及來源的填寫方式，再按用途增加內容要求。例如準備發布給客服使用的規則，團隊可以要求附上政策來源、負責人與審查紀錄。
這些要求應與 OKF 的通用最低條件、特定類型要求分開記錄，讓文件作者知道哪些是格式要求，哪些是企業的發布條件。
新增欄位時，也需要說明欄位意義與讀取它的工具。例如團隊自訂 owner 保存維護人，就要約定使用人員識別碼、群組名稱或其他值，並確認提醒程式能找到對應對象。
寫進欄位的治理資訊，需要有工具或人員實際使用。若讀取端尚未處理這個欄位，維護人通知就得由既有任務系統或人工流程補上。
設計存取權限與知識發布流程
知識包可能同時包含一般產品說明、客戶合約條款與內部事故紀錄。當這些檔案被複製到搜尋服務或提供給 AI 應用時，需要確認哪些內容可以由誰讀取。OKF 未規定儲存、查詢與授權平台，企業需在實際保存及提供文件的系統中實作權限控制。
發布前可以先依用途與敏感程度區分內容，確認每個使用端需要取得的範圍。例如一般客服問答可以使用公開政策，個別客戶的合約例外則需經過身分與權限檢查。
檢索服務應在提供內容給模型前確認授權範圍，避免先將整包文件交給模型，再只靠回答指示限制敏感資訊的使用。
文件更新、撤回或縮小讀取權限時，也要處理索引與快取中的副本。原始儲存庫已刪除的條款，如果仍留在搜尋結果裡，使用端就可能繼續引用。
發布流程應記錄提供的版本與範圍，並保留適當的存取紀錄，讓負責人能確認撤回後的文件是否仍可被查到。
依知識重用需求評估導入範圍
團隊人數與是否已提供工具介面給 AI，都不足以單獨判斷 OKF 是否適用。小型團隊也可能需要讓多個工具共用同一份定義，大型組織中的單一工作流程則可能只需要少量文件。
評估時可以先查看哪些知識被反覆詢問、是否需要跨工具交換，以及目前更新一項規則要修改多少地方。
若文件量少、讀取者固定，也沒有跨工具使用需求，可以先整理少量概念文件，配合既有審查方式維護。當同一份定義開始被不同服務引用，再補上對應的索引、來源與更新安排。
導入範圍應讓負責人有能力審查與維護，避免一次轉入大量尚未確認內容的舊文件。
對每秒變動的股價或感測器資料，OKF 可以保存欄位意義、單位、資料來源與查詢規則，即時數值則由資料服務提供。例如溫度文件記錄攝氏單位、量測位置與缺值處理方式，最新讀值透過查詢取得。
團隊需要分別安排知識文件的複查時機與資料服務的更新頻率，才能在解讀數值時找到適用的說明。
第一個 OKF 試點的選擇原則與候選場景
以高頻問題、定義分歧與明確邊界篩選
挑選第一個概念驗證（Proof of Concept，PoC）場景時，可以先查看新人或 AI 經常答錯的問題。例如客服反覆查詢退款例外、分析師需要解釋兩份報表的人數差異，或業務仍在引用舊版方案限制。
這些問題已有實際使用需求，也能找出曾經答錯的案例，作為整理知識時的依據。
若問題涉及跨部門定義分歧，需要先限定這次要支援的工作，再找能確認規則的人參與。
以活躍使用者為例，可以先處理產品週報使用的定義，約定唯一事實來源（Single Source of Truth），讓週報撰寫者有共同依據。其他報表採用的口徑可保留各自說明，等這次試點需要引用時，再釐清彼此的適用範圍。
第一個試點應以少量文件回答一組明確問題。整理範圍可先估計為 3 到 5 份概念文件，涵蓋主要定義、必要例外及來源。
如果一項問題牽涉多個產品、不同地區與大量特殊合約，就可以先限定某一產品及已確認的政策版本，並寫清楚哪些情況需要交由其他人判斷。
內部作業的申請條件與例外處理
員工申請系統權限、設備或跨部門支援時，需要知道誰能提出申請、要附哪些資訊，以及由誰審核。
這類問題會反覆出現在新人提問與內部服務窗口，適合挑選其中一項作業作為試點。例如申請專案資料夾的讀取權限，就涉及申請人的工作角色、需要存取的範圍與資料負責人的核准。
若規則分散在內部公告、表單說明與口頭交接中，整理時就要先確認目前採用的流程。
小型知識包可以從三份文件開始。申請條件.md 記錄適用對象、必填資訊與處理窗口，審核流程.md 說明各階段由誰確認及如何通知結果，例外處理.md 則交代急件、資料不足或跨部門授權的處理方式。
文件之間以連結銜接，讓讀取者從一般申請規則找到例外情況的處理人，每份文件也保留制度來源與生效時間。
團隊可以先讓內部 AI 助理讀取這份知識包，回答員工的申請問題，實際核准及權限變更仍依既有流程處理。
例如員工詢問「我要申請查看專案資料，需要提供哪些資訊」，AI 助理便依文件說明申請條件，並提醒員工提供專案名稱、存取用途與所需範圍。若申請涉及其他部門管理的資料，AI 助理可指出應聯絡的資料負責人，再由具備核准權責的人確認。
數據與分析的單一商業指標
每週活躍使用者（Weekly Active Users，WAU）、月經常性收入（Monthly Recurring Revenue，MRR）與商品交易總額（Gross Merchandise Value，GMV），都可以作為指標類試點的候選。
選擇時可以查看哪個指標經常出現在會議或報表裡，哪些計算條件需要反覆解釋，以及是否有人能確認資料來源。第一輪先挑一項指標，並限定服務的報表或決策。
以前面的 GA4 案例為基礎，若要整理活躍使用者指標，就需要寫明活躍事件、統計期間、時區、使用者識別欄位與排除條件。資料表說明還應交代更新延遲，讓使用者知道報表是否已包含完整期間的資料。指標文件可以連到資料表及計算文件，並記錄定義與查詢各自由誰確認。
單一指標試點需要一份能逐項核對的計算依據。例如用同一段歷史期間與相同篩選條件，比較分析師既有查詢與 AI 產生的查詢。結果不同時，就追查是識別欄位、時間範圍、去重方式或排除條件造成差異。
若既有報表的計算方式也說不清楚，試點開始前就需要先安排分析師確認，才能準備可供比對的答案。
OKF 試點的落地步驟與驗收標準
選定領域並建立知識資料夾
選定場景後，第一步就是列出這次需要回答的問題，再整理出 3 到 5 個相關概念或規則。
以退款試點為例，可以先限定某項產品的一般退款申請，涵蓋申請資格、補償條件與轉人工判斷。特殊合約若尚未取得可用的政策來源，就先列為需要轉交確認的情況，並記錄由誰處理。
接著，為每份預計建立的文件確認來源與審查者。退款資格可由政策負責人確認，轉人工條件則請客服主管核對，避免文件整理完成後才發現無人能判斷內容是否正確。
這時也可以蒐集客服實際收到的問題，留下客戶提供的條件、當時的回答與待釐清之處，供後續測試使用。
第二步是在專案中建立 knowledge/ 資料夾，依前述概念安排檔案，必要時加入 index.md 提供閱讀入口。資料夾名稱可由團隊自行決定，重點是文件位置能被讀取工具找到，且負責人知道在哪裡修改。
整理時程應納入來源查找與內容確認的時間，遇到尚未取得共識的規則，就記錄待確認事項及處理人。
撰寫概念文件並納入版本審查
第三步是撰寫概念文件。每份文件先填入 YAML 檔頭，以非空的 type 標記類型，再提供便於辨識的 title 與 description。
正文寫清適用條件、例外及相關文件連結，並以 sources 保留依據。若內容尚待確認，可以先標為草稿，等審查完成後再補上對應的驗證紀錄。
以退款規則為例，正文應讓讀取者知道申請期限如何計算、需要哪些資料，以及遇到例外時該查看哪份文件。
規則若有生效日期，就要寫明新舊政策各自適用的條件。使用者會如何提問，也可以作為檢查文件是否完整的依據，例如拿「購買後已使用部分服務」的案例，確認文件是否足以判斷下一步。
第四步是將文件納入 Git 管理，借用程式碼評審（Code Review）的流程檢視修改。技術檢查可以確認檔頭是否能解析、概念類型是否有填寫，以及連結能否找到目標。業務審查則由熟悉內容的人核對規則、例外與有效期間。
格式檢查通過後，需要確認文件能否正確回答業務問題。若修改了補償條件，也要查看退款規則與轉人工文件是否引用了舊條件，再一起提交調整。
接入 AI 並比較相同問題的回答
第五步是讓 AI 代理人（AI Agent）實際讀取知識包。若應用具備檔案讀取工具，可以在系統提示詞（System Prompt）中指定文件入口與閱讀要求。若文件由外部服務提供，也可以透過模型上下文協定（Model Context Protocol，MCP）提供搜尋或讀取功能。
接入後，先確認工具能讀到指定版本，再用同一組問題比較接入前後的回答。
例如退款案例除了條件完整的申請，也要包含缺少購買日期、政策版本不同、規則互相衝突，以及需要轉人工的情況。
每題記錄回答內容、引用的文件與未符合預期之處，便於追查是文件沒寫清楚、工具沒有取回相關段落，還是模型誤用了規則。
比較時盡量固定模型、設定與提問方式，並保留測試使用的知識版本。重要案例可以重複執行，查看回答是否出現不同判斷。
若 AI 引用了舊政策，就先確認讀取紀錄與索引版本，再核對它是否忽略了生效條件，據此決定要修改文件、匯入流程或回答指示。
以共識、回答品質與維護責任驗收
驗收前，相關人員需要先約定合格答案、可接受的差異，以及必須轉人工的條件。遇到資訊不足的題目，合格表現可以是提出必要的補充問題，避免模型在條件不完整時直接做出決定。
驗收可依三個面向整理證據，讓參與者知道哪些項目已完成，哪些仍需處理。
- 共識：相關部門已確認定義、適用範圍與例外，並留下審查紀錄。
- 回答品質：依事先約定的標準記錄答對題數與總題數，保留來源引用及逐題錯誤原因，另行檢查需要轉人工的案例。
- 維護責任：已指定負責人、備援人員與複查安排，並確認規則變更後由誰修改、審查及發布。
整體答對比例需要搭配錯誤內容一起閱讀。例如回答多數一般問題都正確，卻在超出授權範圍時承諾補償，仍需先修正該問題再重新測試。
最後安排一次規則更新演練，由負責人修改文件、完成審查與發布，再重跑受影響的題目，確認 AI 能讀到新版本並採用更新後的條件。
結語：從一個能驗收的場景開始導入 OKF
用退款規則或單一指標完成第一次試行
開始導入 OKF 時，可以先找一個經常需要查文件、詢問同事才能回答的問題。客服已有明確的政策來源時，可從常見問題著手。分析師已有可核對的報表與查詢時，可挑選一項商業指標。
選定場景後，先確認有哪些人能提供依據、審查定義，以及處理後續變更，再安排文件整理工作。
第一個試點要能回答明確問題，也要能查出答錯的原因。整理文件之前，請場景負責人選出第一組真實問題，涵蓋一般條件、例外與資訊不足的情況，並指定由誰確認預期答案。
接著依這組問題準備概念文件，讓每份定義與來源都有具體用途，也讓第一次驗收有可比對的依據。
OKF 導入準備步驟檢核表
開始試行前，可以由場景負責人與參與人員一起核對以下項目，確認文件、讀取方式與驗收安排已準備到什麼程度。
- [ ] 選定一個試點場景，寫明要回答的問題、適用範圍及需要轉人工的情況。
- [ ] 找出規則與資料來源，確認版本、生效條件及尚待釐清的定義分歧。
- [ ] 指定文件整理者、審查者、維護人與備援人員，約定變更及過期時的處理方式。
- [ ] 建立少量概念文件，填入必要檔頭、定義、例外與來源，檢查格式及文件連結。
- [ ] 將文件納入版本管理，安排審查、發布與撤回流程，確認索引及快取的更新方式。
- [ ] 設定讀取工具與存取權限，確認 AI 能取得指定版本，且只能讀取授權內容。
- [ ] 若涉及外部運算，準備沙盒隔離、最小權限與參數白名單，禁止 AI 修改核准的計算邏輯。
- [ ] 準備測試問題、核准答案與合格條件，涵蓋一般問題、例外、資訊不足及轉人工情況。
- [ ] 安排一次規則更新演練，確認修改、審查、發布與重新測試都有負責人。尚未完成的項目應記下負責人與預定處理時間。不涉及外部運算的試點，可以註記該項不適用，之後新增查詢或程式執行功能時再重新檢查。
根據試點結果決定後續整理範圍
試點完成後，可以把答錯的問題、查不到的來源，以及整理和維護花費的時間放在一起檢視。
若定義仍有分歧，就請相關人員確認適用條件。若文件已寫清楚，AI 卻沒有讀到相關內容，就檢查搜尋、連結與版本更新。
每個待處理項目都應對應到一個具體修改，完成後重跑受影響的問題。
擴大 OKF 的整理範圍前，先完成一次規則變更與重新驗收，確認負責人能修改文件、審查者能核對內容，使用端也能取得新版本。
下一個場景可以沿用已確認的欄位與審查流程，再加入該場景的來源、負責人及測試問題。若之後過期文件無人處理，也得先安排維護工作，再決定下一批要納入的內容。
- AI 時代下的架構知識斷層：ADR 如何幫助團隊理解系統的決策背景
- 如何提升技能與知識（Improve Skills and Knowledge）：從能力盤點到團隊成長的三種路徑
- OKF v0.2 規格
- GA4 官方知識包教學入口
- llms.txt 格式提案
- Google Cloud：檢索增強生成
- MCP 官方介紹
