1. 项目概述一次能查出27个问题的电商体检助手这个项目起源于我在运营朋友群里的一次吐槽。她负责某品牌旗舰店的商品上架每次开新款都要准备标题、卖点、详情页文案、资质文件、SKU表、价格库存表六份材料外加一张主图。这些材料散落在不同的Excel、Word和PDF里每次上架前都要人工核对一遍比如标题里的关键词有没有覆盖到搜索热词、详情页里的卖点是否和资质文件矛盾、SKU表的条码能不能对应上库存、价格带和平台活动有没有冲突等等。她说自己每次核对大概要花一个多小时还经常漏掉细节比如某个SKU的颜色名称在表格里是“曜石黑”主图文件名却写的“石墨黑”结果上架后被平台判定为描述不符。我听完就萌生了一个想法能不能用大模型做一个自动化的“资料包体检”工具输入进6份资料和1张商品图大模型直接按电商审核规则逐项检查输出一份带严重级别和修改建议的体检报告。当时正好Qwen3.8-Max发布了更新版本在多模态和长上下文上有明显增强我就决定拿它来搭这套工具。做完之后的结果是模拟的一批商品资料包它一次检出了27个问题覆盖标题关键词遗漏、卖点与参数矛盾、SKU条码不一致、库存价格配置异常、图片与标题主体不符等多个类别。这篇文章我就把这套东西怎么搭、怎么设计体检项、怎么让它输出结构化报告、以及我踩过的坑完整拆出来。它适合谁参考呢一是电商运营或商品管理相关岗位的人你可以直接用同样思路做一个自动审核工具二是做AI应用落地的开发者这里面涉及到的多模态解析、RAG检索、规则引擎和大模型结构化输出都有实际项目价值三是纯粹想看看大模型怎么解决真实业务问题的人这篇也能给你一个比较完整的案例。2. 方案设计为什么选Qwen3.8-Max而不是纯规则引擎2.1 从人工核对流程反推自动化方案在动手写代码之前我先花了很长时间梳理人工核对到底在做什么。这步非常关键因为如果你不清楚人工流程里有哪些检查动作你就不可能设计出自动化的体检项。以朋友运营的那类标品为例人工核对一般分这几步第一步是看标题。运营脑子里记着一堆品牌词、品类词、核心属性词、场景词她会把这些词逐一放进标题里去找看哪些有、哪些没有。同时还会检查标题有没有违规词比如“最”“第一”“国家级”这种绝对化用语。第二步是看详情页文案和资质文件。详情页里如果写了“抗菌率99%”她就要去看检测报告里是不是真的有这个数据写了“质保三年”就要去看售后政策文件里是不是对应。第三步是看SKU表和库存价格表。每个SKU的条码能不能对上颜色规格命名是否统一价格是否在平台限价范围内库存数字是否有异常像负数或超出仓容。第四步是看图片。主图里的产品主体、颜色、外观和标题描述是否一致如果标题写“白色陶瓷版”图里却是个黑色塑料壳显然就不行。你把这些动作拆开来看有的是非常明确的规则判断比如“标题不能超过指定字数”或“价格不能是负数”有的则是语义判断比如“卖点和检测报告是否矛盾”或“图片主体和标题描述是否一致”。如果是纯规则引擎来做第一类能覆盖第二类基本做不了。因为第二类判断的本质是语义对齐需要把两段不同来源的信息做比较判断它们说的是不是同一件事、数值是否一致、描述是否冲突。传统办法是做命名实体识别和关键词匹配但遇到“曜石黑”和“石墨黑”这种说法不同但颜色相近的情况规则很容易误判。我的方案是规则引擎处理确定性检查大模型处理语义类检查。Qwen3.8-Max在这里扮演的角色是一个“能读懂多份文件并做交叉比对的语义引擎”。2.2 Qwen3.8-Max的选型理由选Qwen3.8-Max不是拍脑袋我对比了当时的几个主流方案。首先是它能同时处理文本和图片。商品资料包里有Excel、Word、PDF也有一张商品主图。如果分两个模型处理文本用文本模型、图片用图像模型那在图文一致性判断上就需要额外写中间逻辑把两边结果拼起来。Qwen3.8-Max本身的视觉能力不错可以直接读图并且能和文本内容一起放在同一个上下文里做联合推理这省掉了不少工程量。其次是它的长上下文能力。6份资料加起来少则几千字多则上万字加上图片如果模型上下文窗口不够大就得做切片再分段聚合那交叉比对的逻辑会非常复杂。Qwen3.8-Max的长上下文能一次把全部材料塞进去虽然也不是无上限但应付标品资料包的体量是够的。再次是它的结构化输出能力也就是输出JSON的能力。体检助手最终要输出一份带“问题编号、检查项、严重程度、涉及文件、问题描述、修改建议”的报告如果没有稳定的JSON输出解析这一步会很痛苦。我实测下来Qwen3.8-Max在JSON Schema约束下输出格式的稳定性是够用的偶尔有格式跑偏但配合一个重试机制就能解决。2.3 整体架构RAG检索、规则引擎与大模型的组合这套“体检助手”的完整架构我拆成四个层次。最底层是文档解析层。6份资料的格式不一样Excel要用pandas读sheetWord要用python-docx提取段落PDF要按情况决定用文本提取还是OCR。商品图则直接作为多模态输入传给大模型。这一层的目的只有一个把所有资料变成统一的文本块并记录每个文本块的来源文件、sheet名或页码以便后续定位问题出处。第二层是规则引擎层。这一层跑所有确定性检查比如标题字数限制、是否含违禁词、SKU条码格式是否合法、库存是否为负数、价格是否符合上下限、文件是否缺失等。规则引擎的输出是一批“确定性问题”这些问题不需要大模型来猜。第三层是大模型语义检查层。这一层把规则引擎没覆盖到的部分交给Qwen3.8-Max。具体做法是先把所有文本块和商品图放进上下文然后给它一套检查清单让它逐项做语义比对。检查项包括标题与卖点一致性、卖点与资质文件的一致性、SKU命名统一性、图片与描述的一致性等。最上层是汇总输出层。规则引擎的确定性问题和大模型的语义问题合并在一起按文件来源、严重级别去重和排序最终生成一份Markdown格式或JSON格式的体检报告。这套设计的好处是规则引擎能保证确定性的错误百分之百被抓出来大模型则负责处理那些“需要读上下文才能判断”的问题。两者各干各擅长的事也避免了让大模型去数标题字数这种活。3. 核心细节拆解从资料解析到体检规则的下沉3.1 商品资料的输入规范体检助手要能跑起来第一步是把“6份资料1张商品图”定义清楚。我在实际项目中把这几个文件固定为01_商品标题与卖点.txt包含商品标题、主卖点、副卖点、适用人群、核心参数等。02_详情页文案.md运营写的详情页长文案包含图文逻辑、参数表、售后服务说明等。03_资质检测报告.pdf第三方检测机构出具的报告通常是带骑缝章的扫描件或电子版。04_SKU明细表.xlsx每个SKU的编码、条码、颜色、规格、价格、库存、状态。05_价格与活动配置.xlsx日常售价、活动价、限价、佣金比例、平台活动要求等。06_售后政策.pdf退换货规则、质保期限、维修政策等。product_image.png商品主图或白底图。注意这是一个“模拟规范”实际业务中资料格式可能五花八门。我这里做了一层文件命名规范化是因为在工具体系里文件名的前缀决定了这个文件要交给哪个解析器、以及对它跑哪些规则。你可以根据自己业务情况调整但建议尽量固定输入标准否则文档解析层会变成事故现场。3.2 文档解析层处理的坑文档解析是整套流程里最不性感但最容易出事的一环。我只讲三个高频坑。第一个是PDF里的文字层。如果PDF是从Word直接转出来的或者用PDF打印插件生成的一般有文字层用pdfplumber提取就好。但如果PDF是扫描件没有文字层就必须OCR。Qwen3.8-Max本身能读图所以对扫描件我的做法是把扫描PDF的每页转成图片然后直接交给大模型做多模态识别省掉单独部署OCR服务。实测下来对清晰的扫描件识别准确率很高但对方章、模糊字体、表格线错乱的情况还是要靠人工复核。第二个是Excel多sheet的问题。很多电商的SKU表不止一个sheet除了SKU明细还有库存流水、价格变更记录等。如果只读取第一个sheet那体检范围就会少一大块。我在解析时会把所有sheet的内容全部读出来每个sheet转成Markdown表格然后标记清楚文件来源和sheet名。这样大模型在做交叉比对时知道“这个表格来自04_SKU明细表的sheet2”定位问题就能精确到具体位置。第三个是Word里的图片。详情页文案Word里可能嵌了图说明图、对比图等等python-docx只能拿到段落文本拿不到图片内容。如果详情页的卖点是写在图片上的那文本提取就会漏掉。我在项目里是先用zipfile解包docx把word/media目录下的图片提取出来再把图片路径传给大模型让它结合图片和文本来理解详情页的完整内容。3.3 体检规则的分类与设计体检规则的分类比规则本身更重要。我按“检查性质”拆成了三类。第一类是格式完整性检查。这类检查的输入是文件名、文件格式、编码方式、必备字段是否为空。比如“06_售后政策.pdf不存在”“SKU明细表缺少条码列”“标题长度超过60字符”都属于这一类。它不涉及业务语义规则引擎就能搞定。第二类是数值合法性检查。这类检查针对价格、库存、比例等数值字段。比如“SKU表里的黑色款库存为-5”“活动价高于日常售价”“佣金比例超过50%”等。它需要明确的阈值或公式用规则引擎跑就可以而且必须保证结果可以追责——也就是说规则来自哪份文件、哪个单元格都要能定位出来。第三类是语义一致性检查。这类检查是大模型的主场比如“标题说支持无线充电详情页参数表里却没写”“检测报告里重金属数据超标详情页却说安全环保”“SKU表里叫曜石黑主图文件名叫石墨黑不确定是不是同一个颜色”。这类检查没有标准规则模板可套它依赖模型对两个不同信息源做语义对齐。这正是我选择大模型方案的核心价值。从人工核对流程到这个三类规则体系我要强调一个设计原则规则要可追溯检查项要可解释。体检报告里每一条问题都要能说清楚是依据什么规则、对比哪两份资料得出的结论。这样业务同事拿到报告才不会觉得是AI在瞎猜。4. 实操过程搭建体检助手的完整流程4.1 环境准备与依赖安装这套系统我用的是Python环境核心依赖包括pandas处理Excel、pdfplumber提取PDF文本、python-docx解析Word、openai调用大模型API、Pillow图片预处理、pyyaml配置文件管理。如果你要在本地跑建议用Python 3.10以上太老的版本对pandas和openai库的支持不够好。pip install pandas pdfplumber python-docx openai pillow pyyaml依赖装好之后我会先建一个config.yaml把模型的API地址、密钥、规则参数都放在里面。注意密钥不要写在代码里用环境变量或者配置文件读取避免提交到Git时泄露。model: base_url: 你的API地址 api_key: 你的API密钥 model_name: qwen3.8-max temperature: 0.1 rules: title_max_length: 60 sku_barcode_regex: ^[0-9]{13}$ max_commission_rate: 50 enable_semantic_check: true4.2 文档解析执行示例解析Excel的代码不复杂但要注意读所有sheetimport pandas as pd def parse_excel(file_path): sheets pd.read_excel(file_path, sheet_nameNone) parsed [] for sheet_name, df in sheets.items(): # 空sheet跳过 if df.empty: continue markdown_table df.to_markdown(indexFalse) parsed.append(f### Sheet: {sheet_name}\n{markdown_table}) return \n\n.join(parsed)这里有个细节sheet_nameNone会让pandas返回一个dictkey是sheet名value是DataFrame。然后我把每个sheet转换成Markdown表格。为什么要转Markdown而不直接传原DataFrame因为大模型对Markdown表格的解析能力比对行列索引结构好得多。转成Markdown后它一眼就能看明白行列关系在做交叉比对时更准确。PDF提取我用的是pdfplumber直接按页提取文本import pdfplumber def parse_pdf(file_path): text_parts [] with pdfplumber.open(file_path) as pdf: for i, page in enumerate(pdf.pages): page_text page.extract_text() if page_text: text_parts.append(f--- 第{i1}页 ---\n{page_text}) return \n\n.join(text_parts)如果PDF是扫描件pdfplumber提取出来会是一堆空字符串。这时候我会单独做一个分支用PyMuPDF库把PDF页面渲染成图片然后交给Qwen3.8-Max做多模态识别。Word文件的解析我用python-docx同时把图片从word/media目录拉出来from docx import Document import zipfile, shutil, os def parse_docx(file_path): doc Document(file_path) paragraphs [p.text for p in doc.paragraphs if p.text.strip()] # 提取Word内嵌图片 image_dir os.path.splitext(file_path)[0] _images os.makedirs(image_dir, exist_okTrue) with zipfile.ZipFile(file_path, r) as z: for name in z.namelist(): if name.startswith(word/media/) and not name.endswith(/): z.extract(name, image_dir) text \n.join(paragraphs) images [os.path.join(image_dir, f) for f in os.listdir(image_dir)] return text, images4.3 规则引擎初始化与检查执行规则引擎的代码我会拆成一个RuleChecker类每个规则是一个方法。这样做的好处是后期新增规则时只需要加一个新方法不需要改主流程。我先跑一个非常基础的版本包含五个核心规则class RuleChecker: def __init__(self, config): self.config config self.issues [] def check_title_length(self, title): max_len self.config[rules][title_max_length] if len(title) max_len: self.issues.append({ rule: TITLE_LENGTH, level: warning, message: f标题长度{len(title)}字符超过限制{max_len}字符, source: 01_商品标题与卖点.txt }) def check_barcode_format(self, sku_df): barcode_regex self.config[rules][sku_barcode_regex] for idx, row in sku_df.iterrows(): barcode str(row.get(条码, )) if not re.match(barcode_regex, barcode): self.issues.append({ rule: BARCODE_FORMAT, level: error, message: fSKU {row.get(SKU编码)} 条码 {barcode} 格式非法应为13位数字, source: f04_SKU明细表.xlsx 第{idx2}行 })这里有一个心得规则引擎检查结果里一定要带source字段精确到文件甚至是行号。因为后面汇总报告时按source分组就能快速帮用户定位“问题出在哪份文件哪一行”这是体检工具好不好用的关键。4.4 大模型语义检查的提示词设计提示词设计是整个工具效果的关键。这部分我调整了好几版最终沉淀了一个比较稳定的模板。我给Qwen3.8-Max的角色定义是“电商商品资料审核专家兼资深运营”然后给它三个层次的指示第一层是任务背景说明。告诉它你现在拿到的是某个商品的6份资料和1张商品图你的任务是根据给定的体检清单逐项检查输出JSON格式的问题列表。第二层是体检清单定义。我会在提示词里明确列出需要检查的语义项比如标题中的关键词是否覆盖了核心卖点、品类词和场景词。详情页文案中的参数数据和资质报告中的检测数据是否一致。SKU表里同款不同规格的命名是否统一规范。商品图的颜色、外观、主体是否与标题和SKU描述一致。售后政策里的质保条款和详情页承诺是否冲突。第三层是输出格式约束。我用JSON Schema来约束输出告诉它必须返回一个issues数组数组里每个对象包含check_item、levelerror/warning/info、description、evidence证据即你看到问题的那段原文、suggestion。提示词模板大致是这样的你是一名资深的电商商品审核专家现在需要审核一份商品资料包。 以下是该商品的6份资料和1张商品图。 资料内容 {text_corpus} /资料内容 商品图 {image_data} /商品图 请按照以下检查项逐一检查 1. 标题与卖点一致性 2. 详情页参数与资质文件一致性 3. SKU命名与图片颜色描述一致性 4. 售后政策与详情页承诺一致性 要求只输出JSON格式如下 {issues: [{check_item: ..., level: error, description: ..., evidence: ..., suggestion: ...}]}注意{text_corpus}这一块是所有文本资料拼接后的内容我用了特定分隔符标记每一份文件比如“文件: 01_商品标题与卖点.txt”。这样模型能明确知道每段文字来自哪个文件最终生成的evidence里会自动带出文件名问题定位会很方便。4.5 调用Qwen3.8-Max生成体检结果调用模型的部分我用的OpenAI兼容接口因为Qwen3.8-Max开放了OpenAI SDK兼容的调用方式代码写起来非常简洁from openai import OpenAI import base64 client OpenAI( base_url你的API地址, api_key你的API密钥, ) # 图片转base64 with open(product_image.png, rb) as f: image_base64 base64.b64encode(f.read()).decode(utf-8) completion client.chat.completions.create( modelqwen3.8-max, messages[ { role: user, content: [ {type: text, text: prompt_text}, {type: image_url, image_url: {url: fdata:image/png;base64,{image_base64}}} ] } ], temperature0.1, response_format{type: json_object} ) result completion.choices[0].message.content这里有一个关键点temperature要调低我一般设置0.1。因为体检任务是审核性质我们希望模型输出稳定、严格、不发挥不需要它“有创造性”。温度高了它可能把同一个问题换着花样表达汇总时还要做去重给自己找麻烦。另外response_format要指定为json_object这样模型会尽量输出纯JSON而非夹杂Markdown说明文字解析起来省心很多。4.6 输出体检报告模型输出的JSON经过校验和解析后我会和规则引擎的结果合并去重然后按严重级别排序生成一份最终体检报告。报告的格式我用的是Markdown表格因为它既能读又便于直接粘贴到团队协作平台上。每条问题包含问题编号、检查类型、严重级别、涉及文件、问题描述、修改建议。排序逻辑是error级别优先warning其次info最后同级别里按文件来源排序方便逐份文件整改。以下是模拟的一次完整测试输出6份资料加1张商品图累计检出了27个问题编号检查类型级别涉及文件问题描述修改建议01标题关键词覆盖error01_商品标题与卖点.txt标题缺少核心场景词“露营”该词已覆盖多个热搜长尾在标题中补充“露营”场景词02标题违禁词error01_商品标题与卖点.txt标题出现“全网第一”绝对化用语删除违规词替换为客观描述03详情页-资质一致性error02_详情页文案.md/03_资质检测报告.pdf详情页宣称“抗菌率99.9%”检测报告实际为“99.2%”修改为检测报告数值04SKU命名统一warning04_SKU明细表.xlsx同一颜色在SKU表中使用“石墨黑”和“曜石黑”两种命名统一命名为官方色号05图片-标题一致性errorproduct_image.png/01_商品标题与卖点.txt标题描述主体是“铝合金折叠桌”主图为木质桌面更换主图或调整标题描述..................27售后政策冲突warning06_售后政策.pdf/02_详情页文案.md详情页承诺“7天无理由退换”售后政策写“拆封后不支持”统一退换货规则表述我当时数完这27条问题最大感受是这类工具的真正价值不是替代人工它不会比一个八年经验的资深运营更懂商品但它能把“人容易疲劳、容易忘、容易看漏”的部分全部兜住。人工核对是抽查式、经验式的而体检助手是穷尽式的——只要规则清单里写了的检查项它每一次都会查一遍不会漏。5. 规则引擎与大模型的职责边界划分5.1 哪些检查必须交给规则引擎我看过一些项目什么判断都丢给大模型结果模型一本正经地胡说八道。体检工具最忌讳这一点。你必须想清楚哪些检查是规则引擎的铁律哪些才是大模型的自由发挥。先说必须交给规则引擎的几类一是数值精确比对类。比如检测报告上写的抗菌率是99.2%详情页写的是99.9%这种差异需要精确到小数点后一位。让大模型去读两个数字并比较它能做但存在偶尔看错位的风险。规则引擎直接从数据源取值、做数值计算准确率是百分之百。二是格式正则匹配类。条码必须是13位数字手机号是11位这些用正则表达式一跑就有结果不需要大模型。让大模型去做反而可能因为肉眼读数字的误差而漏报。三是文件与服务状态类。下载文件时发现某份附件缺失、Excel某个必填列为空、PDF无法解密这些属于程序判断与大模型完全无关。四是阈值规则类。比如活动价不得低于日常售价的80%、佣金比例上限50%这类基于业务规则的检查用规则引擎写死即可并且每次调整阈值只需要改配置不需要改代码。5.2 哪些检查必须交给大模型大模型不可替代的有四类一是语义对齐类。两段描述说的是不是同一件事比如详情页里的“五年质保”是否和售后政策里的“整机质保五年核心部件质保十年”对应上。这需要理解句子的语义层级简单的字符串匹配会死得很惨。二是语义矛盾类。SKU表里叫“曜石黑”图片看着像深灰色这到底算不算矛盾规则引擎只能判断字符是否相同而大模型可以根据图片实际颜色和文本描述做判断得出“虽然名称不同但颜色相近属于命名需要统一但不算严重违规”这种有层次的结论。三是诉求与证据匹配类。标题强调“户外便携”但详情页参数表里的产品重量是15kg这算不算矛盾规则引擎需要人工预先把“15kg”和“便携”的关系写死而大模型能根据常识判断15kg的折叠桌称不上“便携”。这类常识推理是规则引擎很难穷举覆盖的。四是图片内容理解类。上面提到的读取主图、判断产品主体和颜色必须用多模态模型。传统的图像分类模型只能给一个“桌子”或“椅子”的标签无法把“这张图里的桌子是木色的”和“SKU表里写的是曜石黑色”做关联判断。5.3 为什么不直接全用大模型你可能会问既然大模型这么强为什么不把所有检查项都丢给它省掉规则引擎我试过。第一次原型就是全丢给大模型的结果有两大问题第一是数字精度不稳定。大模型读数字是并行注意的长文本里两个相近的数字同时出现它真的会搞错。比如SKU表里有998个库存和998元价格模型可能把这两个数字混着用得出一个荒谬的结论。规则引擎用pandas取数永远不会错位。第二是成本没有边界。如果所有字段都让模型去读一份资料包可能消耗几万token。而规则引擎跑完所有确定性检查基本零成本。把简单检查放规则引擎、把复杂语义丢给模型整体成本能降一个数量级。所以我的实践结论是规则的归规则语义的归大模型。这套边界设计不仅降低了成本还提高了整体准确率。6. 实操中的关键细节与经验6.1 提示词里必须给出明确的输出示例大模型的稳定输出离不开少样本示范。我在提示词里除了JSON Schema约束外还会专门附一个“输出示例”以下是一个输出示例仅作格式参考 {issues: [{check_item: 标题关键词覆盖, level: error, description: 标题缺少场景词, evidence: 标题原文..., suggestion: 在标题中补充...}]}为什么有了JSON Schema还要给示例因为大模型对Schema的理解有时候会跑偏比如把level写成“严重”而不是“error”。给一个具体示例相当于把抽象约束具象化模型照着学就会非常规整。我用这个技巧之后JSON解析失败率从15%降到了不到3%。6.2 温度参数和重试机制温度参数前面说过了0.1是一个经验值。但如果你的业务要求特别严格的确定性可以进一步降到0。注意temperature0并不保证每次输出完全一致但能显著降低随机性。重试机制是必须的。大模型偶尔会输出残缺的JSON比如少了一个大括号、字符串没闭合。我写了一个简单的解析重试函数先用json.loads解析失败了就重新请求一次最多重试3次。三次还失败就标记为“待人工复核”拉进一个异常队列。6.3 凭证引用的重要性体检报告里“evidence”字段非常重要它是问题能否被信任的基石。如果模型报告“详情页和检测报告的数值不一致”但没给出原文片段业务同事根本不知道要改哪里也不确定是不是AI误判。我在提示词里强制要求每条issue必须包含evidenceevidence要引用原文中具体的那句话或那个数字。比如“详情页写‘抗菌率99.9%’出自02_详情页文案.md第3段检测报告写‘抗菌率99.2%’出自03_资质检测报告.pdf第2页”。这样写出来的报告业务同事几乎不需要再花时间去核实直接就能按建议去改。6.4 一些常规文档不会写的坑踩过的坑里比较典型的有三个第一个是Excel里的合并单元格。pandas读取Excel时合并单元格只在左上角位置有值其他位置是NaN。比如某一列的SKU名称合并了多行读出来是“黑色”和NaN交替直接把NaN传给模型模型就会困惑。解决办法是在读取后做一次向前填充ffill把合并单元格的值填到所有相关行。第二个是PDF里的页眉页脚干扰。用pdfplumber提取PDF时页码、公司名称这些页眉页脚会混入正文文本。如果检测报告里每一页都带着日期和页码大模型可能把页码当作某个参数。我的做法是做一步文本清洗去掉常见的页眉页脚模式同时如果整段文本全是数字且长度很短就跳过不纳入上下文。第三个是图片方向问题。商品图有时候是竖构图有时候是横构图模型都能识别但你传给它的图片如果分辨率过大比如几MB甚至十几MBAPI调用会变慢甚至超时。我在上传前用Pillow做了压缩处理统一调整为最长边不超过1024像素的缩略图既能保证识别精度又减少了传输时间。7. 验证效果27个问题的分类复盘把一次真实的模拟体检结果拿出来复盘你会更直观地看到这套工具能干什么。那次测试用的是一套虚构的“便携折叠桌”商品资料。输入6份资料和1张商品主图后体检助手输出了27个问题。我按问题类型做了归类第一类是标题合规与搜索优化类共8个问题。包括标题缺少“露营”“户外”等热搜场景词标题出现“全网第一”违禁词核心品类词被覆盖但卖点词缺失。这类问题对搜索流量影响很大平台抓违规词会导致降权改进也最快。第二类是详情页与资质一致性类共6个问题。包括抗菌率数据不一致、材质描述与检测报告参数不符、宣称的质保期限与售后政策冲突。这类问题如果被消费者投诉“货不对版”平台介入会判定商家责任是我朋友日常最怕翻车的部分。第三类是SKU配置类共7个问题。包括条码格式错误、同规格命名不统一、库存为负数、活动价高于日常价。这类问题属于操作层面的低级错误纯粹是人工录入时注意力不集中造成的规则引擎最适合兜底。第四类是图文一致性类共3个问题。包括主图显示木质桌面但标题写铝合金、图片颜色与SKU名“曜石黑”有显著差异、图片包含多件套但详情页描述是单件。这类问题平台机制会重点抽查一旦命中会判定“描述不符”对转化率和店铺分都有影响。第五类是售后政策一致性类共3个问题。主要集中详情页承诺的退换货条件和售后政策的条款冲突以及“一年质保”与“三年质保”表述不统一。这张分类表其实就是一个业务优化优先级的地图。error级别的账号风险先改warning级别的优化项逐步调info级别的建议按运营节奏安排。一个好的体检工具不是给你一堆问题让你头痛而是给你一张按风险排序的整改清单。8. 常见问题与排查技巧实录8.1 模型输出JSON解析失败这是最频繁出现的问题。我用Qwen3.8-Max时response_format指定了json_object之后绝大多数情况下输出都是标准JSON但仍然偶发解析异常尤其在文本量很大、上下文很长的时候。排查思路是三步第一步把原始返回内容打印出来看是纯JSON还是混了Markdown代码块标记。如果被代码块标记包着需要先剥离json和再解析。第二步用json.loads解析如果报错定位到具体异常位置很多时候是某个字符串里带了未转义的双引号。第三步如果重试3次仍然失败不要执着标记为“异常待人工处理”让程序继续跑。体检工具的价值在于覆盖率个别样本异常不值得拖垮整个流程。8.2 大模型漏检了已知问题有一次测试标题里明显有违禁词“最便宜”但大模型报告里没提。查下来原因是我把标题放进了文本语料但同一次请求里资料文本过长模型在处理到最后几个检查项时出现了注意力退化简单漏掉了。这个问题的解决思路不是提高模型能力而是做任务拆分。把一份完整的资料拆成多个子任务比如“标题检查”单独一次请求“详情页与资质比对”单独一次请求“SKU检查”再一次请求。每个子任务的上下文短、聚焦度高模型的漏检率显著下降。代价是API调用次数增加了但效果更稳。8.3 图片识别结果不准确商品图里产品很小、背景很杂的时候模型可能把背景里的元素当主体。我第一次测试时主图是户外场景图桌子在远景前景有个水杯模型居然报告“主体为水杯”这显然是误判。解决方法是做图片预处理。上传前先做一次中心裁剪同时用图像显著性检测算法把主体区域裁出来只把主体区域的图片传给模型能大幅减少背景干扰。或者更简单粗暴让运营提交白底产品图作为体检的主要输入。白底图没有背景干扰模型识别主体几乎不会出错。8.4 体检速度的优化一次完整体检要调多少请求如果拆了子任务可能3到6次请求。假设每次带图调用需要5到10秒总耗时在30秒左右。体感上就是“点一下等半分钟”。对内部工具来说这个速度可以接受。但如果想让很多运营同时用就得上异步任务队列。我目前的做法是简单的FastAPI接口加后台任务前端提交资料后轮询任务状态跑完再拉取报告。不要尝试同步等待同一个API key并发过大会触发限流。8.5 体检报告的闭环迭代体检报告不是终点。我建议每次人工修正完问题后把“问题描述最终整改方案”作为一个新样本记录下来积累到一定量后微调或用于few-shot示例。这样做的好处是下一次体检时模型在提示词里能看到历史整改案例判断风格会和业务实际更为贴合。我目前积累了一批历史案例后把最常见的10个案例直接放到提示词的示例区效果立竿见影——模型对同类问题的建议措辞变得更加业务化不再说空话。9. 这套工具后续可以怎么扩展这个项目做到现在已经能稳定输出“6份资料1张商品图”的体检报告。但距离我理想中的“商品资料包AI审核中台”还差几步。第一步是增加更多资料类型。目前只做了固定的61格式实际上商品资料还可能包含视频、用户手册、报关单、授权书等。如果要做通用版本需要把资料类型抽象成模板每种类型配置独立的解析器和检查规则。第二步是把规则管理从代码里挪出来。现在新增一个规则要改代码业务人员没办法自助配置。后续我可以做一个简单的规则配置界面让运营自己定义“价格上限”“违禁词清单”“必填字段”保存后工具自动按最新配置跑体检。这样工具才能真正脱离开发者的手变成业务能自主使用的系统。第三步是让体检结果对接工作流。现在报告是一份Markdown后续可以和协作平台对接发现问题自动创建整改任务指派给对应负责人并跟踪整改进度。体检就从一个“检测工具”变成“整改闭环系统”。如果你也想搭一个类似的体检工具我的建议是先别急着上大而全的功能把你业务里最常检查的10条规则写清楚先把一个品类的体检跑通再逐步扩品类、扩资料类型。这个项目真正难的地方其实不在代码而在于你怎么把业务检查经验翻译成机器可执行的规则和提示词。把这个翻译做好工具的价值就出来了。