用Qwen3.8-Max搭建电商商品资料体检助手，一次检出27个问题

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读sheet，Word要用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: true

4.2 文档解析执行示例

解析Excel的代码不复杂，但要注意读所有sheet：

import pandas as pd def parse_excel(file_path): sheets = pd.read_excel(file_path, sheet_name=None) parsed = [] for sheet_name, df in sheets.items(): # 空sheet跳过 if df.empty: continue markdown_table = df.to_markdown(index=False) parsed.append(f"### Sheet: {sheet_name}\n{markdown_table}") return "\n\n".join(parsed)

这里有个细节：sheet_name=None会让pandas返回一个dict，key是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"--- 第{i+1}页 ---\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_ok=True) 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, images

4.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": f"SKU {row.get('SKU编码')} 条码 {barcode} 格式非法，应为13位数字", "source": f"04_SKU明细表.xlsx 第{idx+2}行" })

这里有一个心得：规则引擎检查结果里一定要带source字段，精确到文件甚至是行号。因为后面汇总报告时，按source分组就能快速帮用户定位“问题出在哪份文件哪一行”，这是体检工具好不好用的关键。

4.4 大模型语义检查的提示词设计

提示词设计是整个工具效果的关键。这部分我调整了好几版，最终沉淀了一个比较稳定的模板。

我给Qwen3.8-Max的角色定义是“电商商品资料审核专家兼资深运营”，然后给它三个层次的指示：

第一层是任务背景说明。告诉它你现在拿到的是某个商品的6份资料和1张商品图，你的任务是根据给定的体检清单逐项检查，输出JSON格式的问题列表。

第二层是体检清单定义。我会在提示词里明确列出需要检查的语义项，比如：

• 标题中的关键词是否覆盖了核心卖点、品类词和场景词。
• 详情页文案中的参数数据和资质报告中的检测数据是否一致。
• SKU表里同款不同规格的命名是否统一规范。
• 商品图的颜色、外观、主体是否与标题和SKU描述一致。
• 售后政策里的质保条款和详情页承诺是否冲突。

第三层是输出格式约束。我用JSON Schema来约束输出，告诉它必须返回一个issues数组，数组里每个对象包含check_item、level（error/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( model="qwen3.8-max", messages=[ { "role": "user", "content": [ {"type": "text", "text": prompt_text}, {"type": "image_url", "image_url": {"url": f"data:image/png;base64,{image_base64}"}} ] } ], temperature=0.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个问题：

我当时数完这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。注意，temperature=0并不保证每次输出完全一致，但能显著降低随机性。

重试机制是必须的。大模型偶尔会输出残缺的JSON，比如少了一个大括号、字符串没闭合。我写了一个简单的解析重试函数：先用json.loads解析，失败了就重新请求一次，最多重试3次。三次还失败就标记为“待人工复核”，拉进一个异常队列。

6.3 凭证引用的重要性

体检报告里“evidence”字段非常重要，它是问题能否被信任的基石。如果模型报告“详情页和检测报告的数值不一致”，但没给出原文片段，业务同事根本不知道要改哪里，也不确定是不是AI误判。

我在提示词里强制要求：每条issue必须包含evidence，evidence要引用原文中具体的那句话或那个数字。比如“详情页写‘抗菌率99.9%’（出自02_详情页文案.md第3段），检测报告写‘抗菌率99.2%’（出自03_资质检测报告.pdf第2页）”。这样写出来的报告，业务同事几乎不需要再花时间去核实，直接就能按建议去改。

6.4 一些常规文档不会写的坑

踩过的坑里比较典型的有三个：

第一个是Excel里的合并单元格。pandas读取Excel时，合并单元格只在左上角位置有值，其他位置是NaN。比如某一列的SKU名称合并了多行，读出来是“黑色”和NaN交替，直接把NaN传给模型，模型就会困惑。解决办法是在读取后做一次向前填充（ffill），把合并单元格的值填到所有相关行。

第二个是PDF里的页眉页脚干扰。用pdfplumber提取PDF时，页码、公司名称这些页眉页脚会混入正文文本。如果检测报告里每一页都带着日期和页码，大模型可能把页码当作某个参数。我的做法是做一步文本清洗，去掉常见的页眉页脚模式，同时如果整段文本全是数字且长度很短，就跳过不纳入上下文。

第三个是图片方向问题。商品图有时候是竖构图，有时候是横构图，模型都能识别，但你传给它的图片如果分辨率过大，比如几MB甚至十几MB，API调用会变慢甚至超时。我在上传前用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审核中台”还差几步。

第一步是增加更多资料类型。目前只做了固定的6+1格式，实际上商品资料还可能包含视频、用户手册、报关单、授权书等。如果要做通用版本，需要把资料类型抽象成模板，每种类型配置独立的解析器和检查规则。

第二步是把规则管理从代码里挪出来。现在新增一个规则要改代码，业务人员没办法自助配置。后续我可以做一个简单的规则配置界面，让运营自己定义“价格上限”“违禁词清单”“必填字段”，保存后工具自动按最新配置跑体检。这样工具才能真正脱离开发者的手，变成业务能自主使用的系统。

第三步是让体检结果对接工作流。现在报告是一份Markdown，后续可以和协作平台对接，发现问题自动创建整改任务，指派给对应负责人，并跟踪整改进度。体检就从一个“检测工具”变成“整改闭环系统”。

如果你也想搭一个类似的体检工具，我的建议是：先别急着上大而全的功能，把你业务里最常检查的10条规则写清楚，先把一个品类的体检跑通，再逐步扩品类、扩资料类型。这个项目真正难的地方其实不在代码，而在于你怎么把业务检查经验翻译成机器可执行的规则和提示词。把这个翻译做好，工具的价值就出来了。