先說個(gè)讓我下決心寫這東西的瞬間。上個(gè)月要上架一款桌面暖風(fēng)機(jī)運(yùn)營(yíng)同事打包發(fā)來6個(gè)文件加1張商品主圖我坐在電腦前對(duì)著“全網(wǎng)最熱銷”“限時(shí)搶購”這種標(biāo)題一層層往下核兩個(gè)多小時(shí)下來只查完標(biāo)題和詳情頁結(jié)果還是漏了一個(gè)致命問題——參數(shù)表寫著額定功率1500W詳情頁卻寫2200W等平臺(tái)抽檢反饋回來差點(diǎn)整批鏈接被下架。那一刻我意識(shí)到光靠人眼去給商品資料做體檢效率太低漏檢率還高。后來我花了三天時(shí)間用 Qwen3.8-Max 搭了一個(gè)電商商品資料包體檢助手把6份資料和1張商品圖一次性丟進(jìn)去結(jié)果它一口氣查出了27個(gè)問題很多是我人工核對(duì)時(shí)會(huì)忽略的細(xì)節(jié)。這篇就把整個(gè)項(xiàng)目的思路、搭建過程、踩坑記錄全部拆開來講適合電商運(yùn)營(yíng)、商品審核、以及想用大模型做文檔質(zhì)檢的朋友參考。1. 商品資料質(zhì)檢的痛點(diǎn)為什么人工核對(duì)永遠(yuǎn)有漏網(wǎng)之魚1.1 一個(gè)典型商品資料包里到底有什么先別急著聊模型把業(yè)務(wù)場(chǎng)景擺清楚。電商平臺(tái)上架一個(gè)商品看起來只是填個(gè)表單實(shí)際上運(yùn)營(yíng)手里收到的是一堆來源不同、格式各異的資料。我這次處理的暖風(fēng)機(jī)項(xiàng)目資料包里有標(biāo)題與基礎(chǔ)信息文本包含商品標(biāo)題、短標(biāo)題、核心賣點(diǎn)、促銷話術(shù)詳情頁文案文檔通常是從舊鏈接或者競(jìng)品那邊改來的包含品牌故事、功能描述、使用場(chǎng)景規(guī)格參數(shù)表一般是Excel或者PDF內(nèi)容覆蓋型號(hào)、尺寸、重量、額定功率、電壓、材質(zhì)、安全認(rèn)證資質(zhì)證書目錄包括3C認(rèn)證證書、質(zhì)檢報(bào)告、能效標(biāo)識(shí)等售后政策說明包含退換貨規(guī)則、保修年限、維修流程物流發(fā)貨說明涉及偏遠(yuǎn)地區(qū)是否包郵、發(fā)貨時(shí)效、運(yùn)費(fèi)標(biāo)準(zhǔn)。加上一張商品主圖它承擔(dān)的任務(wù)包括展示產(chǎn)品外觀、銘牌信息、核心功能圖標(biāo)、插頭類型這些細(xì)節(jié)。這7個(gè)輸入人工核對(duì)的時(shí)候要在多個(gè)文件之間來回切換眼睛很容易疲勞。而且問題往往藏在細(xì)節(jié)里比如證書上的產(chǎn)品型號(hào)和參數(shù)表里的型號(hào)差了一個(gè)字母這種錯(cuò)誤不逐字比對(duì)根本發(fā)現(xiàn)不了。1.2 人工質(zhì)檢的三個(gè)死穴一致性、合規(guī)詞、圖片交叉驗(yàn)證我復(fù)盤了幾年的上架經(jīng)驗(yàn)發(fā)現(xiàn)人工核對(duì)在三個(gè)環(huán)節(jié)上特別容易崩。第一是跨文件一致性。標(biāo)題里寫“升級(jí)款”詳情頁卻還在用上一代的產(chǎn)品圖參數(shù)表寫重量1.2kg詳情頁寫1.5kg售后政策說整機(jī)保修一年客服話術(shù)卻說核心部件保修三年。這類矛盾必須把多個(gè)文件攤開才能發(fā)現(xiàn)一旦資料多起來人的工作記憶根本裝不下。第二是合規(guī)詞與極限詞。電商平臺(tái)對(duì)“最”“第一”“頂級(jí)”“絕對(duì)”這類詞卡得很嚴(yán)但運(yùn)營(yíng)寫文案時(shí)往往順手就帶出來了。人工看一遍兩遍可能覺得沒什么平臺(tái)抽檢卻是一次命中就違規(guī)。更麻煩的是“秒殺”“限量”這類促銷詞有時(shí)需要結(jié)合活動(dòng)時(shí)間判斷是否合規(guī)純靠眼睛掃很難覆蓋。第三是圖片與文字的交叉驗(yàn)證。商品主圖里明明畫著兩腳插頭文案里寫“國(guó)標(biāo)三腳插頭”圖上標(biāo)注的顏色是“奶白色”參數(shù)表里寫“象牙白”。這種問題做平面設(shè)計(jì)的人容易忽略而平臺(tái)審核有時(shí)會(huì)拿圖片和文字做對(duì)照。人眼識(shí)別圖片細(xì)節(jié)可以但要同時(shí)記住圖上所有信息和所有文字資料里的對(duì)應(yīng)描述幾乎是做不到的。1.3 傳統(tǒng)自動(dòng)化方案的局限為什么正則表達(dá)式不夠用你可能會(huì)問這種核對(duì)工作能不能用傳統(tǒng)腳本做我一開始也試過。用Python寫正則匹配能查出“最”“第一”這類固定關(guān)鍵詞也能對(duì)比一下Excel參數(shù)表和文字里出現(xiàn)的數(shù)字。但它的局限太明顯了。正則只能查“已知的、確定的模式”查不了“語義層面的矛盾”。比如詳情頁寫“采用PTC陶瓷發(fā)熱體”參數(shù)表寫“發(fā)熱體材質(zhì)金屬”這種表述上的沖突正則完全無能為力。再比如“保修三年”和“3年質(zhì)?！比艘谎劭闯鍪且粋€(gè)意思但正則要分別寫規(guī)則。最麻煩的是圖片傳統(tǒng)腳本讀圖之后只能做OCROCR出來的文字還需要再用另一套規(guī)則去比對(duì)流程又臭又長(zhǎng)。所以當(dāng)我看到 Qwen3.8-Max 支持長(zhǎng)上下文和多模態(tài)輸入的時(shí)候第一反應(yīng)就是這東西天然適合做商品資料質(zhì)檢。它能同時(shí)接收文本和圖片能理解語義還能按我的要求輸出結(jié)構(gòu)化結(jié)果。把原本要寫幾百條正則規(guī)則的事情變成一個(gè)提示詞工程問題這個(gè)轉(zhuǎn)變是質(zhì)變。2. 體檢助手的能力邊界與“27類問題”分類體系2.1 我給體檢助手的定位不是改文案而是找問題搭建之前我先把需求邊界劃清楚。這個(gè)助手是“體檢醫(yī)生”不是“文案代筆”。它的任務(wù)是輸出一份問題清單把風(fēng)險(xiǎn)點(diǎn)全部列出來至于怎么改、改成什么樣由運(yùn)營(yíng)和設(shè)計(jì)去決定。這個(gè)定位很重要因?yàn)樗苯佑绊懱崾驹~設(shè)計(jì)和輸出格式。如果讓模型直接改文案一方面改出來的風(fēng)格未必符合品牌調(diào)性另一方面會(huì)把“查問題”和“改內(nèi)容”混在一起輸出結(jié)果難以量化。我只讓它做三件事讀資料、找矛盾、按分類輸出問題。每個(gè)問題包含位置、原文引用、問題類型、嚴(yán)重程度、修改建議。這樣運(yùn)營(yíng)拿到報(bào)告之后可以直接分派任務(wù)誰負(fù)責(zé)改文案誰負(fù)責(zé)改圖片誰去核對(duì)證書清晰明了。2.2 27類問題的四級(jí)分類為了后續(xù)統(tǒng)計(jì)和分析我把可能出現(xiàn)的資料問題分成四個(gè)大類每個(gè)大類下面再細(xì)分小類。這27個(gè)問題不是憑空想出來的而是結(jié)合過去兩年處理過的上架駁回記錄總結(jié)出來的。合規(guī)詞問題主要覆蓋標(biāo)題和賣點(diǎn)里的極限詞、虛假承諾、絕對(duì)化用語。一致性問題是重頭戲跨文件之間的參數(shù)、型號(hào)、保修政策、材質(zhì)描述只要出現(xiàn)沖突就算一條。資質(zhì)問題聚焦證書編號(hào)是否有效、產(chǎn)品型號(hào)是否一致、認(rèn)證范圍是否覆蓋在售型號(hào)、有效期是否過期。圖片交叉類問題則專門用來挑主圖、詳情圖與文字描述之間的“圖文不符”。表格里我按大類列了一下分布情況大類問題小項(xiàng)實(shí)際查出數(shù)量合規(guī)詞類標(biāo)題含極限詞、賣點(diǎn)含絕對(duì)化承諾、促銷用語缺少限定5跨文件一致性功率沖突、重量沖突、保修政策沖突、材質(zhì)描述沖突、型號(hào)不一致、顏色命名不一致、尺寸數(shù)據(jù)矛盾、功能描述前后矛盾8資質(zhì)證書類證書編號(hào)格式異常、證書型號(hào)與參數(shù)表不一致、能效標(biāo)識(shí)缺失、檢測(cè)報(bào)告覆蓋范圍不足4圖片與文案交叉圖中插頭類型與文案不符、圖中含遙控器但資料未提及、顏色與文字不一致、包裝清單數(shù)量沖突4文案質(zhì)量類錯(cuò)別字、全角半角標(biāo)點(diǎn)混用、重復(fù)段落、過度承諾、參數(shù)單位缺失、段落結(jié)構(gòu)混亂6合計(jì)正好27個(gè)。這套分類我后來一直在用因?yàn)樗念w粒度足夠細(xì)每條問題都能直接對(duì)應(yīng)到具體的修改責(zé)任人。2.3 為什么連“錯(cuò)別字”和“全角半角標(biāo)點(diǎn)”都要查有人可能覺得錯(cuò)別字和標(biāo)點(diǎn)這種小問題平臺(tái)審核又不會(huì)管查它干什么實(shí)際不是這樣。詳情頁文案是從舊鏈接復(fù)制過來的經(jīng)常出現(xiàn)繁體字、半角逗號(hào)、缺單位的問題比如“1500W”寫成“1500w”這種細(xì)節(jié)在移動(dòng)端展示時(shí)特別影響觀感。更重要的是標(biāo)點(diǎn)和錯(cuò)別字往往是內(nèi)容被批量復(fù)制修改過的信號(hào)如果一篇文案里出現(xiàn)“干靜”“的卻”這種錯(cuò)字很可能整段都是從別處搬來的連帶的信息準(zhǔn)確性也要打問號(hào)。所以我把這類問題也納入體檢范圍作為內(nèi)容質(zhì)量的兜底指標(biāo)。3. 搭建過程從文檔解析到多模態(tài)識(shí)別3.1 整體流程解壓→解析→分塊→送檢→匯總整個(gè)體檢助手的代碼不算復(fù)雜核心流程分五步。第一步是解壓資料包把6份資料和1張圖片統(tǒng)一放到工作目錄。第二步是解析文件txt和md直接讀取docx用python-docx轉(zhuǎn)成純文本xlsx用pandas讀取所有sheetpdf用pdfplumber提取文本圖片讀取之后轉(zhuǎn)成base64編碼。第三步是分塊因?yàn)閱未握?qǐng)求能處理的上下文有限而且商品資料里有大量重復(fù)的模板內(nèi)容我會(huì)把不同類型的資料切成獨(dú)立的塊避免無關(guān)內(nèi)容干擾模型判斷。第四步是送檢把分塊后的文本和圖片一起發(fā)給 Qwen3.8-Max提示詞里明確要求它按照預(yù)定義的問題分類輸出JSON。第五步是匯總把多次檢查的結(jié)果合并成一個(gè)統(tǒng)一的報(bào)告按嚴(yán)重程度排序?qū)懙絤arkdown或者Excel里。import base64 import json from docx import Document import pdfplumber import pandas as pd def extract_text(path): if path.endswith(.docx): doc Document(path) return \n.join(p.text for p in doc.paragraphs) elif path.endswith(.xlsx): df pd.read_excel(path, sheet_nameNone, dtypestr) return \n.join(f{name}\n{frame.to_string()} for name, frame in df.items()) elif path.endswith(.pdf): with pdfplumber.open(path) as pdf: return \n.join(page.extract_text() or for page in pdf.pages) else: with open(path, encodingutf-8) as f: return f.read() def encode_image(path): with open(path, rb) as f: return base64.b64encode(f.read()).decode(utf-8)這段代碼是主干實(shí)際操作的時(shí)候要針對(duì)亂碼pdf和加密的xlsx做額外處理但大部分情況下夠用。解析這一步最需要注意的是不要把Excel里的NaN值直接拼進(jìn)去否則模型會(huì)把“nan”當(dāng)成一個(gè)真實(shí)內(nèi)容。3.2 提示詞工程讓Qwen3.8-Max“帶著挑刺的眼鏡”讀文檔提示詞是整個(gè)項(xiàng)目的靈魂。我試過好幾版最終沉淀出一個(gè)穩(wěn)定可用的模板。核心思路是明確角色、定義問題類型、限定輸出格式、強(qiáng)調(diào)引用原文。角色設(shè)定部分我會(huì)告訴模型“你是一位資深的電商合規(guī)審核專員負(fù)責(zé)在上架前對(duì)商品資料進(jìn)行全量體檢”。這句話能顯著改變模型的輸出風(fēng)格從“回答助手”變成“挑刺專家”。問題定義部分我會(huì)窮舉需要檢查的類別并且給每個(gè)類別加上例子。比如合規(guī)詞類舉“最”“第一”“頂級(jí)”的例子一致性類明確要求“跨文件對(duì)比相同字段時(shí)必須列出兩個(gè)文件各自的內(nèi)容”。輸出格式部分我要求模型輸出一個(gè)JSON數(shù)組每個(gè)元素包含location、problem_type、severity、original_text、suggestion五個(gè)字段。同時(shí)明確要求“只輸出JSON不要輸出任何解釋性文字”這樣后續(xù)處理起來非常方便。PROMPT 你是一位資深的電商合規(guī)審核專員。你收到的是一份待上架商品的完整資料包包含標(biāo)題、詳情頁文案、規(guī)格參數(shù)表、資質(zhì)證書說明、售后政策、物流說明和商品圖片。 請(qǐng)對(duì)這些資料進(jìn)行全面體檢重點(diǎn)檢查以下五類問題 1. 合規(guī)詞類標(biāo)題或賣點(diǎn)中是否包含“最”“第一”“頂級(jí)”“絕對(duì)”“秒殺”等極限詞或絕對(duì)化用語。 2. 跨文件一致性不同文件中相同字段是否存在沖突例如功率、重量、型號(hào)、保修期限、材質(zhì)、顏色命名等。 3. 資質(zhì)證書類證書編號(hào)格式、產(chǎn)品型號(hào)是否匹配、認(rèn)證覆蓋范圍、有效期。 4. 圖片與文案交叉商品圖片中所能看到的插頭類型、配件、顏色、功能標(biāo)識(shí)是否與文字資料一致。 5. 文案質(zhì)量類錯(cuò)別字、全角半角標(biāo)點(diǎn)混用、重復(fù)段落、缺少單位、過度承諾。 輸出要求 - 只輸出JSON數(shù)組不要包含任何解釋或前后綴。 - 每條問題包含字段location出現(xiàn)位置、problem_type問題類別、severityhigh/medium/low、original_text引用原文必須保留原始表述、suggestion修改建議。 - 如果某段內(nèi)容沒有問題不要輸出。 - 務(wù)必逐條引用原文便于人工復(fù)核。 這套提示詞有一個(gè)關(guān)鍵細(xì)節(jié)要求它輸出原文字段。這一步很多人會(huì)偷懶讓模型直接說“這里有問題”但如果不強(qiáng)制引用原文后續(xù)人工復(fù)核的時(shí)候還得自己回原文里找位置效率大打折扣。強(qiáng)制引用之后每一條問題都可以直接對(duì)應(yīng)到原始文件的具體句子。3.3 圖片質(zhì)檢怎么做主圖與文案的交叉驗(yàn)證圖片質(zhì)檢是這次項(xiàng)目里最有意思的部分。Qwen3.8-Max 是多模態(tài)模型可以直接把圖片和文字一起傳進(jìn)去。但這里有個(gè)坑就是模型視力再強(qiáng)也沒法理解圖片里的每一個(gè)像素所以提示詞里要明確告訴它“重點(diǎn)關(guān)注圖中可以辨認(rèn)的中文文字、插頭形狀、按鍵數(shù)量、顏色、配件清單”。我測(cè)試了幾種做法效果最好的是把商品主圖和全部文字資料放在同一次請(qǐng)求里讓模型自己看圖、讀文、做交叉比對(duì)。舉個(gè)例子我那張測(cè)試主圖上產(chǎn)品正面清晰地印著兩腳扁形插頭但規(guī)格參數(shù)表里寫“插頭類型國(guó)標(biāo)三腳”。模型一眼就識(shí)別出這個(gè)矛盾輸出了一條high級(jí)別的問題。這種跨模態(tài)的比對(duì)傳統(tǒng)OCR加正則的方案很難做到。另外主圖上的文字信息也很重要比如圖里拍的包裝盒上印著“奶白色”參數(shù)表里寫“象牙白”這種顏色命名不一致的問題模型也能通過繪圖文字識(shí)別和語義理解發(fā)現(xiàn)。3.4 結(jié)構(gòu)化輸出設(shè)計(jì)我如何拿到可落地的JSON報(bào)告為了讓輸出結(jié)果能直接進(jìn)入流程我設(shè)計(jì)了一個(gè)兩段式的處理方案。第一次請(qǐng)求是“體檢”模型返回JSON數(shù)組。第二次請(qǐng)求是可選的“復(fù)核”我把第一次結(jié)果里的original_text和suggestion重新塞給模型加上一句“請(qǐng)檢查上述問題和建議是否合理是否誤報(bào)”讓模型自己糾錯(cuò)。這兩段式能有效降低幻覺率因?yàn)榇竽Ｐ偷淖晕壹m錯(cuò)機(jī)制在多次提示下確實(shí)能過濾掉一部分“沒影的問題”。我實(shí)測(cè)下來第一次輸出27條復(fù)核之后有2條被模型自己標(biāo)記為“可能是誤報(bào)”我把它們單獨(dú)摘出來人工確認(rèn)后保留了一條、刪除了一條。最終27條里26條有效。JSON輸出還有一個(gè)處理細(xì)節(jié)有些情況下模型會(huì)在JSON前后加上json這樣的標(biāo)記或者偶爾吐出一句說明文字我的代碼里用一個(gè)簡(jiǎn)單的清洗函數(shù)把非JSON部分剝掉然后解析。如果解析失敗就自動(dòng)重試最多重試三次。4. 實(shí)測(cè)全流程復(fù)盤6份資料1張圖27個(gè)問題是怎么被揪出來的4.1 測(cè)試資料構(gòu)造我故意埋了哪些“雷”為了檢驗(yàn)效果我專門造了一份帶“雷”的資料包不是隨便找現(xiàn)成商品而是在真實(shí)商品資料基礎(chǔ)上人工注入了20多處錯(cuò)誤。這些雷覆蓋了前面說的五類問題而且有些埋得很隱蔽。比如標(biāo)題里我放了“2024年度最受歡迎的桌面暖風(fēng)機(jī)”其中“最受歡迎”就是極限詞。還有一個(gè)雷藏在兩個(gè)文件之間標(biāo)題寫“三檔調(diào)節(jié)”詳情頁里卻只寫了兩檔這個(gè)矛盾需要把兩個(gè)文件關(guān)聯(lián)起來才能發(fā)現(xiàn)。更隱蔽的是功率參數(shù)表里寫1500W售后政策里提到“本產(chǎn)品額定功率為1200W”兩個(gè)數(shù)字都不算離譜但就是不一致。證書那邊我故意把型號(hào)寫成“HF-02”參數(shù)表里卻是“HF-03”同時(shí)檢測(cè)報(bào)告上的日期已經(jīng)超過有效期。圖片上則埋了一個(gè)插頭類型錯(cuò)誤和包裝清單數(shù)量對(duì)不上的問題。這套“雷”方案是為了讓測(cè)試有確定性能精確評(píng)估模型的召回情況。如果直接拿真實(shí)資料測(cè)試我也說不清有沒有遺漏埋雷之后就能計(jì)算出模型找出了多少、漏了多少。4.2 執(zhí)行過程實(shí)錄分步驟說明我把整個(gè)執(zhí)行流程記錄了下來方便復(fù)現(xiàn)。先運(yùn)行了解壓和解析腳本把6份文件變成純文本。參數(shù)表Excel里有一個(gè)sheet叫“規(guī)格參數(shù)”里面混著NaN空值我用dropna清理了一遍。資質(zhì)證書PDF提取出來之后有亂碼因?yàn)樽C書本身的排版比較復(fù)雜pdfplumber提取出來的文本順序有點(diǎn)亂檢查了一遍手動(dòng)調(diào)整了段落順序。接著構(gòu)造請(qǐng)求體文本部分把標(biāo)題、詳情頁、參數(shù)表、售后、物流按順序拼在一起圖片部分用base64編碼。提醒一點(diǎn)通過API傳圖片時(shí)通常要用data:image/jpeg;base64,xxxx這種帶前綴的格式模型才能正確識(shí)別圖片類型。發(fā)送請(qǐng)求之后第一次返回的JSON里包括29條問題。我看了下里面有2條重復(fù)——參數(shù)表里同一個(gè)字段在兩個(gè)位置出現(xiàn)模型給兩條都標(biāo)記了我做了去重。還有1條是模型把詳情頁里的非絕對(duì)化用語“強(qiáng)力加熱”錯(cuò)判成了絕對(duì)化用語我人工復(fù)核時(shí)刪掉了。所以第一輪拋掉2條去重、1條誤報(bào)還剩26條。然后在第二輪復(fù)核中我讓模型檢查這26條里有沒有明顯誤判它返回了兩條存疑的我再人工確認(rèn)其中一條確實(shí)存疑因?yàn)閳D片上的顏色在屏幕上看偏暖實(shí)際產(chǎn)品是奶油白這個(gè)沖突算不算問題我最后保留為低優(yōu)先級(jí)提示。最終定稿27條。4.3 27個(gè)問題的最終分布我按嚴(yán)重程度和類別做了統(tǒng)計(jì)嚴(yán)重程度分布如下嚴(yán)重程度數(shù)量處理方式high阻斷上架6必須修改后才能提交medium建議修改14運(yùn)營(yíng)確認(rèn)后修改low體驗(yàn)優(yōu)化7排期處理6條high級(jí)別問題分別是標(biāo)題含“最受歡迎”、功率跨文件沖突、證書型號(hào)與參數(shù)表不一致、圖片插頭類型與文案不符、保質(zhì)期信息前后矛盾、詳情頁缺少額定功率參數(shù)這會(huì)導(dǎo)致售后爭(zhēng)議。任何一個(gè)問題如果漏掉都可能造成上架駁回或者消費(fèi)者投訴。medium級(jí)別里最典型的是重量1.2kg和1.5kg的差異、顏色命名不一致、材質(zhì)描述沖突、包裝清單數(shù)量不一致。這些問題不至于被平臺(tái)直接攔截但會(huì)影響轉(zhuǎn)化率和售后體驗(yàn)比如材質(zhì)寫錯(cuò)了消費(fèi)者到手后發(fā)現(xiàn)不對(duì)退貨率會(huì)明顯上升。low級(jí)別主要是錯(cuò)別字、標(biāo)點(diǎn)混用、單位大小寫不一致、段落重復(fù)。改起來不難但需要有人發(fā)現(xiàn)。輸出報(bào)告的時(shí)候我按severity排序生成Markdown運(yùn)營(yíng)拿到手的第一眼就能看到high級(jí)別的問題有哪些。5. 必須說的三個(gè)坑幻覺、格式漂移和上下文超長(zhǎng)5.1 幻覺問題模型查出“不存在的問題”怎么辦大模型質(zhì)檢工具最讓人頭疼的就是幻覺。我這次實(shí)測(cè)也遇到了模型把“強(qiáng)力加熱”判成絕對(duì)化用語實(shí)際上這個(gè)詞在電商語境里是允許的還有一次它說“參數(shù)表里沒有找到保修年限”但我明明把保修政策單獨(dú)作為一份文件傳了進(jìn)去它可能因?yàn)閮?nèi)容太長(zhǎng)焦點(diǎn)被前面的大段詳情頁文案帶偏了。針對(duì)幻覺我的解決方案是三重校驗(yàn)。第一提示詞里強(qiáng)制要求引用原文沒有原文支撐的方案不能被標(biāo)記第二增加復(fù)核機(jī)制第二次請(qǐng)求讓模型檢查自己的輸出第三關(guān)鍵問題必須人工復(fù)核我專門把high級(jí)別的問題做成一個(gè)待確認(rèn)列表不能自動(dòng)通過。這套組合下來誤報(bào)率能壓到可以接受的范圍。5.2 JSON輸出結(jié)構(gòu)漂移容錯(cuò)與重試機(jī)制模型輸出JSON雖然支持但有時(shí)候會(huì)出現(xiàn)結(jié)構(gòu)漂移。最典型的情況是明明要求輸出數(shù)組結(jié)果它在數(shù)組前加了一句“以下是對(duì)這些文件的體檢結(jié)果”或者整個(gè)輸出被包在代碼塊的標(biāo)記里。這種問題在直接調(diào)用API時(shí)很常見所以我的代碼里專門寫了容錯(cuò)邏輯def parse_json(raw): raw raw.strip() if raw.startswith(): raw raw.strip() if raw.startswith(json): raw raw[4:] start raw.find([) end raw.rfind(]) if start -1 or end -1: return None try: return json.loads(raw[start:end1]) except json.JSONDecodeError: return None如果解析失敗就重試重試時(shí)會(huì)把上一次的輸出也放進(jìn)提示詞里告訴模型“你剛才的輸出格式不符合要求請(qǐng)修正后重新輸出”。這個(gè)基于錯(cuò)誤信息的重試比直接盲等結(jié)果有效得多。5.3 長(zhǎng)文檔超限分塊策略與上下文管理6份資料加1張圖文本量加起來其實(shí)不算特別大但如果商品資料是大型家電說明書可能有幾十頁一次性全傳進(jìn)去很容易超長(zhǎng)。我的策略是把體檢拆成兩類請(qǐng)求單文件請(qǐng)求和跨文件請(qǐng)求。單文件請(qǐng)求針對(duì)“文案質(zhì)量類”問題只檢查錯(cuò)別字、標(biāo)點(diǎn)、過度承諾這些東西一次輸入一個(gè)文件。跨文件請(qǐng)求針對(duì)“一致性”和“資質(zhì)”問題會(huì)把多個(gè)文件的摘要和關(guān)鍵字段單獨(dú)抽出來拼成一個(gè)精簡(jiǎn)版而不是把全部原文塞進(jìn)去。比如參數(shù)表只保留字段名和值不保留空行和注釋這樣可以把token消耗降到最低。有一個(gè)細(xì)節(jié)值得注意跨文件請(qǐng)求時(shí)一定不要把所有文件一股腦按順序拼接因?yàn)槟Ｐ蛯?duì)出現(xiàn)在中間位置的內(nèi)容關(guān)注度會(huì)下降。我的做法是把“主錨點(diǎn)”文件放在最前面比如規(guī)格參數(shù)表其他文件放在它后面提示里明確要求“以第一個(gè)文件的參數(shù)為準(zhǔn)逐一檢查后置文件中的描述是否與它一致”。6. 把這套體檢助手接到日常流程里的幾點(diǎn)建議6.1 落地形態(tài)命令行腳本、定時(shí)任務(wù)還是Web界面如果你只想在每次上架前手動(dòng)跑一遍命令行腳本就夠了。解壓包放到一個(gè)目錄執(zhí)行一行命令幾秒后得到一份Markdown報(bào)告。如果你想把它集成到現(xiàn)有審核流程可以做成一個(gè)FastAPI服務(wù)把資料上傳接口和報(bào)告生成接口封起來運(yùn)營(yíng)在頁面上傳文件后端自動(dòng)調(diào)用 Qwen3.8-Max 的接口生成PDF或者Excel報(bào)告。我自己的做法是兩套并行本地用命令行腳本做深度調(diào)試線上用FastAPI封裝成異步任務(wù)報(bào)告生成后推送到企業(yè)微信機(jī)器人。運(yùn)營(yíng)只需要把資料包拖到網(wǎng)頁上傳區(qū)幾分鐘后收到一份體檢報(bào)告不需要了解任何模型細(xì)節(jié)。把這個(gè)工具當(dāng)成一個(gè)“審核同事”用而不是讓每個(gè)人都去研究提示詞。6.2 成本與耗時(shí)估算一次完整體檢處理6份資料加1張圖實(shí)際token消耗大概在兩萬左右按 Qwen3.8-Max 的定價(jià)算單次成本在幾分錢到一毛錢之間遠(yuǎn)遠(yuǎn)低于人工質(zhì)檢的時(shí)間成本。耗時(shí)方面單次請(qǐng)求在一分鐘左右如果把多文件和圖片放在一起可能要兩分鐘左右。如果文件特別多建議切分成并行請(qǐng)求同時(shí)處理多個(gè)子任務(wù)能把總耗時(shí)壓縮到三十秒以內(nèi)。6.3 我個(gè)人的使用體會(huì)與后續(xù)擴(kuò)展用了幾天之后最大的感受是大模型質(zhì)檢最大的價(jià)值不在于替代人工而在于把人工從重復(fù)性的枯燥核對(duì)里解放出來讓它去處理真正需要判斷力的事情。以前人工核對(duì)這些資料兩個(gè)小時(shí)能查完就算快的但現(xiàn)在五分鐘出一份包含27個(gè)問題的報(bào)告剩下的時(shí)間我可以逐條確認(rèn)、分類分派判斷錯(cuò)誤率和風(fēng)險(xiǎn)點(diǎn)整個(gè)審核質(zhì)量反而上來了。后續(xù)我打算在幾個(gè)方向上繼續(xù)擴(kuò)展。一個(gè)是用同樣的思路去檢查直播腳本和短視頻口播詞把合規(guī)審核的環(huán)節(jié)提前到內(nèi)容制作階段避免發(fā)布之后再被平臺(tái)下架。另一個(gè)是嘗試把歷史駁回記錄整理成帶標(biāo)簽的樣本用few-shot的方式讓模型理解目標(biāo)平臺(tái)更深層的審核傾向降低誤報(bào)率。還有一個(gè)思路是把體檢報(bào)告和任務(wù)管理工具打通high級(jí)別問題自動(dòng)創(chuàng)建待辦任務(wù)分派給對(duì)應(yīng)負(fù)責(zé)人把整個(gè)流程串得更順。如果你也有大量商品資料需要定期核對(duì)的場(chǎng)景完全可以照這套思路搭一個(gè)自己的版本比我這個(gè)更貼合你們的類目特點(diǎn)。