OKF（Open Knowledge Format＝開放知識格式）確實由 Google Cloud 官方發布（作者 Sam McVeety／Amir Hormati，Apache 2.0 開源，約 2026-06-13）。但它不是「AI 時代網站新標準」、也不取代 HTML——它是「企業內部知識打包格式」，給你自家 AI agent 讀內部 DB schema／指標／runbook 用的。[來源：cloud.google.com/blog · GitHub GoogleCloudPlatform/knowledge-catalog]
OKF 解的是「對內」（inward）：自家 agent 讀公司內部資料。washinmura 解的是「對外」（outward）：讓全網的 AI 引用我們的公開內容。不同層、不是競品、不取代、不影響我們的 AEO。
從權威接地、圖譜規模、運行時驗證到歸因量測，OKF 在「讓外部 AI 引用你」這層完全沒有著墨，而我們整套都已落地（llms.txt 已有 6 萬次抓取實證）。[來源：CF 分析]
🎯研究目的
這一頁要回答 owner 提的三個問題，不多不少。
社群一傳「Google 出新標準」，創業家最怕兩件事：一是「我們是不是漏做了一個會被淘汰的東西」，二是「要不要立刻丟資源去追」。所以這頁的任務，是先把 OKF 查清楚，再誠實對照我們的位置：
- OKF 是真的還是社群誤傳？ 我們直接去查 Google 官方來源，把「事實」和「失真」分開標。
- 對照 OKF，我們有做到什麼？沒做到什麼？ 誠實列，不灌水也不美化。
- 我們有哪些地方做得比它好？ 這是 owner 最想看的，獨立一段、用 7 點突出。
名詞白話：OKF = Google Cloud 推的「把一包知識整理成 markdown 檔＋標籤」的格式；AEO（Answer Engine Optimization）= 讓 AI 回答引擎（ChatGPT／Perplexity 等）願意引用你內容的優化；agent = 會自己讀資料、做任務的 AI 程式。
📋計畫／查證方法：我們怎麼查證 OKF？
不靠社群轉述，直接讀 Google 官方 blog ＋ 官方 GitHub repo，逐項標「✅ 查證屬實 / ❌ 社群失真」。
| 查證項目 | 結論 | 依據（官方來源） |
|---|---|---|
| OKF v0.1 真實存在 | ✅ 查證屬實 | Google Cloud 官方 blog 發布，作者 Sam McVeety／Amir Hormati，Apache 2.0 [cloud.google.com/blog] |
| 有官方 GitHub repo ＋ 規格書 | ✅ 查證屬實 | GoogleCloudPlatform/knowledge-catalog，內含 okf/SPEC.md [github.com] |
| 格式核心：markdown 目錄＋YAML frontmatter＋type 必填＋markdown 連結成圖 | ✅ 查證屬實 | 官方 SPEC.md [github.com okf/SPEC.md] |
| 已整合進 Knowledge Catalog（前身 Dataplex） | ✅ 查證屬實 | Google Cloud 官方 blog [cloud.google.com/blog] |
| 「AI 時代網站標準／取代 HTML／每頁一個 .md」 | ❌ 社群失真 | 官方定位是「企業內部知識打包」，單位是 concept（概念）非網頁；官方樣本是 BigQuery／StackOverflow／Bitcoin 資料集（內部資料，非網站） |
社群把 OKF 講成「AI 時代的網站新標準、會取代 HTML、以後每個網頁都該配一個 .md」——這是把層搞錯了。OKF 的真實用途是：讓你自家的 AI agent 去讀公司內部的資料庫 schema、業務指標、操作手冊（runbook）。它的單位是「概念（concept）」不是「網頁」，官方拿來示範的全是內部資料集（GA4／StackOverflow／Bitcoin），從頭到尾不是給外部爬蟲或搜尋排名用的。
👉 一句話：OKF＝對內（自家 agent 讀內部資料）；washinmura＝對外（全網 AI 引用我們公開內容）。不同層、不是競品、不取代。
官方來源（可點查證）
- Google Cloud 官方發布：https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing/
- 官方 GitHub repo（含 SPEC.md）：https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf
- Search Engine Journal 報導：https://www.searchenginejournal.com/google-cloud-announces-the-open-knowledge-format/579253/
- MarkTechPost 報導：https://www.marktechpost.com/2026/06/16/google-cloud-introduces-open-knowledge-format-okf/
✅第一段：我們有做到的（對應 OKF 的元素）
把 OKF 的每個格式元素拆開，逐項對照我們在「對外 AEO」層的對應做法。結論：格式層我們已經接近、甚至更強。
| OKF 的元素 | 我們對應的做法 | 狀態 |
|---|---|---|
| markdown 內容檔（把知識寫成 .md） | ainews 內容已是 markdown；另有 llms.txt＋llms-full.txt（給 AI 看的網站導覽檔），已有 6 萬次抓取實證真的有 AI 在讀 [來源：CF 分析] | ✅ 已有 |
| YAML frontmatter（type 必填，標這包是什麼） | JSON-LD 的 @type ＋ schema.org 屬性（用全球搜尋引擎都認得的標準詞彙，語意已涵蓋且更強） | ✅ 更強 |
| markdown 連結把概念串成知識圖譜 | sameAs／cite-as 連結 ＋ 73 萬個實體的知識圖譜 | ✅ 已有 |
| vendor-neutral 開放格式（不綁特定廠商） | 多格式混搭：RSS→factfeed／AI-sitemap／帶 citation 的 FAQ schema，「多格式不漏」哲學 | ✅ 已有 |
OKF 用一個 markdown 檔做的事，我們用 JSON-LD＋schema.org＋知識圖譜＋多格式輸出在做，而且因為我們用的是全球搜尋引擎都認得的標準詞彙，語意比 OKF 的「自定 YAML 標籤」更強、更可被外部驗證。
⚠️第二段：我們沒做到的（誠實，不誇大）
這段刻意不灌水。下面 4 項裡，真正算「缺口」的很少；大部分是「OKF 對內企業層，本來就不是我們對外戰場、不需要為 AEO 而做」。
① 沒輸出 OKF-style 的 markdown bundle
OKF 把每個 concept 標準化成「一個 .md 檔＋YAML frontmatter」的純格式；我們的資料目前在 HTML／JSON-LD／DB 裡，沒有另外輸出成 OKF 風格的 markdown 包。
低成本待做 · 待採用率
資料早已結構化，要補近乎零成本，但在 OKF 採用率明朗前不急。
② 沒採「路徑即身分」慣例
OKF 用「檔案路徑＝這個概念的穩定 ID」（path = identity）的慣例；我們用的是 cite-as／canonical 來標穩定身分，沒有借用 OKF 的檔案路徑慣例。
形式借鑑 · 不同做法
同一個目的（穩定 ID）我們已用別的方式達成，差在形式。
③ 沒做對內企業知識打包
把公司內部 DB schema／業務指標／操作手冊打包給自家 agent 讀——這是 OKF 的主場，我們沒做。照做不需要（那是 OKF 對內主場），但它把對內知識結構化的紀律值得學來用在對外——見下方「對內結構→對外應用」。
不同層 · 照做不需要
對內打包不是我們對外 AEO 的戰場，但其結構化紀律可學來用在對外。
④ 沒產 OKF bundle 供 Knowledge Catalog ingest
我們沒有產出 OKF 格式的包，供 Google Cloud 的 agent 去 ingest（吃進系統）。
機會性 · 待定位明確
等 OKF 是否走向「對外」明朗後再評估。
4 項裡，①是低成本、資料已結構化可隨時補；②是形式差異（目的我們已達成）；③④本質上是「OKF 對內企業層」的事，不是我們對外戰場，不做也不影響我們的 AEO。所以請別把這段讀成「我們落後一大塊」——大部分「沒做到」是因為那根本不是同一層的事。
★第三段：我們做得比他好的（7 點）
這是 owner 最想看的一段，獨立放大。聚焦在「對外被 AI 引用」這層——OKF 在這層幾乎沒有著墨，而我們整套都已落地。
OKF 根本沒有「讓全網外部 AI 引用你」這層
我們整套都在做，且 llms.txt 已有 6 萬次抓取實證有 AI 在讀。[來源：CF 分析]
有 Wikidata Q 編號當外部錨點
OKF 的圖只是組織內部概念互連、沒有外部錨點；我們有 Wikidata Q 編號——一個 AI-agnostic、可獨立驗證的指標。
73 萬實體 / 8 萬商家的圖譜
OKF 官方樣本只有 3 個 bundle（GA4／StackOverflow／Bitcoin）；我們是生產級規模。
verify API 能即時驗證一筆引用是否成立
OKF 只是靜態檔案、沒有運行時驗證；我們能在運行時驗證一筆引用的真偽。
Worker 量測管道能算「哪個 AI 真引用了、導多少流」
靠 og:url 歸因；OKF 完全沒有量測歸因層。
用全球都認的 schema.org
OKF 被業界批評「只有容器、沒有共同語意」；我們用 schema.org，外部機器直接看得懂。
同一份內容多格式呈現 ＋ 7 層內容骨架
OKF 只有單一 markdown；我們把同一份內容用多種格式輸出，哪個 AI 偏好哪種格式都接得住。
OKF 解的是「把一包知識整齊地交給自己的 agent」；我們解的是「讓全世界的 AI 都能找到、信任、引用、並把人導回我們」。後者需要外部錨點（Wikidata）、運行時驗證（verify API）、歸因量測（Worker）——這些 OKF 都沒有，因為那不是它要解的問題。在「對外被 AI 引用」這條賽道上，我們每個維度都比它深。
🚀值得優先佈局 — 從 OKF 學起來用在對外
OKF 是對內格式，但它的做法值得我們學來用在對外內容（低成本對沖，呼應「寧願多做不漏掉」）。
OKF 把 Karpathy 的 LLM-wiki 模式標準化＋掛上 Google 背書。它的格式做法值得學來用在我們的對外內容，當一筆低成本對沖。下面按 ROI 排序，標清楚先做哪些、哪些只是監控。
🔄 OKF 對內結構 → 我們對外應用
OKF 把對內知識拆成 3 種 typed concept（table／metric／runbook），每一種都能學來用在我們對外的 entity 內容——舉一反三，從既有發展出新的 AI 格式。
| OKF 對內 concept | 學來用在對外 | 我們現況 |
|---|---|---|
| table / schema（DB 結構） | 每個 entity 的「屬性 schema」：把 facts 標準化成 typed 欄位＋型別＋單位＋來源，像一份資料字典。 | JSON-LD 有但散 可更形式化 |
| metric（業務指標定義） | entity「指標卡」：財務／流量／評分各帶定義＋單位＋時間窗＋出處。 | ＝我們 Fact Density 可做成標準指標 |
| runbook（操作手冊） | ★ 給 agent 的「使用／驗證手冊」：機器可讀的「如何驗證／引用／使用這個 entity」。 | 幾乎沒人對外做 而我們有 verify API 可接 |
OKF 的 runbook 概念（教 agent 怎麼用一包知識）幾乎沒有對外網站在做。給每個 entity 配一份機器可讀的「如何驗證／引用我」說明（接我們既有的 verify API）＝主動教 AI agent 正確引用我們，把 OKF 對內的 runbook 翻譯成對外的全新格式（從既有發展新 AI 格式）。
ROI 排序清單
| # | 要做的事 | 做法與理由 |
|---|---|---|
| 1 | 每個 entity 輸出「concept-bundle」目錄 | 每個實體輸出 index.md（核心）／facts.md（屬性）／news.md（報導）／relations.md（關係）四檔。73 萬資料已結構化，補這份近乎零成本，讓 entity agent 原生可讀。 |
| 2 | path = identity：每 entity 穩定 slug 路徑 | 如 /entity/taiwan-semiconductor，同一路徑給人看的是網頁、給 agent 吃的是 markdown。延伸我們既有的 cite-as／canonical 慣例，形式上對齊 OKF。 |
| # | 要做的事 | 做法與理由 |
|---|---|---|
| 3 | typed links 寫進 frontmatter | 把 IDA 的關係資料（供應鏈／持股／分支）變成 typed edges（relations:[{target,type}]），讓 agent 真的懂關係網。OKF 樣本沒有真實 entity 關係，我們有 73 萬＝能輾壓的點。 |
| 4 | llms-full.txt 升級成 markdown＋frontmatter | 升級後就是一份 OKF-shaped mirror，既有檔案小改即可對齊 OKF 形態。 |
| # | 要做的事 | 做法與理由 |
|---|---|---|
| 5 | 產 OKF bundle 供工具鏈 ingest | 產出 OKF bundle 供 Knowledge Catalog／任何 agent 工具鏈 ingest，等採用率信號再做。 |
把 73 萬已驗證 entity 包成 OKF bundle，任何人的 AI agent 都能直接 ingest → 我們可變成「agent 時代的可驗證實體知識源」。🔮 這是一條對外的新分發管道（B2B／agent 生態），不只是防守，是進攻。
若 agentic web 往「markdown bundle 給 agent」標準化，而我們只有 HTML／JSON-LD，別人的 agent 工具鏈可能覺得我們比對手難吃。🔮 近期機率低，但對沖成本極低＝正是「寧願多做不漏掉」該做的。
🎯結尾：行動建議（按 ROI）
查清楚之後，理性的下注方式。重點是「不為一個 v0.1 的 PoC 大動干戈」，但保持監控。
不為 OKF 做大動作
官方自稱 v0.1（概念驗證階段），社群「網站標準」說法已查證失真。沒有理由為它丟資源、改架構。
每季監控一次
看 Google 會不會把 OKF 從「對內」推向「對外」。一旦定位變了，再重新評估。
機會性做 OKF-mirror 實驗
我們資料已結構化，產一份 OKF bundle 近乎零成本；但在沒有採用率前不急著做。
OKF 真實、值得知道，但它補的是「對內企業知識」（不是我們的戰場）；在「對外被 AI 引用」這層，我們每一個維度都比它深。所以：知道它、監控它，但不為它改變方向。