企业官网建设流程全解析

不需要主标题，直接从正文开始。

1. 为什么我会想到用大模型体检商品资料包

做电商运营的朋友应该都有过这种体验：商品要上架，运营同学吭哧吭哧整理了一堆资料，标题、卖点、参数表、详情页文案、主图、SKU 图……然后发给审核，审核打回来，说主图文字太小、标题出现了违禁词、参数表和详情页对不上、白底图不符合平台规范。运营改完再发，审核再挑出两个新问题，来回几个回合，一整天就耗进去了。

我这边的情况更具体一些。团队手头有六份商品资料文档，外加一张商品主图，需要在一个大促活动开始前全部完成合规检查和信息一致性核对。这六份资料包括：商品基础信息表、卖点提炼文档、详情页文案初稿、参数规格表、价格促销方案、库存与发货说明。外加一张 800x800 的主图，上面有产品外观和几个营销角标。

以前这种检查全靠人工逐项比对，眼睛看花了不说，漏检率还挺高。尤其是不同文档之间的交叉比对——比如详情页里写了一个参数，参数表里又是另一个数值，这种不一致问题人工翻找特别容易漏掉。这次我干脆换了个思路：既然大模型在文本理解、信息抽取、逻辑比对这些方面已经足够能打，那我是不是可以把这些资料全部丢给它，让它当一个“体检医生”，一次性把所有能看出来的问题全部列出来？

说干就干，我基于 Qwen3.8-Max 搭了一个电商商品资料包体检助手。整个思路不复杂：把多份文档作为上下文输入给模型，再给模型一套明确的检查规则和输出格式，让它逐项核对、交叉比对，最后输出一份结构化的“体检报告”。实测下来，6 份资料加上 1 张商品图，一次就跑出了整整 27 个问题，覆盖了文字违规、信息冲突、图片角标风险、促销逻辑漏洞等多个维度。

如果你也在做电商运营、商品上架、内容审核，或者你手里正好有一堆商品资料需要在大促前完成自查，那这篇内容应该能给你提供一套可落地的方案。我会把完整的提示词设计思路、检查维度拆分方法、工具链搭建过程、实测中发现的问题清单，以及中间踩过的坑全部写出来。

2. 体检助手整体设计：资料分析这件事为什么适合交给大模型

2.1 从“人工逐项核对”到“模型全量体检”的思路转变

先说说我为什么会觉得这件事适合用大模型来做。电商商品资料包的问题类型，看起来五花八门，但归纳起来其实就几大类：合规性问题（比如极限词、违禁词、未授权的认证标识）、一致性问题（不同文档之间的参数、价格、日期互相冲突）、完整性问题（该有的字段缺失、该传的图没传）、逻辑性问题（促销方案算下来亏本、库存承诺和实际发货能力不匹配）。

这四类问题里，合规性检查对规则匹配要求高，一致性检查对信息比对要求高，完整性检查对字段枚举要求高，逻辑性检查对数值计算和上下文理解要求高。以前这些工作靠人肉完成，本质上是“人肉 OCR + 人肉比对 + 人肉规则引擎”。而现在大模型在文本理解、指令跟随、结构化输出方面的能力已经相当成熟，完全可以把这些环节自动化。

我选择 Qwen3.8-Max 而不是其他方案，主要有几个原因。第一，它的上下文窗口足够长，六份文档加一张图片转换来的文字描述，全部塞进去也不会截断；第二，它的指令跟随能力比较稳，我给它设计了一套 JSON 输出格式，它能老老实实按格式回，不像有些模型一复杂就自己发挥；第三，它对中文电商语境的理解比较到位，像“国家级”“最高级”“第一品牌”这种广告法违禁词，它基本一眼就能识别出来，不需要我提前维护一份特别完整的敏感词表。

但这里要强调一点：大模型不是万能的，它也有自己的边界。比如对图片的视觉理解能力，虽然 Qwen3.8-Max 支持多模态输入，但涉及图片上具体文字内容的识别，我建议还是先把图片上的文字转成文本再喂给模型，识别准确率会更高。这个在后面实操部分我会详细说。

2.2 六份资料和一张图的信息架构拆解

在写提示词之前，我先把这次要体检的“材料清单”梳理清楚。这步特别重要，因为模型要知道它手里有哪些材料、每份材料应该包含什么内容、材料之间的关系是什么，才能有的放矢地去检查。

我处理的六份文档是这样的：

• 商品基础信息表：包含商品名称、品牌、类目、SKU 编码、材质成分、产地、保质期、执行标准、生产许可证编号等字段。这是整个资料包的“主档”，其他文档里的信息理论上都应该和它保持一致。
• 卖点提炼文档：运营同学整理的 Marketing 角度卖点文案，里面大概率会有夸张表述，是违禁词的重灾区。
• 详情页文案初稿：用于商品详情页展示的长文案，包含产品介绍、功能说明、使用场景等。
• 参数规格表：结构化的技术参数，比如尺寸、重量、功率、电压、容量、接口类型等，和基础信息表存在大量交叉字段。
• 价格促销方案：包含日常售价、促销价、优惠券面额、满减规则、活动时间、限购数量等。
• 库存与发货说明：包含库存数量、发货时效、发货地、物流公司、偏远地区是否包邮等。

外加一张 800x800 的商品主图。这张图上有产品实拍图、品牌 Logo、几个营销角标（比如“限时特惠”“正品保障”），还有角落里的两行小字说明。

把这些材料的关系理清楚之后，我给模型设定的“体检维度”是这样的：

这样设计的好处是，模型在检查的时候不是漫无目的地“读一遍然后自由发挥”，而是带着明确的检查任务去逐项扫描，输出的结果也会更有针对性，不会出现那种“这份材料整体写得不错”之类的废话。

3. 核心细节解析：提示词、输出格式与检查规则的工程化设计

3.1 提示词设计的四个关键模块

很多人用大模型做资料分析，效果不好，问题往往出在提示词上。不是模型不够聪明，而是你没告诉它“该看什么、按什么标准看、看完怎么汇报”。我这次的提示词设计了四个模块，缺一不可。

第一个模块叫“角色与任务定义”。我会明确告诉模型：你是一名资深的电商合规审核专家，你的任务是对给定的商品资料包进行全量体检，找出所有可能的合规风险、信息矛盾、缺失项和逻辑问题。这里的关键词是“全量”和“所有”——要让模型知道它不是在写摘要，而是在找茬，找得越多越好。

第二个模块叫“材料清单说明”。我会把六份文档和一张图片分别编号为材料一、材料二……材料七，并且为每一份材料写一句话的内容摘要。比如“材料一是商品基础信息表，包含商品名称、品牌、类目、SKU 编码、材质成分、产地、保质期等基础字段”。这一步是在帮模型建立“文件索引”，让它知道每一份材料的角色和内容范围，后续交叉比对的时候才能准确引用。

第三个模块是“检查规则清单”。这是整个提示词的核心，必须写得非常具体。不能只写“检查有没有违禁词”，而要写清楚违禁词的类型、常见的表达模式、要检查的位置。我在这部分会给出一些示例性的违规词，比如“最”“第一”“顶级”“极致”“国家级”“全网最低”等，并注明广告法相关规定。同时，我也会定义清楚什么算信息不一致——比如同一商品在不同文档中的材质描述不同、价格数值不同、活动日期不同等。

第四个模块是“输出格式控制”。我要求模型最终以 JSON 数组的格式输出检查结果，每个问题包含四个字段：问题编号（issue_id）、严重程度（severity，取值为 high/medium/low）、问题描述（description，要说明具体是什么问题、涉及哪几份材料）、修改建议（suggestion，要给出可操作的处理意见）。为什么强制要求 JSON 输出？因为后续我要对结果做程序化处理，比如自动统计各类问题的数量、按严重程度排序、生成可视化报告。如果模型自由发挥用散文格式输出，后续处理的成本就会高很多。

3.2 严重程度分级和问题分类的判定逻辑

设计检查规则的时候，还有一个特别重要的细节，就是给每个问题打上严重程度标签。我分了三个等级：

• high（严重）：涉及违规风险高、可能导致商品下架或处罚的问题。比如使用绝对化用语“最顶级”“国家级”、产品参数虚标、宣传内容与实际功能严重不符、许可证编号缺失等。
• medium（中等）：可能导致消费者投诉或影响转化的问题。比如不同文档之间材质描述不一致、促销价格计算方式不清晰、库存数量与限购数量矛盾等。
• low（轻微）：不影响合规但会影响用户体验或运营效率的问题。比如卖点文案里标点符号不统一、详情页有冗余重复的段落、图片角标文字和文案中提到的活动时间不完全一致等。

这个分级逻辑要写进提示词里，否则模型容易大小问题一把抓，最后输出一份几百条问题的大杂烩，反而没法用。我还会在系统提示里加一句“如果一个字段在多个材料中出现多次，务必逐一比对，不能只参考其中一个材料的描述”——这句话对提升一致性检查的召回率帮助很大。

3.3 图片信息如何纳入检查范围

这次体检有一张 800x800 的商品主图，我需要让模型把图上的信息也纳入交叉比对。实际操作上，我不会直接把图片丢给模型让它“看图说话”，而是先把图片用 OCR 工具转成文字提取出来，再把文字内容作为“材料七”的补充文本喂给模型。这样做的原因有两个：一是 OCR 出来的文字是模型百分之百能“看到”的，不会出现视觉识别偏差；二是后续要做交叉比对时，图片上的文字和其他文档内容需要做精确的字段级比较，纯文本格式更好处理。

用 Qwen3.8-Max 的多模态能力直接读图当然也可以，但实测下来，如果图上有小字号文字、艺术字体或叠加了半透明阴影，视觉理解模型偶尔会漏读或误读。OCR 先跑一遍、人工快速核对一下，再作为文本输入，整体的可靠性会上去很多。这个思路我觉得可以作为一个长期实践的方法：不是所有信息都要让模型“亲眼看到”，能转换成结构化文本的，先转换再喂给模型，往往效果更稳。

4. 实操过程：从零搭一个商品资料包体检助手

4.1 工具链选型与准备

整个体检助手的搭建，我用到的工具链非常轻量，没有搞复杂的系统和平台。

• 模型调用：Qwen3.8-Max 的 API 接口。我用的还是同步调用方式，把六份文档的文字内容和图片 OCR 文本拼接成一个大的上下文请求，一次调用跑完。整个请求的 token 消耗大约 12K 左右，响应时间在十几秒量级，完全在可接受范围内。
• OCR 提取：先用通用 OCR 工具把商品主图上的文字提取出来，包括品牌 Logo 区域的文字、营销角标文字、图片角落的小字说明，统一输出为纯文本。
• 文本预处理：把六份文档统一转成纯文本或 Markdown 格式，去掉多余的换行和特殊字符，按“材料一、材料二……”的顺序编号，拼接到一起。
• 代码集成：我用 Python 脚本调用 API，请求体里包含 system prompt 和 user message。返回的 JSON 结果直接解析成 DataFrame，再做简单的统计和过滤。
• 结果整理：最后把模型输出的问题数组导出成 CSV 或 Markdown 表格，方便分发给运营和设计同学逐条整改。

这套流程跑起来之后，从输入资料到输出体检报告，整个流程大约需要两三分钟，其中大部分时间花在 OCR 和手工预处理上。模型推理本身反而是最快的环节。

4.2 Python 调用的关键代码参考

下面是我实际使用的核心调用代码。如果你也想复现的话，可以直接参考这段逻辑，几个关键的参数都有注释说明。

import json import os from openai import OpenAI client = OpenAI( api_key=os.getenv("DASHSCOPE_API_KEY"), base_url="https://dashscope.aliyuncs.com/compatible-mode/v1", ) system_prompt = """你是一名资深的电商合规审核专家。你的任务是对给定的电商商品资料包进行全量体检， 找出所有可能的合规风险、信息矛盾、缺失项和逻辑问题。你必须严格参照以下材料清单、检查规则和输出格式。 【材料清单】 - 材料一：商品基础信息表（商品名称、品牌、类目、SKU编码、材质成分、产地、保质期、执行标准、生产许可证编号等） - 材料二：卖点提炼文档（营销卖点文案，重点检查违禁词和夸张表述） - 材料三：详情页文案初稿（用于详情页展示的长文案） - 材料四：参数规格表（结构化技术参数，尺寸、重量、功率、电压、容量等） - 材料五：价格促销方案（日常售价、促销价、优惠券、满减规则、活动时间、限购数量等） - 材料六：库存与发货说明（库存数量、发货时效、发货地、物流公司、包邮政策等） - 材料七：商品主图OCR文字提取结果（图中出现的所有文字内容） 【检查规则】 1. 合规性检查：识别广告法违禁词、绝对化用语、虚假宣传、未授权认证标识等。 2. 一致性检查：逐字段比对材料一至材料七，找出不同材料间相互矛盾的信息，如材质不一致、价格不一致、日期不一致等。 3. 完整性检查：找出必填字段缺失、SKU覆盖不全、关键信息遗漏等问题。 4. 逻辑性检查：检查促销价格是否自相矛盾、库存承诺是否异常、发货时效是否冲突等。 5. 图片合规检查：结合材料七，检查主图文字是否与文案一致、是否有角标风险等。 【输出格式】 严格输出 JSON 数组，每个元素包含4个字段： - issue_id: 问题编号，格式为 ISS-001 - severity: 严重程度，取值 high / medium / low - description: 问题描述，必须说明具体问题和涉及的材料编号 - suggestion: 修改建议，必须给出可操作的处理方案 只输出 JSON，不要输出任何解释性文字。""" user_message = "以下是该商品的全部资料内容，请进行全量体检：\n\n" + all_materials_text response = client.chat.completions.create( model="qwen3.8-max", messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_message} ], temperature=0.2, ) result_text = response.choices[0].message.content issues = json.loads(result_text) # 按严重程度统计 from collections import Counter severity_counter = Counter(item["severity"] for item in issues) print(severity_counter)

这段代码里有一个细节值得单独说一下：temperature 参数我设成了 0.2。体检这个场景要的是稳定、准确、规则导向的答案，不希望模型发挥创造性。如果把 temperature 调太高，比如 0.8 以上，模型可能把一些模棱两可的信息脑补成问题，或者把同一类问题换着花样描述好几次，反而增加人工核对成本。低温输出的结果更保守、更一致，对于这种“找茬”任务来说是更合理的选择。

4.3 体检实测：6 份资料加 1 张图跑出 27 个问题

参数调好之后，我正式跑了一次全量体检。整个输入文本拼接出来大概有 8000 多个字，加上系统提示词，单次请求的上下文在 12000 token 左右。模型返回的速度大约是 15 秒，一次成功，没有出现截断或者格式错乱的情况。

返回的结果一共是 27 个问题。我把它们按严重程度拆开看，high 级别的问题 5 个，medium 级别的问题 12 个，low 级别的问题 10 个。说实话，这个数量比我预想的多不少——毕竟这些资料在发给我做最终审核之前，运营同学已经自己检查过一轮了。但仔细看模型列出来的问题，绝大部分又是真实存在的，不是模型在无中生有。

我挑选几个比较典型的案例，给大家直观感受一下体检报告的价值。

第一个是 high 级别问题：详情页文案里出现了“全网销量第一”这个表述。这个属于典型的绝对化用语，广告法明确禁止，一旦被平台抽查到，轻则下架链接，重则罚款。人工检查的时候，运营同学通常只会搜索“最”“第一”这种单字关键词，但“全网销量第一”这种长尾表达很容易漏掉。模型做这件事就容易多了，它在语义层面理解“全网”“销量第一”组合起来的违规属性，直接标红。

第二个是 high 级别问题：参数规格表里标注的电池容量是 5000mAh，详情页文案里写的是“超长续航，内置 4800mAh 大电池”。同一个商品，两个文档差了 200mAh。这种不一致，消费者如果较真去对比，很可能直接投诉“虚假宣传”。人工检查的时候，一般只会单独看一份文档，很少有人会真的把参数表和详情页逐字段去对。模型做交叉比对就能轻松发现这种问题。

第三个是 medium 级别问题：价格促销方案里写的活动时间是“6月1日至6月3日”，主图 OCR 文本里的营销角标写的是“限时特惠 6.1-6.5”。活动时间差了整整两天。如果图片已经投放出去，活动实际只做 3 天，那 6 月 4 号和 5 号还在宣传“限时特惠”但价格已经恢复了，就会引发消费者投诉。这是典型的“图文不一致”问题。

第四个是 low 级别问题：商品基础信息表里的商品名称是“智能保温杯 500ml 黑色”，但详情页文案里开篇第一句写的是“这是一款 450ml 的便携保温杯”。容量表述看起来差不多，但消费者很容易以为这是两款不同的商品。虽然不影响合规，但对转化率和评价有潜在影响，归类为轻微问题完全合理。

27 个问题里还有不少关于库存、物流、产地信息遗漏的，就不逐一列举了。最终整理出来的体检报告，我给运营同学发过去，他们反馈说很多问题是他们自己从来没注意到的，尤其是跨文档的一致性冲突。

4.4 从 27 个问题里看商品资料管理的高频死穴

跑完这次体检之后，我做了一个小统计：这 27 个问题按类型分布来看，一致性问题和合规性问题加起来占了 70% 左右，其中一致性问题最多，有 12 个。这个数据其实很能说明电商资料管理的高频死穴：运营同学在写不同文档的时候，基本是“各自为政”，写详情页的是一个思路，填参数表的是另一个思路，做促销方案的可能又改过价格，最后汇总到一起，各种信息冲突就自然出现了。

我建议所有做电商的朋友，在大促前做资料自查的时候，重点关注以下三类问题，这也是我这次体检下来发现的最容易踩的坑：

• 同一字段的多处引用必须一致。比如材质、容量、尺寸、产地、保质期、执行标准，这些字段只要在多个文档中出现过，就必须逐一核对。
• 活动时间的多端同步。主图角标、详情页文案、促销方案、客服话术里出现的时间必须完全一致，哪怕相差一天都不行。
• 价格体系的闭环检查。日常价、促销价、券后价、满减叠加价，这四者之间的逻辑必须能算得通，不能出现“满 200 减 30 后价格高于日常价”这种低级矛盾。

5. 常见问题与调优实战：我用 Qwen3.8-Max 踩过的坑

5.1 问题一：模型输出格式不稳定，JSON 偶发解析失败

第一次跑的时候，我把 system prompt 和 user message 写在一个请求里，没有特别强调输出格式。结果模型返回的内容里夹带了一些解释性文字，比如“根据检查，我发现以下问题：”这种开头，导致 json.loads 直接报错。

后来我在 system prompt 里加了一句“只输出 JSON，不要输出任何解释性文字”，同时在代码里做了防御性处理：如果解析失败，就尝试从返回文本里截取第一对花括号内容再解析。现在基本稳定了，十次里面有九次能一次通过，剩下一次也能通过截取逻辑兜住。

这里给一个额外的建议：如果你的场景允许，最好在代码里加一个“重试机制”。比如第一次返回的 JSON 解析失败，就重新调用一次 API，并把上一次的报错信息作为反馈喂给模型，让模型自己修正输出格式。实测下来，重试一次的成功率接近百分之百，代价只是多等十几秒。

5.2 问题二：严重程度分级太粗，high 级别问题过多失去指导意义

最初我把检查规则里对 high 级别的定义写得太宽泛，结果模型把很多“建议优化”的问题也标成了 high，整个报告看起来像“全是严重问题”，运营和设计同学根本不知道从哪儿开始改。

后来我把 high 级别的判定标准收紧，只保留“可能导致商品下架或行政处罚”和“可能直接引发消费者投诉维权”这两类。medium 级别保留“影响信息可信度但可快速修复”的问题。low 级别则是“纯优化建议”。收紧之后，输出的问题分级明显更有指导性，团队可以直接按 high → medium → low 的顺序安排整改计划。

5.3 问题三：OCR 文字与原始图片信息有偏差

我在图片处理上踩过一个坑。第一次直接把图片丢给多模态模型让它读图，结果主图角落有一行很小的“图片仅供参考，请以实物为准”，模型没读出来，漏掉了这条信息。后来改用 OCR 工具先提取文字，人工再快速扫一眼确认，情况就好多了。

这里要特别提醒：OCR 本身也不是百分之百准确的，尤其是艺术字体、带阴影的文字、倾斜的文字。我的建议是，商品主图的文字提取结果一定要人工快速核对一遍，再去喂给模型。否则 OCR 漏掉的内容，模型是不可能凭空“看”出来的。

5.4 问题四：上下文过长导致响应时间变慢

有一版测试我贪多，把商品详情页的完整长图文字、历史评价摘要、竞品分析报告也一并塞进去了，整个上下文一度超过 25000 token。结果模型响应时间从 15 秒涨到了 40 多秒，而且部分早期输入的信息在输出结果里没有被充分引用。

后来我严格控制输入范围，只保留“该商品自身资料”相关的七份材料，其他外围信息全部拿掉。响应时间降回 15 秒级别，输出质量反而提升了。经验就是：输入越聚焦，检查效果越好。大模型不是输入越多越聪明，冗余信息往往会稀释它对核心材料的注意力。

6. 后续可以怎么扩展这个体检助手的玩法

这次基于 Qwen3.8-Max 搭的商品资料包体检助手，本质上是一个“提示词工程 + API 调用 + 结构化输出”的轻量应用，没有训练模型，也没有搞复杂平台，但它解决了一个非常实际的业务痛点。我觉得这套思路至少还能往三个方向扩展。

第一个方向是“定期巡检自动化”。把体检脚本挂到定时任务里，每两周跑一次全量商品资料扫描，生成历史对比报告。这样资料更新的同时就能检测出新引入的问题，不用每次都等到大促前才集中排查。这次是“被动体检”，做成定时任务之后就是“主动监控”了。

第二个方向是“整改闭环管理”。目前体检助手输出的是问题清单，整改动作还是靠人工跟进。如果能把问题清单导入到项目管理工具里，给每个问题分配负责人和 deadline，整改完成后把修改后的资料重新跑一遍体检，确认问题清零，就形成了一个完整的闭环。这个扩展对团队协作的价值会非常大。

第三个方向是“多商品批量对比检查”。现在是一次体检 6 份资料和 1 张图，后续可以做成一个商品一个文件夹，批量提交、批量体检、批量输出报告，并且横向对比不同商品之间的共性问题。比如十款商品里有八款都出现了同类违禁词，那就说明是运营团队的共性写作习惯出了问题，需要统一培训纠正，而不仅仅是单个商品修改的问题。

我在实际使用这套方案的过程中一个很深的体会是：大模型在垂直场景下的价值，很多时候不在于它能不能“生成一篇漂亮的文案”，而在于它能不能把一个需要人肉花几个小时去做的机械性检查任务，压缩到几分钟内完成，并且做得比人更全面、更不遗漏。合规体检这件事，恰恰是这种价值的典型体现。如果你手里正好也有一堆商品资料需要自查，不妨按这篇文章的思路试一次，大概率你也会发现一些之前完全没注意到的问题。