十一頁資料、二十分鐘人工、一次點擊：電商上架核驗這筆體力活帳，被兩個模型拆開算

2026年9月17日，掘金平臺上一位開發者發布了一篇實測文章，記錄他用藍耘元生代 MaaS 平臺，把電商商品上架前的資料核驗流程從人工約二十分鐘壓縮到一分半。這不是大模型又拿下一個基準測試的故事，它動到的是一個更小的單位：一件商品上架前，那筆重複發生的合規核對工時。

先把規模感建立起來。一個商品要上架，需要六份文件：產品說明書（研發提供）、檢測報告（第三方機構出具）、品牌授權書（品牌方簽署）、平臺發布規則（平臺下發）、商品參數表，以及運營寫的待發布文案。這六份文件來自五、六個不同主體，彼此之間唯一必須成立的事情是關鍵欄位一致：型號、淨含量、品牌名、生產企業、授權渠道、授權有效期。任何一項對不上，輕則被平臺駁回重提，重則按虛假宣傳處理。

該開發者手頭這套文件合計十一頁，逐項人工核完約二十分鐘。他對這項工作的定性很直白：純體力活，人一累就漏。

成本結構：這二十分鐘貴在哪裡

把二十分鐘放進電商運營的成本表裡看。假設一名運營人員月薪人民幣一萬元，每月約二十二個工作天、每天八小時，其每分鐘人力成本約 0.95 元。二十分鐘核驗對應約 19 元的人力成本，單看一次不痛不癢。

問題在頻率。一家鋪貨型電商商家 SKU 動輒數百到數千，新品上架、資料更新、平臺規則改版後的批量覆核，每一次都要重跑這套核對。以一千個 SKU 每季覆核一次估算，一年就是四千次核驗、約一千三百小時的人力投入，相當於半個以上人力的全年工時被鎖在欄位比對上。這類成本的特徵是：單筆小、頻次高、出錯的罰則不對稱。漏核一項授權有效期，對應的可能是商品下架、平臺罰款乃至虛假宣傳的行政責任，罰則金額遠高於核驗工時成本的數量級。

所以這個環節的價值不在「省二十分鐘」，而在把一個出錯率隨疲勞度上升的人工環節，換成出錯率可量測、可複現的自動環節。

為什麼一個模型幹不完：兩種能力，兩種定價

這篇實測最有參考價值的部分，是它誠實記錄了失敗的第一版方案。開發者最初把全部文件連同 base64 轉碼的包裝圖丟給單一模型，一次請求解決所有問題。結果是：同一個模型在長文檔上判斷很細，到圖片上就含糊，包裝上的品牌名和淨含量經常讀錯，或者直接回覆「圖片未顯示相關資訊」。反過來，多模態能力強的模型做文檔級合規判斷又不夠細，把「醫美級修復」這類暗示醫療效果的措辭放了過去。

這裡的結構性原因值得拆開。文本文查喫的是上下文長度和邏輯推理，要在一萬多字的材料裡找欄位衝突，還要判斷一句宣傳語是否踩到廣告法的線；圖片識別喫的是視覺解析，要在包裝圖上把品牌、品名、型號、淨含量逐字符讀出，一個字符不能錯。前者對應的是長上下文模型的定價檔，後者對應全模態模型的定價檔，兩種能力的單價與供給本來就分層。

最終方案是拆開：文檔交給 qwen3.8-max，該模型提供 1000k 上下文；圖片交給 qwen3.5-omni-plus，256k 上下文的全模態模型，結果在本地合併。這與我們先前分析的Agent 工作流裡判斷環節的定價帳是同一條邏輯：當任務可以按能力需求切分，採購方就沒有必要為整條流程買最貴的那一欄。

讓雙模型方案成立的另一個前提，是平臺側的閘道設計。藍耘作為統一網關，文字模型和視覺模型共用同一組 API 憑證，左側供應商列表包含 DeepSeek、智譜、MiniMax、Google、xAI、百度。對接入方而言，換模型只改配置檔裡兩個模型名欄位，不需要為每個模型重新走一次申請流程。這降低的是試錯成本：開發者可以拿三個模型跑同一張包裝圖做對比，再決定留下哪一個。

影響推演：誰受惠，誰承壓

受惠端首先是中長尾商家與代運營公司。他們沒有自建合規團隊的預算，人工核驗成本佔營運支出比重最高，二十分鐘壓到一分半意味著這一欄工時成本降到原來的十分之一以下，且不受人員疲勞影響。其次是 MaaS 聚合平臺本身：當應用場景被拆成「多模型、單憑證」的採購結構，聚合器的價值就從單純轉售 token，上移到模型選型與切換的摩擦成本管理。

承壓端有兩個。一是做單點合規審核 SaaS 的工具廠商，如果其產品底層就是「調用一個模型跑完文檔」，單模型方案在圖片欄位的出錯率會直接侵蝕其可靠性定價。二是企業內部承接這類重複核對的初級運營崗位，這一環節的自動化不會消滅崗位，但會改寫崗位的內容：從欄位比對轉向異常覆核與規則維護。

傳導機制也清楚：核驗成本下降，降低的是上架的邊際成本，邊際成本下降會讓小批量、多 SKU 的鋪貨策略變得相對劃算，這對平臺側的審核吞吐量反過來形成壓力。自動核驗產出的是結構化的衝突清單，不是免檢證明，最終責任仍在商家與平臺之間，工具只是把「誰來發現不一致」這一欄從人工搬到模型。

收束判斷

這篇實測的樣本很小：一套十一頁文件、一次二十分鐘的對照、幾次模型比對。它不能證明所有品類的合規核驗都能壓到一分半，醫療器械、保健食品這類強監管品類的規則密度遠高於一般消費品，模型漏判的法律後果也不同。開發者自己也保留了跑分對比環節，沒有給出量化的準確率數據。

但帳是算得動的。當核驗工時從二十分鐘降到一分半，這一環節的性質就從人力瓶頸變成了 API 帳單上的一行，可以按次核算、按月對比、按出錯率驗收。這與我們在AI 做財報橫向分析的驗證成本帳看到的是同一件事的兩個側面：可核驗性本身就是一種成本，誰能把驗證環節做得又快又留痕，誰就拿到下一輪採購的定價權。對電商這個以 SKU 數量計費的產業，這筆帳會先從鋪貨型商家開始付，再往上遊的代運營與工具廠商傳導。