同一個產品，頁面說支援某種介面，下載資料沒有這項，銷售又說需要定製。這樣的衝突靠增加品牌介紹解決不了。先選一條重要事實，建立來源、條件和版本，再決定它可以出現在哪些內容中；不必一開始就採購複雜的知識圖譜系統。
最小實現：一條事實不是一句廣告語
record_id: FACT-018
subject: 產品系列P的介面支援範圍
claim: 以已稽核的介面清單為準
conditions: 僅適用於指定配置與韌體版本
source_document: DOC-018
revision: B
owner: 產品資料負責人
visibility: public
status: approved
review_trigger: 韌體或配置變更這裡最重要的不是 YAML 語法，而是把 claim 與 conditions 分開。只複製“支援某介面”會丟掉條件，複製整份內部檔案又可能越過公開許可權。visibility 決定能否公開，status 決定是否已經稽核；兩者不能互相替代。具體可以用表格或現有CMS欄位實現，不必照搬這個格式。
資料關係先畫清楚，再考慮自動化
1原始依據已獲授權的資料檔案及其版本，由企業確認覆蓋範圍。
2事實記錄編號、主張、條件、狀態與責任人分開儲存。
3公開表達產品頁引數、問答和服務說明按各自任務引用事實。
4溝通與修訂銷售回覆使用相同條件；資料變更後定位所有相關頁面。
| 欄位 | 公開頁面 | 內部記錄 |
|---|---|---|
| 產品與版本 | 讀者判斷適用性需要時展示 | 保留穩定標識與歷史關係 |
| 條件與限制 | 影響理解時必須說明 | 保留稽核依據 |
| 客戶圖紙 | 未獲授權不公開 | 按許可權處理，不用於公共生成 |
| 稽核人聯絡方式 | 無必要不公開個人資訊 | 按企業職責記錄 |
| 來原始檔 | 可公開且有幫助時連結 | 記錄原始版本及訪問範圍 |
把一句含糊主張改成可核對的回答
公開表達要足夠清楚，但不必把內部流程全部搬上網。企業法律名稱、品牌、產品系列與服務範圍分別有各自位置，不能在所有段落反覆堆疊同一關鍵詞。結構化資料只描述頁面確實展示的內容，不把未稽核能力放進不可見標記。
做一次“版本B改為C”的演練
- 選 FACT-018，假設資料升級，先保持舊公開內容不動，列出所有引用位置。
- 確認變化影響的是條件、數值、名稱還是僅排版。僅排版變化不應編造產品升級訊息。
- 將舊事實標為待複核，相關內容不繼續自動複用；保留舊版適用範圍。
- 更新產品頁、資料下載和確實引用該事實的文章，並讓銷售確認話術。
- 抽查一個買家問題：現在各入口能否給出一致、帶條件的說明。
需要建立獨立資料庫嗎？
未必。幾十條重要事實可以從受控表格開始，先驗證責任和版本流程。只有維護量、許可權與系統連線確實需要時，再評估資料庫或檢索系統。
沒有公開報告能寫嗎？
可以說明已核對的公開範圍和評估步驟，但不能暗示讀者已看到完整證據。保密檔案保持許可權，需要具體結論時轉入授權溝通。