上周三下午，我在车间办公室里对着笔记本愣了五分钟。客户老周——一家立式加工中心厂商的电商负责人——把他手机递过来：问 AI「XK850 配什么刀具」，回答里推荐的是另一个品牌的刀柄，还把他们家 4 月份就停产的旧型号 BT40 刀柄排在第一位。他原话是：「人搜还能忍，AI 答错了没人知道。」这事儿促使我们花了三十天，把主机页和配件页的实体关系用 isAccessoryOrSparePartFor 重理了一遍。下面是过程和一版对照数据，全部出自我们自建的监测口径，没有引用任何第三方统计。

问题长什么样：AI 把配件安到了别人家主机上

先说清楚背景。生成式引擎优化（Generative Engine Optimization, GEO）这个词现在很热，但落到制造业官网，它说到底就是一件事：让 AI 在组织答案时，能准确认出「这是谁的配件、配哪台主机」。我们站内有 6 个主机系列、约 340 个 SKU 的配件页——刀具、刀柄、冷却管、导轨油、易损件包，全都各自独立成页。传统 SEO 年代这不是问题，反正每个页面自己收自己的权重。可 AI 搜索回答「XK850 配套刀具」时，它不是检索一个页面，而是在整站范围里对实体做归并，谁的关系写得清楚、谁的表述更容易被抽取，谁就进答案。

我们 9 月初抽了 40 条典型问法做基线（比如「XK850 配什么刀柄」「VMC1060 用哪种冷却液」「易损件包有没有装 V8 系列的」），发现三类毛病：

也就是说，八成以上的问法 AI 都答得不如一个刚入职的销售。原因不难猜：我们的配件页标题全是「BT40 刀柄 高精度」这种写法，正文里「适用于 XK850」埋在一堆参数表格中间，还是一张图。对人类读者勉强够用，对抽取关系的大模型来说，等于没说。

isAccessoryOrSparePartFor 的原理：为什么一条属性能扭转归属判断

动手之前我先把 Schema.org 的定义读了几遍。isAccessoryOrSparePartFor 是 Product 类型的一个属性，方向是从配件指向主机——意思是「我这个产品，是那台设备的配件或备件」。它解决的不是展示问题，而是知识图谱层面的实体归属：告诉消费方，页面上这个 SKU 和那台主机之间存在一条有方向的边。

这里有个我一开始理解反了的地方，值得单独说。我最初想的是在主机页上罗列「本机支持配件」，用列表把配件 SKU 全挂上去。后来查了属性方向才发现做反了——关系要从配件页出发指向主机页。主机页上要做的是另一件事：用 hasPart 或者 compatibleWith 表达「主机包含/兼容哪些东西」，两边的边方向相反，缺一边图谱就残缺。9 月 6 日我们开会定方案，同事小陈在白板上画了半天，最后总结一句：「配件页单向声明，主机页只做兼容清单，别两边互相指。」后来证明这个简化策略是对的，省了大量双向同步的维护成本。

底层为什么这条边能起作用？我的理解是这样的：大模型在生成回答时，并不是每次都重新读你整页 HTML，而是依赖它对页面结构化信号的记忆和抽取。JSON-LD 里一条明确的 (accessory, host) 二元组，比正文里一句自然语言「适用于 XK850」的抽取置信度高得多——前者是零歧义的谓词关系，后者要靠指代消解去猜「适用于」的主语到底是谁。当用户问「XK850 配什么刀具」，模型在组装答案时沿着这条边反查，配件就能被正确召回到 XK850 名下，而不是飘在「所有 BT40 刀柄」这个模糊集合里。这就是为什么同样两页内容，加了属性和没加，AI 的归属判断差这么多——不是 AI 变聪明了，是它拿到的图变了。

改造方案：两个 JSON-LD 模板

环境：PHP 8.3 模板层输出 JSON-LD，Schema.org 词表取自 schema.org 官方定义，站点为自研 CMS。示例中为便于阅读加了行注释，实际输出时需去掉注释行保证 JSON 合法。

配件页的模板核心长这样：

{
  // 声明词表来源，固定写法
  "@context": "https://schema.org",
  // 页面主实体：一个配件商品
  "@type": "Product",
  "name": "BT40 高精度刀柄 A型",
  // sku 必须与内部物料编码逐字一致
  "sku": "BT40-ACC-0812",
  // 品牌对象，两个字符段即可
  "brand": { "@type": "Brand", "name": "衡锐精工" },
  // 核心关系：本配件从属于哪台主机，方向是配件指向主机
  "isAccessoryOrSparePartFor": {
    "@type": "Product",
    // name 加 sku 能与主机页对上号即可，不必全量展开
    "name": "XK850 立式加工中心",
    "sku": "XK850"
  },
  // 补充规格，方便抽取接口参数
  // 规格字段数量控制在三四个以内，别把参数表整段搬进来
  "additionalProperty": [
    {
      "@type": "PropertyValue",
      "name": "接口规格",
      "value": "BT40"
    }
  ]
}

要点有三个：关系对象不需要完整展开，给足 name 和 sku 让两边能对上号即可；sku 必须和主机页的 sku 字段逐字一致，我们第一个版本里主机页写的是「XK850-A」，配件页写「XK850」，图谱对齐就断了，这个坑排查了两天；下架商品不要直接删页，改成 ProductGroup 或加标记，否则 AI 会从缓存里继续引用旧 SKU。

主机页上则用 compatibleWith 做轻量兼容声明：

{
  "@context": "https://schema.org",
  // 主机页主实体
  "@type": "Product",
  "name": "XK850 立式加工中心",
  // 与配件页关系对象里的 sku 逐字相同
  "sku": "XK850",
  // 轻量兼容声明，指向系列而非逐个 SKU
  // 注意这里指向的是系列页，不是单个刀柄 SKU
  "compatibleWith": { "@type": "Product", "name": "BT40 系列刀柄" },
  // 随机附带件用 hasPart，注意与配件页方向相反
  // hasPart 只写出厂标配，选配项不要混进来
  "hasPart": [
    { "@type": "Product", "name": "标准冷却管组件", "sku": "CL-0850" }
  ]
}

改造范围：340 个配件页里，先挑了 118 个高流量 SKU 做模板级输出，主机页 6 个全部改。模板写好之后是批量灌数据，真正的体力活在数据清洗——把运营当年填的「适配机型」自由文本（「850 也能用」「XK系列均可」这种）逐条改成结构化指向，小陈和另一个同事花了九个工作日。

关于清洗还有个插曲值得记一笔。运营表里大概 40 来条适配记录写的是「同老款」，可「老款」指哪台没人说得清，最早追溯到 2022 年一份内部选型手册才对上号。我们最后定了个规矩：说不清来源的适配关系一律不写进结构化数据，宁可少声明，也不能让 AI 拿着一条来路不明的边去组织答案。这个取舍当时有小争论，老周觉得少写吃亏，后来第 30 天的数据里引用下架旧 SKU 从 7 条降到 2 条，多少能说明谨慎声明是对的——错的边比缺的边危害大，缺了顶多漏推荐，错了就是把用户往坑里带。

30 天对照：自建监测口径下的变化

从 9 月 8 日上线到 10 月 7 日，我们用同一套问法集做对照。监测方法坦白说比较土：每天早上用三台设备、无痕窗口，把 40 条问法丢给主流 AI 搜索入口，人工记录回答里引用的 SKU、归属是否正确，做成台账。这个口径有明显局限——样本小、人工记录有主观误差、AI 端变化我们控制不了——所以下面数字只代表我们自己的观察，不外推成行业结论。

几个感受值得单独记。第一，见效比想象慢，前 12 天几乎没有变化，我一度怀疑方向错了；第 13 天开始归属正确率跳了一截，猜测是抓取和图谱更新有延迟，具体机制我们没能力验证。第二，改进最明显的是「同品牌配件归属」类问法，而跨品牌兼容类（「XK850 能不能装别家刀柄」）改善有限——这大概和 compatibleWith 表达力有关，还没解决。第三，有 3 条问法在第 20 天前后突然开始引用我们一个竞品的配件页，对方页面结构和我们改造后的几乎一样，说明这套打法门槛不高，先做先占位，但也留不住。

流程上，整个链路大概是这样：

flowchart LR
    A[配件数据清洗] --> B[配件页输出 isAccessoryOrSparePartFor]
    C[主机页兼容清单] --> D[主机页输出 compatibleWith 与 hasPart]
    B --> E[SKU 全站对齐]
    D --> E
    E --> F[每日 40 问法人工监测]
    F --> G{归属正确率达标?}
    G -- 否 --> H[补关系边与修数据]
    H --> B
    G -- 是 --> I[纳入日常维护]

日常排查时的判定路径则更线性：

flowchart TD
    Q[AI 回答归属错误] --> S1{主机页 sku 与配件指向一致?}
    S1 -- 不一致 --> F1[统一 sku 命名]
    S1 -- 一致 --> S2{关系方向是否为配件指向主机?}
    S2 -- 反了 --> F2[调换属性方向]
    S2 -- 正确 --> S3{页面是否被重新抓取?}
    S3 -- 未抓取 --> F3[检查 sitemap 与内链]
    S3 -- 已抓取 --> F4[检查问法措辞是否过于模糊]

踩过的坑和没解决的问题

坑一，sku 对齐。前面提了，两天排在一个连字符上，从那以后我们把「SKU 命名规范」写进了上线检查单。

坑二，别过度展开。第一版配件页把关系对象展开成完整 Product，带上了 offers、aggregateRating，JSON-LD 膨胀到 4KB。后来发现关系对象给 name 加 sku 就够，页面反而清爽。少即是多，这条在结构化数据上是真的。

坑三，AI 的转述不受你控制。有两条问法，AI 正确召回了我们的刀柄，但描述里说它是「原厂标配」——其实选配。结构化数据管归属，管不了措辞，这个边界要认。

没解决的问题也有三个：跨品牌兼容的表达还很粗；AI 端缓存导致改进生效周期不可控；40 条问法的样本量太小，置信区间宽得吓人，10 月我们打算扩到 120 条。

给同行的一句话建议：先别急着谈什么生成式引擎优化的大概念，把站内「谁的配件」这一条边画清楚，是投入最小、回报最直接的一步。

参考与延伸

• Schema.org Product 类型与 isAccessoryOrSparePartFor 属性定义：https://schema.org/Product
• Google 搜索中心结构化数据文档（Product 标记）：https://developers.google.com/search/docs/appearance/structured-data/product
• web.dev 关于结构化数据与搜索外观的实践指南：https://web.dev/learn/seo/
• MDN 上 JSON-LD 与链接数据的介绍：https://developer.mozilla.org/docs/Web/API

GEO · isAccessoryOrSparePartFor · Schema.org · JSON-LD · 结构化数据 · 制造业B2B · AI搜索引用