Open Knowledge Format（OKF）是什麼？Google 新標準與它在 GEO 版圖的位置

先說結論：OKF 是「知識的打包格式」，不是新的 SEO 標籤

最近開始有人轉 Google 發表的 Open Knowledge Format（OKF） 給我們，問「我們網站要不要趕快上 OKF」。先把結論講白：

OKF 是一套把知識打包、讓人跟 AI agent 都讀得懂的檔案格式，它最初要解決的是「組織內部知識散落各處、每個 AI agent 都得自己重拼一次上下文」的問題——不是一個你貼在行銷官網上、這週就能讓 ChatGPT 多提到你的標籤。

用 Google 自己的話講白一點：「把內容打包成一個 bundle，不會讓你這週的排名或 AI 能見度動起來。」它真正的價值是方向性的：當 AI agent 哪天來找資料，你的知識「早就整理好、攤在那裡好讀」。所以這篇不是要你今天就去重做網站，而是幫你搞懂這東西在整張 GEO 版圖的哪個位置、跟你已經在做的事是什麼關係。

OKF 到底是什麼

2026 年 6 月，Google Cloud 的 Data Analytics 團隊（Sam McVeety、Amir Hormati）發表了 OKF v0.1。它把近期浮現的「LLM-wiki」模式正式化——這個概念由 Andrej Karpathy 提出：與其讓 AI 每次都重新翻一堆文件，不如給它一座共享的 Markdown 知識庫，讓它隨用隨長、順手幫你維護那些煩人的交叉引用。

技術上，OKF 刻意做得很薄：

• 就是 Markdown — 任何編輯器打得開、GitHub 直接 render、搜尋工具索引得到
• 就是一堆檔案 — 可以打包成 tarball、放 git、掛在檔案系統上
• 就是 YAML frontmatter — 一小組可查詢的結構化欄位

一個概念 = 一個 Markdown 檔，檔案路徑就是這個概念的身分。每個檔案頂部用 YAML 宣告幾個欄位（只有 type 是必填）：

---
type: BigQuery Table
title: Orders
description: One row per completed customer order.
resource: https://console.cloud.google.com/...
tags: [sales, revenue]
timestamp: 2026-05-28T14:30:00Z
---

# Schema
| Column | Type | Description |
|--------|------|-------------|
| `order_id`    | STRING | 全域唯一訂單編號 |
| `customer_id` | STRING | FK 連到 [customers](/tables/customers.md) |

注意最後一行——檔案裡用 Markdown 連結指向另一個概念檔。這就是 OKF 比「一堆散落文件」多出來的關鍵：知識之間的關係被保留下來了，不只是一頁一頁的內容，還有「這頁跟那頁怎麼連」。

它解決的是哪個問題（這點最多人誤會）

把欄位看一眼你大概也發現了：BigQuery Table、資料表 schema、console 連結——OKF 的第一現場是企業內部的資料與知識，讓組織裡的 AI agent 拿到一致、可信的上下文，而不是各問各的、各拼各的。

所以如果你問的是「我的行銷官網要不要上 OKF」，誠實的答案是：就目前 v0.1 的設計目標而言，它瞄準的不是你的對外網站。 沒有任何一家主流 AI 引擎宣布過「我會去爬公開網站上的 OKF bundle，然後拿來決定要不要引用你」。把這件事講清楚，是因為這個區別會直接影響你要不要現在投時間。

那它跟 GEO、跟被 AI 引用有沒有關係

有，但是是方向上的，不是這一季的戰術。

把鏡頭拉遠看，「機器可讀的網路」這幾年是一層一層疊起來的，每一層回答不同的問題：

真正值得注意的，是 OKF 跟我們一直在強調的事同一個直覺：AI 不是只看你單一頁面寫得多漂亮，而是看它能不能把你當成一個前後一致、彼此連得起來的知識實體來理解。OKF 把「頁與頁之間的關係」做成格式的一部分，這跟我們談品牌知識系統、談實體一致性是同一條路上的東西。

但請把這句記牢：OKF 是 v0.1，採用度還是未知數，公開網站這塊更是還沒成形。 它是一個值得追蹤的方向，不是一個「現在不做就輸了」的待辦。誰要是拿它來嚇你「快花錢重做網站不然 AI 找不到你」，那是把次數很少的東西講成體質地基——順序剛好反了。

我們現在有沒有「相關」的東西

有，而且不少。OKF 講的這層，其實是你已經在做或該做的 GEO 基本功的延伸：

• llms.txt — 純文字事實源 / AI 爬蟲的路標，見SSR vs SPA：AI 引用的渲染問題
• 結構化資料（JSON-LD） — 作者親口宣告級別的事實，見結構化資料對 LLM 引用的影響
• Agent 就緒度 — llms.txt、MCP server 等新規範在 GEO 12 維裡的定位，見GEO 各維度怎麼互相影響
• 品牌知識系統 — 把分散的品牌事實整理成 AI 讀得懂的一致實體，見GEO 品牌知識系統

OKF 不是憑空冒出來的新工種，它是把這些「給機器讀的整理工作」往更正式、更可攜帶的方向再推一格。

所以現在該做什麼

不該做的：為了一個 v0.1 標準、在還沒有任何主流引擎承諾消費它之前，就把網站打掉重練去產 OKF bundle。那是追熱度，不是做體質。

該做的，剛好就是那些現在就有回報、又讓你哪天真的「OKF-ready」的同一批基本功：

1. 確認 AI 爬蟲真的抓得到你的內容（純前端渲染的站，crawler 常常只拿到一包空 div）
2. 公司是誰、做什麼、有哪些實績——這些事實在你站內外講得一致
3. 內部連結與主題關係清楚，讓「頁與頁怎麼連」本來就成立
4. 結構化資料正確、跟內容對得上（亂掛反而扣分）

這些做紮實了，等哪天主流引擎真的開始吃這類知識包，你是「早就整理好、等人來拿」，而不是臨時抱佛腳。而且這四件事不是一次性專案——AI 引擎、你的內容、競爭者都在動，它是要持續盯著養的體質工程。這也是為什麼我們把它做成持續監測與託管：你想自己照這個方向做完全 OK，只是手動每週盯到後面真的會累死而已。

OKF 值得你知道它存在、知道它在版圖的哪一格。但別把「知道一個新標準」誤當成「現在就得為它動工」——把地基顧好，新標準來的時候你早就站在對的位置了。