食品批發訂單有多亂？規格、單位、時價的四個辨識難題
凌晨一點半，餐廳收完最後一桌。採購在 LINE 群組丟了一句：「明天大白 2 箱、蔥 5 斤、五花切片 10 斤，中午前要到。」
三點，另一家客戶傳來一張手寫單的照片，字跡潦草，最後一行寫著「小卷 3 尾，看時價」。
早上六點，你的助理打開手機，未讀訊息 47 則。她得在八點出貨前，把這些訊息變成 ERP 裡的一張張銷貨單。
食品批發的訂單就是這樣進來的。你可能已經試過幾套下單系統，也可能被業務推銷過「一鍵匯入」，但真正做過的人都知道：食品批發訂單難的從來不是「打字很慢」，而是這些訊息本身就不是訂單——它是一段需要翻譯的對話。
為什麼食品批發的訂單是自動化最難啃的一塊
先看規模。根據財政部資料，台灣餐飲業的營利事業家數從 2021 年的 160,138 家成長到 2025 年的 178,946 家，銷售額在 2025 年突破 9,000 億元（台灣趨勢研究整理）。這近 18 萬家店，每一家都是某個食品批發商的下單來源。
再看他們的處境。同一份分析引述經濟部統計處「114 年批發、零售及餐飲業經營實況調查」指出，「食材成本波動大」已經是餐飲業者近兩年最感棘手的難題，比例都在六成五以上，排序甚至超過人力短缺與租金。成本會波動，代表價格不是固定的；價格不固定，訂單就沒辦法在下單當下算出金額。
這兩件事加起來，就是食品批發訂單的本質：下游極度分散、上游價格浮動、中間全靠人腦翻譯。
同樣是 B2B 訂單，工業零件的訂單有料號、有固定單價、有標準包裝，格式一致就能自動化。食品批發沒有這些。下面四個難題，是我們實際接觸生鮮、畜產、食品進口的批發商時，最常卡住自動化的地方。
難題一：規格黑話——每家客戶都有自己的品名
同一顆高麗菜，在你的 ERP 裡是「高麗菜（初秋）8 kg/箱」。
但客戶不會這樣說。有人說「大白」，有人說「初秋」，有人說「一般的菜」，有人只丟兩個字：「菜，兩箱」。同一句「大白」，在賣蔬果的和賣海鮮的口中還可能指完全不同的東西。
畜產更明顯。「二級品」「A 貨」「一般貨」這種等級行話，每家批發商的定義都不一樣，甚至同一家批發商對不同客戶的定義也不一樣——因為那是多年來喊價喊出來的默契，從來沒寫進任何一張表。
這代表什麼？品名的對應關係沒有標準答案，只有「這個客戶的答案」。 任何一套想靠統一品項字典解決問題的系統，在這裡都會撞牆。你得為每個客戶記住他自己的說法。
老員工之所以難取代，就是因為這份對照表存在她腦子裡。她離職那天，帶走的不是打字速度，是這份翻譯能力。
難題二：單位換算——箱、件、斤、公斤、尾
台灣的食品批發同時活在兩套計量系統裡。
法律上，《度量衡法》第 10 條規定法定度量衡單位以國際單位制為準，第 13 條更寫明「交易或證明有使用度量衡單位時，應使用法定度量衡單位」（經濟部主管法規查詢系統）。也就是說，ERP、發票、正式單據上該用公斤。
但市場上沒人這樣講話。客戶說斤就是台斤，1 台斤 = 600 公克 = 0.6 公斤。翻開國家度量衡標準實驗室的質量單位換算表會看到一件有意思的事：公克、公斤、公噸旁邊標著「法定度量衡單位」，台斤沒有（NML 質量單位換算）。全台灣的生鮮交易，天天都在用一個不是法定單位的單位在喊價。
而且同一個品項，不同客戶用的單位還不一樣：
| 客戶說的 | 實際意思 | ERP 要存的 |
|---|---|---|
| 「大白 2 箱」 | 1 箱 = 8 kg | 16 kg |
| 「蔥 5 斤」 | 台斤 | 3 kg |
| 「五花 10 斤，切片」 | 台斤 + 加工需求 | 6 kg，加工註記 |
| 「小卷 3 尾」 | 論尾計價，重量出貨才知道 | 3 尾，重量待補 |
| 「牛奶 1 件」 | 1 件 = 24 瓶 | 24 瓶 |
「箱」和「件」的問題最陰險，因為它們不是計量單位，是包裝單位——而包裝規格會改。供應商換了包材，一箱從 10 台斤變成 6 公斤，過去所有的換算邏輯就全錯了，而且錯得很安靜，直到對帳才爆出來。
市場上有系統在處理這一段。台灣的「農易訂」（凌聚科技）就把「斤兩與公斤單位換算」列為主打功能之一（智慧高軟活動頁），這說明單位換算不是我們自己想像出來的問題，是整個產業共同的痛。差別在於：純換算解決的是「數字轉換」，而真正的難點是先判斷客戶說的「斤」是哪一種斤、「箱」是哪一種箱。
難題三：時價品——下單時還沒有價格
葉菜、海鮮、部分畜產是時價品。客戶下單的那一刻，這批貨的價格還不存在。
台北農產運銷的單日交易行情就是這樣運作的：每天拍賣結束後，才依當日總交易量加權平均計算出上價、中價、下價（臺北農產運銷單日交易行情查詢）。也就是說，價格是後於訂單產生的。
這對自動化是個結構性的挑戰。多數訂單系統的預設假設是「品項 × 單價 = 金額」，三個欄位必須同時到位才能建單。但食品批發的真實流程是：
- 客戶深夜下單，只有品項和數量
- 清晨採購進貨，價格才定下來
- 出貨秤重，重量才確定
- 出貨後或月底，才算得出金額
強行要求下單當下就有價格，結果就是助理先隨便填一個數字、事後再回頭改，或者乾脆先記在筆記本上、等價格出來再一起 key。兩種做法都會製造對帳的爛帳。
農易訂公開的功能清單裡也列了「時價報價機制」。這是產業共識：時價不是例外，是常態，系統本來就該支援。
難題四：晨間尖峰——訂單集中在打烊後到天亮前
第四個難題不在訂單內容，在時間。
餐廳客戶什麼時候有空下單？打烊之後。也就是晚上十一點到凌晨三點。而你要出貨的時間是早上七、八點。
這中間的空窗有多要命：訂單在深夜堆積，你的人早上六點才開始處理，兩個小時內要看完幾十則訊息、翻價格、換單位、key 進系統，還要接應臨時追加的電話。一天的錯誤率有一大半是在這兩小時裡產生的。
多請一個人也不太解得了。這是尖峰負載問題，不是總工時問題——你請的人在下午沒事做，在清晨還是趕不完。經濟部統計處的同一份調查顯示，人力短缺、人事成本過高、人員流動率高三項，在餐飲相關業者的經營困境前五名裡就佔了三席。在批發端，情況也差不多。
AI 怎麼處理食品批發訂單的這四題
把四個難題攤開來看，會發現它們需要的不是同一種能力。這也是為什麼「導入一套系統就解決」通常是空話。
| 難題 | 本質 | 需要的機制 |
|---|---|---|
| 規格黑話 | 每個客戶一套語言 | 客戶專屬詞庫，隨訂單累積校正 |
| 單位換算 | 包裝與計量混用 | 品項 × 客戶的單位對應表，含包裝規格版本 |
| 時價品 | 價格後於訂單產生 | 價格待定流程，數量與金額分兩段落地 |
| 晨間尖峰 | 負載集中，不是總量大 | 訊息進來即時處理，不等人上班 |
客戶專屬詞庫
不是一份全公司通用的品項字典，而是「客戶 A 說『大白』＝品號 V0231」這種一對一的對應。這份詞庫的第一版可以從歷史訂單與出貨紀錄自動建起來，之後每一次人工修正都回寫進去。判斷不確定的訂單不硬猜，標記出來給人確認——這比一個看起來很自信卻猜錯的答案安全得多。這一層「讀懂」的能力，和單純把圖片轉成文字的 OCR 是兩件事，我們在OCR 訂單辨識 vs AI 訂單理解裡拆解過差別。
單位對應表要綁包裝規格版本
「1 箱 = 8 kg」這個關係要能記錄生效日期。供應商換包材時改一筆設定，而不是回頭修幾百張單。這一點在畜產這種重量計價的品類尤其關鍵，元榆牧場的案例裡台斤與公斤的換算就是每天都要碰的事。
價格待定，訂單照走
AI 在解析訂單時就把時價品標記出來，數量先進系統、金額欄位留待定。當天行情或秤重結果出來後統一帶入。重點不是 AI 算得出價格——AI 算不出來，市場才知道——而是訂單流程不因為缺一個欄位就停住。
尖峰的解法是「不排隊」
訊息在凌晨一點半進來，就在凌晨一點半被解析成結構化訂單。等你的人早上六點打開系統，看到的不是 47 則未讀訊息，是 47 張已經整理好、其中 5 張標記需要確認的訂單單。人的工作從「翻譯」變成「複核」。
而這整套的前提是：客戶完全不用改變下單習慣。他還是在同一個 LINE 群、用同樣的口氣、在同樣的時間下單。改變的是你這一端。要求餐廳採購改開 App、逐項點選，等於把你的作業成本轉嫁給他——這也是多數 B2B 下單平台推不動的真正原因。想看完整比較，可以參考客戶用 LINE 下單，訂單怎麼自動進 ERP。
什麼情況下，先別急著自動化
說完能做什麼，也該說什麼時候不划算。
每天訂單少於十來張、而且客戶都固定訂同樣的東西。 這種情況複製上一張單就好，導入系統的設定成本和學習成本，很可能高過省下來的時間。
品項少於三十項、單位單一、沒有時價。 上面四個難題你只中了半個，一份設計良好的 Google 表單或既有 ERP 的快速建單功能可能就夠了。
你的 ERP 沒有 API、也不打算換。 資料進不去，前面理得再乾淨都是白工。這件事要在評估的第一天就問清楚，不要等到導入才發現。
你正在換 ERP 或改料號體系。 詞庫和單位對應表都建立在品號之上，底層還在動的時候建上層，等於做兩次。
誠實講，食品批發的訂單自動化不是裝好就跑。詞庫要養、對應表要維護、例外要有人複核。它省下來的是每天清晨那兩小時的翻譯工，不是把人整個換掉。
如果你每天面對的就是那 47 則深夜訊息、那些各說各話的品名、和一堆還沒定價的時價品，那這件事值得評估。如果不是，把力氣花在別的地方可能更划算。
常見問題
食品批發的訂單，AI 真的看得懂那些行話嗎？
看得懂，但不是靠通用模型憑空猜，而是靠一份「客戶專屬詞庫」。同一顆高麗菜，這家客戶叫「大白」、那家叫「初秋」、第三家只說「菜」，這種對應關係沒有標準答案，只能從該客戶過去的訂單與出貨紀錄一筆筆建起來。詞庫建起來之後，AI 判斷的正確率會隨著訂單累積上升。真正該問的不是「AI 懂不懂」，而是「這套系統能不能為每個客戶記住不同的說法」。
時價的品項下單時沒有價格，這種訂單怎麼自動化？
把「數量」和「價格」拆成兩段處理。下單當下 AI 只負責確定品項與數量，價格欄位標記為待定，訂單照樣進系統、照樣排出貨。等當天行情出來或秤重完成，再由系統帶入單價、算出金額。多數 ERP 本來就支援「先出貨、後計價」的流程，卡住的通常不是系統，而是價格資訊還留在某個人的腦袋或紙條上。
導入之後，我的餐廳客戶要改用 App 下單嗎？
不用，這是重點。餐廳採購深夜打烊後用 LINE 丟一句「明天青蔥 5 斤、豬絞肉 10 斤」，是最省他力氣的方式；要他改開 App、選品項、填數量，等於把你的作業成本轉嫁給他。多數下單平台導入失敗都卡在這裡。合理的作法是客戶端維持原樣，由你這端的 AI 把非結構化訊息讀成結構化訂單。