上周幫一位做家居百貨的賣家朋友處理店鋪申訴他的天貓店因為主圖上印了“全網(wǎng)銷量第一”被系統(tǒng)抽檢下架。這個違規(guī)表述其實在商品資料包里躺了半個多月前后經(jīng)過運營、美工、店長三個人之手愣是沒人察覺。也就是在那一周我用 Qwen3.8-Max 搭了一個商品資料包體檢助手把包含 6 份文檔資料和 1 張商品主圖的完整資料包一次性丟進去不到十分鐘就拿到一份 27 個問題的體檢報告。其中至少有 5 個問題是人工審查幾乎必然遺漏的——包括那個“全網(wǎng)第一”。這篇文章不聊概念直接把我搭建這套助手的過程、體檢維度設(shè)計、Prompt 寫法、實測踩坑全部攤開。做電商運營、商品管理、內(nèi)容審核的朋友或者正在研究大模型落地應(yīng)用的同學(xué)都可以照著這套思路改造出適合自己業(yè)務(wù)場景的版本。不需要復(fù)雜的算法基礎(chǔ)核心就是一個大模型 API 加一段可靠的數(shù)據(jù)解析腳本。1. 電商資料包的“隱形體檢需求”為什么非做不可1.1 一份商品資料包里到底藏了多少雷先還原一下我處理的那套商品資料包。它是一個廚房收納置物架產(chǎn)品共包含 6 份資料和 1 張主圖文件格式典型內(nèi)容商品標(biāo)題文案Word標(biāo)題、副標(biāo)題、賣點關(guān)鍵詞詳情頁文案Markdown五張詳情圖對應(yīng)文案、產(chǎn)品故事、場景描述規(guī)格參數(shù)表Excel材質(zhì)、尺寸、承重、容量、顏色等結(jié)構(gòu)化參數(shù)客服話術(shù)文本售前問答、售后話術(shù)、價格解釋、物流說明活動利益點Word大促利益點、優(yōu)惠券規(guī)則、贈品信息合規(guī)自查表Excel平臺審核要求、禁用詞清單、素材要求商品主圖PNG電商平臺首圖含產(chǎn)品圖、促銷文案、標(biāo)識多平臺運營的團隊這套資料還會衍生出天貓版、京東版、拼多多版、抖音版每個平臺對違禁詞、宣傳規(guī)范的要求不完全一致。這些文件分散在不同人手里運營改一版標(biāo)題客服話術(shù)里還是舊價格美工更新了主圖詳情頁文案里還在用舊賣點——這種不一致在團隊協(xié)作中幾乎每天都在發(fā)生。1.2 人工體檢的天然盲區(qū)有人會說這些東西讓有經(jīng)驗的人過一遍不就行了問題在于“有經(jīng)驗的人”看一份資料包需要多久。我之前專門測算過一個熟手把 6 份資料完整過一遍至少需要 40 到 60 分鐘。這還是在只做快速瀏覽的情況下。如果要做到真正的交叉一致性檢查——比如把規(guī)格參數(shù)表里的“承重 30kg”和詳情頁里的“承重 60 斤”做單位換算核對把客服話術(shù)里的價格和活動利益點里的到手價做比對——時間還要翻倍。而人眼的疲勞曲線決定了連續(xù)排查到第 30 分鐘之后漏檢率會直線上升。更重要的是人工檢查存在一個幾乎無法克服的問題人是按文件去讀的不是按“字段關(guān)系”去讀的。讀詳情頁的時候你不會時刻想著去對照規(guī)格參數(shù)表里的每一個數(shù)值打字回復(fù)客服話術(shù)草稿的時候也不會每寫一句就去翻一遍活動利益點?？缥臋n校驗這件事天然違背人的閱讀習(xí)慣卻恰恰是機器和大模型的強項。1.3 為什么選 Qwen3.8-Max 而不是規(guī)則腳本你可能想問這些字段比對用 Excel 函數(shù)或者寫 Python 腳本不也能做嗎能但只能做最表層的那部分。規(guī)格參數(shù)表里的“304 不銹鋼”和詳情頁里的“食品級不銹鋼”一個是材質(zhì)標(biāo)準(zhǔn)一個是安全等級規(guī)則腳本判斷不了它們是否指向同一信息?？头捫g(shù)里寫“七天無理由退換”活動頁里寫“支持 15 天無理由”這種語義級別的差異傳統(tǒng)的精確匹配完全無能為力。我當(dāng)時選 Qwen3.8-Max 的核心原因有三個。第一它的長文本理解能力足夠一次處理完整的多文件資料包不需要把文檔拆得七零八落再分別喂給模型這樣反而會丟失跨文檔上下文。第二它對中文電商語境的理解比較到位平臺禁用詞、廣告法相關(guān)表述、電商黑話它基本都能識別不太需要額外維護一份龐大的詞庫。第三它在結(jié)構(gòu)化輸出方面表現(xiàn)穩(wěn)定配合 JSON 輸出模式可以直接把檢查結(jié)果變成可編程處理的報告數(shù)據(jù)。當(dāng)然我不是說規(guī)則腳本沒用實際上后面你會發(fā)現(xiàn)規(guī)則腳本在大模型跑完之后還有非常重要的“兜底”角色——這個我們留到第三章細(xì)說。2. 體檢維度設(shè)計讓大模型查什么、怎么查、按什么標(biāo)準(zhǔn)查2.1 五維檢查框架完整性、一致性、合規(guī)性、表達力、圖片一致性拿到一套資料包先別急著寫 Prompt。我踩過最大的坑之一就是一上來就讓大模型“檢查一下有沒有問題”——這種開放式的指令得到的回答往往大而空什么“建議加強品牌調(diào)性”“可以優(yōu)化賣點表達”一點實際價值都沒有。正確的做法是先把體檢維度定義清楚。我在這個項目里把檢查項拆成了五個維度完整性必填字段是否缺失。比如規(guī)格參數(shù)表里有沒有材質(zhì)、尺寸、承重這些基礎(chǔ)參數(shù)詳情頁有沒有售后說明合規(guī)自查表是否完整。一致性多份資料之間的交叉信息是否統(tǒng)一。這個維度信息量最大問題也最多。包括價格、規(guī)格、賣點、活動規(guī)則、材質(zhì)表述等。合規(guī)性是否違反平臺規(guī)則和廣告法。極限詞、絕對化用語、無法證明的數(shù)據(jù)宣稱、侵權(quán)風(fēng)險表述等。表達力文案層面的質(zhì)量問題。錯別字、標(biāo)點全半角混亂、長句晦澀、賣點堆砌沒有邏輯等。圖片一致性主圖上的文字信息與文檔資料是否匹配。這是純文本大模型需要借助 OCR 才能完成的部分。2.2 跨文檔一致性檢查的“字段關(guān)系表”五維框架里最容易設(shè)計、也最容易出問題的是“一致性”。你需要提前列出哪些字段之間存在對應(yīng)關(guān)系這些關(guān)系叫“字段關(guān)系表”。舉幾個實際例子。價格這個字段可能同時出現(xiàn)在客服話術(shù)、活動利益點、詳情頁文案三份文件中三處必須一致。容量/凈含量這個字段可能同時出現(xiàn)在規(guī)格參數(shù)表、詳情頁文案、主圖三處而且可能存在單位換算毫升和升、克和千克。賣點關(guān)鍵詞會在標(biāo)題、詳情頁、主圖文案中重復(fù)出現(xiàn)不能互相矛盾。材質(zhì)表述在參數(shù)表里是“201 不銹鋼”在詳情頁里寫“不銹鋼”在產(chǎn)品圖里寫“高級不銹鋼”這三者之間的邏輯關(guān)系需要判斷。構(gòu)建字段關(guān)系表的過程實際上就是盤清你的資料包有哪些“關(guān)鍵信息節(jié)點”。我建議用 Excel 先把這些字段關(guān)系列出來再把它寫進 Prompt 里讓大模型嚴(yán)格按表執(zhí)行。這樣檢查結(jié)果的可復(fù)用性會大幅提升——換一套資料包只需要微調(diào)字段名稱檢查邏輯完全不用重寫。2.3 商品圖這條鏈路OCR 先行語義比對在后主圖的檢查比較特殊。Qwen3.8-Max 是文本模型不能直接“看”圖片所以需要先把圖片上的文字提取出來。我用的方案是 PaddleOCR 本地跑一遍把主圖上的中文、英文、數(shù)字全部抽成文本再連同 OCR 坐標(biāo)信息一起交給大模型做后續(xù)判斷。主圖上的文字通常不多十幾秒就能跑完。這里有一個非常關(guān)鍵的細(xì)節(jié)OCR 輸出的文本一定要保留坐標(biāo)信息。為什么因為判斷主圖合規(guī)性時排版位置很重要。比如“全場五折”和“滿 99 減 50”如果放在主圖的同一個位置可能導(dǎo)致視覺沖突再比如主圖上如果有小字備注“活動最終解釋權(quán)歸本店所有”這種字體過小、容易誤導(dǎo)消費者的表述平臺往往是重點監(jiān)管對象。有坐標(biāo)信息Prompt 里的檢查規(guī)則才有落地的抓手。3. 系統(tǒng)搭建實錄數(shù)據(jù)解析、Prompt 工程與代碼兜底3.1 整體架構(gòu)與數(shù)據(jù)預(yù)處理整個系統(tǒng)的代碼不大核心流程分四步文件解析、OCR 提取、大模型體檢、報告生成。我用 Python 搭的主流程文件解析部分用了幾個成熟庫Word 和 Markdown 直接讀文本Excel 用 openpyxl 讀取并保留單元格結(jié)構(gòu)圖片用 PaddleOCR 識別。核心代碼骨架如下import json import openpyxl import docx from paddleocr import PaddleOCR import dashscope from dashscope import Generation def extract_text_from_docx(path): doc docx.Document(path) return \n.join([p.text for p in doc.paragraphs]) def extract_from_excel(path): wb openpyxl.load_workbook(path, data_onlyTrue) rows [] for ws in wb.worksheets: for row in ws.iter_rows(values_onlyTrue): rows.append( | .join([str(c) for c in row if c is not None])) return \n.join(rows) def ocr_image(path): ocr PaddleOCR(use_angle_clsTrue, langch, show_logFalse) result ocr.ocr(path, clsTrue) items [] for line in result: for box, text in line: items.append({ text: text[0], position: box }) return items def check_with_llm(context: dict): prompt build_prompt(context) # 核心 Prompt 構(gòu)造 resp Generation.call( modelqwen3.8-max, messages[{role: user, content: prompt}], result_formatmessage ) return json.loads(resp.output.choices[0].message.content)提示這里用了 dashscope SDK 調(diào)用 Qwen3.8-Max 模型接口實際使用時替換為自己的 API Key 和模型可用名稱即可。為了演示完整流程我保留了最簡調(diào)用方式生產(chǎn)環(huán)境建議加上重試和超時處理。3.2 Prompt 工程三個決定成敗的設(shè)計Prompt 是這套系統(tǒng)的靈魂。我前后迭代了三個版本才穩(wěn)定下來最終版有三個關(guān)鍵設(shè)計。設(shè)計一給模型一個明確的“檢查專家”角色并定義輸出約束。一開始我的 Prompt 只寫了檢查要求沒有定義輸出結(jié)構(gòu)結(jié)果每次返回的格式都不一樣有的用列表有的用段落后處理非常痛苦。后來改成角色設(shè)定 固定 JSON 輸出結(jié)構(gòu)一次就穩(wěn)定了。角色設(shè)定讓模型以“平臺資深審核員”的視角去做判斷輸出約束強制它按 [{file: 詳情頁, issue: ..., severity: high, suggestion: ...}] 這樣的結(jié)構(gòu)逐條返回。設(shè)計二把檢查維度和字段關(guān)系表寫進 Prompt而不是讓模型自由發(fā)揮。第二章說的五個維度和字段關(guān)系表這一步真正發(fā)揮作用。Prompt 里明確列出每個維度要檢查什么哪些字段之間需要做交叉比對模型輸出的結(jié)果就非常聚焦。比如我明確寫了“請重點核對規(guī)格參數(shù)表中的承重、容量、尺寸與詳情頁文案及主圖文字信息的一致性”模型就會把精力集中在這類跨文檔比對而不是泛泛而談“優(yōu)化文案”。設(shè)計三引入“先推理再作答”的兩階段輸出。這是效果提升最大的一步。我在 Prompt 里要求模型先輸出一個“檢查過程摘要”說明它發(fā)現(xiàn)了哪些可疑點、做過哪些交叉比對再輸出最終 JSON 報告。這個設(shè)計有點類似讓模型先展示思考過程再給結(jié)論實際跑下來漏檢率比直接輸出答案要低不少。也不需要單獨發(fā)兩次請求在同一個 Prompt 里讓它先寫推理再輸出 JSON 就行。3.3 數(shù)值歸一化與規(guī)則兜底大模型不擅長精確比對大模型在語義判斷上很強但在精確數(shù)字比對上有明顯短板。我的實測里模型遇到“500ml”和“0.5L”這種單位換算能反應(yīng)過來但遇到“358×246×84mm”和“35.8cm×24.6cm×8.4cm”這種規(guī)格表達時偶爾會給出錯誤判斷甚至出現(xiàn)把 358 和 35.8 直接當(dāng)成兩個不同數(shù)值的低級錯誤。解決方案是在把文本喂給大模型之前先用代碼做一次數(shù)值歸一化。我寫了一個預(yù)處理函數(shù)把所有常見的單位換算統(tǒng)一成標(biāo)準(zhǔn)單位尺寸統(tǒng)一換算成 mm容量統(tǒng)一換算成 ml重量統(tǒng)一換算成 g。歸一化后的文本再喂給模型數(shù)字比對的準(zhǔn)確率明顯提升。同理規(guī)則腳本在大模型跑完之后還承擔(dān)“硬性攔截”的角色。像“第一”“絕對”“最”這些極限詞我另外維護了一個小型敏感詞庫用正則在大模型輸出結(jié)果之外做一次全量掃描。這樣做不是為了替代大模型而是給合規(guī)性檢查加一道保險——規(guī)則永遠比模型更可靠也更容易向平臺審核人員解釋。4. 實測結(jié)果27 個問題是怎么分布的哪類最致命4.1 問題清單總覽整套資料包跑完Qwen3.8-Max 一共返回了 27 個問題。我按五個維度做了分類統(tǒng)計檢查維度問題數(shù)嚴(yán)重級別典型問題舉例一致性9高 6 / 中 3標(biāo)題“免打孔”與參數(shù)表“需鉆孔安裝”沖突主圖“承重 30kg”與參數(shù)表“承重 15kg”不一致客服話術(shù)價格與活動利益點到手價相差 10 元合規(guī)性6高 4 / 中 2主圖含“全網(wǎng)銷量第一”詳情頁“頂級工藝”未標(biāo)注專利號卻宣稱“專利設(shè)計”完整性5中 4 / 低 1規(guī)格參數(shù)表缺少材質(zhì)字段詳情頁無售后說明合規(guī)自查表質(zhì)檢報告編號為空圖片一致性4高 2 / 中 2主圖促銷文案“滿 99 減 20”在活動利益點中未出現(xiàn)主圖容量標(biāo)注與規(guī)格參數(shù)不一致表達力3低 3“不占空間”重復(fù) 4 次詳情頁第三段全角標(biāo)點混亂客服話術(shù)“哦哦”等語氣詞過多27 個問題里嚴(yán)重級別為高的有 12 個。這個比例比我預(yù)想的高得多也間接說明這套資料包在發(fā)布前的人工審核環(huán)節(jié)幾乎是形同虛設(shè)的。4.2 三個典型問題的深度復(fù)盤問題一標(biāo)題“免打孔安裝”與參數(shù)表“需鉆孔安裝”直接沖突。這是整套報告里最觸目驚心的一條。標(biāo)題文案寫的是“免打孔安裝”而規(guī)格參數(shù)表里明確標(biāo)注“安裝方式需鉆孔”。運營、美工、店長三個人分別看過材料卻沒人把標(biāo)題和參數(shù)表放在一起對照過。如果這套資料包直接上新買家收到貨發(fā)現(xiàn)需要鉆孔退貨退款和差評幾乎是必然的。問題二主圖“承重 30kg”與參數(shù)表“承重 15kg”不一致。主圖為了突出賣點把承重標(biāo)到了 30kg參數(shù)表里寫的卻是 15kg。這個差異我推測不是惡意夸大而是運營在寫主圖文案時憑印象填的。但平臺規(guī)則里主圖宣傳參數(shù)和詳情參數(shù)不一致屬于誤導(dǎo)消費者被舉報或抽檢到就是違規(guī)。這類問題典型的產(chǎn)生原因就是信息源多、更新不同步人工極難發(fā)現(xiàn)而大模型只要把主圖文案和參數(shù)表放在一起做一次交叉比對立刻現(xiàn)形。問題三客服話術(shù)的價格與活動利益點的到手價相差 10 元。活動利益點寫的是“前 100 名到手價 89 元”客服話術(shù)里卻還保留著“日常售價 99 元活動到手價 99 元”的舊版本。買家咨詢時按客服的說法下單實際支付卻是 89 元用戶不會覺得自己賺了只會覺得店鋪價格體系混亂。這類問題在電商里特別常見因為客服話術(shù)的更新滯后于運營活動節(jié)奏往往是一個月前的話術(shù)還在沿用到新活動里。4.3 誤報與漏報大模型實測的邊界在哪27 個問題里也有兩條誤報。一條是模型把“加厚不銹鋼”里的“加厚”判斷為疑似絕對化用語實際上“加厚”是描述性詞匯只要不寫“最厚”“超厚第一”這類表述平臺一般不會判定違規(guī)。另一條是模型認(rèn)為詳情頁缺少“生產(chǎn)日期”信息——但這是一個收納置物架屬于非食品類目根本不需要標(biāo)注生產(chǎn)日期。誤報不算嚴(yán)重說明模型的判斷在合理范圍內(nèi)但提醒我兩點第一合規(guī)檢查規(guī)則需要結(jié)合具體類目食品、美妝、電器、家居的合規(guī)要求差異很大Prompt 里的檢查清單得按類目定制不能一套規(guī)則打天下。第二大模型的判斷結(jié)果適合做“候選清單”不適合直接當(dāng)“最終結(jié)論”。我現(xiàn)在的流程是模型輸出結(jié)果后由人工對高嚴(yán)重級別的問題做二次確認(rèn)中低嚴(yán)重級別的問題直接走修改流程。這個分層審閱機制既保留了 AI 的效率也保留了人的最終判斷權(quán)。5. 踩坑復(fù)盤系統(tǒng)從能跑到好用關(guān)鍵在三個細(xì)節(jié)5.1 OCR 識別誤差圖片文字質(zhì)量的隱形陷阱PaddleOCR 中文識別準(zhǔn)確率已經(jīng)很高但在主圖這種字體多變、有背景干擾的場景下仍然會出錯。我第一次跑的時候“ml”被識別成“m1”“304 不銹鋼”被識別成“3O4 不銹鋼”。如果不做處理這些錯誤文本直接喂給大模型模型會在錯誤信息的基礎(chǔ)上做判斷結(jié)果自然不可靠。后來我加了兩個處理。一是針對數(shù)字和單位做了 OCR 后處理結(jié)合商品類目常見的單位詞庫對疑似識別錯誤做自動糾正二是在 Prompt 里明確要求模型“注意 OCR 文本可能存在的識別誤差如遇無法確認(rèn)的字符請單獨標(biāo)注可疑程度”讓它不至于在錯誤信息上得出過度自信的結(jié)論。5.2 模型輸出偶爾“胡編”結(jié)構(gòu)化校驗必須有大模型偶爾會輸出一些資料包里不存在的“問題”。比如它在一份資料里憑空生成了一個不存在的型號“BX-20”還說這個型號和標(biāo)題中的“BX-10”不一致。我追蹤了一下猜測是模型在上下文里看到了“型號”這個字段后自由發(fā)揮編造了一個。應(yīng)對方案是在代碼里加一道結(jié)構(gòu)化校驗?zāi)Ｐ头祷氐拿織l問題記錄必須能從原文中找到對應(yīng)的證據(jù)文本并記錄證據(jù)所在的文件名和原始句子。如果程序在原文中檢索不到對應(yīng)證據(jù)這條問題直接降級為“疑似”不進入正式報告。這個機制在程序上不復(fù)雜但對報告的可信度提升非常大。5.3 Prompt 從第一版到終版的三個關(guān)鍵改動第一版 Prompt 太“放養(yǎng)”只給了角色和任務(wù)模型輸出一堆正確的廢話。第二版加入了五維框架和字段關(guān)系表輸出開始聚焦但格式不穩(wěn)定。第三版加了 JSON 結(jié)構(gòu)約束和“先推理再輸出”的兩階段要求這才達到我想象中的可用狀態(tài)。除開發(fā)送前的 Prompt 設(shè)計生成后的報告整理同樣重要。我把模型返回的 JSON 報告直接轉(zhuǎn)成了帶嚴(yán)重級別標(biāo)簽的 Excel 表格按“高-中-低”排序后發(fā)給業(yè)務(wù)同事。表格里每條問題都帶“證據(jù)文件-證據(jù)原文-修改建議”業(yè)務(wù)同事不需要再翻原始資料包就能定位問題整個推動整改的流程順暢了很多。注意如果要把這個流程做得更完整還可以在報告生成后加一層“整改閉環(huán)”——每條問題記錄指派負(fù)責(zé)人和截止日期整改完成后再次用體檢助手復(fù)檢確認(rèn)問題清零。這一步不涉及技術(shù)但能把體檢的價值落到業(yè)務(wù)結(jié)果上。5.4 成本與耗時大家最關(guān)心的數(shù)字這套體檢跑一套資料包耗時主要取決于文件數(shù)量。我的實測數(shù)據(jù)是6 份文檔加 1 張主圖OCR 約 10 秒大模型推理約 1 到 2 分鐘全程不超過 3 分鐘。費用方面OCR 本地跑不花錢Qwen3.8-Max 按 token 計費一份資料包入?yún)⒓映鰠⒖偣?1 萬 token 左右成本可以忽略不計。對需要批量檢查幾十上百個 SKU 的團隊來說這個成本和效率都相當(dāng)有競爭力。6. 適用邊界與進一步擴展思考這套方案目前最適合的是 SKU 數(shù)量多、資料包結(jié)構(gòu)相對固定的電商團隊。SKU 越多人工檢查的邊際成本越高AI 體檢的收益越明顯。相反如果團隊只有兩三個商品人工檢查也就一兩個小時的事搭建這套系統(tǒng)的投入產(chǎn)出比就不劃算了。我在實際使用中還有一個體會這套系統(tǒng)的價值不止在于查出問題更在于把檢查標(biāo)準(zhǔn)固化了下來。以前團隊對“什么樣的資料包算合格”沒有統(tǒng)一認(rèn)知每個人的標(biāo)準(zhǔn)都不一樣?，F(xiàn)在五維檢查框架寫進 Prompt 里等于把團隊內(nèi)部的品控標(biāo)準(zhǔn)變成了可執(zhí)行、可復(fù)現(xiàn)的流程新來的運營照著報告改就行不需要再靠口口相傳去理解老員工的經(jīng)驗。后續(xù)如果要擴展我建議優(yōu)先考慮兩個方向。一是把檢查結(jié)果接入內(nèi)部通知跑完自動推送到工作群時效性會更好二是沉淀每個商品的歷史檢查報告形成一個質(zhì)量問題數(shù)據(jù)庫用數(shù)據(jù)反向優(yōu)化團隊的工作流程——比如如果一段時間內(nèi)一致性類問題頻發(fā)說明協(xié)同流程里有環(huán)節(jié)需要調(diào)整這比單次檢查的意義大得多。