把产品资料拆成两层：事实层（型号、参数、认证、谁能供，只有对错）和表达层（文案、排版、卖点顺序，只有好坏）。事实只存一处，页面、JSON-LD、报价单、询盘回复全部从它派生。判断你有没有真的建立事实源：当页面和文档不一致时，你会去改哪一边？改文档，文档才是事实源；改页面，那文档只是笔记。

事实与表达分离：为什么产品资料要单独存一层

三件看起来无关的糟心事

第一件：客户按你网站上的参数下了单，生产的时候发现做不出来。翻回去查，那个数字是半年前从供应商的旧版规格书上抄的，供应商早就改版了。

第二件：客户在询盘里附了一张你官网的截图，问那张 CE 证书还有效吗。你查了一下，两个月前就过期了。

第三件：同一个型号，品类页上写最大流量 120，产品详情页上写 110。哪个对？你也得去问供应商。

这三件事通常被归因成“资料没整理好”、“人手不够”、“该做个系统了”。都不对。它们是同一个结构问题的三种表现。

病根：你没有区分两类完全不同的东西

产品资料里混着两类东西，它们的性质完全相反。

第一类是事实：这个型号存在吗、最大流量是多少、壳体什么材质、有没有 ATEX 认证、证书哪天到期、哪家供应商能做、多久能交货。

事实只有对错。120 就是 120，不存在“这个 120 写得更漂亮一点”。

第二类是表达：产品页开头那段介绍怎么写、卖点按什么顺序排、用哪张图、FAQ 放几条、CTA 写“Request a Quote”还是“Get Pricing”。

表达只有好坏，没有对错。换一种写法可能转化率更高，但不存在“写错了”。

现在看糟心事的成因：当事实和表达混在同一个页面里，改一次事实的成本，等于改所有装着这个事实的表达。

一个参数出现在 5 个页面里，改它就要改 5 个地方。人的本能反应是只改最重要的那个，或者干脆不改。于是资料开始分叉，分叉之后就没有真相了——第三件糟心事就是这么来的。

一个问题，判断你有没有真的建立事实源

很多人会说“我有整理啊，我有个 Excel / 有个 Notion 库 / 每个产品一个文件夹”。

有文档不等于有事实源。用这个问题检验：

当页面和你那份文档不一致时，你会去改哪一边？

• 你会去改文档，让文档跟上现实 → 那页面才是事实源，文档只是一份过时的笔记
• 你会去改页面，让页面跟上文档 → 那文档才是事实源

绝大多数人的真实答案是第一种。这就是为什么整理了资料还是不断出错：那份资料从来没有成为事实源，它只是事实的一份副本，而且是过时得最快的那份。

事实源的定义不是“我把资料写在这里了”，而是“任何一处和它不一致都算 bug”。

这个定性很关键。定成 bug，就会有人去修；定成“资料没同步”，就永远排在待办最后一行。

分离之后长什么样

把事实抽出来单独存一层，结构就变了：

                  ┌─────────────────────────┐
                  │      产品事实层          │
                  │  型号 / 参数 / 认证       │
                  │  谁能供 / 什么价 / 多久交  │
                  │      （只存一处）         │
                  └────────────┬────────────┘
                               │  派生
        ┌──────────┬───────────┼───────────┬──────────┐
        ▼          ▼           ▼           ▼          ▼
   网站产品页   JSON-LD     报价单     询盘回复    规格书 PDF
   （表达）    结构化数据   （表达）    （表达）    （表达）

关键不在图好看，在于三个后果：

一、事实只有一个维护点。 供应商改版了，你改事实层一处，所有出口下次生成时自动带上新值。

二、表达可以随便重写。 想换文案风格、换页面结构、换卖点顺序，尽管改——因为你动的东西里没有事实，改坏了最多是难看，不会变成对外发错参数。这一点在用 AI 批量改写文案的时候尤其重要。

三、对内和对外不是两套系统。 这一条最容易被忽略，但它决定了这一层值不值得建。

客户来问 CP-100 能不能做，你需要的是“哪家能供、成本多少、多久交货”。这些和网站上要展示的“最大流量、材质、认证”来自同一份事实，只是走了不同的出口——一个出口筛掉了成本和供应商名，另一个出口筛掉了营销文案。

所以建事实层不是“为了做网站多干一件事”，它同时解决了你日常翻微信找报价的问题。反过来说也成立：如果你建完了事实层，回客户询盘的时候还在翻微信记录，说明这一层没真正建成——它只服务了对外那一个出口。

和关键词注册表的关系：两个注册表

如果你跟着这个系列做过中央关键词注册表，会发现这两件事结构上很像，但管的东西正好互补。

关键词注册表（需求侧事实）        产品事实层（供给侧事实）
         ↓                                ↓
    客户在搜什么                      我们能供什么
         └──────────── 交集 ───────────┘
                       ↓
             该建哪些页面 / 页面上写什么数字

• 注册表管「说什么词」：这个词归哪个页面、意图属于商业还是工程、哪些词绝不能出现在这一页
• 事实层管「说什么数」：这个型号的流量是多少、认证到哪天、哪家能供

两边缺一样都不行。只有注册表，你知道该建一个 “Magnetic Drive Pump for Chemical Transfer” 的页面，但页面上的参数只能靠编。只有事实层，你有一堆准确的参数，但不知道该建哪些页面、每页该主打哪个词，多半会建出一堆互相抢词的页面。

pSEO 的组合矩阵其实就是这两者的交集，只是那一篇里的产品维度只到品类级（Centrifugal Pump 这种），没到型号级。事实层补的正是型号级和供应商级这两层。

边界：事实层不管什么

一个东西之所以有用，往往是因为它拒绝了很多东西。事实层要拒绝四类：

不管文案。 产品介绍怎么写不进去。哪怕是“这款泵特别适合腐蚀性介质”这种听着很像事实的句子——它是表达，因为它没有可验证的标准。可以进去的是“壳体材质 SS316”。

不管关键词。 那是注册表的活。事实层不知道也不需要知道 SEO。

不管客户和订单。 谁问过、报了多少、成交没成交，那是 CRM。混进来之后，事实层会迅速膨胀成一个什么都装的杂物间。

不管你的经验判断。 “这家供应商比较难沟通”、“这个型号的客户一般砍价很狠”，这些确实有价值，但它们不是事实，是笔记。一旦开始往里塞，事实层就退化成了又一个笔记本——而笔记本没法被自动派生成页面。

判断标准很简单：这条信息能不能被第三方验证对错？ 能，是事实；不能，是表达或笔记，另外存。

三个反模式

反模式一：直接把网站当事实源。

“我参数都在页面上，改页面就行了。” 问题在页面会被润色、被 AI 改写、被换模板。任何一次改动都可能顺手动掉一个数字，而你无法区分“这次改的是文案”还是“这次改的是事实”。事实必须待在一个不因为审美而变动的地方。

反模式二：一上来就上向量库做 RAG。

现在提到“知识库”很多人第一反应是切片、embedding、语义检索。产品事实的查询模式恰恰相反：你要查的是“CP-100 的最大流量”，这是精确查询，答案唯一，数据量也小（几百条量级）。用语义相似度去召回一个必须精确的答案，等于把一件确定的事变成了概率问题。

RAG 解决的是“我不知道答案在哪份文档里”。事实层解决的是“我知道答案在哪个字段里”。别用前者的工具解决后者的问题。

反模式三：每个产品一个 Word 文档。

文档是给人读的，字段是给机器派生的。一份 Word 里的“最大流量：120 m³/h”没法自动变成页面上的表格行、JSON-LD 里的属性、报价单里的一栏。文档不是事实，字段才是。

落地要点

思路讲完了，落地只有三个决定：

一、先用文件，别上数据库。 几百条产品事实用文本文件（YAML / JSON）存在 Git 里就够，理由是能 diff、能回滚、AI 能直接读写、构建时能校验，成本为零。什么时候该升级：多人同时改、要给不懂技术的同事填表、条目过千且需要复杂筛选。

二、事实和表达物理分开放。 事实文件和页面文件不在同一个目录，不在同一次编辑里改。

三、可公开的事实和内部的事实也要分开。 供应商名、出厂价这类东西一旦跟着构建流程上线就收不回来了，这件事的具体做法见本模块的两种死法那一篇。

具体的文件结构、字段模板和校验规则，都在这个模块最后的产品事实层工具箱里，可以直接抄。

小结

• 产品资料里混着事实（只有对错）和表达（只有好坏），混在一起时改事实的成本等于改所有表达
• 检验你有没有事实源：不一致时你会改哪一边。会去改文档的，说明页面才是事实源
• 事实源的定义是「任何一处和它不一致都算 bug」，定性成 bug 才会有人修
• 分离之后：事实一个维护点、表达可以放心重写、对内查询和对外发布是同一份事实的两个出口
• 事实层拒绝四类东西：文案、关键词、客户订单、经验判断
• 别用 RAG 解决精确查询，别把 Word 文档当事实

→ 下一篇：AI 的边界划在哪：以「错了能不能被发现」为唯一标准