「AI 對我們沒有用」——問題其實幾乎總在上游那幾個從來沒統一過的欄位

一間 SME 拿現有的真實產品目錄去試一件 AI 工具，結果得出不一致或錯誤的答案，通常是診斷錯了層次。模型並沒有誤解要求；它被餵入的，是一批由這一行到下一行都不代表同一件事的資料，而它照樣產出一個自信的答案——因為這就是這類工具對任何輸入的做法：在輸出那一刻，自信而錯與自信而對，看上去完全一樣。我們見過的大部分個案，真正的修補不是換一件更好的工具，而是修回底層那個目錄。

「乾淨到可以給 AI 用」實際要求甚麼

Google Merchant Center 的產品資料規格在這裡是有用的參考，不是因為大部分 SME 直接把資料餵入 Merchant Center，而是因為它是一個做足功夫的範例，示範了一部大規模處理產品資料的機器要運作起來，實際需要甚麼：每件貨一個穩定唯一的 ID、一個受長度限制的結構化標題與描述、一個符合指定數字與貨幣格式的價格、一個由固定允許值表達的庫存狀態（in_stock、out_of_stock、preorder、backorder——不是自由文字）、一個在商品需要時才填的品牌欄位，以及一個把同一產品的呎碼或顏色 variant 串連起來的 group identifier。文件亦講得很清楚，甚麼會令整條 pipeline 斷開：缺少必填產品資料可能令產品無法刊出；不準確的資料可能造成審批與質素問題；而 Google 對價格的指引另外要求 feed 價格必須與上架頁面、結構化資料及結帳一致——即三個系統必須對同一件事說法一致。

這張清單，對任何一件接入自家目錄的 AI 工具都是合理的檢查清單，不限於購物 feed。一個要回答客人庫存查詢、生成產品描述或處理退貨的 agent，需要的與 Google 規格需要的完全一樣：一個所有系統都認同的穩定產品識別碼、一個以固定值域表達而非員工當日隨手打上的狀態欄位，以及一個唯一的價格來源，而不是三張各自漂移、任何一張被人手改過之後就開始對不上的試算表。

SME 目錄實際在哪裡斷開

我們最常見的樣式不是資料缺失，而是同一件資料存在於三個地方，而每個地方的意思都有些微差別。在網店後台改了的價格，沒有同步到 agent 所對着的試算表。一個「顏色」欄位，在一個渠道是受控下拉選單，在另一個渠道是自由文字，於是「Navy」、「Navy Blue」與「深藍」變成三個各自指向同一件貨的值。一個庫存狀態，在人手盤點那一刻是準確的，之後兩星期直到下次盤點都已經過時。這些全部都不是 AI 問題，而是一直存在於 SME 營運之中的普通資料質素問題。分別在於由誰去對數：以前是人手憑判斷靜靜地對回來，而自動化工具甚麼都不會對——它照單全收欄位的字面值，並據此行動。

Variant 屬性這個個案特別值得點名，因為它會複合放大。Google 的規格要求以一個 Item Group ID 串連同一產品的呎碼與顏色 variant；這個識別碼一旦出錯或不一致，建在目錄之上的每一個下游系統，無論是否 AI 驅動，都會繼承一批看似獨立產品的 variant，或看似重複 variant 的產品。這正是關於「自動化在哪裡值得做」那篇提到的對應層失敗：API 驗證的是資料的形狀，不是這個形狀是否代表正確的意思。

揀工具之前該做甚麼，而不是之後

先揀一個大部分 AI 工具最先會碰到的欄位——通常是庫存狀態或價格——確認它只存在於一個所有系統都從那裡讀取的位置，而不是三個要靠人手同步的位置。凡是自動化會據此分支決策的欄位，都要把詞彙統一：用一張固定的狀態列表，而不是自由文字；每個屬性值在各渠道之間只有一種寫法，而不是同一個字的三個變體。並且為每件產品指定一個穩定的 ID，這個 ID 要捱得過重新上架、渠道遷移與改名——因為此後建立的每一個自動化，無論是否 AI，可靠程度都只等於它用來第二次找回同一件產品的那個識別碼。

所以呢

在拿新 AI 工具去試目錄之前，先做那個較小的測試：揀十件產品，檢查它們的價格、庫存狀態與 variant 分組，在目前接觸這些資料的每一個系統之間是否一致。如果今日已經不一致，任何工具疊上去都不會令它們變得一致——它只會用碰巧讀到的那一個版本的資料，產出一個自信的答案。這個在揀工具之前、而不是在工具令人失望之後才做的資料就緒檢查，正是開發中的 ELELAND AI（eleland.ai）帶 SME 賣家走的第一步。