对话内结账这个按钮已经没了，当初为它而建的那份商品数据源却留了下来。OpenAI 与 Stripe 在 2025 年 9 月底发布 Agentic Commerce Protocol，随之上线的卖点是在 ChatGPT 里直接下单；2026 年 3 月，OpenAI 关掉了对话内结账，保留了 feed。这不是一条可以略过的注脚。它意味着这份标准里今天仍然和你有关的，恰恰是最枯燥的那一半——AI 助手在决定要不要提到你之前，会先读的那几列结构化商品数据。
如果你做家具、五金配件或建材，这份规范里有一句话值得整篇文章的篇幅：回答“装得下吗”的那些字段，全都是可选的。
走到今天的四步
| 时间 | 发生了什么 | 对卖家意味着什么 |
|---|---|---|
| 2025 年 9 月底 | Stripe 与 OpenAI 发布 Agentic Commerce Protocol，并在 ChatGPT 上线 Instant Checkout，首批覆盖美国 Etsy 卖家和 Shopify 商家 | 两件活一起压过来：交一份商品 feed，再打通由代理发起的结账 |
| 2025 年底到 2026 年初 | 对话内下单的采用一直很薄，买家却持续在助手里做调研、回到卖家自己的站点付款 | 真正在干活的是“发现”这一半，不是“结账”那一半 |
| 2026 年 3 月 | OpenAI 终止 Instant Checkout，转向 ChatGPT 内的商品发现与零售商对接 | 结账集成不再是紧急事项 |
| 现在 | Product Feed Specification 仍然是你的商品库和助手之间的接口 | feed 质量就是全部胜负 |
这条曲线给出的结论不好看，但耐用：会过期的是支付管道那部分对接，会滚成雪球的是数据。
AI 购物代理商品数据源是什么
AI 购物代理商品数据源，是一份定期刷新、可被机器读取的商品库文件——编号、标题、描述、价格、库存状态、图片视频、履约信息和物理属性——AI 助手把它读进去，才能在一段对话里把你的商品捞出来、筛掉一部分、和别家放在一起比。它不是对你网站的爬取，也不是你店铺页面的 HTML。它是你主动交出去的一份平铺文件，一行一个商品或一个变体。
按现行规范，机制上这份文件是 UTF-8 分隔文本——.txt、.tsv 或 .csv，制表符或逗号分隔，允许 gzip 压缩——表头行必须全小写、用下划线连接。文件里每一个 URL 都必须返回 HTTP 200。卖家先提交一份初始样本 feed 供校验，之后每天推送快照，系统最快接受每 15 分钟一次更新。
HTTP 200 这条要求值得单独停一下。图片 URL 挂掉，不是把这一行的排序压低一点，而是让这一行直接失效。CDN 链接断了，是从助手答案里消失的最安静的一种方式。
字段清单：按“忽略它的代价”分档
下面是规范目前的形态。要看的不是这份清单本身，而是每个字段落在哪一档。
| 档位 | 字段 | 说明 |
|---|---|---|
| 必填 | item_id、title、description、url、brand、image_url、price、availability、seller_name、seller_url、target_countries、store_country，以及 is_eligible_search / is_eligible_checkout / is_ads_eligible 三个开关 |
title 上限 150 个字符，description 上限 5,000，brand 和 seller_name 上限 70 |
| 有条件必填 | gtin 或 mpn，除非把 identifier_exists 置为否；预售和缺货补单要给 availability_date；return_policy；开启结账时还要给卖家隐私政策和条款 |
缺编号是从其他所有 feed 标准一路带过来的经典静默压制 bug |
| 推荐 | group_id、listing_has_variations、variant_dict、size、size_system、q_and_a、reviews、related_product_id 配 relationship_type |
relationship_type 接受 part_of_set、required_part、often_bought_with、substitute、accessory 这类取值 |
| 可选 | dimensions、length、width、height、dimensions_unit、weight、item_weight_unit、material、condition、product_category、additional_image_urls、video_url、model_3d_url、return_rate、popularity_score、warning、age_restriction |
你商品身上所有物理属性，全住在这一档 |
回头再看最后一行。image_url 是必填。length、width、height 和 dimensions_unit 是可选。而买家丢给助手最多的那类问题——这个能塞进我的空间、我的车、我现有的框架吗——靠的恰恰是大多数 feed 留空的那批字段。
尺寸缺口，以及它为什么是个口子
可选不等于会被忽略。可选等于不强制，而在 feed 这门经济学里，“不强制”是一个字段能拥有的最有意思的状态：所有同行都被允许跳过它，而大多数真的跳过了，因为把几千个 SKU 的 length / width / height / dimensions_unit 填齐是实打实的工作量，而且从来没有哪份结账报错日志会因为它空着而报警。
被问到“找一个宽度不到 80 cm、能塞进壁龛的书架”时，助手只能在 width 有值、且能解析出来的行里挑。照片再漂亮、width 却是空的那一行，不是在这条查询里排得靠后——它根本不在候选池里。照片不是兜底方案。没有哪个助手会去量你的 JPEG。
由此有三个可落地的结论：
- 先把物理字段填完，再谈别的优化。
dimensions收一个紧凑字符串，例如12x8x5 in；length、width、height各收一个单值，单位交给dimensions_unit写in或cm。数据允许的话，组合字段和单个字段都填——不同的消费方解析的不是同一个。 - 每一行都显式写上
dimensions_unit。 一个没有单位的80不是尺寸。这和商品详情页上犯的是同一个错，商品尺寸结构化数据那篇写过。 - 把
material、weight、item_weight_unit当成同一个模块。 材质是买家筛“要实木橡木、不要贴皮”的依据；重量是懂物流的买家筛“一个人能不能搬上楼”的依据。
规范里还带了一个可选的 return_rate 字段，用百分比表示。不管助手拿这个信号去做什么，它出现在 schema 里这件事本身就值得琢磨：退货表现从此是一个结构化、可横向比较的商品属性，而不再是你内部的私有指标。如果你从来没给“每个 SKU 的退货成本是多少钱”算过一个数，退货率计算器是拿到这个数最快的方式。
feed 解决不了的那一半
feed 数据让你进候选名单。它成不了单，因为买家最后还是落在你自己的页面上。
这个交接环节，正是很多本来做得不错的 feed 工作悄悄漏水的地方。助手告诉买家这个书架宽 78 cm；买家点进来，看到的详情页全是布景样板间照片，哪儿都没有一个尺寸。没有任何东西确认助手刚说过的那句话。最常见的两种结局：一条你得手动回的售前咨询，或者一笔靠猜下单、最后以尺寸不合退回来的订单。
把这个环闭上，是视觉活，不是数据活。它意味着详情页上要有一张图，把真实、量过的尺寸标在商品本身上——和 feed 里声明的是同一组数字，出现在买家眼睛已经落到的位置。“测量必须是确定的”这件事，在这里第一次变得格外重要：feed 里的数字和图上的数字，现在可以被机器交叉核对，而一张 AI 生成、顺手编了个看起来合理的尺寸的图，会在公开场合和你自己的结构化数据自相矛盾。
下一步，按回本速度排序
挑你这个季度真能做完的那一档。把其中一件彻底做完，胜过每一件都只开个头。
- 先审无效行。 任何不返回 HTTP 200 的
url或image_url都会把整行拖废。这是一个下午能写完的脚本，通常也是单笔最大的一次挽回。 - 修编号。 把
gtin或mpn填上，或者老老实实设identifier_exists。静默压制比一个你看得见的报错更糟。 - 填物理字段那一块。
length、width、height、dimensions_unit、weight、item_weight_unit、material——先做最好卖的 SKU，再按销售额往长尾走。 - 把变体结构做对。
group_id、listing_has_variations和variant_dict是助手理解“60 cm 版和 80 cm 版是同一个商品”的方式，理解了它才能把装得下的那一个递给买家。 - 让 feed 里的数字和页面图片对上。 无论你靠内部设计流程、外部设计公司，还是靠能把量好的尺寸锁在照片上、并按各平台图片尺寸导出的软件，目标都一样：助手报出来的那个数字，在它把买家送去的那个页面上看得见。同一批商品铺在多个渠道上的话，多平台销售实战里的排序建议在这里同样适用。
- 然后再去管
reviews、q_and_a、popularity_score这些增强档字段。
常见问题
Instant Checkout 都下线了，我还需要商品 feed 吗？
需要，而且比以前更需要，因为现在 feed 就是整个对接，不再只是其中一半。对话内下单在 2026 年 3 月被终止，商品发现没有。助手是通过 feed 才知道你的商品库存在的，而结账依然发生在你自己的站点上。
Agentic Commerce Protocol 是什么？
Agentic Commerce Protocol 是 OpenAI 与 Stripe 联合开发的开放规范，2025 年 9 月底发布，定义了卖家如何与 AI 代理交换商品数据、购物车和订单信息。其中的 Product Feed Specification，就是规定你的商品库该怎么被描述的那部分。
哪些 feed 字段能让 AI 购物代理按尺寸筛选？
length、width、height 配 dimensions_unit，加上组合字符串 dimensions，以及 weight 配 item_weight_unit。它们全部落在规范的可选档——这就是为什么大多数商品库没法按“装不装得下”来筛，也是为什么把它们填满，是 feed 这块所剩不多的便宜优势之一。
AI 购物代理商品数据源要多久刷新一次？
卖家先提交一份初始样本 feed 供校验，之后每天推送快照，更新最快可以到每 15 分钟一次。每天一次是实际的工作基准；15 分钟这个上限是为价格和库存波动准备的，不是让你把一个没变过的商品库反复重报一遍。
一张好照片能补上缺失的尺寸字段吗？
不能，而这个假设是最该先丢掉的一个。照片是渲染给人看的；决定你能不能进候选名单的筛选，发生在文本字段上。做匹配的那套系统量不了照片——照片只能替人确认字段早已声称过的东西。