做电商的同学应该都有过这种经历一个商品要上架运营、设计、产品、客服各自写一版资料标题一份、卖点一份、规格一份、说明书一份等到汇总到手里时6份文档互相打架——标题写“5000mAh”参数表写“4500mAh”详情页还印着“240g 轻巧便携”结果主图里产品明明看起来厚实得很。以前这种问题全靠人肉校对费时间不说漏掉一个参数矛盾轻则被平台下架重则被用户退货投诉。我最近用 Qwen3.8-Max 搭了一个电商商品资料包体检助手把 6 份资料和 1 张商品图丢进去一次就查出了 27 个问题。这份工作以前我大概要对着表格核一整天现在从投喂资料到拿到排查报告十分钟以内就能跑完。这篇文章就把这套东西的完整思路、规则设计、提示词写法、踩坑经历全部分享出来。如果你也在做电商运营、商品上架、内容合规或者产品资料管理可以直接照着我这套逻辑搭一份自己的体检助手不用懂太多代码会调用 API、会写提示词就行。1. 思路拆解为什么商品资料需要“体检”而不是“校对”先说我为什么要做这个事。我之前在一个电商团队负责商品资料管理每天经手的商品资料包大概分六类商品标题和卖点文档、详情页文案、规格参数表、质检与认证文件、使用说明书和 FAQ、售后物流政策。一开始我用人肉对照审核后来资料量越来越大发现问题根本不只在“错别字”这个层面。1.1 电商资料的真实痛点不一致才是最大成本大部分商品资料的问题可以归成四类完整性缺失该有的资料没放进来比如没有质检报告、没有规格书、FAQ 里没写充电时长。参数不一致同一商品在不同文档里的核心参数对不上这是最频繁也最致命的问题。合规风险文案里出现极限词“最好”“100%”、缺少必要的认证信息、材质宣称没有依据。图文不匹配商品图和文字描述不符比如图里是黑色款详情页参数却写了“白色”。这些问题长期以来靠人工检查效率极低。一个熟练的运营核对 6 份资料和几张商品图少说也要两个小时而且容易漏。人眼更擅长“发现明显错误”但不擅长“跨文档比对一致性”因为注意力会被大量文本淹没。1.2 为什么用 Qwen3.8-Max 来做而不是传统脚本或 OCR我一开始想过用正则表达式加规则引擎去查参数矛盾比如提取所有“mAh”附近的数字做比对但试了一圈就放弃了。这种方式的死穴在于不同文档对同一参数的表达方式完全不同——有的写“电池容量 5000mAh”有的写“电池锂离子 5Ah”还有的用表格形态。格式不统一规则就写不完整光“单位换算”一条就能把脚本写到崩溃。后来换成大模型之后问题简单了很多。Qwen3.8-Max 这类模型的长上下文能力可以在一次会话里同时接收多份文本并且能自动识别语义层面的对应关系。比如它能判断出“5000mAh”和“5Ah”其实是同一个参数也能看出详情页承诺“一年质保”和售后政策里写的“只换不修限 15 天”之间存在矛盾这种能力是传统脚本不具备的。最终我确定的定位是大模型做理解与判断规则库做框架约束输出格式化报告。这相当于请了一个读过所有资料的品控专员它的工作不是替你决定而是把所有可疑点按风险等级列出来再由人来确认和修复。1.3 体检助手的整体架构整套系统我分了三层解析层把 PDF、Word、Excel、图片等格式统一变成文本供模型读取。图片则单独走视觉理解提炼成“图片描述文本”。分析层由 Qwen3.8-Max 接收全部文本材料按照预设的检查规则逐项体检输出结构化 JSON 格式的问题列表。报告层把 JSON 转成可视化报告按严重程度排序附上原文引用和修复建议。这个架构的好处是每一层都能独立替换。解析层换了文件格式不用改模型分析层换了模型不用动解析逻辑报告层想接入企业微信、表格或者钉钉都很方便。不用关心底层推理细节只需要把接口串联好整个项目两三天就能跑通。2. 规则库设计27 类问题是怎么归纳出来的很多人以为这类助手的关键是“模型”但我做了几轮之后发现真正的核心是“检查规则”。模型再强如果规则没有定义清楚它就只能泛泛地总结“资料存在不一致”而给不出具体、可复现的问题点。所以我把大量精力花在了把人工审核经验转成规则表上。2.1 六类资料的规范化字段在做检查之前我先把一份商品资料包应该包含的要素拆成了标准化字段。以我测试用的“智能温控杯”为例六份资料对应的规范字段大概是这样的商品标题与卖点文档商品名、核心卖点、适用场景、目标人群。详情页文案功能描述、材质介绍、使用方式、场景图文字。规格参数表容量、尺寸、重量、材质、电池/续航、充电方式、接口类型、防水等级、温控范围。质检与认证文件检测标准、认证编号、检测结论、生产日期、有效期。说明书与 FAQ操作步骤、维护方法、故障排查、常见问答。售后与物流政策质保时长、退换货条件、维修政策、发货时效。只要这些字段存在就可以针对性地做交叉检查。比如规格参数表里的“容量”要和标题、详情页里出现的容量数量级一致质检报告里的“材质”要和说明书里的清洁方式兼容。2.2 从“人工审核经验”到“27 项检查细则”我根据过往审核记录把人工最常标记的问题整理成了 27 个检查项分成六类完整性类5 项缺质检报告、缺规格表、缺使用说明、缺售后政策、缺 FAQ。一致性类7 项标题与规格参数冲突、卖点与详情页冲突、详情页与规格表冲突、说明书与规格表冲突、售后政策与详情页承诺冲突、认证文件与商品信息不匹配、FAQ 与说明书步骤矛盾。合规类5 项极限词、虚假宣称、缺少必要认证标识、材质表述无依据、售后承诺超出法律基础。逻辑类4 项功能描述前后矛盾、参数单位书写不统一、适用场景与产品定位偏航、缺失参数导致用户无法直接下单。图文匹配类3 项图片中外观颜色与文字描述不符、图片显示配件数量与清单不符、图片标注信息与参数不符。规范类3 项标题超长关键词堆砌、专有名词拼写不统一、中英文品牌名混用。这里有个经验检查项不是越多越好。我一开始想做到 50 项结果模型输出变得很不稳定经常自己发明新的检查项或者强行套用不适用的规则。后来压到 27 项每一项都有明确的规则说明和判断标准模型的执行稳定度明显提升。2.3 如何通过提示词把 27 项规则“编码”进模型给大模型定规则时最忌讳只给一个清单让它自己发挥。我把每项规则都写成了“规则描述 判断标准 输出示例”的格式。举两个例子。比如“标题与规格参数冲突”这条规则我写的描述是提取标题和卖点中出现的关键规格词容量、尺寸、材质、功率等。与规格参数表的对应字段做比对。同一参数出现数字不同的情况即为问题输出时给出两个来源的原文引用。再比如“图片与详情页不匹配”这条规则我要求模型先分别描述图片内容与详情页文字内容。再找出图中可见元素颜色、配件、接口等与文字信息的差异。无法确认的项目不做判断避免无依据猜测。这样处理后模型知道自己该怎么做而不是凭空“分析”。输出格式我也固定成 JSON每条问题包含“问题编号”“风险等级”“涉及文件”“原文引用”“问题说明”“建议修复方式”六个字段方便后续直接建工单。3. 实操过程从投喂资料到输出体检报告下面进入正题把我完整跑通的一套流程写下来。我这里用 Python 调用接口做串联所有代码片段都可以直接复制修改。3.1 工具选型与运行环境准备我本机环境的配置如下Python 3.10Qwen3.8-Max 的 API 接口通过兼容 HTTP 接口调用PDF/Word/Excel 解析库pdfplumber、python-docx、openpyxl图片理解走 Qwen3.8-Max 的多模态能力直接把图片上传识别报告展示先输出 JSON再用 pandas 转换成 Excel 表格测试时我把 6 份资料放在sample_pkg文件夹内商品图为product_main.png。资料长短不一最短的售后政策只有两页最长的说明书接近二十页全部转成文本后大概 3.2 万字符这个长度在 Qwen3.8-Max 的上下文范围之内能够一次全部读取。3.2 资料解析与预处理解析部分我写了几个小函数把不同类型的资料统一转成文本。这里做两个处理所有文档提取后加上文件名标记避免模型混淆来源图片则单独提取描述。import pdfplumber import docx import openpyxl def extract_pdf_text(file_path): text with pdfplumber.open(file_path) as pdf: for page in pdf.pages: page_text page.extract_text() if page_text: text page_text \n return text def extract_docx_text(file_path): doc docx.Document(file_path) return \n.join([p.text for p in doc.paragraphs]) def extract_xlsx_text(file_path): wb openpyxl.load_workbook(file_path, data_onlyTrue) lines [] for sheet in wb.sheetnames: ws wb[sheet] for row in ws.iter_rows(values_onlyTrue): values [str(c) for c in row if c is not None] if values: lines.append( | .join(values)) return \n.join(lines)这三个函数分别处理 PDF、Word 和 Excel。实际操作中很多规格参数表是 PDF 导出的表格pdfplumber 对这类文件的支持还不错但偶尔会出现表格单元格错位。遇到这种情况我会把 PDF 另存为 Excel 再解析虽然多一步但能显著降低后续模型误判的概率。图片的处理要单独说。Qwen3.8-Max 的多模态接口可以直接接收图片我让它“描述图片中的商品、颜色、配件、标签和可见文字”输出一段结构化的文字描述再把这段描述作为一个独立文本块参与后面的体检。def extract_image_description(image_path): # 以二进制形式读取图片走视觉理解接口 with open(image_path, rb) as f: image_data f.read() # 具体调用方式视 SDK 而定返回图片的文字描述 return call_vision_api(image_data)3.3 组装“体检输入包”把解析后的文本按照固定模板拼接起来。我给每一份资料都加了明确的分隔线并给出一份“文件清单”让模型知道自己拿到了哪些材料。本次商品体检的资料包包括以下文件 1. 商品标题与卖点文档[标题卖点.txt 内容] 2. 详情页文案[详情页.txt 内容] 3. 规格参数表[规格参数.txt 内容] 4. 质检与认证文件[质检报告.pdf 提取内容] 5. 说明书与FAQ[说明书.txt 内容] 6. 售后物流政策[售后政策.txt 内容] 7. 商品图片描述[商品图描述.txt 内容] 请严格按照27项检查规则进行比对输出JSON格式结果。这里要注意一个细节资料解析后的原文会很长如果全部塞进提示词模型虽然能处理但“注意力”会被无关信息稀释。我在第一阶段只做“全量阅读”让模型生成一个初步检查结果第二阶段再针对可疑项定向把相关文件片段发过去确认。两轮结构比一轮直接给结论要稳定得多。3.4 执行体检并输出结构化结果核心调用逻辑是这样的import json def run_check(all_materials_text, rules_text): prompt f 你是一个电商商品资料审核员请根据以下规则进行体检。 规则如下 {rules_text} 资料如下 {all_materials_text} 请输出JSON格式结果格式为 [ {{problem_code: R-01, risk_level: high, involved_files: [...], original_text: ..., issue: ..., suggestion: ...}} ] response call_qwen_max(prompt) return json.loads(response)我返回来的结果会用 pandas 转成表格按风险等级排序风险等级问题数说明高风险6直接影响上架或用户决策中等风险13影响体验或可能引起投诉低风险8规范性问题建议优化27 个问题并不是平均分布的。实测下来高风险项集中在参数不一致和合规风险这两类低风险项则集中在标题堆砌、专有名词不统一等规范类问题上。这也符合人工审核的经验——最影响转化的往往不是文字是否精美而是参数之间互相“打架”。4. 一次真实体检智能温控杯的 27 个问题拆解拿我手头实际测试过的“智能温控杯”案例来完整展示一次体检结果。这个商品资料包来自我模拟的团队协作产物包含 6 份资料和 1 张泳池蓝配色的主图。体检助手跑完后输出的 27 个问题中有几个特别典型挑出来详细展开。4.1 高风险问题示例第一个典型问题是“容量参数三处不一致”。商品标题里写的是“420ml 大容量”规格参数表写的是“450ml±5%”详情页文案又写成“500ml 刚刚好”。模型在检查一致性类时直接标注了三个文件互相矛盾并且引用原文给出了对比。这一类问题如果放过去用户的预期会被严重误导退货率大概率会上升。第二个典型问题是“材质宣称缺少认证支撑”。质检报告里明确指出杯身材质是“304 不锈钢”但详情页和卖点文案写的是“食品级 316L 不锈钢”。模型结合质检文件、说明书和详情页三方信息判定该宣称在现有资料中找不到依据属于高风险合规问题。这个判断听起来简单但传统脚本很难做到因为“304”和“316L”在文档中相隔数万字且表述完全不同必须依赖语义理解才能关联起来。第三个典型问题是“保温时长标注互相矛盾”。说明书里写“6 小时保温”详情页 FAQ 里写“12 小时长效保温”而售后政策中关于“保温性能争议”的描述完全没提这个参数。模型给出的建议是统一所有资料中的保温时长数据并且在 FAQ 中补充测试条件说明比如“室温 25℃ 环境下实测”。这种细节人工校对很容易漏掉因为两份资料可能分别由技术和运营撰写。4.2 中低风险问题示例中风险问题中比较有意思的是“充电接口描述不一致”规格参数表写 Type-C 接口详情页一张图写了“USB 充电”模型判定为术语不统一建议全链路统一为“Type-C 充电口”。低风险问题包括标题中“智能”“恒温”“便携”三个词重复出现三遍关键词堆砌明显品牌名在六份材料里分别写成“WarmGo”“warmgo”和“暖行杯”中英文混用不统一FAQ 里的“怎么清洗”和说明书里的“清洁维护”描述的操作顺序存在细微差异模型标注为“逻辑性建议”。这类低风险问题虽然不影响上架但对内容质量和品牌一致性有影响。电商平台对于标题规范、材质表述的要求越来越严格早一点修掉后期被平台抽查时就能少很多麻烦。4.3 从人工核对到智能体检到底省了什么如果是人工核对这些资料我做过一个对比测试。同样一份材料包一位有三年经验的运营同事进行逐项核对总耗时约 1 小时 50 分钟共发现 16 个问题漏掉 11 个尤其是那些涉及跨文件语义比对的问题比如材质宣称与质检报告冲突人工很难在短时间内定位。用体检助手跑一遍耗时约 8 分钟能够稳定输出 27 个问题。后续人工只需要针对“高置信度”的问题进行确认而不是逐行比对全文。模型能保证“不会漏”但无法保证“不会错”所以我的定位是把它当筛子把所有可疑点筛出来再由人做最终决策。5. 使用 Qwen3.8-Max 时遇到的坑与排查技巧任何模型在实际使用中都会有一些奇奇怪怪的表现Qwen3.8-Max 也不例外。我在搭建过程中踩过不少坑这里梳理一下最常见的问题和我的解决办法。5.1 长上下文截断问题最初我把 6 份资料依次接入上下文没有做任何精简第一次就跑出了乱码式的输出。排查后发现问题出在 PDF 解析时某些页包含了大段图片型内容提取出的文本里夹杂了很多空行和零星字符。方法一改进解析后先做清洗去掉空行、无效字符方法二改进把过长的说明书按章节切成片段先分块预检再汇总结果而不是一次性硬塞给模型。一个可以长期使用的经验是不要直接用解析原始文本做全量输入先做“摘要压缩”。对说明书、详情页这类长文档让模型先提取出“参数、承诺、操作步骤”三要素再把压缩后的结果合并进体检提示词。这样信息密度更高模型给的判断也更集中。5.2 模型幻觉导致误报有一次模型报告里出现了详实但虚构的“检测标准编号”说质检报告里包含 GB 4806.9-2016 标准可我翻遍原 PDF 也没找到这一条。这是大模型比较典型的“补充性幻觉”它知道这类文件通常会有标准编号于是自作主张地补上了。解决办法是在提示词里加了强制约束“所有引用必须来自资料原文若原文中不存在对应信息输出 not_found不得自行补充。输出 JSON 若包含原文引用则引用必须逐字摘录。”这一条约束立竿见影后续输出的幻觉比例明显下降。5.3 输出格式不稳定大模型输出 JSON 时偶尔会在前后加多余说明文字或者使用 Markdown 代码块包裹直接 json.loads 就会报错。我的解法是加一个后处理函数import re def parse_model_json(text): # 去掉可能存在的代码块围栏 text re.sub(rjson|, , text).strip() start text.find([) end text.rfind(]) if start -1 or end -1: raise ValueError(No JSON array found) return json.loads(text[start:end 1])这个函数先把代码块围栏去掉再截取第一个[到最后一个]之间的内容。虽然有点粗暴但实测能兼容大部分模型输出格式。5.4 检查规则与模型的配合别让它做判断题还有一个整体性的经验不要让模型做“是否有问题”的判断而是让模型做“依据规则查找并标注”的执行。同样是查“极限词”如果提示词写“请检查是否有违规极限词”模型会泛泛地输出“建议删除夸张词汇”但如果提示词写“请逐一检查以下 50 个禁用词是否出现在材料中若出现则输出原句和位置”模型就能给出精确的命中列表。工具类项目里给出明确封闭的检查范围远比要求模型总结归纳要准确得多。5.5 成本控制与批量使用建议完整跑一次体检的 Token 消耗大致在 4 万到 6 万之间。如果只做单次体验成本无所谓但如果在团队里批量跑建议做以下几点第一文件级缓存同一份资料解析结果在一天内不重复调用第二分片检查长文档不要反复整体投喂第三拆分高频检查和低频检查规范类问题用正则规则做初步筛大模型只处理一致性、合规性等需要语义理解的部分。我做了一个简单统计用“先规则后模型”的两段式方案后每次体检的 API 调用成本降低了将近 40%同时误报率没有明显上升。最后的实操心得整套项目从想法到稳定跑通我大概花了一周时间其中一半时间花在规则库的调优上。Qwen3.8-Max 的语义理解能力确实够用但真正让检查结果可靠的不是模型本身而是你愿意花多少心思去定义“什么算一个问题”。规则写得越具体模型执行得就越像老员工。最后再分享一个我自认为非常实用的小技巧不要只输出问题清单而是把“原文引用”和“两条原文之间的映射关系”一起给出来。比如“标题写 420ml规格表写 450ml±5%”直接列两条原文引用。这样人工复核时不到 5 分钟就能判断模型结论是否正确而不是重新翻几份资料去验证。体检助手的价值不在于替你做最终决定而是把“核对全文”这个体力活变成“确认问题点”这个脑力活。对每天要处理大量商品资料的团队来说这一层省下来的时间相当可观。