題幹與適用場景
公司有多個代理持續產生指標定義、運行手冊與表結構。請設計一個基於 OKF v0.2 的知識目錄，說明如何記錄來源、產生者、驗證者、過期狀態與計算證明，並確保 v0.1 消費者仍能讀取。
Google Cloud 於 2026 年 7 月發布 OKF v0.2 介紹。Open Knowledge Format 使用 Markdown 檔案與 YAML frontmatter 表達可由人與代理共同維護的知識；v0.2 將 provenance、trust、lifecycle 與 attestation 變成可查詢訊號，同時保持增量、向後相容。它是資料格式與治理約定，不是集中式執行時或存取控制系統。
面試官考察點
面試官會關注你是否區分「誰產生」與「誰驗證」，是否用來源 ID 做逐條聲明歸因，能否把 freshness 與 lifecycle 變成可執行篩選，是否理解信任等級是消費方推導的建議訊號而非權限控制。也要說明 v0.1 欄位回退、寫入冪等、版本遷移、惡意內容與計算證明的驗證邊界。
回答前需要釐清的問題
- 知識包由哪些生產者寫入，誰擁有最終人工審核權？
- 消費者需要過濾未驗證、過期、棄用還是僅特定信任等級的概念？
sources是否必須支援外部 URL、包內路徑與範圍描述？- attested computation 的執行環境、輸入版本與驗算資源是什麼？
- v0.1 消費者是否只能讀取舊欄位，還是需要得到遷移提示？
30 秒回答框架
「我會把 OKF 檔案當作可版本控制的知識事實，生產、驗證、索引與消費分開。每個概念記錄來源、產生者與時間、獨立驗證記錄、狀態與過期時間；逐條聲明透過穩定的 sources[].id 歸因。消費者先在 frontmatter 上按狀態、信任等級與 freshness 篩選，再讀取正文。v0.2 新欄位全部可選，讀取器保留未知鍵，並把 timestamp 回退到 generated.at、正文引用回退到 sources。信任等級由消費者推導，不能取代授權；計算證明必須綁定輸入、程式碼與可重算證據。」
分步驟深入解答
1. 設計最小概念檔案
每個檔案只表達一個可維護概念，保留 type、標題、描述、資源與標籤等基礎欄位。frontmatter 放需要索引與篩選的中繼資料，正文放解釋、模式與示例查詢。目錄與 Git 版本控制提供變更、審查與回復能力，執行時不強依賴中心註冊表。
2. 建立來源與逐條歸因
sources 記錄概念產生所依據的外部文件、包內路徑或範圍描述，並為來源附加作者、使用次數與更新時間等客觀訊號。正文聲明用腳註引用穩定的來源 ID，而不是 sources[0] 這類位置索引；清單重排時仍能正確歸因，消費者也能獨立計算可信度。
3. 分離 generated 與 verified
generated 描述目前內容由誰、何時產生；verified 描述誰、何時根據來源或資源確認內容。沒有 verified 是未驗證，只有機器確認可推導 machine-confirmed，包含人工確認者可推導 human-reviewed。等級是消費方的建議訊號，不應直接當作存取控制或合規結論。
4. 管理 freshness 與 lifecycle
用 status 表示穩定、草稿或棄用等生命週期，用 stale_after 或等價時間表達內容何時需要複查。索引器按目前時間、來源更新時間與業務規則計算 freshness；過期不等於錯誤，消費者應決定隱藏、降權或要求重新驗證，並保留原因。
source -> generated -> verified -> trust tier
-> status/stale_after -> consumer filter -> body read5. 處理 attested computation
對指標或計算結論，記錄計算定義、輸入資源版本、執行者、執行時間與驗算結果。attestation 證明「按聲明的方法得到這個值」，不自動證明輸入正確或業務解釋完整。執行器與打包方式不由 OKF 規定，團隊必須在治理層固定環境、依賴與重播證據。
6. 保持 v0.1 相容
v0.2 是增量、向後相容的小版本；未採用新欄位的 v0.1 包仍然有效。讀取器保留自訂鍵與未知擴充，優先讀取 generated.at，缺失時回退舊 timestamp；正文 sources 不存在時可讀取舊的 # Citations 約定，並產生遷移警告。寫入器應提供版本化遷移而非靜默改寫歷史。
7. 建構可信消費管道
生產器提交檔案，校驗器檢查 frontmatter、來源 ID 與時間格式，驗證器寫入獨立確認記錄，索引器物化可過濾欄位，消費者在載入正文前按策略篩選。為重複產生設定概念 ID 與內容雜湊，使用冪等寫入與審查佇列。對遠端連結、Markdown、腳註與代理產生內容執行轉義、允許清單與稽核。
高品質示範回答
我會把 OKF 包當作 Git 中可審查的知識事實，每個檔案表達一個概念，frontmatter 放可篩選中繼資料，正文放解釋與示例。來源用帶穩定 ID 的 sources 表示，正文腳註按 ID 做逐條歸因。generated 與 verified 分開記錄生產者與確認者，消費方據此推導未驗證、機器確認或人工複核等級，但不把等級當作權限控制。status 與 stale_after 驅動生命週期與 freshness 篩選，過期內容可降權或進入複核佇列。計算結論附帶輸入版本、執行環境、方法與驗算證據，明確 attestation 不等於輸入正確。v0.2 讀取器保留未知鍵，支援 generated.at 與舊 timestamp、sources 與舊引用的回退，並用遷移警告保護 v0.1 相容。最後以冪等提交、雜湊、審查佇列與安全渲染把生產、驗證、索引與消費隔離開。
常見錯誤
- 把驗證者和產生者合併 → 無法表達獨立確認 → 分別記錄
generated與verified。 - 把信任等級當權限 → 建議訊號被誤用為安全控制 → 授權仍由身分、策略與資源系統決定。
- 使用
sources[0]做歸因 → 清單重排會錯配來源 → 用穩定的來源 ID 與腳註鍵。 - 把過期視為錯誤 → 消費策略過於粗暴 → 由消費者決定隱藏、降權或複核。
- 聲稱 attestation 證明事實正確 → 忽略輸入與業務語意 → 綁定輸入版本、方法與驗算邊界。
- 遷移時靜默刪除舊欄位 → v0.1 消費者失效 → 採用回退、警告與版本化寫入。
追問及應對
為什麼不在格式裡規定統一信任分數？
分數依賴領域、消費者與時間，寫入格式後容易失真且不可遷移。格式記錄可驗證訊號，消費者根據作者、更新時間、驗證者與使用情況推導本地策略。
一個概念被兩個獨立驗證者確認怎麼辦？
保留多條 verified 記錄及其時間與主體，消費方可按人工、機器、領域或最近確認策略組合；不要覆蓋較早證據。
如何避免 stale_after 被任意延後？
限制誰能修改該欄位，要求來源或業務負責人批准，並在稽核中記錄舊值、新值、理由與驗證證據；刷新時間不應取代內容複核。
v0.1 消費者看不懂新欄位怎麼辦？
它應忽略未知欄位並繼續讀取基礎欄位；提供相容寫入、舊欄位回退與遷移警告。不要把 v0.2 必填擴充寫入所有舊包。
代理產生的指標如何進入高信任層？
先記錄產生來源與計算證明，再由獨立驗證流程確認輸入、方法與結果；人工複核或業務流程滿足條件後，消費者才可推導更高信任等級。