做电商运营的朋友应该都有过这种体验一个商品要上架手里攥着标题、卖点、详情页文案、参数表、资质文件、客服话术好几份资料来回核对信息是否一致、有没有违禁词、参数有没有夸大检查完一遍眼睛都快花了。我自己负责的店铺每月要上新几十个SKU光靠人工审资料根本审不过来经常出现商品详情页参数和质检报告对不上、标题里带极限词被平台处罚这类低级事故。所以前段时间我用Qwen3.8-Max搭了一个电商商品资料包体检助手把资料包一次性丢进去模型自动按规则逐份扫描把标题、文案、参数、资质、客服话术和商品图全过一遍。实测拿6份文本资料和1张商品图跑了完整流程一次查出27个问题从违禁词、极限词、信息矛盾到图片规范全都有整个过程不到两分钟。这篇文章就把这套方案的思路、提示词设计、代码实现和踩坑记录完整分享出来想用大模型做商品审核的朋友可以直接参考复现。1. 为什么要做资料包体检助手人工审核的痛点和模型选型1.1 人工审核到底慢在哪、错在哪先说一个我自己的数据。以前一个商品从资料整理到审核完成平均要花40到60分钟。检查项特别碎标题字数有没有超限、有没有“最”、“第一”这类极限词、卖点文案里有没有夸大宣传、参数表的数值和质检报告是否一致、客服话术里有没有承诺“100%有效”之类的违规表述、商品图上有没有水印和文字遮挡。这些检查项分布在不同文档里光来回切换文件就够累的。更麻烦的是人工审核的准确率并不高。我让两个人分别审同一套资料结果问题清单重合率只有六成左右漏检是常态。尤其是“跨文档一致性检查”比如详情页写的规格是500ml参数表却标了450ml这种矛盾靠肉眼很难逐一发现。所以我就想能不能用大模型把审核这件事自动化。1.2 为什么选 Qwen3.8-Max 而不是本地小模型选型上我先排除了本地部署的7B、14B模型原因很简单资料包审核涉及多文档综合判断需要模型有不错的上下文理解能力本地小模型在处理跨文档一致性和复杂规则判断时表现不太稳定容易出现明明文案有矛盾却给不出结论的情况。Qwen3.8-Max是API调用方式不需要自己准备GPU推理环境。我实测下来它的指令跟随能力比较扎实尤其是在“按规则输出JSON”这个环节几乎没有跑偏过。另一个优势是支持图片输入商品图的规范检查不用再单独接一个视觉模型一个API就把文本和图片都覆盖了。对于想快速落地的人来说省掉部署运维这一步能省很多精力。1.3 体检助手的核心工作流程整个体检助手本质上是一个“读取资料包 → 逐份规则检查 → 汇总问题清单”的流水线遍历资料包目录按文件类型分别提取文本内容txt、md、docx等。将每份资料的内容和对应的检查规则模板组装成Prompt。调用Qwen3.8-Max接口让模型逐份返回json格式的检查结果。把每份资料的检查结果合并按问题类别去重、归类生成总报告。这套流程对技术栈要求不高只要会Python基础就能跑通。我后面会给出实际可用的代码示例。2. 体检清单怎么定先搞清楚一份商品资料包该查什么2.1 6份资料的分类和各自检查重点开始写代码之前最需要花心思的是“检查项”本身。没有一份靠谱的体检清单模型再强也给不出有价值的结论。我结合自己的类目和平台规则把一份典型的商品资料包分成6类每类对应不同的检查重点资料类型典型文件检查重点商品标题标题文案.txt字数范围、堆砌词、特殊符号、极限词卖点描述五点描述.md夸大宣传、无依据承诺、信息冗余、语法错误详情页文案详情页说明.docx错别字、违禁词、参数一致性、绝对化用语规格参数表参数表.xlsx转文本缺失关键参数、数值单位错误、与详情页矛盾资质文件摘要质检报告摘要.md报告编号缺失、检测项覆盖不足、品牌授权链不完整客服话术话术FAQ.txt违规承诺、不文明用语、售后政策表述不清这里要特别提醒检查项不是越多越好而是越“有依据”越好。如果模型被你要求“找出所有可能的问题”它会倾向于把没问题的内容也标成问题产生大量误报。我的做法是每条检查规则都尽量对应明确的平台规则或常识性合规要求。2.2 一张商品图要查什么视觉规范不可忽视商品图是整个资料包里最容易被人忽略、却又很容易被平台判违规的部分。常见的图片问题包括白底图背景不纯、商品主体占比过小、图片带促销文字或水印、模特图出现品牌Logo遮挡、图片分辨率不足等。这些检查项以前需要美工人工看图现在可以直接把图片传给Qwen3.8-Max让模型描述图片内容并对照检查规则逐项判断。我在实际使用中模型对“背景是否纯白”“是否有文字压住商品”“主体是否居中”这类问题的判断基本准确可以直接作为初筛结果再用人工复核。2.3 检查规则的表达方式让模型听得懂、不跑偏同一句话不同的人理解不同模型也一样。检查规则必须写成“可执行”的表述而不是模糊的“有没有问题”。举例来说模糊写法检查标题是否合规。可执行写法检查标题中是否出现明确禁止的绝对化用语例如“最”、“第一”、“顶级”、“100%”等如果出现请列出原文和对应规则编号。我在设计Prompt时会在规则后面附带1到2个示例告诉模型“什么情况算违规什么情况不算”。比如“质量更好”这种相对描述通常不算违规但“全网质量最好”就是典型的绝对化用语。用到几个真实例子引导后模型的准确率会明显提升。3. 提示词设计体检助手好不好用关键在这一层3.1 系统提示词把角色和职责定清楚我使用的Prompt结构分两层系统提示词负责定义模型角色和输出格式用户提示词负责塞入待检查的文本和具体规则。系统提示词大概是这样的你是一名资深的电商商品合规审核专家熟悉各大电商平台的商品发布规则。你的任务是检查给定的商品资料内容找出其中可能存在的合规问题、信息矛盾、表述不当等内容。请严格按照给定的检查规则逐项执行不要遗漏也不要无中生有。输出格式必须为JSON字段如下 { checked_type: 资料类型, issue_count: 问题数量, issues: [ { rule_id: 规则编号, severity: high/medium/low, quote: 问题原文摘录, reason: 问题原因说明, suggestion: 修改建议 } ] }这里有个细节值得说一下我要求模型必须输出“问题原文摘录”quote字段而不是只给一个“标题里有限制词”这种模糊描述。有了具体原文后续人工复核就不用再去原文里翻找了。3.2 用户提示词规则清单加待检内容的组装方式用户提示词部分我会把同一类资料的规则清单和文本内容一起传进去。规则清单我单独维护在一个Python字典里方便随时增删而不是硬编码在Prompt字符串里。这样做的好处是规则一更新不需要改代码逻辑。举个例子检查商品标题时用户提示词大致是请对以下商品标题文本进行合规检查 【待检内容】 {title_text} 【检查规则】 1. 标题长度是否在10到50个字符之间 2. 是否出现极限词/绝对化用语最、第一、顶级、极致、100%等 3. 是否出现堆砌词大量重复的促销词如包邮、特价连续出现3次以上 4. 是否包含违禁词例如医疗相关、权威认证、国家级别等表述 5. 是否存在特殊符号滥用、【】、★等连续使用超过2个 请按系统提示中的JSON格式输出。注意我没有让模型“自由发挥”而是把规则一条一条列出来。规则越具体模型越不容易乱来。早期版本我试过“检查标题里有没有问题”这种开放式指令结果模型一会儿说标题太长一会儿说标点有问题但很多判断并不准确。3.3 图片检查的Prompt让模型先描述再判断图片检查和纯文本检查不太一样直接问“这张图有没有问题”容易得到发散的回答。我的做法是分两步提示模型先让它描述图片的核心要素再让它对照规则逐项给出判断。这是一张电商商品主图。请先描述图片的基本内容包括主体商品、背景颜色、是否有文字、是否有水印或Logo、商品在画面中的位置和占比。然后根据以下规则判断 1. 背景是否为纯白色或接近纯白允许轻微色差 2. 商品主体是否完整可见是否被文字、Logo或水印遮挡 3. 商品主体是否居中且占画面比例是否在50%以上 4. 图片中是否存在与商品无关的元素 5. 图片四周是否有边框或留白不足 请用JSON格式输出{description: ..., issue_count: n, issues: [...]}先描述再判断的好处是模型的注意力会先放在“看图上”而不是一上来就猜答案。实测下来对于背景不纯、文字遮挡、主体不居中这类问题识别准确率能达到比较满意的水平。4. 实操过程从零到一实现体检助手的完整步骤4.1 环境准备和依赖库安装我的运行环境是Python 3.10主要依赖openai库用于调用兼容OpenAI格式的API接口、python-docx提取Word文档内容、Pillow处理图片大小。安装命令很简单pip install openai python-docx Pillow python-dotenv本地文件我统一放在一个目录下比如/data/product_package/里面按资料名称命名好。代码里我用了一个load_text_file()函数根据扩展名调用不同的解析方法。txt和md直接读文本docx用python-docx逐段提取。from pathlib import Path import docx def load_text_file(path: Path) - str: ext path.suffix.lower() if ext in [.txt, .md]: return path.read_text(encodingutf-8) elif ext .docx: doc docx.Document(str(path)) return \n.join([p.text for p in doc.paragraphs]) elif ext .csv: return path.read_text(encodingutf-8) else: return 如果你的资料包里有PDF文件可以先用pdfplumber或PyMuPDF提取文本再复用同一套逻辑。我这里暂时没把PDF纳入流程因为我的质检报告是摘要文本形式。4.2 调用Qwen3.8-Max接口超时、重试和参数设置调用方式采用OpenAI兼容接口比较省事。关键参数我建议这样设置model使用qwen3.8-max这个模型名。temperature控制在0.2左右。审核任务需要稳定输出温度太高模型会“发挥”太低又容易死板0.2是我试下来比较平衡的值。max_tokens根据资料长度调整我一般设置为4096足够输出完整JSON。timeout网络请求超时设长一点60秒比较保险遇到长文本省得频繁重试。我在代码里还写了个简单的重试机制因为API偶尔会因为网络波动报错。重试3次、每次间隔2秒基本能覆盖大部分临时性故障。from openai import OpenAI client OpenAI( api_key你的API-KEY, base_urlhttps://你的接口地址/v1, timeout60 ) def call_qwen(system_prompt: str, user_prompt: str, temperature: float 0.2): for attempt in range(3): try: response client.chat.completions.create( modelqwen3.8-max, messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt} ], temperaturetemperature, max_tokens4096 ) return response.choices[0].message.content except Exception as e: if attempt 2: raise e time.sleep(2)4.3 图片预处理上传前先压缩和转Base64图片传给模型有两种常见方式一种是直接传图片URL另一种是把本地图片转成base64字符串随请求一起发送。本地文件一般用后者因为不需要额外建对象存储。我踩过的一个坑是图片太大的时候请求会失败所以我在传图前统一用Pillow做了压缩处理把长边限制到1024像素以内保存为JPEG格式转base64。这样既保证模型能看清商品主体又避免请求体积过大。import base64 from PIL import Image from io import BytesIO def encode_image_to_base64(path: Path, max_side: int 1024) - str: img Image.open(path) img img.convert(RGB) img.thumbnail((max_side, max_side), Image.Resampling.LANCZOS) buffer BytesIO() img.save(buffer, formatJPEG, quality85) encoded base64.b64encode(buffer.getvalue()).decode(utf-8) return fdata:image/jpeg;base64,{encoded}注意base64编码后要加data:image/jpeg;base64,前缀不然模型端识别不了图片格式。这个前缀我刚开始就漏了浪费了不少调试时间。4.4 主流程把6份资料和1张图逐个送检主流程我写成一个循环遍历资料清单对每一份资料调用对应的检查函数把返回的JSON解析出来汇总成总的报告。为了不让单个请求卡死整体流程我用了ThreadPoolExecutor并发处理6份文本资料图片检查单独跑一份任务总体耗时能压到2分钟以内。from concurrent.futures import ThreadPoolExecutor, as_completed def inspect_document(file_path: Path, doc_type: str, rules: str): content load_text_file(file_path) user_prompt f请对以下{doc_type}内容进行合规检查\n【待检内容】\n{content}\n\n【检查规则】\n{rules} result call_qwen(SYSTEM_PROMPT, user_prompt) return doc_type, result def main(package_dir: Path): tasks [] with ThreadPoolExecutor(max_workers4) as executor: for doc_type, file_name, rules in DOC_CHECK_PLAN: file_path package_dir / file_name tasks.append(executor.submit(inspect_document, file_path, doc_type, rules)) # 图片任务单独提交 tasks.append(executor.submit(inspect_image, package_dir / 商品图.jpg)) all_issues [] for future in as_completed(tasks): doc_type, result_json future.result() parsed json.loads(result_json) all_issues.extend(parsed.get(issues, [])) print(f{doc_type} 检查完毕发现问题 {parsed.get(issue_count)} 个) return all_issues这里有一个经验解析模型返回的JSON时千万不要直接用json.loads一把梭。模型偶尔会在JSON前后加一些说明文字比如“好的以下是检查结果”导致解析失败。我的处理办法是先做一次“JSON提取”——用正则把最外层大括号内容截取出来再尝试解析。如果还失败就启用备用方案要求模型重新输出纯JSON。4.5 输出报告按严重程度分级方便运营快速处理27个问题如果只是堆在一起给运营看人家还是会晕。我的做法是按严重程度分成三档高可能引发平台处罚或客户投诉、中需要修改但影响有限、低建议优化项。输出样式做成Markdown表格直接贴在协作文档里就行。严重程度问题数量处理建议high4必须修改后才能提交medium13尽快修改建议3天内处理low10择机优化问题的具体描述我会保留模型输出的quote和suggestion。实测下来运营同事对这种“带原文、带修改建议”的格式反馈很好不用再自己去翻原文逐条解决了。5. 实测记录6份资料加1张图查出27个问题的全过程5.1 测试样本说明我拿自己店铺一个即将上架的商品做了测试。资料包里有6份文本文件和1张商品主图分别是标题文案.txt商品标题和副标题五点描述.md卖点描述详情页说明.docx详情页的图文文案脚本参数表.csv规格参数表质检报告摘要.md检测报告核心内容摘录客服话术FAQ.txt客服常见问答商品主图.jpg白底商品图这些文件是平时上架资料的常规组合覆盖了文本和图片两类模态。5.2 一次跑出来的问题清单和我的处理方式整个流程跑完程序汇总出来27个问题。我按类型整理如下标题类问题5个包含“极致”这个绝对化用语、“包邮”出现3次属于堆砌、特殊符号“”连续使用2个以上、标题超过50字符、副标题有重复卖点词。卖点描述问题6个出现“全网销量第一”的绝对化表述、有两个卖点描述重复且占据大量篇幅、一处用“100%纯天然”未提供检测依据、两处信息与参数表矛盾容量一个写500ml一个写450ml、结尾处有疑似诱导评价的表述。详情页文案问题7个错别字2处“防滑”写成“防华”、“耐磨”写成“耐魔”、出现“国家级”字样、与参数表有3处参数不一致型号、重量、尺寸、一句描述“超强耐用”缺少可验证对比数据。参数表问题3个缺失“生产日期”字段、重量单位“g”和“kg”混用导致歧义、售后政策表述“7天无理由退换”与平台规则不完全一致。质检报告摘要问题3个缺检测报告编号、检测项目里没有“甲醛含量”这一项详情页却声称通过甲醛检测、报告有效期未标注。客服话术问题1个FAQ中出现“保证绝对不坏”的绝对化承诺。商品图问题2个图上有促销角标文字且遮挡了商品左下角、背景不是纯白而是偏米色。看到这个清单的时候我自己也吓了一跳。以前人工审核只盯标题和详情页参数表和质检报告基本是走过场没想到这里能挖出这么多问题。特别是“详情页写500ml而参数表标450ml”这种矛盾人工真的很难发现。5.3 哪些判断准确、哪些需要人工复核模型自动识别和我的预期做了对比。准确率比较高的项包括极限词识别、堆砌词识别、错别字识别、图片背景判断。这些属于模式相对固定的问题模型基本一抓一个准。需要人工复核的项主要集中在这几类跨文档一致性判断模型能发现“容量不一致”但到底是详情页写错还是参数表写错需要人来确认。政策合规性判断比如“7天无理由退换”是否完全符合平台规则模型只能提示“有待确认”不能替代运营判断。语义层面的夸大宣传比如“超强耐用”这种表述模型能识别它缺少量化支撑但算不算违规还是要结合平台的具体规则。所以这套体检助手的定位是“初筛预警”不是“终审”。它能帮我们把80%的显性问题在几分钟内揪出来剩下的20%判断留给人工效率已经比纯人工提升了一个量级。6. 常见问题与排查技巧实录6.1 模型返回的内容不是合法JSON怎么办这个问题几乎每个人都会遇到因为大模型偶尔会在JSON前后加一点解释性文字。我的解决办法是写一个extract_json()函数用正则把第一个{到最后一个}之间的内容截出来再做解析。如果正则提取后仍然解析失败就把错误信息返回给模型让它“修正输出JSON”。import re import json def extract_json(text: str) - dict: match re.search(r\{.*\}, text, re.DOTALL) if not match: raise ValueError(未找到JSON内容) return json.loads(match.group())我还在Prompt末尾加了一句“不要输出任何多余内容只输出JSON”这一句话就把跑偏率从大约15%降到5%以下。6.2 待检文本太长超出上下文限制怎么办详情页文案经常很长动不动几千字全部塞进Prompt会占用大量token还可能超出上下文窗口。我的做法是先做长度判断超过2000字就按段落拆成几个片段分别检查再把各片段的结果合并。这样做还有个附带好处单次请求的耗时和成本都更低。def split_text(text: str, max_len: int 2000): paragraphs text.split(\n) chunks [] current for para in paragraphs: if len(current) len(para) max_len: chunks.append(current) current para else: current \n para if current: chunks.append(current) return chunks拆分时有一个细节尽量按段落切而不是简单按字符数硬切避免把一句话从中间断开影响模型对语义的理解。6.3 误报和漏报怎么平衡最开始我的规则写得特别细、特别多结果模型给出的“问题清单”长得离谱很多其实是正常描述也被标成问题。后来我做了三个调整每条规则都加“判定标准”和“排除条件”比如“如果出现‘最’字但上下文是‘最近’则不算违规”。在Prompt里明确要求“仅报告有明确依据的问题对于存疑内容不要列入”。设置一个“疑似问题但需要人工确认”字段让模型把拿不准的内容单独列出和确定问题分开。调整之后误报数量下降了很多剩下的基本都是值得看一眼的内容。6.4 图片传不上去或识别效果差图片识别效果差大多数时候不是模型能力问题而是图片预处理没做好。分辨率太低、商品太小、光线太暗都会影响识别。我建议把长边控制在1024像素左右保证清晰度的同时避免文件过大。还有一个经验如果商品图上文字很多模型可能把注意力都放在文字识别上反而忽略了对背景、遮挡等问题的判断。这种情况可以在Prompt里强调“请先判断构图和背景再识别图中文字”模型的关注点会明显调整。6.5 成本控制检查一份资料大概花多少钱有人会担心调用大模型API做审核的成本。以我实测的这份资料包为例6份文本加1张图总共消耗的token大约在15000到20000之间折合费用不到几毛钱。相比人工审核几十分钟的时间成本这个成本几乎可以忽略。唯一要注意的是如果不做文本拆分直接硬塞超长内容token消耗会成倍增加所以拆分策略本身也是一种省钱手段。7. 这套方案还能怎么扩展我目前这个体检助手只处理了“上架前检查”这一环但仔细想想它完全可以往前后两端延伸。向前延伸可以接入商品资料提交流程运营把资料包上传到内部系统后自动触发检查检查不通过直接打回省去中间人工分拣的环节。向后延伸可以把历史问题汇总成问题知识库定期用模型分析高频问题类型反哺到商品资料模板的优化里。另外现在我只检查了文案和商品主图其实整个链路还可以加入视频素材的逐帧画面检查、评价回复的合规检查、竞品资料包的对比分析等。模型的能力边界已经不是瓶颈瓶颈在于我们愿意投入多少精力去完善检查规则库和流程设计。说实话用Qwen3.8-Max做体检助手这件事技术上并不复杂真正的价值在“规则设计”和“流程整合”这两个层面。规则定得准模型才能查得准流程接得顺工具才有人愿意用。我实测下来这套方案已经完全能替代掉我之前60%左右的人工审核工作量剩下的40%是模型不擅长、必须靠人判断的内容。两分钟查完27个问题放在以前想都不敢想。