同一个产品，页面说支持某种接口，下载资料没有这项，销售又说需要定制。这样的冲突靠增加品牌介绍解决不了。先选一条重要事实，建立来源、条件和版本，再决定它可以出现在哪些内容中；不必一开始就采购复杂的知识图谱系统。
最小实现：一条事实不是一句广告语
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，假设资料升级，先保持旧公开内容不动，列出所有引用位置。
- 确认变化影响的是条件、数值、名称还是仅排版。仅排版变化不应编造产品升级消息。
- 将旧事实标为待复核，相关内容不继续自动复用；保留旧版适用范围。
- 更新产品页、资料下载和确实引用该事实的文章，并让销售确认话术。
- 抽查一个买家问题：现在各入口能否给出一致、带条件的说明。
需要建立独立数据库吗？
未必。几十条重要事实可以从受控表格开始，先验证责任和版本流程。只有维护量、权限与系统连接确实需要时，再评估数据库或检索系统。
没有公开报告能写吗？
可以说明已核对的公开范围和评估步骤，但不能暗示读者已看到完整证据。保密文件保持权限，需要具体结论时转入授权沟通。