對話內結帳那顆按鈕已經收掉了，當初為它而生的那份商品資料卻留了下來。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 標準一路帶過來的經典靜默壓制問題 |
| 建議 | 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 分鐘這個上限是為價格與庫存波動準備的，不是讓你把一份沒變過的商品目錄重報一遍。
一張漂亮的商品照能補上缺漏的尺寸欄位嗎？
不能，而這個假設是最該先丟掉的一個。照片是渲染給人看的；決定你進不進候選名單的篩選，發生在文字欄位上。負責配對的那套系統量不了照片——照片只能替人確認欄位早就宣稱過的東西。