AI知識庫長出「標準」：LLM Wiki、OKF，跟我們那套知識庫的三層關係

前面三篇文章，我們把三件事講完了：

第一篇，為什麼台灣建築營造產業需要一個開源知識庫——因為這個產業最寶貴的資產是經驗，而經驗正以每天幾個人的速度消失。那套知識庫開源在 GitHub 上（HJPLUS_Taiwan_Architect_KB），每一則條目同時是給人看的 Wiki、也是給 AI 讀的「技能」。

第二篇，知識庫是燃料，地端模型是引擎——怎麼讓引擎在你自己的硬體上轉起來，從 Ollama 到 vLLM，從 RAG 到量化。那篇我們帶過一句：「我們知識庫採的標準叫 OKF」。

第三篇，你的知識庫不是檔案，是 Agent 的「專案記憶體」——AU 2026 上，有人用一組數據證實了我們一直在做的事：把知識存在外部，agent 冷啟動就能讀到，準確率從 38% 拉到 78%。

但三篇講完，有一個問題一直被跳過：格式這件事，到底有沒有標準？第二篇帶過 OKF 一句話就過去了，今天把它講透——順帶把一個我們自己都沒意識到的故事講清楚：

我們那套知識庫，其實比 OKF 還早。

先講我們的故事：先做，後來發現就是 OKF

我們的知識庫是怎麼建的？說穿了很樸素：一組 Markdown 檔案，每個檔案開頭帶一段 YAML frontmatter（檔案開頭用 --- 包起來的結構化標頭，寫 key: value 的欄位，跟下面的 Markdown 本體分開），裡面有 type、title、description、tags、resource 等欄位；檔案之間用連結互相關聯。人可以直接讀，AI agent 也可以直接讀，不需要任何專用工具或 SDK（Software Development Kit，開發者套件——這裡指不用寫程式碼、不用裝任何函式庫就能讀）。

我們建它的時候，圈裡已經在流行一套做法——LLM Wiki。你如果沒聽過，下一節會講。重點是：我們就是照這個精神做的。

然後 2026 年 6 月，Google Cloud 發布了 OKF（Open Knowledge Format）。我們打開規格一看，發現跟我們從頭建的結構幾乎一模一樣。不是我們為了 OKF 去改格式——是我們先照 LLM Wiki 的精神做了，後來發現「喔，這就是 OKF」。

這個順序很重要，因為它代表一件事：你不需要等標準發布才開始建知識庫。照 LLM Wiki 的精神建，標準來了你就天然相容。

LLM Wiki：一個「讓 LLM 幫你維運 wiki」的做法

LLM Wiki 這個做法（pattern——這裡指一套反覆出現、被多家獨立採用的慣例，還沒被正式定義成標準），最清楚的表述來自 Andrej Karpathy（OpenAI 共同創辦人、現在獨立做教育）2026 年 4 月的一份 gist（GitHub 上的輕量分享文件，比正式專案倉庫輕，適合放單一文件）。他自己定位得很清楚：這是一份「idea file」——設計來複製貼上給你的 LLM agent 看的理念文件，不是可執行的規格。

它的核心想法只有一句：

不要只在查詢的時候從原始文件裡檢索，而是讓 LLM 增量式地建立並維運一個永久的 wiki——一組結構化、互相連結的 Markdown 檔案，放在你和原始資料之間。

三層架構：

• Raw sources：不可變的原始資料（法規原文、圖說、會議記錄）
• The wiki：LLM 產生並維護的 Markdown 目錄——提煉過的知識
• The schema：CLAUDE.md 或 AGENTS.md，告訴 LLM 結構跟工作流

三個操作：Ingest（吃進新資料）、Query（回答）、Lint（檢查交叉引用有沒有壞掉）。

他有一句話我直接引用：「Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.」（Obsidian 是 IDE，LLM 是程式師，wiki 是程式庫。）

另一句值得記：「LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass.」——LLM 不會厭煩、不會忘記更新交叉引用、一次可以動 15 個檔案。這正是「讓 LLM 幫你做 wiki 簿記」的論點。

但這個 pattern 有個問題：它只是做法，不是標準。每家照著做的結果，互相之間長得很像（markdown、frontmatter、交叉連結），卻沒有刻意設計成可以合作。Obsidian vault（Obsidian 是個人知識管理工具，vault 是它的資料夾，支援 markdown 雙向連結）、AGENTS.md / CLAUDE.md（放在專案根目錄的說明檔，告訴 AI agent 這個專案的結構、規則、工作流——各 AI 工具自訂的格式）、資料團隊的 metadata-as-code 倉庫（把資料表的結構、欄位定義等元資料用程式碼管理，跟資料本身一起版本控制）——同一個 DNA，一百種實現，互不相容。

OKF：Google 把 LLM Wiki 標準化了

2026 年 6 月 12 日，Google Cloud（Data Cloud 團隊）發布了 OKF（Open Knowledge Format）——一個開放規格（open specification，任何組織都能採用、不綁定特定廠商的正式文件格式定義），Apache 2.0 授權（最常見的開源授權之一，允許自由使用、修改、商業使用，只要保留授權聲明）。官方部落格開頭的原話是：

「That's why today, we're introducing the Open Knowledge Format (OKF), an open specification that formalizes the LLM-wiki pattern into a portable, interoperable format.」

注意那個動詞：formalizes。OKF 不是另起爐灶，是把 LLM wiki 這個 pattern 正式化成一個可攜、可互操作的格式。

時序很清楚：

格式本身：極其簡單

OKF 的核心，跟我們知識庫的結構幾乎逐條對得上：

• 一個 knowledge bundle＝一個 Markdown 檔案的目錄樹
• 每個「概念（concept）」＝一個 .md 檔，檔案路徑（去掉 .md）就是概念 ID
• 每個檔案兩部分：YAML frontmatter（結構化欄位）＋Markdown 本體（自由內容）
• 唯一必填的欄位：type。建議欄位：title、description、resource、tags、timestamp
• 概念之間用標準 Markdown 連結互連——使目錄變成一張圖，而不只是一棵樹
• 保留檔：index.md（目錄清單，支援逐層展開）、log.md（更新歷史）

官方把這個設計原則叫「minimally opinionated」——刻意少管。它不規定你的 type 該有哪些值、不規定目錄怎麼分、不規定內容怎麼寫。它只要求一件事：每個概念檔有可解析的 frontmatter，且 type 非空。合規檢查就三條，一條都不多。

分發形式也隨你：git repo（官方建議）、tarball/zip、或大倉庫裡的一個子目錄。能 git clone 就能分發，能 cat 就能讀——零 SDK、零 runtime、零資料庫。

跟我們知識庫逐條對照

OKF 要求我們的知識庫狀態Markdown 目錄樹，檔案路徑即概念 ID每個條目一個 .md，路徑即分類已符合YAML frontmatter 可解析每則條目帶 frontmatter已符合必填 type 欄條目帶 type已符合標準 Markdown 互連條目間用連結互相關聯已符合保留檔 index.md / log.md有目錄結構，檔名待對齊需調整

所以「遷移」的成本是什麼？把目錄檔對齊成 index.md、更新歷史對齊成 log.md，就完成了。不是重做，是改名。

為什麼需要標準：bespoke 的代價

官方部落格把問題講得很準：

「The pattern is compelling and powerful, but each instance is bespoke. Karpathy's wiki and your team's wiki and a vendor's catalog export may all look alike (markdown, frontmatter, cross-links), but none of them are intentionally designed to cooperate.」

每家都是 bespoke（各自客製、沒有統一標準）。長得一樣，但沒有一家是刻意設計成可以合作的。代價有三個：

一、移植成本。你的知識庫建在 Obsidian 裡，同事的 agent 讀的是 AGENTS.md 格式，客戶的系統吃的是自訂 JSON——同一份知識，三套格式，三套維護。

二、agent 讀不到。第三篇講過：agent 要讀到 GitHub 上的知識庫，得先走一道 RAG。如果格式是標準的，任何支援 OKF 的 agent 都能直接讀——不用檢索，直接讀檔。

三、知識被鎖在工具裡。這正是第一篇講的「知識主權」：工具會把知識封裝在黑盒子裡。格式是標準的，知識就隨時搬得走——搬去任何一個支援 OKF 的 agent、任何一個新人、任何一個未來的生態。

官方也承認 OKF 目前的邊界：它不取代既有的 data catalog（data catalog＝組織裡集中管理「有哪些資料表、欄位、定義」的目錄系統；system of record＝權威的正式記錄來源——catalog 是那個正式來源，OKF 只是可攜的快照），也不取代領域專用的 schema（Avro、Protobuf、OpenAPI 這類「描述資料結構」的正式格式定義——OKF 只 reference 它們、不重寫）。目前也還沒有正式的「發現機制」——OKF 是被明確載入的，不是被爬蟲發現的。這些都是 0.x 版本還在長的部分。

OKF 跟 RAG：不是對立，是分工

第二篇講過 RAG（檢索增強生成，Retrieval-Augmented Generation）：把文件切小段、轉成向量（embedding，把文字轉成一串數字，讓電腦能算「相似度」）、存進向量資料庫；查詢時先從資料庫找出最相關的片段，再跟問題一起餵給模型。那 OKF 跟它到底什麼關係？

官方 FAQ 的答案很明確：「OKF 不取代 RAG，但改變了 RAG 要處理的範圍。」

逐點比較：

先解釋表裡的幾個詞：embedding＝把文字轉成向量；chunking＝把長文件切成小段；re-rank＝初檢索後再對候選片段重新排序、把最相關的排到前面；source of truth＝最終依據的單一事實來源；git diff＝版本控制工具 git 用來顯示檔案改動的功能。

三件事要注意：

第一，分工不是二選一。官方結論是並用：RAG 管「不知道在哪」，OKF 管「確定在哪且穩定」。而且 RAG 可以直接把 OKF bundle 當乾淨的 Markdown 輸入來切塊（chunking，把長文件切成小段再向量化——切塊品質直接影響檢索準確度）——格式標準化之後，RAG 的輸入品質跟著提升。

第二，量化數字目前都還是第三方整理的。官方只給定性結論（直接讀取 vs 檢索），正式的 benchmark（效能基準測試）數字還沒出。有看到過一個第三方數據：agent 之間用 OKF bundle 做交接，可以減少 28–37% 的 time-to-first-token（TTFT，從送出請求到模型吐出第一個字的時間——交接的 context 結構化、不用重新檢索，所以更快）。寫進文章的話，記得標明這是第三方數據。

第三，RAG 檢索回來的片段是孤立的。top-k 回來的幾段文字，模型看到「片段 A」跟「片段 B」，但不一定知道 A 是 B 的規範依據、A 是 B 的前置條件——片段之間沒有「關係」，只有「相似度」。OKF 的引用圖（條目之間的 markdown 連結）正好補上：agent 讀到一個條目，可以順著連結跳到相關條目，關聯性不丟。這不是語意知識圖譜（那是下一篇的事），只是最輕量的一層——「誰連到誰」。

v0.2 的信任訊號：正好打在營造業的稽核痛點上

v0.2（2026 年 7 月 24 日）新增了一組「信任訊號」，全部 opt-in（選填——不填也不會報錯，但填了 agent 就能用到），不影響 v0.1 相容性。這組欄位對我們這種產業特別對味：

• sources：provenance（出處資訊）——這個知識來自哪裡、誰寫、被引用幾次、最後修改時間。客觀訊號，不是主觀分數。
• verified：信任層級——unverified（未驗證）/ machine-confirmed（機器確認）/ human-reviewed（人工覆核）。
• stale_after：時效——這個知識多久之後視為過期。
• type: Attested Computation：驗證「某個數值是否以認可的方式算出」，帶 executor（誰算的）、attester（誰認可的）、receipt（計算憑證）三個欄位。

官方設計理由很聰明：多數時候，agent「還沒讀到本體就得決定要不要讀」。所以把信任訊號放在 frontmatter——agent 在燒 token（模型處理文字的最小單位，類似「字」但更細，一個英文詞或一個中文字約對應 1–2 個 token）讀本體之前，就能先過濾。

對營造業，這四樣東西直接對應稽核需求：

對 AEC 產業：OKF 的四個落點

把上面的拼起來，AEC（建築、工程、營造，Architecture / Engineering / Construction）產業用 OKF 建知識庫，有四個具體落點：

一、法規條目（type: Regulation）。容積計算、執照申請、防火區劃——每則條目 frontmatter 帶 resource（指向條文 URL）、stale_after（規範修訂時效）。Agent 檢核時直接讀取，精確且可追溯。這正是我們知識庫現在就在做的事。

二、工程 runbook / SOP（type: Runbook）。runbook（運維手冊，把「遇到 X 狀況該怎麼做」寫成步驟的參考文件）跟 SOP（標準作業程序）——讓 AI agent 依序執行、更新交叉引用——官方特別強調 LLM 擅長 wiki 簿記，這正是 LLM wiki 的 Lint 操作（Lint＝檢查程式碼或文件裡的小問題，這裡指檢查交叉引用有沒有斷掉、有沒有過期）。

三、驗收與指標（type: Attested Computation）。營造驗收、結構安全係數這類「數值必須以認可方式算出」的場景，v0.2 的信任訊號直接對應。

四、跨專業交接。建築師→結構→營造，多專業之間的知識交接，用 OKF bundle 作為可攜格式。這跟第三篇講的「agent 之間交接」是同一件事：結構化的交接 context，比重新檢索快得多。

回到我們那套知識庫

對照一下第三篇講的 AS2183「專案記憶體」：

而 AS2183 講者強調「記憶體存在哪裡很重要——存在一個所有工具都能讀的地方，記憶體才真正屬於專案」。OKF 就是那個「所有工具都能讀的格式」：Git 上開源、任何支援 OKF 的 agent 直接讀、人也能直接讀。

我們的知識庫目前 150+ 筆條目、119 個 fork（GitHub 上的「分岔」——別人把整個倉庫複製到自己的帳號下、可以各自修改的版本，代表這個知識庫被多少團隊複製去用了）。它照 LLM Wiki 的精神建，跟 OKF 結構一致。當 OKF 被更多 agent 生態採用——Google Cloud 自家的 Knowledge Catalog（知識目錄服務）已經能匯入 OKF 格式的資料——我們那套知識庫不用重做，任何支援 OKF 的 agent 都能直接讀。

過去各團隊都在各自造輪子——AGENTS.md、CLAUDE.md、Obsidian 資料夾、各種自訂格式。OKF 想把這一百種做法統一成一個標準。而我們是照這個標準從頭建的，往後移植成本最低。

結論：格式標準的價值，是知識主權

把三篇文章串起來：

• 第一篇講「知識庫是燃料」——經驗必須被外部化，否則人才一流動就消失。
• 第二篇講「地端模型是引擎」——燃料要能跑，得有自己的硬體跟 RAG。
• 第三篇講「知識庫是 agent 的專案記憶體」——存在外部，冷啟動就能讀，準確率 38% 到 78%。
• 本篇講「格式要有標準」——OKF 把 LLM wiki 這個 pattern 標準化，讓知識庫可移植、可被任何 agent 直接讀、人也能讀。

對建築營造業，我們的建議跟第二篇一致，現在多了一個理由：RAG + OKF 是成本效益最高的組合。你的知識庫已經是 Markdown + frontmatter 的格式，照 OKF 對齊（補 type、對齊 index.md/log.md）就能被任何支援 OKF 的 agent 直接讀；接上 RAG 就能讓模型「有憑有據」地回答。fine-tune（微調，用你自己的資料重新訓練模型的一部分參數，讓它學會特定領域的語言或風格）留給真正需要模型「學會某種風格」的少數場合。

最後回到知識主權。標準格式的價值不在於「標準」本身，而在於：你的知識不再被鎖在任何一家公司的格式裡。格式是標準的，知識就隨時搬得走——搬去任何一個 agent、任何一個新人、任何一個未來的生態。

這正是第一篇開頭講的那件事：把散落在各處的實務知識集中起來，讓經驗不再因為人才流動而流失。現在，它連格式都有標準了。

格式解決的是「怎麼把知識寫下來」這件事。下一篇，我們講另一件：知識寫下來之後，怎麼取用它、誰來判斷——語意檢索跟結構化判斷是兩條完全不同的路，成本差了好幾個量級。