上個月朋友找我?guī)兔徍艘慌鷾蕚渖霞艿碾娚藤Y料六個文檔加一張商品主圖按他們運營的說法人工過一遍至少要半小時還總擔心漏掉細節(jié)。我實在不想對著Excel和Word來回切著看干脆用Qwen3.8-Max搭了一個商品資料包體檢助手把資料一次性丟進去幾分鐘跑完一次查出27個問題其中好幾個是人工審核時特別容易忽略的。這篇文章就把這個項目的完整思路、數(shù)據(jù)建模、提示詞設計、代碼寫法和踩坑經(jīng)歷都攤開講適合正在做電商運營、供應鏈管理、商品數(shù)據(jù)治理或者打算用大模型做文檔審核工具的朋友參考。1. 為什么需要給商品資料做體檢1.1 電商上架前資料審核的真實痛點電商的商品資料從來都不是一個文件而是散落在各個協(xié)作環(huán)節(jié)里的。商品基礎信息表可能由運營維護詳情頁文案是文案寫的規(guī)格參數(shù)在研發(fā)或采購手里資質(zhì)證書在法務或品控那里價格庫存又是另一個系統(tǒng)導出的。每個人維護一份沒有人能保證它們完全同步。結果就是上架前必須有人把這幾份資料逐項比對發(fā)現(xiàn)問題再一個個找人確認修改。人工審核最大的問題不是能力而是穩(wěn)定性和效率。人看前兩份資料時注意力還在線看到第五份時已經(jīng)麻木了很多不一致就順手放過去了。更麻煩的是每個審核人員的標準不一樣有的人會查極限詞有的人只看價格有的人只關心規(guī)格參數(shù)是否齊全最后商品上架后不是被平臺駁回就是被用戶投訴描述不符。我之前也試過用傳統(tǒng)規(guī)則腳本做檢查比如寫正則查手機號格式、用關鍵詞列表匹配違禁詞但效果很有限。規(guī)則引擎只能查長得不對的問題查不了語義不對的問題。比如標題寫無線吸塵器規(guī)格參數(shù)表里卻出現(xiàn)電源線長度5米這在規(guī)則引擎看來沒有任何語法錯誤但任何有常識的人都知道這是矛盾的。這類問題必須靠語義理解才能發(fā)現(xiàn)。1.2 為什么選擇大模型而非純規(guī)則引擎?zhèn)鹘y(tǒng)自動化審核的邏輯是窮舉把所有可能出錯的地方變成規(guī)則一條條匹配。問題是電商資料的錯誤形態(tài)太開放了而且很多錯誤藏在上下文關系里。比如詳情頁文案里寫銷量全網(wǎng)第一這不是格式錯誤是合規(guī)風險。比如價格表里的劃線價和實際售價倒掛平臺會判定為虛假促銷。再比如商品參數(shù)表標注的容量是500ml但詳情頁主圖里印的卻是600ml這種圖文不一致靠關鍵詞規(guī)則幾乎不可能捕獲。大模型的優(yōu)勢在于它能同時理解多份資料中的語義并且能跨越文檔做比對。它不需要你事先定義什么算錯誤而是根據(jù)你的檢查維度、行業(yè)常識和文檔內(nèi)容推斷出哪些地方存在矛盾、缺失或風險。用Qwen3.8-Max來做的另一個原因是它對中文電商語料的理解比通用模型更細能識別出全網(wǎng)最低價頂級品質(zhì)這類常見但違規(guī)的表達也能理解規(guī)格表里約/左右/±這些詞帶來的不確定性。1.3 整體方案選型Qwen3.8-Max在流程中的定位在設計這個體檢助手時我一開始考慮的是讓模型一次性把所有文件和圖片都讀進去直接輸出問題列表。但實際跑下來發(fā)現(xiàn)不行六份資料的文本量加起來非常大再加上圖片信息很容易把上下文撐爆而且模型在一個超長上下文里做精細比對容易遺漏中間部分的內(nèi)容顧頭不顧尾。后來我把流程改成三階段第一階段是資料結構化和信息抽取第二階段是基于抽取結果做多維交叉檢查第三階段是把模型輸出結果整理成可執(zhí)行的問題工單。Qwen3.8-Max在三個階段都有參與但它不是簡單地被調(diào)用一次而是按需被調(diào)用多輪。第一階段用一次調(diào)用來抽取所有資料的關鍵信息并匯總成統(tǒng)一JSON第二階段按檢查維度分多次調(diào)用如果一次能塞下也可以一次調(diào)用每個維度獨立做交叉比對第三階段則主要靠本地代碼把模型返回的JSON結構化成報表不再需要模型參與。這樣做的好處是每一輪任務更聚焦上下文更短模型的穩(wěn)定性和準確率都會明顯提升。另一方面一旦某個維度出現(xiàn)問題我只需要重新檢查對應的那一段而不是重新讀一遍所有資料排查問題的成本也低很多。2. 資料清單與數(shù)據(jù)建模把7個輸入變成統(tǒng)一結構2.1 資料包里到底有什么先說說這次體檢的輸入。這里說的6份資料和1張商品圖分別對應真實的商品上架前常見的文件集合我按實際使用頻率整理成了一張清單序號資料名稱常見格式主要內(nèi)容1商品基礎信息表Excel/CSV商品名稱、標題、賣點、類目、品牌、產(chǎn)地2規(guī)格參數(shù)表Excel/Word型號、尺寸、重量、功率、容量、材質(zhì)、執(zhí)行標準3詳情頁文案Word/Markdown商品賣點描述、功能說明、使用場景、營銷文案4價格與庫存表Excel/CSV售價、劃線價、成本價、庫存數(shù)量、SKU編碼5資質(zhì)與證書文件PDF/圖片質(zhì)檢報告、3C認證、授權書、檢測標準編號6營銷活動說明Excel/Word活動名稱、優(yōu)惠力度、贈品信息、活動時間7商品主圖JPG/PNG商品外觀圖、包裝圖、宣傳視覺實際業(yè)務里還可能更多比如說明書、售后政策、物流說明但核心配置就是這七類。很多錯誤不是某個文件內(nèi)部的問題而是文件與文件之間對同一事實的描述不一致。所以第一步要做的不是檢查而是把不同格式的資料拉平放到同一個結構里。2.2 數(shù)據(jù)建模定義一個統(tǒng)一的商品資料包模型我在設計時給所有輸入定義了一個統(tǒng)一的JSON結構相當于把六份資料和一個圖片縮略信息都映射到一份商品資料檔案里。給模型看的Prompt和最后的輸出檢查結果都基于這個結構展開。這個模型的結構大致如下我簡化了部分字段方便說明思路{ product_name: 便攜榨汁杯, basic_info: { title: 無線便攜榨汁杯 家用隨行果汁機, brand: 某品牌, category: 廚房小電, selling_points: [無線便攜, 一鍵操作, 易清洗] }, specs: { model: XZ-500, capacity_ml: 500, weight_g: 380, power_w: 60, material: Tritan, voltage_v: 5V/2A }, detail_copy: { sections: [ {heading: 核心賣點, content: 600ml大容量一次榨汁滿足全天需求}, {heading: 續(xù)航, content: 滿電可榨15杯出差旅行必備} ] }, price_stock: { sku_list: [ {sku: XZ-500-白, price: 129, original_price: 199, stock: 320}, {sku: XZ-500-綠, price: 139, original_price: 199, stock: 0} ] }, certificates: { cert_numbers: [質(zhì)檢報告編號: QZ-2024-0158], cert_status: 有效, cert_issuer: 某檢測機構 }, activity: { activity_name: 春季煥新, discount_info: 前100名下單立減30元, gift_info: 贈定制杯刷 }, main_image_text: 容量500ml杯身材質(zhì)Tritan功率60W }這個模型不需要每個字段都填滿凡是能從資料里抽取到的就填抽不到的就保留空字符串或null。這樣設計有三個好處一是后續(xù)檢查腳本可以直接按字段做一致性比對二是模型在抽取時會更認真因為它知道你后面要用這個做檢查三是檢查結果可以追溯到具體是哪個環(huán)節(jié)丟了信息。2.3 圖片和PDF怎么進模型OCR與多模態(tài)輸入的取舍商品圖在資料包中很重要但也是最難處理的。如果直接用多模態(tài)能力把整張圖送進模型模型固然能看圖但是它對圖上的小字、標簽、參數(shù)表細節(jié)的識別不一定可靠。實際項目中我更推薦把圖片分成兩條路處理商品主圖這種以視覺表達為主的圖直接讓模型看圖判斷圖片風格、構圖與文案是否匹配但圖片上如果印了參數(shù)、容量、生產(chǎn)日期等關鍵信息就必須先用OCR或表格識別工具把文字抽取出來再作為文本輸入補充進去。我在這套體檢助手里也是這么做的。商品主圖先過一遍本地部署的OCR服務抽取到容量500ml材質(zhì)Tritan功率60W這樣的文本片段然后和圖片本身一起傳給后續(xù)檢查模塊。這樣既保留了模型對圖像內(nèi)容的感知又避免了圖片里有一行小字模型根本沒看到這種翻車場景。需要注意的是OCR的識別結果一定要保留坐標或段落位置不要只抽文本。有時候詳情頁圖片上有500ml淡色水印OCR識別出來后你可能誤以為它是實際參數(shù)。寧可多保留一些上下文信息也不要讓后續(xù)模型被OCR噪音帶偏。3. 體檢助手核心實現(xiàn)提示詞、代碼與輸出設計3.1 檢查維度設計27個問題從哪里來一次查出27個問題不是瞎數(shù)的我在模型輸出格式里強制要求了多維度的檢查項。每個維度下預置了一些子項同時允許模型補充它認為重要的額外問題。我最終使用的檢查維度如下維度檢查內(nèi)容典型問題示例完整性必填字段是否缺失、證書是否缺失缺少質(zhì)檢報告編號、缺少規(guī)格表中的材質(zhì)一致性不同資料對同一信息的描述是否矛盾標題寫500ml參數(shù)表寫600ml合規(guī)性是否含極限詞、違禁詞全網(wǎng)銷量第一、最強吸力、絕對化用語規(guī)范性單位、格式、數(shù)值范圍是否規(guī)范電壓寫成5V/2A、容量單位不統(tǒng)一為ml圖片一致性圖片展示內(nèi)容與參數(shù)/文案是否一致主圖標顏色綠色實際圖片是白色價格合理性劃線價、售價、成本之間關系是否合理劃線價與售價差值異常、成本高于售價活動沖突活動信息與價格、庫存、贈品是否沖突活動寫全店包郵實際商品為海外直郵我在提示詞里把每個維度都展開成具體的檢查指令同時要求模型輸出問題時必須帶上發(fā)現(xiàn)該問題所在的文件來源不能只給一個結論。3.2 Prompt模板的寫法和參數(shù)選擇給模型的system prompt我采用的是角色定義任務說明輸出格式約束三段式結構。我沒有用請你扮演一名資深電商審核專家這種泛泛的角色扮演而是直接告訴它要干什么以及輸出什么格式的數(shù)據(jù)實測下來前者更容易產(chǎn)出穩(wěn)定結構。下面是我實際用的一個簡化版Prompt你是一位電商商品資料審核助手。你會收到一份整理后的商品資料JSON和一張商品主圖的OCR文本。請按照以下維度檢查問題完整性、一致性、合規(guī)性、規(guī)范性、圖片一致性、價格合理性、活動沖突。 要求 1. 對比不同資料之間的描述重點檢查數(shù)據(jù)不一致。 2. 合規(guī)性檢查重點關注絕對化用語、極限詞、虛假宣稱。 3. 每個問題必須包括問題編號、所屬檢查維度、涉及的文件、問題描述、具體位置引用、修復建議。 4. 只輸出JSON數(shù)組不要輸出解釋文字。 輸出格式 [ { issue_id: ISSUE-001, dimension: 一致性, source: [規(guī)格參數(shù)表, 詳情頁文案], description: 規(guī)格參數(shù)表標注容量為500ml詳情頁文案描述為600ml。, location: 規(guī)格參數(shù)表-容量字段詳情頁文案-核心賣點段落, suggestion: 確認實際容量統(tǒng)一兩處描述并修改對應參數(shù)。 } ]這種明確到輸出JSON數(shù)組的寫法配合response_format之類的結構化輸出參數(shù)能極大減少后續(xù)解析的負擔。參數(shù)設置上我把temperature調(diào)到了0.1top_p調(diào)到0.9。溫度低是因為審核任務要的是穩(wěn)定、可復現(xiàn)的結果不需要創(chuàng)造性發(fā)揮。如果你發(fā)現(xiàn)模型漏檢或者誤報先不要急著改溫度先檢查是不是Prompt里把檢查維度描述得不夠具體。3.3 關鍵代碼實現(xiàn)調(diào)用Qwen3.8-Max的完整流程下面這段代碼是我這個項目里的核心流程簡化掉了一些業(yè)務細節(jié)。整體思路是讀入多份資料 - 用第一輪調(diào)用抽取并歸納資料 - 組裝成統(tǒng)一JSON - 用第二輪調(diào)用得到問題列表 - 解析JSON并生成報表。import json from openai import OpenAI client OpenAI( api_keyyour_api_key, base_urlyour_dashscope_base_url # 以官方SDK文檔為準 ) def load_documents(file_paths: dict) - str: 加載多份資料并拼接成文本用于第一輪抽取。 sections [] for key, path in file_paths.items(): with open(path, r, encodingutf-8) as f: content f.read() sections.append(f### {key}\n{content}) return \n\n.join(sections) def extract_product_json(documents_text: str) - dict: 第一輪從多份資料中抽取統(tǒng)一商品資料模型。 prompt f 請從以下多份商品資料中抽取關鍵信息輸出為JSON。 必須覆蓋product_name、basic_info、specs、detail_copy、price_stock、certificates、activity。 無法確定的字段留空字符串。 {documents_text} resp client.chat.completions.create( modelqwen-max-v38, # 以官方模型版本為準 messages[ {role: system, content: 你是一個嚴謹?shù)纳唐焚Y料抽取器只輸出JSON。}, {role: user, content: prompt} ], temperature0.1, response_format{type: json_object} ) return json.loads(resp.choices[0].message.content) def check_product_issues(product_json: dict, image_ocr_text: str) - list: 第二輪基于統(tǒng)一JSON模型做多維度體檢。 prompt f 商品資料JSON {json.dumps(product_json, ensure_asciiFalse)} 商品主圖OCR文本 {image_ocr_text} 請按照系統(tǒng)指令中的7個檢查維度檢查問題輸出JSON數(shù)組。 resp client.chat.completions.create( modelqwen-max-v38, # 以官方模型版本為準 messages[ {role: system, content: SYSTEM_CHECK_PROMPT}, {role: user, content: prompt} ], temperature0.1, response_format{type: json_object} ) data json.loads(resp.choices[0].message.content) return data.get(issues, data) if isinstance(data, dict) else data # 使用示例 documents { 商品基礎信息表: files/basic_info.xlsx, 規(guī)格參數(shù)表: files/specs.xlsx, 詳情頁文案: files/detail.docx, 價格與庫存表: files/price_stock.xlsx, 資質(zhì)與證書文件: files/cert.pdf, 營銷活動說明: files/activity.xlsx } docs_text load_documents(documents) product_json extract_product_json(docs_text) issues check_product_issues(product_json, image_ocr_text容量500mlTritan材質(zhì)60W) print(json.dumps(issues, ensure_asciiFalse, indent2))實際項目中l(wèi)oad_documents這一步不是簡單讀文本就能解決的。Excel要用openpyxl或pandas讀成文本PDF要用專門的庫抽取文本圖片上的表格信息可能要先用PP-Structure這類工具做版面識別。我當時是把每個文件都先轉成markdown風格的文本塊每個表格轉成管道的文本表這樣模型理解起來負擔最小。3.4 輸出層設計把模型結果變成可直接執(zhí)行的工單模型返回的是一堆JSON但這還不算完。真正要交付給運營、客服、供應鏈同事的是一個可執(zhí)行的問題清單。我在本地寫了一個后處理腳本做幾件事第一把模型返回的JSONissues數(shù)組轉成Excel表格列包括問題編號、維度、涉及文件、問題描述、位置引用、修復建議第二按風險等級給問題排序把價格倒掛極限詞風險證書缺失這類嚴重問題排到最前面第三為每個問題生成一個簡短的修復動作描述方便對接人直接復制進工單系統(tǒng)。這里有個很實用的技巧輸出Excel時盡量把涉及文件和具體位置做成獨立的列。因為電商團隊大多用飛書或釘釘協(xié)作這些字段可以直接作為表格篩選條件誰負責哪個文件就篩出誰的問題。模型給出問題列表后人工復核的成本會低很多。4. 實操實錄一次真實的體檢結果分析4.1 輸入資料概覽為了說清楚這套東西的實際效果我把當時其中一個測試項目匿名化后拿出來講。這是一個便攜式榨汁杯商品資料包里有商品基礎信息表、規(guī)格參數(shù)表、詳情頁文案、價格與庫存表、資質(zhì)證書PDF、營銷活動說明以及一張商品主圖。產(chǎn)品定位是無線便攜目標人群是有通勤和出差場景的年輕人。資料不算復雜但我特意沒有預先做任何清洗完全模擬運營把一堆文件丟過來的真實場景。文件里既有表格又有長段文案PDF證書里還夾雜著掃描件的水印。整個文本量折算下來大概1.8萬個token左右。4.2 27個問題分類和分布模型跑完一輪檢查之后返回了27個問題。我按維度做了統(tǒng)計檢查維度問題數(shù)量典型例子一致性8詳情頁寫600ml規(guī)格表寫500ml標題寫無線參數(shù)表卻出現(xiàn)電源線長1.5米合規(guī)性6文案出現(xiàn)最強榨汁活動說明寫全網(wǎng)最低價完整性5資質(zhì)證書掃描件缺報告編號綠色SKU缺少庫存對應圖片規(guī)范性3充電參數(shù)寫成5V/2A未標注單位容量單位在ml和L之間混用圖片一致性3主圖杯身顏色為白色標題寫抹茶綠圖上有600ml水印實際規(guī)格為500ml價格合理性2綠色SKU售價139元劃線價199元折扣力度約7折但成本價120元毛利偏低活動沖突0本次活動信息與價格庫存無沖突這個分布很有參考價值一致性類問題最多這也是人工審核最容易漏掉的部分。模型一次性把這些差異找出來省去了運營在多個文件之間反復切來切去的痛苦。4.3 幾個典型問題的處理細節(jié)我挑三個當時印象最深的問題展開說。第一個是容量標識不一致。規(guī)格參數(shù)表里是500ml詳情頁正文第一段寫的是600ml商品主圖的OCR文本里又出現(xiàn)了600ml水印。人工只看單個文件根本發(fā)現(xiàn)不了問題因為每個文件內(nèi)部讀起來都挺通順。模型把三個來源放在同一個上下文里對比后立刻給出容量信息存在三處沖突的結論。修復建議也很明確以規(guī)格參數(shù)表為準或確認實際容量后統(tǒng)一所有位置。第二個是合規(guī)風險。詳情頁文案里的最強榨汁和活動說明里的全網(wǎng)最低價都是絕對化用語。這類詞如果靠關鍵詞字典確實也能命中一部分但模型能看到上下文能更好判斷最強是在描述性能還是在違規(guī)宣傳減少誤報。第三個是圖片一致性。商品主圖顯示杯身是白色但標題和商品基礎信息表里寫的顏色是抹茶綠。這種錯誤發(fā)生的原因一般是運營套用了舊圖或者顏色字段填錯。模型返回問題時還把圖片OCR里識別到的白色字段一并列出修復建議是重新拍攝或替換主圖同時核對基礎信息表顏色字段。5. 避坑指南與問題排查5.1 常見問題速查表我把自己在這套方案落地過程中遇到的典型問題整理成了一個速查表方便你直接對照排查現(xiàn)象可能原因處理辦法模型返回的JSON解析失敗未開啟結構化輸出或溫度過高設置response_format為json_object降低temperature到0.2以下漏檢某個文件里的問題上下文太長模型注意力分散拆分為多輪檢查每個文件或每個維度單獨調(diào)用一次把沒問題說成有問題提示詞范圍太寬模型過度發(fā)揮增加僅基于資料中明確出現(xiàn)的信息判斷不推測同一問題重復出現(xiàn)多次多個維度都觸發(fā)同一異常在提示詞中增加去重規(guī)則同一問題只輸出一次問題定位不到具體文件提取階段丟失了來源信息在抽取階段要求模型輸出每條信息的source_file字段處理速度太慢單次調(diào)用塞入過多內(nèi)容評估token數(shù)文本超過2萬時優(yōu)先做分塊再做結果合并5.2 三個容易踩的坑第一個坑是過度相信模型的全知視角。一開始我試圖讓模型直接讀取原始Excel和PDF文件內(nèi)容覺得大模型既然什么都會應該能自己處理這些格式。結果發(fā)現(xiàn)不行表格結構稍復雜一點模型就會讀串行。老老實實先用代碼把各種文件轉成Markdown文本再喂給模型穩(wěn)定性和準確率都提升了一個級別。第二個坑是忽略了輸出字段約束。最初版本的Prompt只要求輸出所有問題結果模型有時候輸出的是自然語言段落有時候又是結構化的列表下游解析代碼要兼容好幾種格式寫得很痛苦。后來系統(tǒng)里強制約定輸出JSON數(shù)組每個問題必須包含issue_id/dimension/source/description/location/suggestion這些字段缺一不可解析邏輯才穩(wěn)定下來。第三個坑是成本失控。一開始我圖省事全文一次性丟給模型每次調(diào)用消耗大量token。后來發(fā)現(xiàn)第一階段抽取和第二輪檢查分開跑總token反而少了很多因為抽取階段可以把重復的表格內(nèi)容精簡掉檢查階段只面對一個干凈的結構化JSON檢查效率和效果都會提高。5.3 成本與響應時間控制建議用大模型做批處理審核心里一定要有成本賬。我當時統(tǒng)計了一下一個標準資料包6份文檔1張圖如果全部用文本方式處理總token大概在2萬到3萬之間。用Qwen3.8-Max跑一輪的成本并不高但如果每天要處理幾百個SKU積少成多也是一筆不小的開支?？刂瞥杀镜霓k法有幾個。一是先做規(guī)則預篩選比如用正則把必填字段缺失、價格倒掛這種規(guī)則性很強的問題先篩掉剩下的語義類問題再交給大模型。二是合理利用模型上下文能力一個模型實例在同一輪里盡量讓它處理多個SKU減少重復的Prompt開銷和網(wǎng)絡請求開銷。三是對結果做緩存同一個商品資料如果沒變過就直接讀歷史檢查結果不用重新跑一遍。四是設置好超時和重試機制避免因為個別調(diào)用超時導致整個批次失敗重新跑一遍反而更費錢。在實際使用中我建議把抽取商品資料模型和問題檢查做成兩個獨立的API調(diào)用不要合并成一個超級Prompt。兩者的目的不同合并了反而會影響模型的專注度增加token消耗還對排錯不友好。6. 這個助手還能怎么擴展項目跑通之后我又順手做了兩個小擴展。一個是在輸出Excel之外生成了一個Markdown格式的上架修改清單運營可以直接把它貼到飛書文檔里問題、負責人、修改狀態(tài)一目了然。另一個是把檢查結果接了個簡單的回調(diào)如果某個SKU連續(xù)兩次檢查都出現(xiàn)合規(guī)類問題會自動把對應商品標記為高危需復審方便品控團隊優(yōu)先處理。目前這套體檢助手已經(jīng)不只是我自己在用我把它包裝成了一個簡單的內(nèi)部工具輸入是商品資料壓縮包輸出是一個問題報告。整個流程走下來最大的感受是大模型解決的不是能不能發(fā)現(xiàn)矛盾的問題而是把發(fā)現(xiàn)矛盾這件本來要人工花大量時間做的事情變成了一個可以隨時調(diào)用、可重復、可追溯的標準流程。如果你也想搭一個類似的工具我的建議是從最痛的一兩個場景切入先別急著做成全流程自動化。比如只看價格與庫存的一致性或者只看詳情頁的合規(guī)性跑通之后再逐步加維度。資料類型越收斂模型的表現(xiàn)越可控后續(xù)維護成本也越低。最后再分享一個小技巧在Prompt里給模型留一個其他問題的開放檢查項讓它在完成預設維度檢查之外自主判斷還有哪些值得關注的問題。我這次查出的27個問題里有好幾個就是模型主動補出來的比如規(guī)格參數(shù)表里電壓值標注方式不符合平臺規(guī)范這種細顆粒問題。開放項既能兜底又能幫你發(fā)現(xiàn)之前沒考慮到的審核盲區(qū)。