數據與報表
怪 AI 之前，先統一產品欄位
AI 助手讀你的產品表，無論欄位是否對得上，都會給出一個看似肯定的答案。模型本身不會告訴你，哪一個答案是從一行乾淨的資料得出。真正要處理的在上游：每個欄位一套用語，每個 SKU 一行，加上每晚一次掃描，明確講出哪些行仍然欠資料。
- 觸發
- 兩個
- 執行頻率
- 寫入時，加每晚一次
- 工具
- 4 件
- 需要 durable execution
- 不需要
流程
兩個觸發、一個判斷。上面那條在資料進來時即時清理，下面那條每晚掃描整張表，把可以用的行同仍然要人處理的行分開。
新產品資料進來
Sheets · Airtable
模型標記自由文字
OpenAI · Anthropic
一個 SKU 一行
Sheets · Airtable
每晚一次
n8n 排程
撈出仍然欠資料的行
n8n · Make
必填欄位是否齊全？
n8n IF
標記為可使用
Sheets · Airtable
把缺口交給負責人
Slack · WhatsApp
逐步拆解
- 01
新產品資料進來
Sheets · Airtable可以是供應商檔案、平台匯出，或者同事逐行輸入。入口是哪一個並不重要，之後全部行同一道門。
- 02
模型標記自由文字
OpenAI · Anthropic模型只在你固定的清單裡選一個分類，並從描述中抽出屬性。它只做分類同抽取，不會計算任何數字。價格、重量、庫存一律原樣搬過去，或者留空。
- 03
一個 SKU 一行
Sheets · Airtable每次都是同一組欄位名、同一個單位、同一種日期格式。同一個 SKU 用兩種寫法出現兩次，正是這一步要攔住的問題。
- 04
每晚一次
n8n 排程定時掃描整張表。只在寫入時清理，之前已經錯了的行會一直錯下去。
- 05
撈出仍然欠資料的行
n8n · Make分批讀取，不要一行發一次請求。API 配額以分鐘計算，逐行迴圈正是把配額用光的做法。
- 06
必填欄位是否齊全？
n8n IF只比對你事先定為必填的那幾個欄位，不是比對整張表所有欄位。
- 07
標記為可使用
Sheets · Airtable用一個欄位標明哪些行容許 AI 工具讀取。之後的答案來自已經核對過的行，不是來自整張表。
- 08
把缺口交給負責人
Slack · WhatsApp寫明是誰負責、是哪幾行、欠哪幾個欄位。沒有人負責的清單只是報表，而報表不會自己補回。
平台不容許的事
頭兩項界定模型可以保證什麼；第三項界定你可以用多快的速度讀這張表。
結構化輸出只保證回覆符合你提供的 JSON Schema——文件寫明模型「will always generate responses that adhere to your supplied JSON Schema」。它管的是格式，不是那個值是否正確。
OpenAI — Structured Outputs所有欄位必須標為 required，物件必須設定 additionalProperties: false。所以即使模型判斷不到，那個欄位仍然會回傳；你需要一個明確的「未知」值，而不是一個缺席的鍵。
OpenAI — Structured OutputsSchema 不支援數值限制（minimum、maximum、multipleOf）和字串長度限制（minLength、maxLength），所以價格範圍只能在呼叫之後另行檢查。正規表達式驗證是支援的，所以 SKU 格式可以直接寫進 schema。
Anthropic — Structured outputsSheets 每個專案每分鐘容許 300 次讀取同 300 次寫入，每個使用者每分鐘 60 次；配額每分鐘重新補滿，之上沒有每日上限。
Google Sheets API — Usage limits
什麼情況不值得做
以下三種情況，維護成本會高於資料不一致的代價。
產品數量仍然少到一個人記得住每個 SKU。他發現壞資料會比每晚掃描更快，掃描反而變成另一個沒人留意的環節。
大家未就欄位的定義達成共識。在未定義的用語上做自動化，只會產出一致地錯的資料，而這比明顯的混亂更難察覺。
沒有人負責補回缺口。每晚那張清單要送到一個本身就要處理它的人手上才有用，否則你只是自動化了「生成清單」這件事。