同一個產品，頁面説支持某種接口，下載資料沒有這項，銷售又説需要定製。這樣的衝突靠增加品牌介紹解決不了。先選一條重要事實，建立來源、條件和版本，再決定它可以出現在哪些內容中；不必一開始就採購複雜的知識圖譜系統。
最小實現：一條事實不是一句廣告語
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，假設資料升級，先保持舊公開內容不動，列出所有引用位置。
- 確認變化影響的是條件、數值、名稱還是僅排版。僅排版變化不應編造產品升級消息。
- 將舊事實標為待複核，相關內容不繼續自動複用；保留舊版適用範圍。
- 更新產品頁、資料下載和確實引用該事實的文章，並讓銷售確認話術。
- 抽查一個買家問題：現在各入口能否給出一致、帶條件的説明。
需要建立獨立數據庫嗎？
未必。幾十條重要事實可以從受控表格開始，先驗證責任和版本流程。只有維護量、權限與系統連接確實需要時，再評估數據庫或檢索系統。
沒有公開報告能寫嗎？
可以説明已核對的公開範圍和評估步驟，但不能暗示讀者已看到完整證據。保密文件保持權限，需要具體結論時轉入授權溝通。