
运营同事抱着一叠资料过来的时候我以为这就是一次普通的上架前核对——6份文档加1张商品图按以前的节奏半小时怎么都看完了。结果那一次她来回翻了三遍只找出两三处明显问题真正让整个链接被平台打回的是一个藏在跨文档细节里的矛盾详情页写的是“500g”质检报告上的项目名称却是“0.5kg”两个端口数据对不上链接直接被冻结重审。这种“每份文件单独看都没毛病合在一起全是问题”的场景做过电商的人应该都不陌生。所以我在两个周末里用 Qwen3.8-Max 搭了一个电商商品资料包体检助手专门处理这种反人性的审核工作把一堆资料丢进去让模型一次性把跨文档、图文不一致的问题全揪出来。实测里6份资料加1张商品图一次输出27个问题从资质有效期到详情页极限词都有覆盖。这篇文章适合两类人看一类是电商运营、商品治理相关岗位想了解怎么用大模型把资料审核这个环节自动化另一类是本身就在做LLM应用开发的工程师想看看一个真实的文档审核场景是怎么拆解、怎么落地的。我不会只贴一个Prompt就完事会把整套流水线设计、踩坑过程以及哪些问题是真的值得自动化、哪些还是得人来判断全部讲清楚。1. 上架前的资料审核为什么人工核对总在“漏”1.1 一份商品资料包里到底装了什么先别急着上技术得先搞清楚“体检”的对象长什么样。一个常规的电商商品资料包通常由这些部分组成主体资质类营业执照、开户许可、商标注册证或商标授权书商品资质类质检报告、强制性认证证书视类目而定、生产许可证运营素材类商品详情页文案、主图文案、包装设计图、说明书其他佐证采购合同、报关单跨境、供货证明等这里最麻烦的地方在于形态不统一。营业执照是扫描件质检报告可能是PDF详情页文案是Word或纯文本包装设计图是图片商品实拍图又是一张不同的图。人眼处理这些东西时大脑会在不同格式之间来回切换非常耗神。而且很多资料本身就是“半结构化”的格式稍微不规范字段就要靠人工去找。比如一份质检报告里产品名称可能印在表格第一栏也可能写在标题里还可能只出现在报告编号的命名中没有固定的抽取路径。1.2 人工审核的死穴不是看不清而是记不住、比不动做过商品上架审核的朋友应该都有这种体会文件单独看都能看懂可一旦要把六份文件里的同一个字段拉出来比对就很容易看漏。这不是责任心的问题是人脑的工作记忆容量本来就不适合做“跨文档一致性”这种事。举个例子。营业执照上的公司名称是“杭州某某日用化妆品有限公司”商标授权书里的授权方写的是“某某日用化妆品有限公司”详情页里则简写成“某某日化”。单独看每一份谁都不会觉得有问题但放在合规审核里这就是典型的名称不一致可能导致授权链路被质疑。人眼要发现这个问题得记住三份文件里的三个名称再去挨个比对——读一遍不一定记得住回头再翻又忘了这就是审核漏项的根本原因。另外人眼对“缺失”比对“不一致”更敏感。比如营业执照缺一个章一眼就能看出来但详情页写“500g”质检报告写“0.5kg”这种单位换算是不会被人眼自动识别的除非运气好正好翻到那一页。我后来统计过人工审核的记录大量漏掉的问题都属于“不一致”而非“缺失”因为缺失只需要盯一个位置而不一致需要同时盯好几个位置还要保持记忆这对人来说非常反直觉。1.3 我最初试过纯规则脚本结果放弃了在决定用大模型之前我先试过用规则脚本做字段校验。写法也很直接把PDF里的文本抽出来用正则去匹配“统一社会信用代码”“有效期至”这些关键词然后检查有没有值、格式对不对。这个方案用Python写起来很快跑起来也稳定处理纯字段缺失非常管用比如“营业执照没填有效期”这种一眼就能查出来的硬伤。但规则脚本一碰到语义层面就抓瞎。比如“授权书里的品牌名和商标注册证上的品牌名不一致”这类问题根本没有可穷举的规则再比如“详情页里写了‘全网最低价’”关键词列表只能查静态词换个说法比如“没有比我们家更便宜的”就查不出来了。这个阶段我印象特别深代码写得再严谨也无法覆盖“同一种含义换一种写法”的情况。规则引擎适合做硬校验不适合做软判断这是我转向 Qwen3.8-Max 这类大模型方案的核心原因。2. 为什么最后选 Qwen3.8-Max 当“体检医生”2.1 三个硬指标长文本、视觉理解、结构化输出选型的时候我的需求其实非常明确就三个硬指标。第一是长文本处理。6份资料全文丢进去光文本量就几万字模型得能真正记住前文提到的品牌名、生产商、规格号而不是只关注最后一段。Qwen3.8-Max 的长上下文能力是我最先确认的一点我会拿一份真实资料包的全文做基线测试看它能否在十几页文本里准确“回溯”到第一页的某个字段。实测下来只要给足来源标记它基本能把分散在不同页的信息串起来。第二是视觉理解。商品图不是拿来当装饰的包装上的生产日期、净含量、品牌Logo、宣传语全都需要被模型“读”出来并且要和文档里的描述做交叉比对。这就不能只是OCR还要求模型理解“包装印刷文字”和“详情页文案”之间的语义对应关系。我用一张印着艺术字体的包装图测过普通OCR会漏字但模型可以直接结合上下文把“某某经典版”和“某某升级版”的差异判断出来。第三是结构化输出。体检助手最终要落成一个问题清单问题类型、风险等级、证据原文、修改建议这些都要以结构化数据的形式交给后端。模型必须稳定输出JSON不能今天给数组、明天给字符串。三个能力缺一个这套东西就搭不起来。Qwen3.8-Max 在这三个方面都能覆盖我后续的Prompt设计和流水线拆分也都是围绕这三个能力来做的。2.2 它擅长“判断”但不会替你做“决定”这里有个很重要的认知我把模型定位成“体检医生”而不是“审判法官”。体检医生负责检查指标、指出异常至于要不要停药、要不要做手术那是人的事。放到这个项目里模型负责找出“哪里和哪里对不上”但最终要不要阻断上架、该怎么整改还得由业务审核人员来拍板。这个定位直接影响了我怎么设计Prompt。我不会让模型输出“该商品应该下架”这类主观决策只会要求它输出“详情页第2段写‘500g’质检报告项目名称为‘0.5kg’数值相同但单位展示不一致建议统一为‘500g0.5kg’”。结论和证据分离后续人工复核才有依据。我见过一些团队把大模型用在审核场景时直接让它给“通过/不通过”的结论结果模型给错了结论却找不到依据整个流程就失去了可追溯性。所以从一开始我就坚持模型只负责输出“事实不一致”的证据链决策留给规则岗和人工。2.3 和OCR规则、纯人工方案的对比为了说明这个选择我做了一张对比表都是实际跑过的方案方案跨文档比对能力图文交叉验证落地成本适合范围纯人工审核弱依赖个人记忆弱凭经验靠肉眼人员成本高、天花板明显少量精品链接OCR规则脚本无法处理语义不一致做不到开发快但规则复杂字段级缺失校验大模型方案强可跨文档语义比对强图文可互验需要做Prompt编排和兜底批量商品资料初筛这张对比表说明了一个问题OCR规则不是不能做但“6份资料不一致”这个核心痛点语义层面它写不出规则来。我之所以选择大模型方案不是因为它显得高级而是因为它能直接命中最大的漏项。在实际production里我也不会完全抛弃OCR和规则而是让它们负责模型“不擅长”的部分——比如硬字段校验、格式检查——这个混排思路在后面的兜底章节会详细讲。3. 把“体检”拆成五条检查流水线3.1 文档预处理扫描件、PDF、Word 统一变成“可读材料”正式调用模型之前得先解决“资料怎么喂进去”的问题。我常用的组合是PDF 用 pypdf 抽取文本扫描件先用 OCR 把整页转成文字Word 另存为文本再读。图片则不做强制文字化因为商品图上还有设计稿、艺术字体OCR 出来反而丢失排版信息直接让模型看原图更合理。这步有个很容易忽略的细节一定要给每种文档做“来源标记”。我会把每份文档编成“文档1-营业执照”“文档2-商标授权书”这样的编号然后在文本前面加一行“【文档3-质检报告】”。为什么要这么做因为后来跨文档比对时模型必须能在证据字段里准确指出“这份内容来自文档几”如果一开始没有来源标记模型输出的证据就无法被追踪整个体检报告的可信度就崩塌了。预处理时保存好文本、页码、块位置的对应关系等于给后续每条问题都装上了GPS定位。3.2 流水线一单文档关键字段抽取第一条流水线做的是“从每份文档里抽取结构化字段”。不同类型的文档Schema 不同营业执照公司名称、统一社会信用代码、法定代表人、经营范围、有效期商标授权书授权方、被授权方、商标名称/注册号、授权期限质检报告产品名称、规格型号、检验依据、检验结论、报告编号详情页文案商品名称、卖点、规格参数、宣传用语这一步的输出是“文档级字段表”每一条字段都附上原文位置。比如“产品名称某某修护精华质检报告第1页、项目名称第一行”。这个阶段不建议让模型做任何“判断”只做“提取”越机械越好因为一旦在抽取阶段就夹带判断后面的比对结果就会失真。我实际跑下来单纯抽取的准确率很高问题几乎都出在比对阶段所以两条流水线一定要分开。3.3 流水线二跨文档一致性比对字段抽取完之后才是重头戏。我开始把所有文档的字段拉平到一张主数据表里让模型对“同一语义字段”做交叉比对。这张表有点像Excel里的主数据表每一行对应一个商品不同列对应不同文档来源里的字段。模型的作用是逐列阅读、跨列比对找出“单位不同”“名称写法不同”“数值冲突”这些不一致。这里必须强调“字段归一化”。不同文档里同一个含义可能长得很不一样500g 和 0.5kg字面不同但数值等价XX牌、XX、XX中国品牌名带括号和后缀2025年6月1日和2025-06-01日期格式不同如果直接拿字符串去比一定全是误报。我先在Prompt里给模型一条规则判断一致性的前提是先把单位、繁体简体、括号类型、全角半角做归一化再比较语义是否等价。步骤做完才能输出真正有意义的问题。我在后面的案例拆解里会详细提到5.3节的“净含量不一致”其实就是归一化做得好才被发现的。3.4 流水线三商品图与文档交叉验证第三条流水线处理的是商品图。我会把商品图以图片形式喂给模型让它先读取包装上印刷的关键文字再和详情页文案、质检报告里的字段做比对。这条流水线我花了不少时间调因为图片输入和纯文本输入在Prompt写法上不太一样。我会先让模型回答“包装上有哪些文字信息”再给它文档字段表让它逐项做交叉检查而不是一上来就让它“直接判断”。这套逻辑能查出很多人工容易忽略的问题。比如包装正面印着“某品牌经典版”详情页标题却写“某品牌升级版”这属于包装和宣传不一致再比如包装上的净含量印的是“500ml”详情页参数却写“500g”这种单位错误如果靠人眼真的要很大概率才会注意到。我在测试里还遇到过包装设计图角落印着“非卖品”这个细节正常审核流程几乎不会有人去看但模型会把它当成一个独立的图文不一致问题报出来。3.5 流水线四合规规范检查与流水线五问题清单生成第四条流水线做合规和平台规范检查主要是资质的有效期、授权链路完整性、详情页极限词、条码校验等。这里我刻意把“合规检查”和前面的一致性检查分开是因为合规规则更偏确定性强适合用规则清单模型判断结合。比如“让模型判断有没有极限词”“让代码去算有效期剩几天”两者不要混在一起。规则代码负责计算模型负责语义判断各干各擅长的。第五条流水线则是把前四条的结果汇聚成统一的问题清单。每条问题包含类别、风险级别阻断级/风险级/提示级、证据原文、所在文档、修改建议。最终输出类似这样的一组结构化数据。到这里“体检”才真正结束后面的工作就是人工复核和整改。之所以把清单生成单独做成一条流水线是因为它要做“去重、合并、排序”的工作——有时候同一条不一致会在跨文档比对和图文比对里被报两遍必须按照证据原文去重否则人工看到一堆重复问题会非常烦躁。4. 搭建过程中两个让人头大的实现细节4.1 喂“证据”而不是喂“结论”我在搭建时遇到过最典型的问题就是模型输出“结论正确但证据可疑”。比如它说“文档2和文档3的商标注册号不一致”但你翻遍两个文档发现商标注册号根本没有出现在文档2里。这就是典型的模型“脑补”。原因在于我早期的Prompt给模型太多“判断空间”它觉得这里应该有注册号就直接编了一个。解决办法是给Prompt立规矩任何一条判断都必须先引用原文再下结论引用不出来的判断就视为不存在。我在系统提示词里原话是这么写的“当你发现问题时必须先在‘evidence’字段中给出文档编号和原文摘录再给出判断如果无法引用原文请直接忽略这条疑似问题。”这个约束加上之后误报率明显下降问题清单也更容易复核。需要注意的是这条规则要放在Prompt最前面而且要连续强调几次模型才会真正把它当成硬约束而不是建议。光靠“请仔细核对”这种措辞效果约等于零。4.2 输出格式不稳定怎么兜底大模型输出JSON偶尔会出现字段缺失或括号配对错误这是用LLM做结构化任务绕不开的坎。我的做法是“双保险”第一层是Prompt里的JSON格式说明明确要求字段名固定、字段类型固定第二层是代码里的后置校验和修复。校验失败时把模型上一次的原始输出和错误原因重新发给模型让它自己修复成合法JSON。这个方法实测最有效比自己写正则硬修靠谱得多。还有一个值得说的经验temperature一定要压低。内容审核场景不需要创意我把温度调到0.1左右让模型尽可能保守地输出宁可漏掉一条也不要胡编一条。安全边界上“漏报”可以靠人工复核兜底“误报”过多会让人直接失去对系统的信任。另外我也会在JSON Schema里限定枚举值比如level只能传“blocker”“risk”“tip”三选一category只能传五类减少模型自创类别的概率。4.3 上下文超长怎么破6份资料堆起来最满的时候有几万字。单个请求塞不下我就做了一个简单的分级策略先让模型对每份文档生成一段“文档摘要关键字段表”跨文档比对时只把“字段表摘要”送入而不是全文只有比对结果需要引用原文时才回头检索对应文档的原文片段。这样既保住了比对的准确性又把单次请求的上下文控制在一个安全的范围内。这个策略的代价是“摘要丢失细节”。比如某一份合同的某项条款特别重要但摘要里没有体现比对时可能就漏了。为了降低这个风险我会让前一条流水线把“关键字段表”做得足够详细宁可字段多一点也不要漏掉重要信息。处理长文核心思路不是把全文一股脑喂给模型而是尽量让模型在“高价值的片段”上做判断。5. 实测复盘6份资料1张图27个问题具体怎么来的5.1 材料清单与预期我在测试集里放了这样一批材料营业执照、商标授权书、质检报告、商品详情页文案、包装设计图、采购合同外加一张实拍商品图。看起来都是常规文件但我在里面埋了不少坑包括单位不统一、品牌名带后缀、授权链路断了一环、详情页出现极限词、包装图和详情页宣传不一致等。第一次跑的时候说实话我是带着怀疑的担心模型大概率只能找到一两处明显缺失。结果它输出27个问题我当时第一反应是“这货是不是在凑数”。随后我把输出逐条打开对照原文人工复核发现绝大部分问题都是真实存在的而且有明确的证据引用。这个结果让我对这套流水线从“试试看”变成了“能上线用”。5.2 27个问题的分类统计问题类别数量说明跨文档字段一致性9品牌名、产品名、规格、生产商在不同文件里写法不一致信息缺失/模糊6缺少检验依据标准号、授权书未标注有效期、合同缺少签章图文一致性5商品图上的文字与详情页描述不符、包装料号与合同料号不一致资质合规类4经营范围不覆盖目标类目、授权链路不完整、证件临近有效期平台规范类3详情页极限词、外包装未标注生产许可证号、SKU命名含敏感词9加6加5加4加3正好27个。这个分类不是为了凑数而是每类问题都对应不同的后续处理方式所以才会在生成阶段就要求模型打上类别标签。比如资质合规类的问题走资质补传流程图文一致性走设计修改流程跨文档字段一致性走信息统一流程分类清楚整改责任人也更明确。5.3 典型案例拆解这些问题到底是怎么被“揪”出来的案例一净含量单位不一致。详情页参数段写“500g”质检报告项目名称写“0.5kg”采购合同里写“500g/瓶”三个文件数值等价、但单位呈现不一致。人工审核翻到这三处得花不少时间而模型在跨文档比对时会把“500g”“0.5kg”这组字段拉出来做归一化比较直接命中。案例二品牌名带后缀。营业执照上的公司名称、商标注册证上的商标、授权书里的品牌名三处写法分别是“某某”“某某中国”“某某牌”。归一化之后发现商标主体一致但这属于“写法不规范”而非“不一致”最终被我归到“提示级”而不是“阻断级”。这个细节说明问题分级本身也需要语义判断不是所有不一致都是硬伤。如果系统把这类问题全当阻断级运营一天能收到几十条整改通知很快就会失去对工具的信任。案例三包装图上的“非卖品”字样。包装设计图右下角赫然印着“非卖品/赠品”字样但详情页完全按正常在售商品来写。这个如果没有图文交叉验证人工几乎不可能注意到因为谁会专门去看包装设计图角落里的三个小字呢。这类问题一旦上架后被发现轻则修改链接重则被判违规。案例四授权链路断裂。营业执照主体是A公司商标授权书授权方是B公司但采购合同签的是C公司C公司并没有A或B的直接授权。模型会在资质链路里画出关系然后指出“C公司未出现在授权链条上”这是一个非常典型的跨文档逻辑漏洞。人工审核时这类问题通常要等平台方提出质疑才会被发现前置筛查能省掉大量沟通成本。案例五详情页极限词。详情页开头写“全网最低价”这个其实用关键词列表就能扫出来但模型还能识别同类变体比如“没有比我们更划算的”这种表述正则几乎无法覆盖语义模型处理起来就轻松很多。我特意测试过几种变体写法模型的识别率明显高于正则黑名单这一点在平台规范检查里非常实用。5.4 “查出27个问题”不代表问题越多越好我特别想强调一句问题数量本身不是KPI。如果为了让模型多报问题把提示词改成“尽可能多地发现问题”一会儿就会收到几十条“疑似问题”其中一半是误报人工翻完直接崩溃。我在实际使用中把所有输出划分为阻断级、风险级、提示级三级只有前两级才计入最终问题清单提示级只能作为参考即使是这样每次跑完仍然要求业务侧做一次人工抽检大模型的输出永远是“初筛建议”而不是“最终裁决”。这里有一个很现实的考虑太多的“提示级问题”会淹没真正需要整改的“阻断级问题”。人工处理时只有当问题数量控制在几十条以内且每条都带证据时审核效率才真正提升。我也见过一些团队把模型调得“过灵敏”结果每条商品都能报出一堆小问题运营反而更累了这就是典型的没有控制好问题分级。6. AI“体检”也会翻车误报、漏报与兜底方案6.1 误报案例模型把“注册地址和生产地址不同”当作问题第一版跑测试的时候模型报了一条营业执照地址是A区xx路质检报告上的地址是B区xx路地址不一致。我一看就觉得不对——营业执照上的叫注册地址质检报告上的叫生产地址两个概念本来就允许不同。这个问题是模型“过度解读”的典型表现它看到两个地址字符串不一样就直接套用了“不一致”的判断逻辑却没有考虑字段语义是否允许不同。这个问题后来在Prompt里加了一句话解决“仅当同一字段在不同文档中语义等价且预期应一致时才判定为不一致例如注册地址与生产地址不是同一字段不应做一致性检查。”这里面的教训是不要把所有字段扔给模型做自由比对人工要先定义哪些字段“必须一致”哪些字段“允许不同”。字段语义分类是大模型应用里常常被忽略、但非常关键的一步。我后来专门做了一张“字段关系表”把需要比对的字段对、允许不同的字段对都列进去模型只在这张表定义的范围内做判断。6.2 漏报案例包装图上反光导致关键文字识别不出来商品实拍图如果带透明反光模型有时会漏读净含量那一行字导致图文一致性检查直接跳过。我第一次遇到这个问题是拿一张亚克力瓶身实拍图测试瓶身反光把“净含量500ml”这行字盖住了一部分模型完全没有提取到这个信息。这让我意识到纯视觉通道并不总是可靠。实际解法是除了实拍图把包装设计图也一并传入如果同属一个商品二者可以互为备份。包装设计图是印刷稿文字清晰实拍图用来验证“实物和设计稿是否一致”分而治之。这个策略基本把漏读率降到了可以接受的范围。6.3 兜底规则引擎做硬约束大模型做软判断这套系统跑通之后我做的最重要的一件事是在模型前面和后面各加了一道规则闸门。前置规则负责“硬字段校验”证件有效期用代码计算剩余天数、统一社会信用代码用正则校验格式、条码用模量算法校验。这些确定性很强的工作交给代码处理比让模型处理稳定得多。后置规则负责“结果过滤”模型输出的每条问题都要被白名单和黑名单检查比如“经营范围”这种字段必须存在但不做语义判断模型误报“经营范围不含目标类目”时会被直接过滤掉。这样做的思路很简单能用规则做的确定性问题不要交给大模型大模型只负责做语义判断和跨文档推理。两套能力互补翻车率才真正降下来。6.4 怎么验收拿历史商品做回归最后说说验收。我拿过去半年已经人工审核过的商品资料做了回归测试把当时人工标注的问题和这套系统跑出来的结果做对比主要看两个指标一是人工发现的问题里系统能找到多少二是系统报出的问题里有多少是真的问题。实际跑下来系统的召回表现远超人工速度但精确率做不到100%误报集中在两个领域品牌名带后缀的“伪不一致”以及地址类的“概念混淆”。这也说明大模型应用不是一锤子买卖需要根据误报语料持续调整Prompt里的字段语义定义。把误报样本收集起来每周做一次Prompt迭代整个系统会越用越稳。这里我想多提一句“人工验证”的价值。每次跑完测试集我都会人工抽查20%的输出把误报和漏报记录下来然后反推是Prompt问题、字段定义问题还是模型能力边界问题。经过三轮迭代误报率降到可以接受的范围后才敢把输出结果直接交给运营侧使用。没有这套验证流程模型输出再漂亮也只是空中楼阁。最后再分享一个我觉得最值得记住的小技巧所有Prompt里我都在最前面加同一句硬规则——先引用原文再下结论。这句话帮我挡住了至少六成的模型“脑补”。如果你也想搭类似的审核工具不用急着上复杂的Agent框架先把“资料预处理、字段Schema、证据约束”这三件事做好再把大模型放进去当核心判断器效果会比堆功能好得多。工具能帮人省下大量重复劳动但真正为结果负责的始终是坐在屏幕前做最终复核的人。