用大模型给商品资料包做自动化“体检”，一次查出27个问题

1. 项目背景：为什么商品资料包需要“体检”

1.1 资料包到底长什么样

做电商运营和商品管理的朋友应该都有这种体验：一个新品要上架，手里会攒出一大堆资料。标题表、SKU规格表、卖点文案、质检报告、包装信息、竞品对比，再加上一张或几张商品主图，零零散散散落在邮箱附件、网盘目录、微信传输记录里。多数团队的现状是——这些文件有人建、有人传、没人核对。

我这次拿到的这包资料，就是一位做家居日用品运营的朋友发来的，结构挺典型的：

• 资料1：商品基础信息表，包含标题、品牌、类目、卖点关键词。
• 资料2：SKU规格参数表，包含每个SKU的价格、库存、条码、规格参数。
• 资料3：详情页营销文案，也就是准备投放到商品详情页的那段宣传文字。
• 资料4：合规资质文件，包括质检报告扫描件、品牌授权书。
• 资料5：包装信息表，包含包装尺寸、生产日期、包装上的信息标注。
• 资料6：竞品对比表，用来做卖点对标和定价参考的表格。
• 附件：1张商品主图，就是准备做主图的那张JPG。

这些资料单独看都“还行”，但一旦放到一起，问题就全暴露了。我数了一数，这次一次性查出27个问题，里面真正要命的不是错别字，而是多份材料之间互相打架。

1.2 人工审核的真实痛点

以前这种资料包审核靠什么？靠运营和编辑肉眼一张张看、一个个字段对。听起来不复杂，但实际做过的人都知道有多折磨。

一是跨文件比对非常容易漏。标题里写了“加厚加大”，竞品对比表里对标的是“标准款”，SKU表里又只有常规尺寸，这三份文件如果不是同一个时间版本，很少有人会逐字比对它们之间的措辞差异。

二是合规问题靠人记不住。平台对“最”“第一”“国家级”这些词有多敏感，老运营知道，新人未必知道。更别说授权书有效期、品牌名称写法、条码格式这些细节，一次审核要看几十项，漏掉太正常了。

三是审核结果没有沉淀。今天人工查出3个问题改了，明天另一个平台要用同一套资料，又得重新审一遍。没有标准化规则，经验就永远只是个人经验，变不成团队能力。

所以我想的很清楚：与其继续在“人工打补丁”这条路上熬，不如把检查环节做成一件事——让模型当体检医生，我只需要把资料包扔进去，它把问题清单报出来。

1.3 为什么选大模型而不是传统规则脚本

有人可能会问：这种一致性比对、合规词检测，用Python写规则不就行了？确实，一部分可以，比如“标题是否超过60个字符”“条码是否为13位”“授权书是否过期”这类强规则，脚本处理又快又准。但另外一大部分，规则脚本搞不定。

举个例子。详情页文案写“采用加密压缩工艺，强度提升50%”，质检报告里实测数据写的是“抗压强度提升45%”。这种“文案宣称和检测报告数据不一致”的问题，传统规则根本没法自动识别，因为两个数字出现在完全不同的句式里，字段名也不对应。但大模型能，它读得懂语义，知道“强度提升50%”和“抗压强度提升45%”在说同一件事。

再比如竞品对比表里写的竞品名称，和授权书里出现的商标名称不完全一致，规则脚本只能做字符串匹配，匹配不上就放弃了。而大模型可以根据上下文判断“这俩指的是同一个东西，只是一个写了全称一个写了简称”。

所以我的结论是：规则脚本做硬校验，大模型做软理解，两者结合才是最稳的方案。Qwen3.8-Max在这个场景里的定位不是替代规则，而是补上规则覆盖不到的那一层语义比对能力。

2. 整体方案设计：一个体检助手该有哪些模块

2.1 从“查问题”倒推功能拆解

既然目标是“一次查出27个问题”，那就得先想清楚：这些问题是从哪几个维度查出来的？

我把体检维度拆成四层：

第一层：基础完整性检查。必填字段有没有缺失，资料包里有没有空文件、占位文件，资质附件是不是图片冒充PDF，这些属于拿到资料包第一步就能做的事。

第二层：格式规范检查。标题长度、条码位数、日期格式、图片尺寸分辨率，这些都有硬性标准，适合用程序化的规则直接跑。

第三层：跨文件一致性检查。同一商品的标题、详情页文案、规格参数表、竞品对比表，四个文件里的品牌名称、核心卖点、价格区间、参数数值是否一致。这一层是工作量最大的，也是人工最容易漏的。

第四层：合规风险检查。营销文案有没有触犯广告法的高风险词，授权资质有没有超出有效期，主图上有没有出现未授权的LOGO或者二维码水印。

这四层检查合起来，就是体检助手的整体功能范围。项目一开始就按这个结构来设计模块，后面每加一个体检项，都能落到具体的层级里，不会乱。

2.2 技术选型：为什么是 Qwen3.8-Max

选型这件事，我其实纠结过一阵。当时摆在面前的有几条路：直接用现成的文档比对工具，用传统NLP方案，或者用大模型。最后选了 Qwen3.8-Max，主要看重它的三点：

一是上下文长度够用。一个资料包里的6份文件转成文本之后，多的时候能到几万字。Qwen3.8-Max的上下文窗口能撑得住完整输入，不需要把一份文件拆成好几段再分别送进去，这对保持全局一致性判断非常重要。上下文窗口不够的话，模型很容易“只见树木不见森林”，看到后面忘了前面。

二是指令遵循能力强。体检助手这个场景，本质上是让模型按照一套固定规则去审查材料，输出结构化结果。我实测下来，Qwen3.8-Max对Prompt里的输出格式约束响应得比较稳定，让它输出JSON就输出JSON，让它逐条列问题就逐条列，不太会自由发挥。

三是部署和调用成本可控。对于一个内部工具来说，成本是不能不考虑的因素。Qwen3.8-Max这个档位的模型，单次调用费用完全在可接受范围内，即使后面把全店商品资料包都跑一遍，预算也不会爆。

当然，如果你手头用的是其他同级别的模型，整个方案思路也完全适用。这个项目的核心不在“非某个模型不可”，而在于怎么把体检规则设计好、Prompt组织好。模型只是执行引擎。

2.3 整体流程与数据流转

整个体检流程，我拆成六个环节：

1. 文件接收：上传6份资料和1张商品图到指定文件夹。
2. 格式解析：Excel转成结构化表格数据，PDF抽取文字和表格，图片做OCR或者直接交给多模态模型读取。
3. 规则预检：用Python脚本跑第一轮硬性检查——必填项、长度、格式、日期等，这部分不消耗模型调用。
4. 模型深度比对：把六份资料的文本内容组织成一份结构化的“检查工作台”，连同检查规则一起交给 Qwen3.8-Max，让它逐项核对。
5. 结果聚合：把脚本发现的问题和模型发现的问题合并去重，按严重程度分级。
6. 生成报告：输出一份问题清单，每条包含问题描述、涉及文件、修改建议。

实际跑下来，一轮完整体检耗时不到两分钟，其中大头在模型推理，规则预检基本是秒出结果。这个速度已经能覆盖大批量商品的日常巡检需求了。

2.4 27个体检项怎么来的

说实话，“27个问题”不是一开始就规划好的数字。我先列了一份常见的检查点，大概五六十项，然后根据这次实际的数据做了收敛，去掉了那些在当前资料包里不适用或者重复的项，最后落到27项。

这27项覆盖了我上面说的四个层级。我列个简表，方便大家快速理解：

体检项不是固定的，不同类目、不同平台的规则差异很大。所以我在设计的时候把每个体检项做成了可配置的，加一条规则就是往配置文件里加一行，不需要改代码。这也是这个项目能持续用下去的关键——工具要跟着业务规则走，不能业务规则跟着工具走。

3. 核心实现：解析、抽取、比对、判责

3.1 文件解析层：Excel、PDF、图片怎么处理

文件解析是整个流程的第一步，也最容易被低估。我这次实际踩了几个坑，先说结论：

Excel解析用pandas就够，但要注意多Sheet的情况。SKU规格参数表经常有多个Sheet页，一个Sheet放商品信息，一个Sheet放价格库存，还有一个Sheet放包装参数。直接用pd.read_excel()只能读到第一个Sheet，必须先把Sheet名全部列出来，定位到真正有数据的那个Sheet。我这次的资料包就是这样，SKU数据藏在第三个Sheet里，名字叫“明细”，前面两个Sheet反而是空模板。

PDF解析得分情况。质检报告这类文件，如果是印刷体文字版PDF，用pdfplumber抽取文字和表格效果不错；如果是扫描件，就必须走OCR。我这次碰到的质检报告是扫描件，直接用文字抽取什么都拿不到，后来加了一层OCR才把关键数据捞出来。OCR这块我用的是本地OCR方案，识别中文印刷体效果足够，关键是数据不出本机，安全性也更好。

商品主图处理分两条路。一条是纯规则——用PIL检查图片尺寸、分辨率、格式、是否有水印区域，这些信息直接可读；另一条需要模型参与——图上有没有出现违禁词、有没有不合规的营销语、LOGO是否清晰可辨，这些需要把图片喂给多模态模型来识别。我是两条路都走，规则查硬指标，模型看内容。

解析层所有产物统一处理成文本和结构化数据，方便后面拼接Prompt。这里有一个经验：解析出来的表格不要丢列名，列名是模型理解表格含义的关键线索。如果只保留数据行不保留表头，模型很容易猜错每个字段是什么意思。

3.2 产品字段抽取：先让模型“读懂”资料

拿到文本之后，第一件事不是直接让模型找问题，而是先做一轮字段抽取。

为什么要多此一举？因为直接问“这份资料包有什么问题”，模型给出的答案往往是零散、片面的，可能只盯着某一份文件看，遗漏其他材料。但如果先让它把商品的关键信息抽成一张统一的“商品事实表”，再拿这张表去做交叉比对，效果会好很多。

我这边的做法是，让模型从全部资料中抽取以下字段：

• 商品名称、品牌、类目
• 核心卖点词及出处
• 规格参数（尺寸、重量、材质、容量等）
• 价格体系（前台价、活动价、成本价）
• 资质信息（证书编号、有效期、授权品牌）
• 包装信息（包装尺寸、生产日期、条码）

输出格式是JSON。比如抽取结果的片段是：

{ "brand_aliases": ["某某生活", "某某家居"], "main_selling_points": [ {"content": "抗菌率99.9%", "source": "详情页文案"}, {"content": "容量提升50%", "source": "标题"} ], "specs": { "color": "白色", "size": "加大号", "material": "食品级PP" } }

这一步的实际价值是：把分散在不同文件里的信息统一到一个结构里，后续不管是做字段比对还是合规审查，模型需要处理的数据量都小了很多，输出质量也更稳定。

3.3 交叉比对：同一商品在不同文件里的口径是否一致

交叉比对是查出“27个问题”里占比最高的部分，也是最能体现大模型价值的部分。

传统脚本做交叉比对，核心是字段映射——你得告诉程序“标题里的尺寸”和“规格表里的型号”是同一个概念，才比得起来。但资料包里不是所有对应关系都这么明确。比如详情页文案写“加厚加硬”，规格参数表里写的材质厚度是“5mm”，标题里写的是“升级款”——这三者之间有没有矛盾，脚本判断不了，但模型能。

所以我把交叉比对的Prompt设计成“声明式”风格：不要模型自由发挥去找问题，而是给它一组明确的比对任务。每个任务说清楚比对哪两个数据源、判断标准是什么。举个例子：

请比对以下两组信息是否一致：

1. 商品标题中的尺寸描述："XXL加宽款"
2. SKU规格表中的尺寸字段："常规款（非加宽）"

判断标准：标题、规格表、详情页文案三者中，对同一属性的描述应保持一致。如果存在冲突，请指出冲突双方及具体表述。

这样做的优点是，模型不会跑偏，每条输出都能对应到具体的检查任务，排查和追溯都很方便。我这次查出来的问题里，有大约14个属于这类跨文件不一致，包括：

• 标题强调“加厚”，质检报告里厚度数据和常规款一样。
• 竞品对比表里写的自身产品容量，和SKU表里的规格对不上。
• 包装信息表上的品牌名称，和授权书上的商标名称差了两个字。
• 详情页文案写出“含赠品”，SKU表里根本没有赠品对应条目。
• 价格体系里，详情页文案宣传的到手价和SKU表活动价不在一个区间。

这类问题如果靠人工找，需要把六份资料打印出来铺在桌上一一对应，非常耗时。模型做这件事，优势不在“聪明”，而在“耐心”——它不会因为文件多就看漏。

3.4 合规审查：把平台规则翻译成Prompt

合规审查这部分，我一开始也想得太简单了，以为写几句“检查有没有违禁词”就行。后来发现，合规检查的本质是“把平台的规则库翻译成模型能执行的语言”，这里面有不少门道。

首先是违禁词识别。不能只给模型一个词表让它“查一下有没有”，因为很多违禁表达不是唯一的固定词，而是带有强烈主观评价色彩的句式。比如“质量最好”“性价比之王”“全网第一”，词表匹配不了这类变体，模型却能根据语义识别出来。所以我的Prompt里明确要求：不仅要找出词表里的词，还要找出“语义上属于绝对化承诺”的表述。

其次是资质检查。授权书有效期这种硬规则，其实直接用正则和日期比较就能做，不一定要模型来。但“授权品牌是否与本次上架商品品牌一致”就需要模型判断了。我这次就查出一个问题：授权书上的品牌是全称，商品基础信息表里用的是简称，从字符串角度完全匹配不上，但语义上都指向同一个品牌。这种又属于模型的活。

再者是图片合规。给模型传一张商品主图，它可以识别出图上有没有出现明显的营销水印、二维码、未授权品牌LOGO。我这次检查商品图的时候，模型给出提示“图片右下角疑似存在其他平台水印”，后来人工确认确实是处理图片时残留的水印。如果不是专门查，这张图大概率直接就被上传了。

合规这块我的建议是：能上规则就上规则，规则解决不了的语义问题才交给模型。否则每次检查都让模型读一遍全部资料，成本高不说，还可能因为模型“太灵活”把合规的表述误判成违禁词。

3.5 报告输出与问题分级

所有问题查完之后，最终要落到一份可执行的报告里。我这边输出的每一条问题都包含六个字段：

1. 问题编号：便于后续跟踪，比如Q-01到Q-27。
2. 严重级别：分为致命、严重、警告、建议四档。
3. 问题描述：说清楚发生了什么冲突或缺失。
4. 涉及文件：指出是哪份资料、哪个字段、哪一行。
5. 依据说明：为什么这是问题，引用的规则或标准是什么。
6. 修改建议：给出具体的修复方向。

分级标准也很直接：致命问题影响上架或触犯法规，必须解决；严重问题会造成消费者误解或平台处罚；警告问题属于规范性偏差；建议类属于优化项。

举一个具体的例子，某条严重问题的记录是这样的：

Q-14 | 严重：详情页文案宣称“容量提升50%”，但SKU规格参数表中标注的容量为2L，未找到可对比的“旧版容量”数据，无法支撑50%的提升结论。涉及文件：资料3详情页营销文案第2段、资料2SKU规格参数表第5行。建议：补充旧版容量数据或修改文案表述。

报告生成之后，我会把它保存成Markdown文件，方便在文档工具里直接查看和评论。如果后续要对接工单系统，把输出格式改成JSON也不难。

4. 实操实录：用 Qwen3.8-Max 跑通一次完整体检

4.1 环境准备和依赖

先说环境。整个项目我用Python 3.10写的，核心依赖如下：

pip install pandas openpyxl pdfplumber pillow

这几个是基础解析库，分别处理Excel、PDF和图片。如果你需要OCR支持，还可以加一个OCR库，不过我这里做的是先测试文字版PDF的可读性，再决定是否启用OCR，避免引入不必要的处理链路。

模型调用方面，因为Qwen3.8-Max我们是通过API方式接入的，所以不需要本地部署模型，几行代码就能把服务端的能力调到本地脚本里来，比较适合快速做原型验证。如果你追求数据完全不出内网，部署本地版本也是完全可以的，只是体力活多一点。

4.2 核心代码结构

整个脚本我控制在三百行左右，分成四个模块。这里分享核心的结构思路，完整代码不建议直接抄，因为每个人的资料结构不一样，但框架可以复用。

第一步，读取和解析所有资料：

import pandas as pd import pdfplumber from PIL import Image def parse_excel(filepath): """读取Excel的全部Sheet，返回字段名能保留的字典结构""" sheets = pd.read_excel(filepath, sheet_name=None) parsed = {} for sheet_name, df in sheets.items(): if df.empty: continue parsed[sheet_name] = df.astype(str).to_dict(orient="records") return parsed def parse_pdf_text(filepath): """抽取PDF中的文字和表格""" pages_text = [] with pdfplumber.open(filepath) as pdf: for page in pdf.pages: text = page.extract_text() if text: pages_text.append(text) tables = page.extract_tables() if tables: for table in tables: pages_text.append("表格数据：") pages_text.append("\n".join([" | ".join(row) for row in table])) return "\n".join(pages_text)

第二步，把解析结果组织成Prompt输入。这里的关键是给每份资料编号、加标签，让模型清楚地知道每段内容的来源：

def build_context(parsed_files): context_parts = [] for file_id, info in parsed_files.items(): context_parts.append(f"<文件{file_id}>{info['filename']}</文件{file_id}>") context_parts.append(info["content"]) return "\n\n".join(context_parts)

第三步，调用模型。这里我把检查任务分成几类Prompt，每一类对应一个检查维度，每一类都会做一次模型调用。比如“字段抽取”一次、“交叉比对”一次、“合规审查”一次。

def run_check(context, task_prompt, output_format): full_prompt = f""" 你是一个电商商品资料包审查专家。 以下是需要检查的全部资料内容，每份文件都有明确的文件编号标记。 {context} 请完成以下审查任务： {task_prompt} 输出要求：{output_format} """ response = call_qwen_model(full_prompt) return response

第四步，把模型返回的结果解析成结构化数据，和规则脚本的检查结果合并，生成最终报告。

def merge_and_generate(rule_issues, model_issues): all_issues = rule_issues + model_issues # 按严重级别排序 level_order = {"致命": 0, "严重": 1, "警告": 2, "建议": 3} all_issues.sort(key=lambda x: level_order.get(x["level"], 99)) return format_report(all_issues)

整个流程没有很复杂的逻辑，真正花时间的是调试Prompt。我前前后后改了七八版，才把输出的稳定性和准确率调到比较满意的程度。

4.3 Prompt设计要点：让模型当“审核员”而不是“作家”

这次项目里最值得分享的，是Prompt设计上的一些心得。

不要把模型当API调就完事了，要给它清晰的角色和工作流。我最初的Prompt只是列出资料内容然后问“有什么问题”，结果模型给出的答案很泛，像一篇总结报告，没有可执行性。后来改成“你是电商商品资料包审查专家，请按以下步骤逐项检查”，效果立刻不一样了。

检查任务要拆细，一次只让模型做一类事。我一开始试图让模型一次性完成所有检查，比如“请检查所有资料的完整性和一致性，找出全部问题”。结果模型要么过度关注某一个方面，要么就是平均用力但每个方面都查得不深。拆成“先做字段抽取，再做交叉比对，再做合规检查”三个独立任务后，每一轮的精确度都明显提升。

输出格式要给出明确的JSON结构，并且附上一个小示例。模型对JSON并不陌生，但不同模型对JSON的边界理解不一样。给一个few-shot示例，能大幅减少输出格式不稳定的问题。

检查标准要写在Prompt里，而不是让模型自己发挥。比如“请检查品牌名称是否一致”这个描述太模糊。要改成“请对比资料1中的品牌字段、资料4授权书中的授权品牌、资料5包装信息表中的品牌名称，三者指向同一商业主体时，允许全称/简称差异，但不得指向不同主体”。规则越明确，误报越少。

4.4 一次实测的结果长什么样

跑完全部流程之后，输出的报告开头是这样的：

共发现问题27项，其中致命问题2项，严重问题9项，警告问题11项，建议事项5项。

27个问题的分布情况：

• 基础完整性：查出3项。包括资质文件夹中有一个空PDF、竞品对比表中有一列数据为空、包装信息表缺少生产日期。
• 格式规范：查出5项。包括SKU条码不足13位、商品主图分辨率低于平台要求、标题超长、重量单位不统一、日期格式混用。
• 跨文件一致性：查出14项。这是问题重灾区，主要集中在标题/详情页文案与规格参数表、竞品对比表之间的数据冲突。
• 合规风险：查出5项。包括“质量最好”这类绝对化用语、授权书有效期不足三个月、商品主图右下角残留水印、详情页文案出现竞品未脱敏名称、赠品信息在SKU中无对应设置。

这27项里，最让我印象深刻的是那条致命问题——竞品对比表里引用了竞品品牌的完整名称和型号参数。如果这张表被当作详情页素材直接使用，不仅涉及侵权风险，还会让店铺因为“贬低同行”被平台处罚。但这份表本身只是内部参考资料，并不是最终对外素材，所以实际危害没有那么直接，但作为体检项必须标出来，提醒运营在对外输出前再次确认。

5. 常见问题与排查技巧实录

5.1 模型误报太多怎么办

这是第一个会遇到的问题。模型查出100个问题，人工复核后一半是误报，这种情况我见过不止一次。排查方向有两个：

先看Prompt里的判断标准是否足够明确。很多误报其实是因为判断标准有歧义。比如你让模型检查“价格是否合理”，它没有明确标准，只能凭感觉，自然容易把正常价格当成异常。改成“价格是否超出同类目商品平均价格的合理范围，具体范围为同行的0.5-2倍之间，超出此范围请标出”，误报率立刻降下来。

再看是不是任务拆得不够细。如果让模型同时检查十个维度，它很可能为了“完成率”而把可疑但不异常的内容也列出来。拆细任务之后，每个检查项的职责清晰，模型反而会收敛，不那么发散。

5.2 长文本截断导致漏检

资料包内容多的时候，模型容易受上下文长度限制，如果Prompt里塞了太多内容，可能会导致后面的文件内容被截断，模型自然查不到问题。这个在项目里遇到过。

解决思路是分级处理。不要把所有文件一股脑全塞进一个Prompt。先让模型对每份文件单独做关键信息抽取，抽取结果通常比原文短很多，再把抽取结果汇总在一起做交叉比对。这样既保留了对全局的视野，又不会触达上下文上限。实测下来，这个“抽取-汇总-比对”的三段式结构，比直接灌长文本的效果稳定得多。

5.3 模型输出格式不稳定

十个问题里有一个输出格式不对，整个解析流程就会断。这是大模型的通病，但可以通过两件事来缓解：一是在Prompt里明确输出JSON的结构和示例；二是在代码里做容错，拿到模型输出后用正则提取JSON片段，即使用json.loads失败也不至于脚本崩溃，而是把原文记录下来，等人工确认。

我这边每次调用都会保留模型原始回复的日志，一旦解析失败，可以快速定位是哪一轮出了问题。

5.4 成本和性能怎么平衡

大模型调用的费用是持续成本，批量跑商品资料包的时候不能不计成本。我这边有一些实测经验：

规则前置能省下大量无效调用。像“必填项缺失”“条码格式错误”这类问题，脚本就能查出结果，完全不用让模型参与。我这次27个问题里有8个是脚本直接查出来的，如果全让模型查，费用至少贵30%。

能一次查完的不分多次。如果上下文长度允许，尽量把同一类检查任务合并成一次调用，减少重复发送资料内容的开销。我的做法是：字段抽取一次调用，交叉比对一次调用，合规审查一次调用，三次调用覆盖全部27个检查项，单次体检模型调用成本完全可以接受。

缓存重复内容。同一个商品不同批次上传的资料包，解析结果经常是重复的。我在解析层加了一个简单的哈希缓存，内容没变的文件直接复用上次的解析结果，不需要重新解析，更不需要重新调模型。

6. 把这套方案用在更多场景

这个体检助手目前是命令行工具形态，我后续把它做成了一件可以持续迭代的事，而不是跑完一次就丢。

一个自然的扩展方向是接入商品管理后台，每次新商品资料上传时自动触发体检，结果直接推送审核群。这样就不需要运营手动提交文件、手动运行脚本了，整个上架前检查环节变成了自动化流程的一部分。再往后还可以加”体检项配置“的可视化界面，让运营自己调整哪些检查项开启、哪些关闭，不需要改代码。

另一个方向是把这个思路复制到其他数据类型上。例如活动页面搭建前需要准备的图片、文案、价格表，本质也是一种“资料包体检”；直播带货前的主播口播稿和产品参数表之间，也存在大量的信息一致性核对需求。处理过一次商品资料包之后就会发现，“多份资料，一份商品真相”的矛盾是这个行业里普遍存在的,大模型能做的其实是把“找不同”这件事从人的负担变成机器的职责。

做这个项目最大的感受是：Qwen3.8-Max这类模型真正改变效率的地方，不是它能写出多么华丽的文案，而是它能把以前需要人工逐字核对的工作，变成一次能快速跑完的自动化流程。模型当然会误判，规则脚本也会有漏洞，但一台准确率90%的体检仪器加上一个复核的医生，怎么都比只用肉眼一个一个文件翻要强。这套方案落地之后，我第一时间把它用在了后续所有新品的资料包审查上，光是节省出来的对比时间就足够值回开发投入了。