先说结论：AI 导购能否给出可执行的商品建议，取决于它拿到的不是一段营销描述，而是一份带有产品、变体、价格、库存、市场和更新时间的可核对数据契约。本文适合负责 Shopify 商品运营、数据工程、跨境市场和 AI 导购验收的团队；不适合把 AI 当成自动报价、自动采购或自动结账系统的团队。本文所称 “Feed” 是面向导购的规范化只读数据层，不等同于某个固定的 Shopify API 或 Storefront MCP 端点。文中时效性事实均标注 last verified 2026-08-30，发布前仍须按当前官方文档与商家店铺设置复测。
先说结论：把 AI 导购当成受约束的数据读取者
一个稳健的 AI 导购首先要回答三个问题：这是什么商品、顾客正在选择哪个可售变体、在这个市场和时点能否按什么价格购买。只有当这三层数据都能追溯到店铺事实，模型才适合生成解释；如果任何一层缺失，系统应降低回答的确定性，要求顾客补充条件，或把请求交给人工，而不是用语言流畅度掩盖数据空洞。
这意味着商品 Feed 的第一目标不是“让模型写得更像导购”，而是建立可拒答、可降级、可回放的数据边界。模型输出可能有错误，必须由商家审核；即使输入来自 Shopify，也不能把 AI 的建议写成自动正确的商品事实。发布前应按商家自己的审核流程复核输入、回答和降级日志；这条规则适用于本页全部示例。
适用的团队和最小交付物
适用对象包括：商品经理希望规定哪些字段能被导购使用；数据工程师希望让多来源商品数据有统一命名；客服或运营负责人希望看到缺字段时的人工接管条件；以及 QA 负责人希望用固定样本证明“能推荐”不等于“能下单”。最小交付物应包括一份字段字典、一份来源与更新时间规则、一份缺字段降级矩阵，以及一组可重复的失败演练。
不适用的承诺
本文不承诺自然搜索排名、AI 搜索引用、转化增长或库存准确率，也不定义全自动支付、退款、采购和订单取消流程。AI 导购可以读取经过授权的商品与政策信息并提出建议，但价格、库存、税费、配送、退货和结账结果仍受店铺配置、市场、支付方式和实时状态影响。Storefront MCP 的搜索、购物车、政策和结账边界属于另一篇实施主题，本文只说明上游数据应如何准备，不提供端点实现。
这篇指南解决什么，明确不解决什么
“Feed”在本文中的含义
Feed 是给导购消费的规范化记录。它可以来自 Shopify 商品目录、库存记录、市场化价格和店铺政策的组合，再由适配层整理为统一字段。它不是让模型直接读取后台所有字段的许可，也不是把后台数据库原样暴露给第三方。每个字段都应有来源、更新时间、适用市场、访问权限和缺失时的处理方式。
数据层与交易层的分界
商品事实属于交易前理解：名称、用途、材质、尺寸、选项、图片、价格和可售状态。购物车、结账、支付授权、退款和订单变更属于交易动作，应由专门的受控流程处理。数据契约可以告诉导购“这个蓝色、M 码的变体在某市场目前被标记为可售”，但不能把这个标记扩展成“支付一定成功”或“仓库一定会按时发货”。
事实、推断和文案要分开
建议在 Feed 中显式区分三类值：fact 是来自店铺或经审校来源的事实；derived 是按明确规则计算的派生值，例如“库存状态为低库存”；copy 是用于解释的自然语言。导购回答优先使用 fact，对 derived 给出计算时间和规则，对 copy 只当作辅助说明。不要让模型把“适合送礼”“热卖”或“库存紧张”从一段没有来源的文案中自行推断出来。
先定义商品 Feed 的最小数据契约
商品契约要同时满足“可理解”和“可拒答”。可理解表示字段名称和取值能让导购解释商品；可拒答表示缺少关键字段时，系统知道停止哪一种回答。Shopify 官方商品文档说明，商品可包含价格、媒体、变体、库存、标签和 metafields；具体店铺字段、权限和功能仍需依当前文档与后台配置确认，last verified 2026-08-30。可参考 Products、Product details 和 Variants。
必须带上的身份字段
至少需要稳定的 product_id、variant_id、商品标题、变体标题、商品状态、来源店铺标识和 updated_at。如果只传标题而不传稳定 ID，模型无法判断两个同名商品是否是同一记录，也无法在价格或库存改变后使旧答案失效。来源店铺标识用于防止跨店铺混用目录，尤其是一个 AI 服务同时服务多个商家时。
把字段元数据当成一等公民
每个字段除了值，还应携带 source、last_synced_at、market_scope、confidence 和 redaction。confidence 不应该伪装成模型概率，而是表示字段是否经过商家流程确认；redaction 用于阻止把供应商成本、内部备注或客户个人数据暴露给导购。若上游没有可靠的更新时间，宁可写 freshness_unknown，也不要填一个看起来精确但没有证据的时间。
字段字典：产品、变体、库存、价格和市场
下表是本页独有的建议契约，不是 Shopify 官方 API schema。必需指允许导购给出对应结论的最低条件；字段名和同步方式需要在开发环境按当前实现复测。
| 数据域 | 建议字段 | 导购可以据此回答 | 缺失或不可信时的处理 | 验收要点 |
|---|---|---|---|---|
| 产品 | product_id、title、status、product_url | 识别商品和进入详情页 | 不生成确定的商品推荐；仅返回需要补充信息 | ID 在一次同步中稳定且不跨店复用 |
| 产品 | description、product_type、tags、metafields | 解释用途、材质、规格和筛选条件 | 只使用可核对的短事实；不从标签臆造功效 | 关键描述有维护人和来源 |
| 产品 | media、alt_text | 告知是否有图片或媒体 | 不根据图片自动断言颜色、尺寸或性能 | 媒体与对应产品/变体关联正确 |
| 变体 | variant_id、option_names、option_values | 区分颜色、尺寸、容量等选择 | 缺选项映射时先追问，不推荐具体 SKU | 每个可选值能回到唯一变体 |
| 变体 | sku（如允许暴露）、barcode（如需要） | 供内部审计或人工定位 | 不把 SKU 当作顾客可见名称 | 个人数据和供应商敏感值已过滤 |
| 价格 | amount、currency、price_type、price_updated_at | 展示该市场可核对的价格 | 没有币种或过期则不报确定金额 | 币种、市场和时间同时存在 |
| 库存 | available_quantity 或受控 availability_status、location_scope | 判断是否可继续选择 | 过期或未知时显示“库存需确认”，不说有货 | 库存口径、地点和同步时间可追溯 |
| 市场 | market_id、locale、country、domain_or_path | 解释当前市场、语言和入口 | 市场不明时先确认国家/地区，不套用默认价格 | 不能把语言推断为市场 |
| 政策关联 | shipping_policy_ref、returns_policy_ref | 引导顾客查看适用政策 | 政策版本未知时转人工或给政策入口 | 版本和生效时间与可见政策一致 |
| 质量 | source、last_synced_at、schema_version | 控制回答时效和回放 | 缺质量元数据则降低信任级别 | 可在日志中还原输入快照 |
产品层字段：让导购先理解“卖什么”
产品层定义商品的语义范围，但不能替代变体层和市场层。一个商品可以有多个选项和库存状态，产品描述中的“有多种颜色”不等于当前每种颜色都有货；“适合旅行”也不等于已证明符合顾客的重量限制。导购需要把产品事实作为候选集过滤条件，而不是当作无需核对的广告句。
身份与状态：先过滤不可售记录
product_id 是内部关联的主键，title 是给顾客读的标签，status 用于处理草稿、归档或其他非公开状态。只有公开并且与当前店铺关联的记录才应进入顾客可见候选集；如果系统无法确认公开状态，应隐藏该条目或交给人工。不要只用 product_url 是否存在来判断可售，因为 URL 可存在但市场、库存或变体仍不满足购买条件。
描述、标签和 metafields：事实要有出处
描述、产品类型、标签和 metafields 可以承载材质、尺寸、兼容性或护理方式，但它们的字段含义由商家维护。导入时要记录字段定义，例如 material 与 care_instruction 不能因为都属于文本就混用。若同一事实在描述、标签和 metafield 中冲突，导购不应自行投票；应按照商家定义的优先级标记为冲突，并输出需要核对的提示。
媒体不是自动测量工具
图片和 alt_text 能帮助顾客理解展示内容，但不能在没有可审计属性时自动推断实际颜色、尺寸、成分或性能。若导购回答“图片里看起来是深蓝色”，那是视觉推断，不应代替变体的颜色值。可见媒体、变体颜色和商品文本必须在样本中交叉检查，避免把图片顺序误当成变体顺序。
变体层字段：让推荐落到可购买的 SKU
AI 导购最容易出错的地方往往不是商品标题，而是“推荐了商品却没有锁定可购买的变体”。对于需要尺寸、颜色、容量、包装或其他选项的商品，推荐结果至少要能从 product_id 追到一个唯一的 variant_id，并解释仍需顾客选择的选项。
选项名称和值必须保持成对关系
不要只传一个扁平字符串“蓝色 / M / 500ml”。应传 option_names 与 option_values 的对应关系，并保留该变体在商品中的原始顺序。例如 [{name: "颜色", value: "蓝"}, {name: "尺寸", value: "M"}] 只是示意数据结构，字段名、排序和序列化方式需要按当前实现复测。若选项名称为空、重复或与商品配置不一致，系统只能推荐产品层，不能确定 SKU。
变体 ID、SKU 与顾客语言各司其职
variant_id 用于系统关联；SKU 是否对顾客展示取决于商家流程；选项值才是导购与顾客沟通的主要语言。不要让模型把内部 SKU 当作产品名称，也不要把多个变体合并成一个“平均价格”。价格、库存和可购买状态必须按变体记录保存，不能从产品层继承而不注明继承规则。
变体数量是设计约束，不是推荐承诺
资料包引用的 Shopify 当前文档说明，变体选项最多三项、单商品最多 2,048 个变体；这些限制和功能属于时效性事实，last verified 2026-08-30，实际店铺、计划和当前产品配置必须再按 Variants 复测。文章不应把这个限制写成所有商家永远不变的系统保证。超过系统或运营可维护范围时，可先把导购范围缩到已验证的选项组合，并给出完整产品页入口，而不是让模型拼造不存在的变体。
库存与价格：实时性要分层，不要伪装成承诺
“实时库存”不是一个可以脱离上下文的布尔值。库存可能按地点、渠道、预留状态或同步时间产生差异；价格也可能按市场、币种、销售状态和顾客条件变化。Feed 应当把数值、范围、时间和适用条件一起交给导购。
库存状态优先于未经解释的数量
对顾客而言，in_stock、out_of_stock、preorder、backorder 和 unknown 的含义必须由商家定义。若暴露数量，要说明它属于哪个地点或库存口径，并避免把低库存阈值写成 Shopify 的普遍规则。若只需要导购判断能否继续选购，可使用受控状态值；若要展示数量，必须另行说明数量的同步时间和可能变化。
新鲜度字段要参与回答决策
建议至少记录 source_updated_at、last_synced_at 和 freshness_class。例如，商家可以自行规定“同步时间超过某个内部阈值即为 stale”，但该阈值不是 Shopify 官方保证，必须在店铺和业务流程中确认。导购遇到 stale 或 freshness_unknown 时，应该回答“可售状态需要确认”，并引导顾客查看商品页或联系人工；不能继续使用旧快照声称“现在有货”。
价格必须和市场、币种、时间绑定
最低价格记录包括金额、币种、价格类型（正常价、促销价或其他商家定义类型）、市场标识和更新时间。100 这个数不带币种和市场就没有可执行意义。比较价、折扣文案或会员价只有在顾客条件和可见政策都能核对时才能展示。不要通过模型换算汇率制造“当前价格”，除非商家明确提供汇率来源和有效期。
当前库存不能由其他指标代替
导购回答“现在能否购买”只能依当前可核对的可售状态、范围和同步时间。历史记录、推测值或模型生成的判断都不能替代当前库存字段；它们也不能被包装成实时库存保证或自动采购依据。只要当前状态缺失、过期或冲突，就应按下方降级矩阵处理。
库存与价格字段表：从输入到安全回答
| 场景 | 输入最低要求 | 允许的回答 | 必须避免的回答 | 失败信号与动作 |
|---|---|---|---|---|
| 变体有货且新鲜 | 唯一 variant_id、市场/币种、状态、同步时间 | 说明匹配的选项、价格和“当前记录显示可售” | “库存绝不会变化”“一定能发货” | 结账或复核时状态变化，重新读取并提示顾客 |
| 变体有货但市场不明 | 变体身份和库存，缺市场 | 询问国家/地区；可给产品页，不报市场价格 | 默认套用店铺主市场价格 | 市场缺失，阻止价格断言 |
| 库存过期 | 变体身份，freshness=stale | “库存需确认”，提供刷新/人工路径 | 继续引用旧数量 | 超过商家阈值，降级为未知 |
| 价格有金额但无币种 | 变体身份和金额，缺 currency | 不展示确定价格；请求市场信息 | 自行猜 USD、CNY 或换算 | 价格校验失败，阻止购买建议 |
| 产品有多个变体但无选项映射 | 产品身份和候选集合 | 描述产品范围，要求顾客选择规格 | 选择第一个变体或生成组合 | 一对多无法唯一定位，转澄清 |
| 库存为零或明确不可售 | 唯一变体、状态、时间 | 告知当前记录不可售，可推荐经审校的替代品 | 把缺货变成“马上补货” | 状态与页面不一致，创建人工复核事件 |
市场与本地化：同一商品不等于同一报价
跨境导购必须把语言、市场、域名或路径、币种、税费提示、配送和退货政策分开建模。语言只说明顾客希望怎样阅读；市场决定适用的商品、价格和政策集合。Shopify 的 Markets、Localization and translation、International SEO for Markets 和 Currencies for Markets 文档说明，多语言可产生不同 URL，币种处理器也可能受 Shopify Payments、Adyen 等条件影响；这些时效性事实 last verified 2026-08-30，详见 Markets、Localization and translation、International SEO for Markets 和 Currencies for Markets。
先确认顾客市场，再选择价格记录
如果顾客只说“这个多少钱”，导购应先确认目标国家/地区或当前市场上下文；不能从界面语言直接推断市场，更不能把 IP、浏览器语言或历史订单当成无须确认的结论。市场不明时可以回答商品事实，但价格、税费、配送和退货要降级为“选择市场后显示”。
语言翻译不改变变体身份
同一个 variant_id 可以有不同语言的名称，但翻译字段不能生成新的变体。导购应保留原始值和显示值的关联，检查颜色、尺寸、容量等术语是否在目标语言中一致。缺少某一语言的翻译时，可以回退到商家指定的默认语言，并标记需要人工校对；不能用模型臆造成分或使用说明。
URL 与政策版本要可回溯
如果市场使用不同域名或子文件夹，Feed 应存 domain_or_path 和市场 ID 的映射。配送和退货链接也应携带政策版本或最后更新时间；否则导购可能给出旧政策。政策的具体条款由商家负责维护，本文不提供任何地区法律结论。需要法律解释、税费判断或特殊退货例外时，直接转人工或政策页面。
缺字段时如何降级：从精确推荐退到安全回答
缺字段处理要预先写入系统行为，不能每次由模型临场决定。建议把输出级别定义为：L0 可执行变体建议、L1 产品级候选、L2 有边界的澄清问答、L3 人工接管或仅提供官方页面。级别越高，确定性越低，但仍应对顾客说明缺少了什么。
产品字段缺失：不让空描述变成想象
缺标题或产品 ID 时，不能向顾客推荐该记录；缺描述但有完整 ID、变体、价格和库存时，可以展示事实字段并提示“详细说明待商家补充”，不从标签或图片补写性能。缺少用途或兼容性字段时，导购应询问顾客需求或给产品页，而不是把相似商品的用途复制过来。
变体字段缺失：暂停 SKU 级结论
缺 variant_id、选项映射或唯一可购买组合时，输出最多到产品级，并询问颜色、尺寸、容量等条件。不能选择第一个变体作为默认，也不能把同一产品的价格和库存合并成一个平均值。若产品只有一个经过验证的变体，仍需确认该事实来自 Feed，而不是依赖模型推断。
库存字段缺失：把“未知”写成未知
没有库存字段或同步时间时，使用 availability=unknown。顾客可以得到“商品页当前状态需确认”的指引，但不能得到“有货”“可立即发货”或“库存还剩 X 件”的结论。库存为零是确定不可售，库存未知不是可售；这两个状态在提示、日志和人工队列中必须分开。
价格字段缺失：不猜币种，不用旧促销
没有金额、币种或市场映射时，导购只说明需要选择市场或打开商品页。价格更新时间过期时，不能继续展示旧促销。若正常价存在而促销价缺失，按商家定义可以只展示正常价；不能自动推断折扣、折后价或“限时优惠”。
数据冲突：冻结确定性并记录证据
当产品页写“蓝色”，变体字段写“绿色”，或两个库存来源给出不同状态时，应进入 conflict，保留两条来源和时间戳，暂停确定推荐。人工只需解决冲突字段，不必先重写整个商品。日志记录输入快照、规则版本、模型回答和人工决定，便于在错误回答发生后重演。
缺字段降级矩阵
| 缺失/冲突条件 | 允许输出级别 | 顾客可见表述方向 | 人工或系统动作 | 不可越过的边界 |
|---|---|---|---|---|
| 缺产品身份或商品状态未知 | L3 | 暂不确认该商品，提供安全入口 | 隔离记录，检查目录同步 | 不展示推荐、不拼接 URL |
| 缺描述但身份与购买字段完整 | L1 | 只说标题、选项、价格和已核对状态 | 建立内容补全任务 | 不补写功效、材质和兼容性 |
| 缺变体选项或无法唯一定位 | L2 | 请顾客选择规格或打开产品页 | 记录澄清问题 | 不选默认 SKU、不合并变体 |
| 库存未知、过期或地点不明 | L2 | 库存需要确认 | 刷新或转人工 | 不说“有货”“立即发货” |
| 金额缺币种、市场或时间 | L2 | 先确认市场，再展示价格 | 重新读取市场化价格 | 不猜币种、不做汇率承诺 |
| 政策链接缺失或版本冲突 | L3 | 引导人工或官方政策入口 | 锁定旧答案并更新版本 | 不解释法律义务、不承诺退货结果 |
| 多来源出现冲突 | L3 | 暂不作确定判断 | 创建冲突事件并保留证据 | 不用模型投票消除冲突 |
一次导购请求的可执行数据流程
第一步：建立请求上下文
在读取目录前先记录店铺、市场、语言、顾客约束和请求时间。请求中没有国家/地区时，把市场标记为 unknown；没有尺寸、颜色或容量时，把缺少的选择条件列为待澄清项。不要将上一次会话的市场或顾客偏好静默套用到新会话，除非商家已定义并记录了同意和保留规则。
第二步：筛选产品，再展开变体
先按产品状态、可见范围、类目和明确的顾客条件生成候选产品；然后为每个候选展开选项和唯一变体。产品层的描述只能减少候选集，最终推荐要回到变体记录。过滤过程中保留被排除的原因，例如“市场不匹配”“缺少尺寸”“库存过期”，让人工可以解释而不是只看到一个黑盒答案。
第三步：绑定市场化价格与库存
对每个候选变体绑定与当前市场和币种匹配的价格、库存状态和同步时间。任何一个关键绑定失败，就按降级矩阵降低输出级别。所谓“实时”应当是商家为该数据源定义并验收的刷新承诺，不能由模型自行保证；回答中可以说“截至数据更新时间的店铺记录显示”，不能说“结账时一定有货”。
第四步：生成答案前执行硬检查
硬检查至少包括：变体 ID 是否唯一、价格是否带币种、市场是否明确、库存新鲜度是否可接受、政策入口是否为适用版本、输入是否含不应暴露的内部字段。硬检查失败时，模板化的“很抱歉”不是重点，重点是告诉顾客下一步可做什么：选择市场、补充选项、打开产品页或联系人工。
第五步：临近交易动作时重新核对
如果导购随后进入购物车或结账流程，必须在该受控流程中重新读取关键价格、变体和可售状态；不要复用会话初始快照。这里仅说明数据交接原则，不实现 Storefront MCP endpoint，也不把顾客确认、省略支付授权或结账边界写成自动化承诺。MCP 的工具、认证和结账能力按当前官方文档单独复测，last verified 2026-08-30，参见 Storefront MCP 概览。
失败演练：库存过期与变体错配的回退 Runbook
以下是可在开发店铺或离线 fixture 中执行的 runbook/test scenario，不是客户真实案例。它专门验证两个高风险故障：库存快照过期，以及模型把产品级候选误当成唯一变体。
测试场景 A：过期库存仍被回答为“有货”
准备一个包含同一产品两个变体的 fixture：蓝色/M 的库存更新时间超过商家设定阈值，黑色/M 的库存记录新鲜；两者价格都带 USD 和目标市场。向导入层发送“我要一件 M 码，哪个颜色现在可以买？”的请求。预期是：蓝色/M 进入 unknown 或 stale，黑色/M 若状态明确可售则可被推荐；回答必须带“截至同步时间”的限定，不得声称库存绝对存在。
测试场景 B：缺少选项映射却生成具体 SKU
移除产品的 option_names 与 option_values 映射，只保留产品标题、两个变体 ID 和价格。发送“给我蓝色款”。预期是系统不能返回任意一个 variant ID，应追问颜色或引导产品页，并在日志中记录 variant_not_unique。若模型仍返回某一 SKU，测试失败，需回退到规则层阻断回答，而不是修改文案掩盖问题。
回退、修复与复测步骤
- 立即将受影响字段状态置为
unknown或conflict，停止该字段的确定回答；保留原始快照、同步时间、规则版本和回答 ID。 - 用只读方式核对开发店铺的产品、变体、库存和市场映射；不要在未经审核的正式环境中直接修补。
- 修复上游字段或同步任务后，重新运行 A、B 两个场景以及一个完整数据的正向样本；只有硬检查、人工抽样和日志回放均通过，才解除降级。
- 若无法在当前窗口确认库存或价格，维持
L2/L3，给出商品页或人工路径；不要为了通过演示恢复“有货”答案。
验收与监控：用数据契约而不是点击率猜质量
契约完整性检查
每次 Feed 构建都应检查必需字段覆盖、唯一 ID、产品—变体关系、价格币种、市场映射、库存新鲜度、政策版本和敏感字段过滤。指标采用计数和失败样本，不使用无来源的“转化提升百分比”。建议把每次失败按字段分组：identity_missing、variant_not_unique、price_context_missing、inventory_stale、market_unknown、policy_conflict。
语义与事实抽样
每天或每个发布批次从不同市场、语言、商品类型和库存状态抽样。人工逐项比对商品页、变体选择器、价格显示和库存状态；若采用多语言，要同时核对原文与显示值。抽样结果记录审校人、时间、输入快照和结论。AI 输出可能错误，抽样通过不等于免审计；它只说明当前样本满足当前规则。
新鲜度和冲突监控
监控 last_synced_at 的分布、超过阈值的记录数、同一变体多来源冲突数、导购因未知状态降级的请求数、人工接管数和用户重新选择市场的次数。这些是运营信号，不是排名或增长保证。若库存过期比例突然上升，先暂停库存确定回答，定位同步任务，再决定是否恢复；不能用模型生成更强的措辞掩盖数据延迟。
结构化数据和可见内容一致
若文章或商品页使用 Product、Article 等结构化数据，字段只能反映页面可见且可核对的内容。不要创建所谓“AI/GEO 专用 schema”，也不要把隐藏字段、未展示库存数量或模型置信度塞入结构化数据；AI 搜索没有额外的 GEO 专用 schema 可替代基本的可抓取、可索引和可引用内容规则。结构化数据必须与可见内容一致，发布前由发布负责人复核可见字段与标记内容。
与 Shopify AI 主题 Hub 的分工和内链
本页只负责导购输入数据和安全降级，建议把相邻问题交给各自页面：
- Storefront MCP 导购的搜索、购物车与结账边界：解释受控工具、权限和交易交接；本页只提供上游数据契约。
- Shopify AI 多语言、本地化与市场政策验收：验证 locale、市场、币种、税费提示、URL 与退货政策；本页只定义导购需要的市场字段。
- Hydrogen AI 导购的 Headless、SEO 与 GEO 架构：讨论 Liquid 与 Hydrogen 的渲染、缓存和架构取舍；本页不指定前端架构。
这三个链接分别承接开发、市场验收和 headless 架构意图，不把它们合并为一个“AI 导购万能指南”。它们互相补充，但输入数据、端点实现、市场验收和渲染架构的主问题不同。
常见问题
1. AI 导购必须拿到商品 Feed 的哪些字段才能推荐具体变体？
至少需要稳定的产品和变体 ID、产品与变体可见名称、选项名称和值、市场、币种、价格、可售状态以及库存或库存新鲜度信息。还应带来源和更新时间，便于回答可追溯。如果缺少任一关键绑定，系统应退回产品级候选或澄清问题，而不是凭标题猜一个 SKU。具体字段名不是 Shopify 官方统一 AI Feed schema，需按商家实现复测。
2. Shopify 的库存数据可以直接被 AI 导购称为“实时库存”吗？
不能直接这样承诺。导购只能引用某个库存来源在某个同步时间的状态；“实时”需要商家为数据源定义刷新阈值、地点口径和重新核对步骤。库存过期或更新时间未知时，应显示需要确认，不能说有货、立即发货或保证结账成功。
3. 缺少变体选项映射时，导购能否先推荐产品再默认第一个变体？
可以推荐产品级候选，但不应默认第一个变体。缺少选项映射意味着系统无法证明顾客要求对应哪一个可购买组合。正确降级是询问颜色、尺寸或容量，或引导顾客到产品页选择；日志应记录无法唯一定位的原因。
4. 多语言商品名称是否等于不同市场的商品数据？
不等于。语言是显示层，市场还可能决定价格、币种、域名或路径、税费提示、配送和退货政策。Feed 应分别保存 locale 与 market_id，先确认顾客市场再绑定市场化价格。缺少目标语言时可回退到商家指定默认语言，但不能由模型臆造规格或政策。
5. 这篇文章是否等同于 Storefront MCP AI 导购的实现指南？
不是。本页定义的是导购上游应提供的产品、变体、库存、价格和市场数据，以及缺字段时的降级规则；不提供 endpoint、工具调用、认证或结账实现。MCP 的具体能力、权限、认证和可用性要按当前 Shopify 官方文档在开发环境复测，并由另一篇开发主题承接。
来源与时效边界
本稿使用补充资料卡列出的官方一手资料，事实时效统一以 last verified 2026-08-30 标注。Shopify 商品、变体、Markets、多语言、多币种和 Storefront MCP 边界会随产品、计划、地区和店铺配置变化；若发布前无法复测某项限制、价格、权限或可用性，应写成“需按当前官方文档复测/由商家确认”，而不是补猜一个固定答案。AI 输出始终需要商家审核；本稿不提供地区法律意见、交易安全保证或增长承诺。