先统一商品主数据，再谈 GEO

示例场景：一家做户外电源的出海品牌，德国站收到一封退货申请，理由写得很具体——AI 说这台机器能同时带电饭煲和电热水壶，买回来一起开就跳保护。运营先去改商品页，规格表没错；再去看平台 listing，功率写的是峰值；翻到经销商那份 Excel，功率那栏只写着“大功率”。三个渠道，三个说法，改哪一个都不算改对。

商品主数据不统一时，GEO 做的不是优化，而是给错误的数据化妆——AI 不会因为文案漂亮就忽略三个渠道里三个不同的功率。

AI 比较的是字段，不是文案

买家问“这台能不能带电饭煲”，AI 要做的事只有一件：把几个候选 SKU 的功率、容量、接口摆在一起比。文案可以各写各的，字段必须同口径。

断裂通常发生在三处。一是定义不同：额定功率和峰值功率都叫“功率”，写进同一栏就开始骗人。二是单位与叫法不同：同一个容量，美国站用 Wh，欧洲站用 mAh，换算需要电压才成立。三是变更不传播：规格、兼容性、价格改在官网，feed、平台 listing、经销商表还停在三个月前。

第三处最贵，也最不显眼。AI 检索时会同时读到几个版本，它不挑你想让它读的那个，只挑能自洽的那个——而三个版本里往往没有一个是自洽的。

先划范围：哪些算主数据

多数团队把叙事当主数据、把属性当文案，顺序恰好反了。 叙事决定 AI 引不引用你，属性决定它引用得对不对；前者可以各站不同，后者必须全渠道一套。

数据域	包含什么	GEO 依赖它的哪一步	该谁拥有
身份	品牌、型号、GTIN、变体关系	AI 能不能把五个页面认成一件商品	商品负责人
属性	尺寸、材质、功率、容量、兼容性	买家“能不能用”这类提问	品类与产品
合规与履约	认证、保修、退货、发货地	AI 敢不敢推荐、agent 敢不敢下单	法务与运营
商业	价格、库存、促销	答案里的报价是否可信	定价与运营
叙事	卖点、场景、图片、视频	被不被摘录、被不被相信	内容与品牌

这张表的作用不是分类，是分权。凡是落进前四行的字段，都不该由某个站点的运营单独改。

分工：三种决策权，不能合并

主数据项目失败，很少是系统失败，而是没有人对“这个字段是什么意思”负责。 三种权力必须分开：语义归市场，取值归运营，管道归 IT。

市场与品类决定“买家会问哪些属性”，这是取舍，不是技术问题。运营与商品维护值和单位，对准确性负责，错一个数字就该有人被问。IT 负责唯一权威系统、同步机制与校验，让改动只录一次。

最常见的误用是整包交给 IT：结果是一套完整字典，字段名叫 erp_pwr_max_kw，运营不愿意填，买家也不会这么问。另一个极端是交给内容团队：文案改了，feed 没改，AI 读到的还是旧值。

三个角色共用的东西只有一张“字段卡”：定义、单位、允许值、缺失时怎么写、来源系统、责任人、变更要通知谁。它不是文档工程，是这份数据能不能被引用的合同。

最小可行治理：12 个字段，5 步

不要一上来建全量属性库。 先挑 12 个“买家会拿来提问、AI 会拿来比较”的字段，跑通一次端到端发布，比上线一套 PIM 更能证明这件事值得继续投。

步骤	做什么	谁来做	怎么算过
1 选字段	从客服工单、站内搜索、AI 提问记录里挑 12 个高频属性	运营 + 品类	每个字段能对应至少 3 个真实提问
2 定口径	写字段卡：定义、单位、允许值、缺失规则	品类 + IT	同一 SKU 在三个渠道读出同一个值
3 建真源	指定唯一权威系统，其余系统只读同步	IT	改一次，只在一个地方录
4 同源发布	商品页、feed、结构化数据由同一份数据生成	IT + 运营	抽 30 个 SKU，三处一致
5 变更与抽检	字段变更走同一条流程，按月抽检	运营	有变更记录与抽检结果

第 2 步是分水岭。跳过它，后面四步会变成“把错误的数据更快地同步到更多地方”。属性怎么变成买家听得懂的话，是把规格翻译成购买理由要解决的问题；这里只保证翻译的原料是对的。

示例：三个渠道的容量

示例：假设一个做户外电源的品牌（不含真实品牌与数据）。同一款产品，美国站标 Wh，欧洲站标 mAh，经销商表写“约 1 度电”，三处都对，却没有一处能和另外两处直接比较。AI 被问“能不能带上飞机”时引用了容量，却给不出确定结论——航空运输看的是 Wh，只有 mAh 时必须知道电压才能换算。买家拿到的是一句含糊的话，品牌丢掉的是这个问题下的答案位。

改法只做三件事：容量统一为 Wh，并把电压设为必填的伴随字段；把“额定功率”与“峰值功率”拆成两个字段，各自带单位；给兼容性建允许值列表，不再让每个站点自由填写。没有重写任何一句文案。

验收看两个数：抽 30 个 SKU，三个渠道的容量、功率、兼容性是否一致；用同一批问题复测，AI 答案里的数值是否与官网相同。第二个数才是 GEO 的验收，第一个数只是它的前提。

边界：什么情况下先别做

第一，SKU 只有几百个。一张字段卡加一份共享表格就够，上系统是浪费。

第二，成交集中在平台内。平台的 listing 字段本身就是你的主数据界面，先把必填属性补齐，再谈自建 PIM。

第三，产品线一年内要大改。先把字段卡定下来，库可以晚建；建早了，搬一次家的成本比不建更高。

第四，没有字段责任人。先做一次只读盘点，把三个渠道的冲突列成清单，让冲突自己说话，比启动项目更有说服力。

第五，指望它解决“不被推荐”。字段对了只保证 AI 不读错，不保证它推荐你——后者要靠证据与实体覆盖，见实体覆盖率。主数据与商品图谱的关系，Product Graph讲得更完整；品类怎么分层，见品类树怎么建；这条线上其他文章在战略与市场主题页。

先做一件事：导出近 90 天客服工单里带“能不能”“多大”“多久”的问题，挑出被问最多的 12 个属性；取卖得最好的 30 个 SKU，把官网商品页、商品 feed、一个平台 listing 三处的值拉进同一张表，标出所有不一致的格子；只修冲突最多的 3 个字段，每个字段写一张卡——定义、单位、允许值、缺失时怎么写、来源系统、责任人。下个月用同一批问题复测答案里的数值。