供应商和产品是多对多关系，供应商名不能写进产品条目里。判断一条信息该挂在哪层用一个问题：换掉供应商，这条信息会不会变？不变的（型号、参数、认证）属于产品；变的（成本、MOQ、交期）属于这一对关系，不属于任何一方；只跟供应商有关的（工厂地址、产线、联系人）属于供应商。此外要按腐烂速度分层：参数以年计、认证 2-3 年、报价数周至数月、库存数天，混在一起存会让整份资料的可信度被最快腐烂的那项拖垮。

供应商与产品的关系怎么想：多对多、角色与腐烂速度分层

从一个具体的麻烦说起

你有一个型号 CP-100，A 厂在做。你在产品资料里写：

型号：CP-100
供应商：A 厂
出厂价：¥3,200
交期：25 天

看起来很合理。三个月后出现两件事：

第一件：A 厂产能排满，你找了 B 厂做同款，价格 ¥3,050，交期 30 天。这条记录该怎么写？

第二件：A 厂还给你供另外 12 个型号。你要查“A 厂总共给我供哪些东西”，只能把所有产品条目翻一遍。

这是多对多关系：一个型号可能有主供、备供、打样三家；一家供应商又供你十几个型号。

“供应商及对应的产品资料”这句话里，最难处理的其实是「对应」这两个字——它不是一个字段，是一层独立的关系。

一条判据：换掉供应商，这条信息会不会变

要把信息分对层，不需要背字段清单，只要问这一句：

如果我换一家供应商做同一个型号，这条信息会不会变？

三种答案，三个归属：

不会变 → 属于产品

型号名、结构形式、最大流量、壳体材质、外形尺寸、产品认证。这些是产品自身的属性，谁做都一样（如果不一样，那就不是同一个产品，见后面）。

会变 → 属于这一对关系，不属于任何一方

出厂价、起订量、交期、最小包装、付款条件、这家给你的折扣。

这些既不属于产品也不属于供应商——它们属于“你和这家供应商就这个型号达成的条件”。这是最容易放错的一类：塞进产品里，第二家供应商就没地方放；塞进供应商里，同一家供应商不同型号的价格就打架了。

只跟供应商有关 → 属于供应商

工厂地址、产线情况、资质证书、联系人、沟通习惯、账期。这些不随产品变。

这条判据的好处是它能处理你没见过的信息。碰到一条不知道该放哪的资料，问一遍就有答案了，不用回来查表。

分完之后是三层：

   产品事实            供货关系               供应商
  ┌────────┐        ┌──────────┐        ┌──────────┐
  │ CP-100 │◄───────┤ 价 / MOQ  ├───────►│  A 厂     │
  │ 参数    │        │ 交期 / 角色│        │ 地址/资质 │
  │ 认证    │        └──────────┘        └──────────┘
  └────────┘        ┌──────────┐        ┌──────────┐
       ▲            │ 价 / MOQ  │        │  B 厂     │
       └────────────┤ 交期 / 角色├───────►│ 地址/资质 │
                    └──────────┘        └──────────┘

中间那一层是关键。很多人的资料结构里没有中间层，所以第二家供应商一出现就崩。

一个边界情况

“如果两家做出来的参数不一样怎么办？” —— 那就不是同一个产品。

这种情况比想象中常见：型号名撞了，实际结构和性能有差异。这时候正确处理是拆成两个产品条目，而不是在一个条目里放两套参数。硬塞在一起的后果是你永远不知道页面上展示的是哪一家的性能。

三类供应商角色，信息需求不一样

关系层里有一个字段值得单独说：角色。

同一个型号的三家供应商，你需要知道的东西完全不同：

不区分角色的后果是：你给每家都建一套完整字段，然后发现备供和打样那两套永远填不满。填不满的字段会持续给你“资料没做完”的心理负担，最后你会放弃维护整个结构。

字段该按角色的实际需要来设，不是按“最完整的那种情况”来设。

腐烂速度分层：这一篇最该记住的一条

前面讲的是信息属于谁。这一节讲的是信息能活多久——这一条比前面重要，但几乎没人在设计资料结构的时候考虑它。

产品资料里的东西，有效期差了两个数量级：

把它们混在一份资料里存，会发生一件很隐蔽的事：

整份资料的可信度，等于其中腐烂最快那一项的可信度。

因为你打开这份资料的时候，没法只信一半。看到价格是三个月前的，你会顺带怀疑旁边的参数是不是也过期了——即使参数三年都没变。一份“部分可信”的资料，在使用的时候等于不可信，你还是会去翻原始文件确认。

由此得出两条推论

推论一：不同腐烂速度的信息分开存，各自带有效期。

参数和认证可以放在一起（都是慢的），价格和交期要单独存并标明“报价有效期到某日”。分开的好处是你能一眼看出“哪部分需要复核、哪部分不用管”。

推论二：腐烂太快的东西，要么标有效期，要么干脆不存。

库存就是典型。库存以天为单位变化，你不可能每天更新，存进去的每一条从第二天起就是错的。它的正确位置是每次需要时去问，不是存下来。

判断标准：你能不能在它腐烂之前更新它？ 不能，就别存——存一个你知道会过期的值，比不存更糟，因为它会被当成事实使用。

这条思路的通用形态

按变化频率把东西分开，是个通用的结构原则，不只用在产品资料上：变化慢的和变化快的放在一起，整体的维护成本会被快的那部分决定。写代码的人对这个规律很熟；产品资料完全同理。

分家的另一个理由：密级

上面按腐烂速度分家，还有一个理由要求分得更彻底一点：这三层的密级完全不同。

• 产品事实（参数、认证）→ 本来就要公开
• 供货关系（成本、MOQ）→ 绝不能公开
• 供应商（工厂名、地址）→ 绝不能公开

后两层一旦跟着构建流程上线，客户拿着工厂名直接找厂，你这单就没了。所以分层不只是为了整洁，是为了让“能不能公开”变成一个由文件位置就能回答的问题，而不是每次靠人判断字段。

这件事的完整做法在事实层的两种死法那篇。这里只强调结论：分层的时候顺手把密级边界和层边界对齐，后面能省掉一整类风险。

查询模式决定存储形态

结构想清楚了，才轮到“用什么工具存”。顺序不能颠倒——先挑工具的人最后都会被工具的结构逼着改数据模型。

判断工具，看你的查询长什么样。产品事实的查询有三个特征：

1. 精确：查的是“CP-100 的最大流量”，答案唯一
2. 按主键：几乎总是“给定型号，取它的字段”
3. 量小：几百条量级，不是几百万条

这三个特征决定了文本文件就够用。放在 Git 里，好处是能 diff（改了什么一目了然）、能回滚（改错了退回去）、AI 能直接读写、构建时能自动校验，成本为零。

什么时候真的该升级：

注意这几个信号都不是“数据变多了”，而是使用方式变了。单纯条目变多（几百到一两千）不构成升级理由。

两个错误的升级方向

别一上来就上向量库做 RAG。 你的查询是精确的、答案唯一的。用语义相似度召回一个必须精确的值，是把确定的事变成概率问题。RAG 解决“我不知道答案在哪份文档里”，事实层解决“我知道答案在哪个字段里”。

别为了“以后可能需要”提前上数据库。 几百条数据配一套数据库+后台，你会把时间花在维护那套东西上，而不是维护数据本身。事实层的价值在数据准不准，不在存储技术。

一个常见的混存错误

最后说一个很容易犯的：把“常做的型号”和“客户问过但没做过的型号”混在一起。

前者是事实——你确实能供，参数确实核过。 后者是线索——某个客户问过，你觉得也许能找到供应商做。

混在一起的后果是致命的：AI 基于事实层批量生成产品页时，会把线索也生成成页面。于是你站上出现了一堆你其实供不了的产品，客户询盘进来你答不上，转化率和信任一起掉。

线索不该占事实层的位置。 它属于选品待办清单，是另一份东西。事实层里的每一条，都应该是“客户现在问，我就能报”的状态。

落地要点

• 三层拆开：产品事实 / 供货关系 / 供应商，中间层不能省
• 关系层带角色字段（主供 / 备供 / 打样），字段按角色实际需要设
• 快腐烂的信息单独存并带有效期；更新不了的（库存）干脆不存
• 层边界和密级边界对齐
• 先定结构再选工具；几百条用文件，升级看使用方式而不是数据量

三层的结构模板（YAML 版和 Airtable 字段版都给）、角色字段枚举、有效期字段规范，在产品事实层工具箱里。

小结

• 供应商和产品是多对多，中间必须有独立的关系层，否则第二家供应商一出现结构就崩
• 判据：换掉供应商这条信息会不会变 → 不变归产品、变归关系、只跟厂有关归供应商
• 两家参数不一样，那就不是同一个产品，拆成两条
• 供应商分主供 / 备供 / 打样，字段按角色实际需要设，别按最完整情况设
• 整份资料的可信度等于其中腐烂最快那一项的可信度——所以按腐烂速度分开存
• 更新不了的东西别存（库存），存一个你知道会过期的值比不存更糟
• 层边界和密级边界对齐，能省掉一整类泄露风险
• 先定结构再选工具；升级的信号是使用方式变了，不是数据量变大
• 别把“问过但没做过”的线索混进事实层，否则会生成出你供不了的产品页

→ 下一篇：事实层的两种死法：漏出去，和放过期