做电商运营或者自己开过店的人都知道商品上架前最烦的不是拍照、不是定价格而是把一堆资料包凑齐之后你根本不知道里面到底藏了多少坑。标题写了“3年质保”详情页变成“5年质保”规格参数表里明明标了“USB-C接口”主图却画了个老式Micro口运费模板写着“新疆西藏不包邮”售后说明里又变成了“全国包邮”。这类问题靠人眼一份一份地看真的会看到怀疑人生。所以我用 Qwen3.8-Max 搭了一个专门做“商品资料包体检”的小助手输入 6 份文档加 1 张商品主图它能自动完成字段抽取、一致性比对、图像文字识别和语义判断最后一次性输出一份带证据引用的问题清单。我拿手头一个真实商品资料包试跑了一遍一共查出 27 个问题其中有 3 个属于“必改项”如果不改直接上架大概率会被平台抽检处罚。这篇就把完整思路、实现细节、问题清单和踩过的坑都写出来。1. 为什么商品资料包必须“体检”一份资料包里的真实混乱1.1 电商上架资料的典型构成从来不止“一张图一个标题”先还原一下我处理的这个资料包里到底有什么。市面上大部分电商商品资料包无论你是做天猫、京东、拼多多还是跨境出海核心构成基本一致商品标题一般是运营单独给的一个 txt 或表格字段商品卖点文案5到8个卖点通常躺在Word文档里详情页长图文案一到两个长文档里面是分模块的图文说明规格参数表Excel 或 CSV包含材质、尺寸、接口、功率、保修期等运费说明通常是一段说明文字偶尔是一张运费模板截图售后/退换货政策一个独立的文档或网页导出的文本商品主图一张或多张图上可能叠有促销文案、卖点标签、规格标注我这次用的资料包一共就是 6 份文本或表格类资料加 1 张主图这已经是比较克制的配置了。很多成熟店铺一个商品动辄十几份资料情况只会更复杂。这些资料的产出路径也决定了它们天然容易互相打架标题是运营早上写的卖点是设计下午补充的规格表由产品经理从工厂规格书里复制出来售后文案则是客服主管从别的商品直接复制改的。每个人都在自己的局部信息源里工作没有人有精力把六份文档从头到尾交叉核对一遍。1.2 人工检查的致命盲区不是不仔细是注意力带宽不够我用最笨的办法人工核过同类资料包深刻体会到一个现实人眼检查的准确率会随文档数量和字段数量呈指数级下降。一份资料包里的信息量其实非常大。以我这次这套为例6 份资料里大约有 70 多个关键字段交叉比对的可能组合轻松超过 200 对。人工核对会面临三个具体问题字段分散在不同格式的文件里需要一个一个打开、搜索、跳转非常消耗耐心很多字段表面上是同一件事但表述方式不同比如“质保”和“保修”、“30天退货”和“一个月内可退”靠肉眼很难一一对应注意力在 20 到 30 分钟后就会明显滑坡而一份资料包恰恰需要 40 分钟以上的连续核对我这次查出 27 个问题其中至少有 10 个问题我在第一遍手工检查时完全没发现直到用体检助手跑了一遍才注意到。不是我不认真而是那些问题藏在跨文档的语义不一致里已经超出了人工核查的舒适区。1.3 为什么选择 Qwen3.8-Max 而不是纯规则脚本可能有人会问这种资料比对用 Python 写一堆字符串匹配和正则表达式不也差不多吗为什么非要上一个 LLM核心原因在于真实资料包里的不一致绝大部分不是“字符串不同”这种机械问题而是“语义层级”的不一致。举个例子规格参数表写“输入电压220V 50Hz”详情页写“电压 220V-240V频率 50/60Hz”标题写“全球通用电压”这三条信息在字符层面没有任何一个文本片段是相等的但它们描述的是同一个物理属性。纯规则脚本要在这种情况下判断“是否冲突”就必须先写一大堆电压、频率、瓦数的单位解析和数值范围逻辑而且每换一个商品类目就要重写一轮。LLM 的优势在于它天然理解“220V 50Hz”和“220V-240V 50/60Hz”之间的关系只需要给它明确的比对指令和上下文它就能直接给出“存在范围不一致”的结论。选择 Qwen3.8-Max 的具体原因有三个长上下文能力突出6 份文档全量塞进去也不需要人工截断摘要信息损耗最低中英文混杂内容理解稳定电商资料里大量的参数术语、营销话术、中英混排都能正确解析JSON 结构化输出稳定方便直接把体检结果解析成问题单而不是靠人读一大段散文2. 体检助手整体架构三层分离一次遍历2.1 三层架构设计思路整个体检助手我设计成三个独立层次每层只做一件事层与层之间用标准 JSON 传递数据。这样做的原因是电商资料包的格式变化非常快如果不分层一旦某个文档格式变了整个脚本就得跟着重构。第一层资料解析层。负责把 6 份文档和 1 张图片统一转换成纯文本或 Markdown 结构。输出是“字段名 字段值 来源文件”的结构化数据第二层规则检测层。包含硬规则检测和一致性检测。硬规则负责必填项、格式、长度等确定性校验一致性检测负责同一属性在不同文档中的数值、描述、口径是否冲突第三层LLM 语义裁决层。把第二层无法判定的争议项、以及跨文档语义冲突交给 Qwen3.8-Max 做深度比对。最终生成一份带严重级别、问题描述、证据片段的问题清单这个架构的核心收益是如果某天换了模型只改第三层如果新增了文档类型只改第一层如果想加规则只改第二层。每个层次都能独立测试。2.2 项目和目录结构设计实际工程的目录结构我这样安排product_doctor/ ├── main.py # 检测入口负责串起三个层次 ├── parsers/ │ ├── pdf_parser.py # PDF 文本抽取 │ ├── word_parser.py # Word 文档解析 │ ├── excel_parser.py # Excel/CSV 参数表解析 │ └── image_parser.py # 商品图视觉信息提取 ├── rules/ │ ├── hard_rules.py # 必填、格式、字符规范等硬规则 │ └── consistency_rules.py# 跨文档一致性规则 ├── llm/ │ ├── client.py # Qwen3.8-Max 调用封装 │ └── prompts.py # 体检提示词模板 ├── report/ │ └── generator.py # 生成 Markdown 检测报告 └── data/ ├── product_pack/ # 输入的 6 份文档 1 张图 └── output/ # 检测结果输出main.py 里只做编排工作真正的业务逻辑都被拆分到对应模块中。3. 核心代码拆解从文件解析到 LLM 裁决一步步说清3.1 资料统一解析让六种格式变成同一种语言所有资料进到系统里之后要做的第一件事就是统一格式。我不能让后面的检测逻辑一会儿处理 PDF、一会儿处理 Excel、再来一段 Word 里的表格。所以我在解析层做了一个关键的“标准化输出”不管来源文件是什么格式最终都输出成一个包含若干字段对象的 JSON。每个字段对象的格式如下{ field_id: title_001, field_name: 商品标题, field_value: XX智能蓝牙耳机 主动降噪 30小时续航, source_file: 01_商品标题.txt, field_type: text }针对 6 份文档解析层的处理策略分别是商品标题 txt直接读取纯文本按 UTF-8 编码解码卖点文案 Word用 python-docx 遍历段落和表格把非空段落全部抽取详情页长文 PDF如果 PDF 本身就是文字版用 pdfplumber 抽取如果是扫描图需要走 OCR但这次资料包是文字版所以没有启用 OCR规格参数 Excel用 pandas 读取每一行把“参数名 - 参数值”成对提取运费说明 pdf同样用 pdfplumber 抽取售后政策 docx用 python-docx 抽取并手动识别其中的条款列表这一层最关键的细节是“来源文件”必须被保留下来。因为后面对问题定级时证据要精确到“哪个文件、哪一段、哪一行”而不是模糊地说一句“某处写着什么”。我在每个字段对象里都记了 source_file凝胶剂后面所有检测结果都能回溯到原始位置。3.2 商品视觉信息提取主图不是起点是最大的变量商品主图的处理比文本要复杂。图片里的文字信息很容易被骗但图片里的“实物属性”文字往往比规格表更接近消费者视角。我这次的主图里有三个信息需要提取图片上叠加的促销文案标签产品本身的实物渲染图比如接口、按键、指示灯图片角落的规格标注比如“50dB 降噪”“40h 续航”“蓝牙5.4”实现上我用了两步方案。第一步用 OCR 模块把图片上的文字全部抽出来并记录每个文字块在图片中的坐标位置第二步把这些文字块连同整张图片交给 Qwen3.8-Max 多模态接口让它判断“图片上显著标注的产品属性有哪些”。这里的难点是纯 OCR 只能识别文字无法理解“这颗文字标注在耳机上到底指什么”。例如图片角落写着“40H”没有经验的人会当成串码但实际上它指的是 40 小时续航。所以我让 LLM 同时看图 看 OCR 文字块由它把图像中的视觉信息翻译成语义化字段。处理完以后图片层输出的也是同一套字段对象格式只是 source_file 填的是图片文件路径。3.3 硬规则检测这些错误不需要 AI但必须交给 AI 一提醒硬规则检测是第二层的第一步负责处理“确定性错误”。这类错误不涉及语义只要条件不满足就是有问题。我定义了 6 组硬规则必填项缺失标题、卖点、规格表中的关键参数材质、尺寸、保修期、接口是否都有值字符异常是否存在乱码、全角半角混用、多余空格、异常换行黑名单词是否出现“最”“第一”“绝对”等广告法禁用词数值格式规格表中的数值是否带单位、是否使用约定格式例如电压写成 220v 而不是 220V编码异常抽出来的文本是否存在“锟斤拷”“”等乱码字符缺失图片信息主图是否没有叠加强化卖点文字、是否没有展示关键规格其中黑名单词检测是最有价值的。广告法违禁词这一项在 27 个问题里占了 4 个都是“最”字头词汇。这种词靠人工检查确实容易麻木但规则检测一秒钟就定位出来。硬规则的代码实现很简单以必填项检测为例REQUIRED_FIELDS [标题, 材质, 尺寸, 保修期, 接口, 电池容量] def check_required_fields(all_fields, required_listREQUIRED_FIELDS): problems [] field_names {f[field_name] for f in all_fields} all_text .join(f[field_value] for f in all_fields) for req in required_list: if req not in field_names and req not in all_text: problems.append({ level: critical, type: required_missing, description: f关键字段[{req}]在资料包中完全找不到, evidence: 全量资料中没有匹配字段名或内容 }) return problems这里有个很实际的细节不是每个产品都严格按照字段名“材质”来命名有的叫“壳体材质”有的叫“耳套材质”。所以在硬规则里做匹配时不能只查精确字段名还要在全文文本里做子串包含匹配。上面的代码就是这样处理的字段名匹配不到就到全文里去找有没有相关内容出现。3.4 一致性检测规则不硬写了交给字段对第二层的重头戏是一致性检测。我预先定义了若干“字段对”比如标题中的“续航” ↔ 规格表中的“续航时间” ↔ 主图中的“续航时长”标题中的“质保” ↔ 售后政策中的“保修期”规格表中的“重量” ↔ 卖点文案中的“轻盈机身”详情页中的“包装清单” ↔ 规格表中的“配件列表”主图中的接口标注 ↔ 详情页的接口参数对于每一组字段对我先用规则做一次“数值类”自动比对。比如规格表说“蓝牙版本 5.3”详情页说“蓝牙 V5.4”这种情况就能被数值规则直接抓出来。但更多时候字段对的值不是纯数值而是描述性文本。例如卖点文案说“轻至 198g”规格参数表说“净重200g”这两个值在字面上完全不同但人一眼就能看出两者可能指向同一个属性且存在 2g 的出入。这种就不能靠正则匹配了需要走到第三层 LLM 裁决。一致性检测模块的伪代码大致如下CONSISTENCY_PAIRS [ (商品标题, [续航, 质保, 重量, 蓝牙版本]), (规格参数表, [续航, 质保, 重量, 蓝牙版本, 接口, 防水等级]), (售后政策, [质保, 退换货, 保修期]), (卖点文案, [重量, 续航, 材质]), ] def run_consistency_checks(fields_by_file): pending_pairs [] for group_name, attribute_list in CONSISTENCY_PAIRS.items(): for attr in attribute_list: values extract_values_for_attribute(fields_by_file, group_name, attr) if len(values) 2: pending_pairs.append({attribute: attr, values: values}) return pending_pairs这一层不直接下结论而是把“可能存在冲突的字段对”收集起来交给下一层做语义裁决。这样既避免了把所有内容都丢给 LLM 带来的成本浪费也保证了规则引擎的快速响应。3.5 Qwen3.8-Max 语义裁决提示词和 JSON 输出的设计这是整套助手最核心的部分。第二层收集到的字段对连同原始文件里的上下文片段一起进入 Qwen3.8-Max 的提示词。提示词的设计我踩过不少坑最终稳定下来的核心模板包含几个固定区块你是一名资深电商运营合规审核专家。下面是一个商品资料包中同一属性在不同资料文件中的描述请判断这些描述是否互斥、部分重叠还是一致。 要求 1. 如果所有描述在语义上可以同时成立输出 consistent。 2. 如果存在数值范围不一致、参数口径冲突、保修期限矛盾等输出 inconsistent并说明冲突点。 3. 如果只是措辞详略不同但核心事实一致输出 partially_consistent。 4. 必须输出 JSON{attribute: 续航, status: inconsistent, conflict_summary: ..., evidence: [{file: ..., content: ...}]}模型调用层的封装如下from openai import OpenAI client OpenAI( api_keyos.getenv(QWEN_API_KEY), base_urlhttps://api.qwen.example.com/v1 ) def llm_judge(attribute, values, context_chunk): prompt build_judge_prompt(attribute, values, context_chunk) resp client.chat.completions.create( modelqwen3.8-max, messages[{role: user, content: prompt}], response_format{type: json_object} ) result json.loads(resp.choices[0].message.content) return result实践中我发现 response_format 指定 json_object 后有两大好处一是模型会更严格按照 JSON 输出而不是唠叨一堆解释二是即便偶尔输出非法 JSON也因为格式已经限制住修复成本大大降低。还有一个很关键的提示词细节必须要求模型给出“evidence”也就是冲突点的原文引用。这个设计不是为了展示所谓专业性而是为了后续人工复核时有据可查。如果没有证据引用模型说“有问题”你根本不知道它是真的发现了问题还是产生了幻觉。4. 一次真实体检报告6 份资料 1 张商品图27 个问题全清单4.1 问题分级标准critical / warning / info体检报告把问题分成三个级别这个分级直接影响用户处理顺序。critical必改会造成违规、处罚、消费者投诉或退款的硬性错误warning应改不影响上架但会降低转化率或引发售后纠纷info建议优化影响购物体验或合规风险较低但值得注意我这次跑出来的 27 个问题按级别分布如下级别数量说明critical3广告法违禁词 2 个、保修期跨文档矛盾 1 个warning9续航数值不一致、重量不一致、接口描述冲突等info15格式不规范、信息缺失、表述冗余4.2 按类别归因这 27 个问题到底错在哪如果按“错误类型”来归因分布更值得分析跨文档数值不一致7 个。集中在续航、重量、蓝牙版本、充电接口、保修期广告法违禁词4 个。全部是“最”字头表述必填字段缺失3 个。分别是重量、防水等级、充电线长度图片与文本冲突3 个。主图标注的续航数字与卖点文案不一致格式不规范5 个。包括金额大小写、单位缺失、字母大小写不统一新旧内容残留3 个。详情页中保留了旧版商品型号的表述口径不清晰2 个。比如“支持快充”但没说清楚功率其中“新旧内容残留”是我之前完全没预料到的问题。详情页里一段描述还是上一代产品的内容放着 AI 放大之下这种情况其实并不少见但人工检查非常容易漏。4.3 三个 critical 问题还原现场第一个 critical 问题出在广告法违禁词。详情页卖点里写了“行业最优降噪算法”这七个字中“最优”属于绝对化用语在广告市场监管中属于高风险词。硬规则直接抓出来了这个完全不需要 AI 参与。第二个 critical 是“最轻”出现在标题里“最轻盈的半入耳设计”。同样是违禁词但这个藏在标题长尾里人眼真的容易滑过去。第三个 critical 是保修期矛盾。售后政策文档里写“整机保修一年核心部件两年”但规格参数表里却写“质保三年”。同时商品标题里又有“3年质保”字眼。三个文件两个口径消费者一旦较真售后费用和平台处罚都跑不掉。这个组合问题是由一致性检测模块发现的LLM 给出的证据引用清晰地定位了三个文件的原文位置。4.4 图像与文本冲突的三个典型case主图与文本冲突的问题最值得单独拎出来说因为这类问题靠人工目视检查很容易漏掉。Case 1主图角落印着“40H 超长续航”卖点文案却写“超长续航 30 小时”规格表又写“电池续航音乐播放约 32 小时”。三个数值互不相同。主图上的数字是设计部门从产品包装上提取的卖点文案是运营凭印象写的规格表则是最新版产品规格。三套信息源没有对齐。Case 2主图上标了“蓝牙 5.3 稳定连接”规格表里写的是“蓝牙版本V5.4”。看起来只差一个小版本号但 5.3 与 5.4 在协议层面是不同的版本同时也证明资料包的内部信息没有统一基线。Case 3主图放了一张 USB-A 接口的充电线图片规格表里标注“充电接口Type-C”。这一条其实比前两条更危险因为消费者按图片理解会用 USB-A 线去充电但实际上产品是 Type-C 口极易引发低星评价。这个冲突是纯图像信息与表格信息的比对单纯查文档几乎无法发现必须多模态参与才能识别。4.5 更容易被忽略的 info 级问题info 级问题虽然不至于导致处罚但长期积累会显著影响运营效率和用户体验。我清点了一下这次抓出来的 info 问题包括商品标题超过 60 个汉字部分平台会被截断详情页中出现了英文括号与中文括号混用规格表中的“dB”写成了“db”大写不统一主图中没有任何关于“售后保障”的视觉提示售后政策复制痕迹明显提到“本店铺注册会员”但店铺名不匹配多个文件的换行符不一致在部分销售平台导入时可能出现乱码这类问题单个看都是小事但累积起来就是“商品资料不专业”的第一印象。体检助手最有价值的地方之一就是能把这些碎片化的小问题统一归档让运营知道哪些地方值得去改。5. 部署成日常工具的细节耗时、成本与持续集成5.1 轻量接入命令行一次跑完全流程体检助手的使用方式我做成了一条命令尽可能降低运营团队的抵触感python product_doctor.py \ --input ./data/product_pack/ \ --output ./data/output/report_20240601.md \ --model qwen3.8-max运行时脚本会先做本地规则检测再调 LLM 做语义裁决并生成检测报告。整个过程在普通开发机上大概耗时 40 到 60 秒其中大部分时间耗费在 PDF 文本抽取和网络请求上。对于不想敲命令的人我还做了一个简单的交互式模式python product_doctor.py --interactive进入交互模式后只需要拖入资料包文件夹路径剩下的事情程序自动完成。5.2 报告生成与 Diff上次的问题这次改了没有体检报告最终输出为 Markdown 文件包含三个区块问题总览表、按严重级别归类的明细、建议修改方案。而我觉得最有用的功能是“Diff 对比”。如果同款商品资料包每周都要更新一次运营很关心“上次提的问题这次有没有改掉”。我在 report 里增加了历史对比能力会读取上一次的体检 JSON 结果和新结果做字段级对比def diff_reports(old_path, new_path): old load_json(old_path) new load_json(new_path) fixed [p for p in old if p not in new] new_issues [p for p in new if p not in old] return {fixed: fixed, new: new_issues}这个功能上线后团队看周报的效率明显提升因为不再需要人肉核对一份几十行的查错清单了。5.3 接入 GitLab CI上架前自动拦截如果商品资料包是存在 Git 仓库里的还可以把体检助手接到 CI 流水线里。每次有新的资料提交合并请求时自动跑一遍体检流程如果检测到 critical 级别问题流水线直接失败阻止合并product_check_job: stage: test script: - python product_doctor.py --input ./data/product_pack/ --output ./report.md variables: AIDER: 1这里提一个实操中的坑LLM 调用是外部网络请求CI 环境里如果网络受限会导致检测流程卡住。稳妥做法是先做本地硬规则拦截只有本地规则通过后才调用 LLM 语义裁决。这样即便模型接口临时不可用核心的违禁词和必填项检查也不会挂掉。6. 让体检结果可信的四个关键心得幻觉、误报与兜底策略6.1 模型幻觉的解法强制证据引用 人工复核锚点LLM 做语义判断时最怕的就是幻觉。明明两份文档内容完全一致模型却脑补出一个“不一致”或者反过来明明明显矛盾模型却觉得“差不多这样可以”。这个问题不解决体检助手就是一个只会制造噪音的工具。我的经验是在提示词里强制模型为每一个问题输出“evidence”字段并且要求 evidence 必须是原文原句不允许转述或总结。如果模型无法提供原文证据那就默认这条检测结果不成立不进入最终报告。这个策略极大降低了误报率尤其是对于 warning 级别的问题。6.2 提示词设计里最常见的两个认知错误第一个错误是让模型去“搜索问题”而不是“判断给定属性对”。一开始我让模型直接看六份文档然后输出所有不一致的地方。结果模型经常过度发挥把一些描述性差异、营销口吻差异也当成问题导致报告里一堆没用的内容。后来改成每一组字段对单独调用一次模型模型只做判断题不做阅读理解输出质量立刻稳定。第二个错误是让模型判断“哪个对”。这个提示词是绝对扣分项。模型不是质检仪它没有能力判断规格表里 32 小时和卖点里的 30 小时哪个才是真实续航。它的职责是发现“两者存在差异并指出差异”具体该以哪个为准应该由产品经理决定。一旦模型越权去判断对错它就会开始编造理由来自洽。所以最终提示词里我明确写了“不要判断哪个正确只负责指出差异存在及差异内容”。6.3 JSON 输出兜底偶发解析失败不阻塞整个流程模型接口偶尔会返回非法 JSON或者因为上下文超长导致输出被截断。我做了三层兜底第一层是重试机制最多重试 2 次每次间隔 3 秒第二层是 JSON 修复遇到截断情况尝试补齐闭合括号第三层是降级策略如果重试和修复都失败就把该字段对标记为“待人工复核”而不是直接丢弃这个降级策略很重要。宁可在报告里有一条“待人工复核”也不能让这条潜在问题直接消失否则就失去了体检助手的意义。6.4 后续想扩展的方向目前这个版本已经能用但我心里清楚还有很多可扩展的空间。比如把检测结果直接生成一份可导入到店铺后台的修改对照表增加同款竞品标题的正向参考把多张商品图都纳入检测范围而不只是一张主图对历史体检报告做趋势分析找出团队在资料维护上最常犯的错误点定向做培训。如果你也在做电商运营、供应链管理或者商品素材审核这类工作我建议你真的可以试试用 LLM 搭一个类似的“资料包体检助手”。不需要一开始就做得很复杂先从最简单的一个“字段一致性比对”开始跑通一条命再逐步加规则、加多模态一步步就能做成一个真正每天离不开的效率工具。