适用读者：负责零售电商商品页结构化数据的前后端工程师、在做生成式引擎优化（Generative Engine Optimization, GEO）的站点维护者、需要排查 AI 搜索引用归属错误的电商技术负责人。要求对 JSON-LD 和 Schema.org 有基础了解，能看懂一段商品结构化数据模板。

用户在 AI 搜索里问「XX 品牌的主动降噪耳机哪家的渠道靠谱」，答案里把我们的经销商公司名当成了品牌，正牌厂商的名字压根没出现。追查到根上，是商品页 JSON-LD 里 seller 和 brand 两个字段被同一个模板变量填了。这篇文章把这段混写是怎么发生的、怎么用脚本批量找出来、改完之后 60 天里 AI 引用行为的变化，完整记录下来。

一、问题是怎么被发现的

事情起于运营的一次例行巡检。我们做品牌授权经销，站内卖某音频品牌的耳机和音箱，AI 搜索兴起之后团队每周会抽查几个品类词在主流 AI 引擎里的回答。第 14 周的抽查里发现一个怪现象：问品牌相关的问题，AI 给出的推荐商户名单里有我们，但介绍我们时写的是「经销商某某科技旗下的耳机产品」——把经销商当成了品牌方，真正的品牌名反而只在参数表里出现。

第一反应是文案问题，改描述就行。但翻了几篇被引用的商品页，发现 AI 引擎复述的措辞几乎照搬了页面里的结构化数据：schema 里的 brand 字段写的就是经销商的工商全称。也就是说，AI 引擎没理解错，是我们自己喂给它的实体关系就是错的。

把这个发现同步给团队时，不少同事第一反应是「AI 不会只看正文吗」。实际测试下来恰恰相反：对商品这类强实体页面，AI 爬虫对 JSON-LD 的信任度明显高于正文散文。正文里写了 20 次「XX 品牌授权」，一句 schema 里的 brand 就能把实体归属整个带偏。

二、混写现场：出问题的那段 JSON-LD

混写的来源很典型。我们商品页模板是三年前写的，当时对接的品牌只有一个，模板作者图省事，把「商家信息」这个对象同时塞进了 brand 和 seller 两个槽位。出问题的结构长这样（公司名做了脱敏）：

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "XX 主动降噪耳机 Pro",
  "brand": { "@type": "Organization", "name": "某某数字科技有限公司" },
  "offers": {
    "@type": "Offer",
    "price": "1299.00",
    "priceCurrency": "CNY",
    "seller": { "@type": "Organization", "name": "某某数字科技有限公司" }
  }
}

brand 和 seller 指向同一个 Organization，AI 引擎做实体对齐时自然会得出「这个商品的品牌就是这个经销公司」的结论。更麻烦的是，品牌方的官网和百科里有自己的规范实体信息，两边在 AI 引擎的知识图谱里对不上，结果就是引用时归属混乱——有时写经销商，有时干脆把两个组织名拼接在一起。

后来复盘，这类混写在授权经销模式里很常见：站点运营方既是页面维护者又是卖家，写模板时顺手把「我们」填进了所有「主体」槽位。自营站点没问题（自营时 brand 确实可以指自己持有的品牌），但授权经销的语义完全不同。

三、原理与机制剖析：AI 引擎怎么读 seller 和 brand

要把这个问题修对，得先讲清两个字段在 Schema.org 里的语义差别。

brand 描述的是「商品属于哪个品牌」，定义在 Product 上，推荐用 Brand 类型节点，也可以用 Organization。它回答的问题是：消费者心智里这个商品挂谁的名字。

seller 描述的是「这单生意谁在卖」，规范位置在 Offer 上，类型是 Organization 或 Person。它回答的问题是：交易关系里的卖方是谁。两者的语义完全正交，一个属于产品维度，一个属于交易维度。

AI 引擎拿到商品页后，大致会做三层处理：先解析 JSON-LD 抽出实体和关系，再把实体和自己的知识图谱对齐（这里会拿 Wikipedia、官网、百科等外部信源交叉验证），最后在生成回答时按对齐结果组织表述。混写页面的要害在第二层：页内数据说「品牌=经销商 A」，外部信源说「品牌=B 厂商」，两个证据冲突。不同引擎处理冲突的策略不一样，实测有的引擎会保守地都提一嘴，有的直接按页面 schema 走——于是经销商的名字占了品牌位。

还有一个容易忽略的放大效应：AI 引擎会引用站内多个页面互相印证。我们全站 340 个商品页用的是同一套模板，混写是成批出现的。对 AI 来说，「340 个页面都说品牌是经销商」比「1 个页面写错」的置信度高得多，错误归属反而被规模放大了。这也是为什么这个问题必须批量修，单页修几页意义不大。

把三个容易混的主体的字段语义列成对照表，模板评审时可以直接对着查：

修模板之前先确认这三行语义，比反复改文案有效得多。

四、批量排查：写一个 lint 脚本扫全站

人工翻页面不现实，我们写了个脚本，扫商品页导出的 JSON-LD，找出 brand 与 seller 指向同一实体的页面。脚本只依赖 Python 3.9+ 标准库，不需要装任何第三方包，直接跑在导出目录上：

#!/usr/bin/env python3
# 依赖：Python 3.9+，仅标准库，无第三方包
# 用途：扫描商品页导出的 JSON-LD，找出 brand 与 seller 混写的页面
# 用法：python lint_brand_seller.py ./export/*.json

import json
import sys
import glob


def extract_products(node):
    # 递归收集所有 @type 含 Product 的节点
    # 参数 node 可能是 dict、list 或标量，三种情况都要覆盖
    if isinstance(node, dict):
        types = node.get("@type", [])
        # @type 可能是字符串也可能是列表，先统一成列表
        if isinstance(types, str):
            types = [types]
        if "Product" in types:
            # 命中商品节点，交给上层做字段检查
            yield node
        # 继续下钻嵌套结构，比如 offers、isVariantOf 里面
        for value in node.values():
            yield from extract_products(value)
    elif isinstance(node, list):
        # 数组节点逐项递归，@graph 顶层就是这种结构
        for item in node:
            yield from extract_products(item)
    # 其他标量类型直接落空，不产生任何产出


def get_name(entity):
    # 取实体名：兼容字符串、Brand 对象、Organization 对象三种写法
    if isinstance(entity, str):
        # 旧模板常见写法，直接就是名字字符串
        return entity
    if isinstance(entity, dict):
        # 规范写法是 {"@type": "Brand", "name": "..."}
        return entity.get("name", "")
    return ""


def brand_seller_equal(product):
    # brand 按规范应挂在 Product 上，取它的名字
    brand_name = get_name(product.get("brand"))
    # seller 规范位置在 Offer 里，但旧模板常写在 Product 外层，两处都查
    offers = product.get("offers") or {}
    seller = offers.get("seller") if isinstance(offers, dict) else None
    # 外层 seller 优先级更高，覆盖 Offer 里的取值，模拟引擎看到的冲突
    seller = product.get("seller") or seller
    seller_name = get_name(seller)
    # 两个名字都非空且相同，判定为混写嫌疑页
    # 名字相等不一定百分之百是错，但在我们这种授权经销场景里命中率极高
    hit = bool(brand_name and seller_name and brand_name == seller_name)
    return hit, brand_name, seller_name


def main():
    pattern = sys.argv[1] if len(sys.argv) > 1 else "*.json"
    bad_count = 0
    for path in sorted(glob.glob(pattern)):
        try:
            # 导出文件统一存成纯 JSON，解析失败就跳过并记录
            data = json.load(open(path, encoding="utf-8"))
        except Exception as exc:
            print(f"[SKIP] {path}: {exc}")
            continue
        for product in extract_products(data):
            hit, brand, seller = brand_seller_equal(product)
            if hit:
                # 打印 sku 和两个字段的值，方便回查到具体模板
                sku = product.get("sku") or product.get("@id") or "?"
                print(f"[HIT] {path} sku={sku} brand={brand} seller={seller}")
                bad_count += 1
    # 退出码非 0 表示存在混写，接进 CI 可以直接卡住发布流程
    print(f"总计 {bad_count} 个混写商品")
    sys.exit(1 if bad_count else 0)


if __name__ == "__main__":
    main()

脚本跑完，340 个商品页里命中 317 个。剩下 23 个「干净」的页面是后来新增品类时另一个同事写的模板，他当时查过 Schema.org 文档，把 brand 写成了独立的 Brand 节点。这 23 个页面成了后面修复的参照样本。

顺手把脚本接进了 CI：模板渲染后的快照文件每次发版跑一遍，退出码非 0 就拦下来。这个决定后来证明很值，修复两周后有个运营同学改模板又把旧变量填了回去，CI 当场拦截。

五、修复方案：把两个字段各归各位

修复的目标结构：brand 用独立的 Brand 类型节点指向品牌方，seller 挪进 Offer 并指向经销商主体，两边用不同的 @id 锚点，让 AI 引擎能明确区分两个组织。批量改写脚本如下：

#!/usr/bin/env python3
# 依赖：Python 3.9+，仅标准库
# 用途：批量修复混写页面，brand 指向品牌方、seller 归位到 Offer 指向经销商
# 用法：python fix_brand_seller.py ./export/*.json

import json
import sys
import glob
# 全部使用标准库，方便直接放进 CI 镜像，不用额外装包

# 品牌方与经销商的主体信息，实际项目中从配置或主体库读取
# 两个主体都带 @id 锚点，后续在站内用同一个锚点保持一致
BRAND = {
    # brand 用 Brand 类型，而不是和 seller 共用 Organization
    "@type": "Brand",
    "name": "XX 品牌音响",
    # @id 指向品牌介绍页，全站所有商品页引用同一锚点
    "@id": "https://brand-example.com/#brand",
}
DEALER = {
    # seller 保持 Organization 类型，语义是交易卖方
    "@type": "Organization",
    "name": "某某数字科技有限公司",
    # @id 指向经销商的关于我们页，和品牌方锚点明确区分
    "@id": "https://www.example-shop.com/#organization",
}


def fix_product(product):
    # brand 强制替换成品牌方节点，不再引用经销商实体
    # 用 dict(BRAND) 拷贝一份，避免多个商品共享同一个可变对象
    product["brand"] = dict(BRAND)
    offers = product.get("offers")
    # 没有 Offer 的商品页属于更早的结构问题，这里只提示不处理
    if not isinstance(offers, dict):
        print(f"[WARN] {product.get('sku', '?')} 缺少 offers 节点")
        return False
    # seller 统一挪进 Offer，指向经销商主体，并挂上独立 @id
    # @id 是实体锚点，引擎靠它区分品牌方和经销商两个组织
    offers["seller"] = dict(DEALER)
    # 清掉 Product 外层残留的旧 seller，避免引擎读到两份冲突数据
    # pop 带默认值，字段本来就不存在时也不会报错
    product.pop("seller", None)
    return True


def main():
    fixed = 0
    for path in sorted(glob.glob(sys.argv[1] if len(sys.argv) > 1 else "*.json")):
        data = json.load(open(path, encoding="utf-8"))
        # 假设导出文件顶层就是 @graph 或单个 Product，遍历修复
        # @graph 不存在时退化成只处理顶层的单个节点
        nodes = data.get("@graph", [data])
        changed = False
        for node in nodes:
            types = node.get("@type", "")
            # 同样把 @type 归一成列表再判断，和 lint 脚本口径保持一致
            types = types if isinstance(types, list) else [types]
            if "Product" in types and fix_product(node):
                changed = True
        if changed:
            # 写回时保证 UTF-8 且中文不转义，diff 里能直接看到中文变化
            # indent=2 是为了和渲染模板的快照 diff 保持行级对齐
            json.dump(data, open(path, "w", encoding="utf-8"),
                      ensure_ascii=False, indent=2)
            fixed += 1
    # 修复脚本正常结束返回 0，是否还有漏网由 lint 脚本复核
    print(f"修复完成 {fixed} 个文件")
    sys.exit(0)


if __name__ == "__main__":
    main()

改完之后有两件事必须同步做，不做等于白修。一是全量重提交：把修复后的页面 sitemap 重新推给各 AI 引擎的抓取入口，让新版 schema 尽快进入抓取队列。二是主体对齐：经销商和品牌方两个 Organization 节点的 @id 都指向稳定页面，分别挂 sameAs 链到各自的官方介绍页，帮助引擎完成实体消歧。

六、60 天引用对照：数据怎么变的

修复在第 0 天上线。我们固定每周五用同一组 12 个测试问题（品牌词 6 个、品类词 4 个、渠道词 2 个）在各家 AI 引擎里跑一遍，记录引用情况。对比数据如下：

几个值得单独说的细节。第 9 天才第一次观察到归属正确的引用，之前一周多毫无动静，当时一度怀疑方案没用——后来在引擎方抓取日志里确认，旧缓存直到第 7 天才被替换，也就是说前面几天观察到的还是修复前的快照。第 30 天时正确率到 54%，但「把经销商当品牌方复述」还有残留，追查发现是两个长尾聚合页忘了同步修，补齐后这部分归零。到第 60 天，正确引用的比例稳定在 80% 以上，剩下不到两成的偏差主要来自引擎对聚合页的摘要改写，已经不在 schema 层面能控制的范围里。

整个过程画成时间线是这样的：

sequenceDiagram
    participant E as AI 引擎爬虫
    participant P as 商品页(JSON-LD)
    participant K as 知识图谱
    E->>P: 抓取页面并解析 schema
    P->>K: 提交 brand/seller 实体关系
    K->>K: 与外部信源交叉验证
    alt 字段混写(修复前)
        K->>E: 归属冲突,引用表述混乱
    else 字段分离(修复后)
        K->>E: 品牌归品牌方,卖方归经销商
    end
    E->>P: 第 7 天完成缓存替换
    Note over P: 第 9 天首次出现正确归属引用

排查与修复的执行链路也整理成一张图，方便后续复用：

flowchart LR
    A[AI 引用抽查发现归属异常] --> B[定位商品页 JSON-LD]
    B --> C[lint 脚本扫描全站]
    C --> D{命中混写?}
    D -- 是 --> E[批量修复脚本改写]
    D -- 否 --> F[纳入观察名单]
    E --> G[重提交 sitemap]
    G --> H[每周固定问题集追踪]
    H --> I{第 60 天正确率达标?}
    I -- 是 --> J[脚本接入 CI 防回归]
    I -- 否 --> H

七、复盘时被问得最多的三个问题

第一个问题是「自营站点要不要管这个」。要。自营时 seller 写自己是合理的，但 brand 仍然必须指向真实品牌实体——哪怕品牌是自营公司持有的子品牌，也建议拆成独立 Brand 节点，别和主体 Organization 混成一个对象。实体分离对 GEO 的好处在授权经销场景里已经验证过，自营场景同样成立。

第二个问题是「seller 还要不要写」。要写，而且要写对位置。Offer 里没有 seller 的商品页，AI 引擎在回答「去哪买」类问题时会缺一块关键证据，实测这类页面被引用进推荐名单的概率明显低一截。字段的问题从来不是「删掉就干净」，而是各归各位。

第三个问题是「改 schema 是不是就万事大吉」。不是。schema 只是实体声明的入口，正文、FAQ、商品详情里关于品牌归属的自然语言表述要和 schema 一致，否则引擎拿到的证据仍然互相打架。我们第 30 天残留的那两成错误，有一半就是聚合页正文还在用旧话术。

八、误区澄清与趋势

最常见的误区是把 seller 和 brand 当成「同义的主体信息」，哪个模板槽位空着就填哪个。这两个字段分属交易维度和产品维度，AI 引擎的实体对齐对它们的处理完全不同。另一个误区是出了问题先去改文案——正文改十遍，不如把 schema 里那行错误实体改对。

趋势上，AI 搜索对商品实体的引用会越来越依赖页内结构化数据与外部信源的一致性。对授权经销的电商站点来说，谁先把 brand 和 seller 的实体关系理清楚，谁的商品就更容易在 AI 推荐里被正确地挂上品牌名。这件事不依赖任何引擎的特殊配合，纯粹是把schema 的语义写规范，属于投入很小、复利很长的 GEO 基建。如果你也在做品牌授权经销，建议今天就跑一遍 lint，混写可能比你以为的普遍得多。欢迎在评论区交流你遇到的实体对齐案例。

参考与延伸

• Schema.org Product 类型定义：https://schema.org/Product
• Schema.org Offer 类型定义（seller 属性在此）：https://schema.org/Offer
• Google 搜索中心商品结构化数据文档：https://developers.google.com/search/docs/appearance/structured-data/product

关键词：GEO、AI 搜索引用、seller 字段、brand 字段、实体对齐、JSON-LD、零售电商