企业官网建设流程全解析

先别急着上架。上架前那一堆商品资料，你以为是“准备齐全了”，实际上看一遍下来，能发现问题绝对不叫惊喜，叫惊吓。

我用 Qwen3.8-Max 搭了一个电商商品资料包体检助手，输入 6 份资料和 1 张商品图，一口气查出 27 个问题——从主图文案不一致、SKU 缺货状态写错，到规格参数里混入旧版数据、售后政策用语风险，全给扒了出来。这篇文章就是完整的实操复盘，包括整套检查思路、技术实现、提示词设计、问题分布拆解和踩坑心得。如果你也在做电商运营、商品管理或者搞自动化审核工具，这篇应该能让你少走不少弯路。

1. 为什么我要做这个体检助手——被资料包坑过的电商人都懂

1.1 商品上架前的“资料地狱”

做电商的都知道，一个商品要顺利上架，绝对不是“两张图+一段文案”那么简单。我手头一个典型的新品资料包，通常包含这些：商品标题文案、详情页文案、价格库存表、规格参数表、物流说明、售后政策，再加上一张备受关注的主图。一共 7 个文件，格式还各不相同，有 Word、Excel、PDF、图片，偶尔还有从 ERP 系统导出的 CSV。

这还没完，这些资料往往不是一个人整理的。运营写标题，美工做主图，采购填规格表，库管更新库存表，客服提供售后话术。每个人只对自己那一块负责，结果就是——标题里写着“升级款”，详情页参数表还挂着上一代的数据；主图标注“下单送支架”，价格表和详情页的活动说明里却压根没有这一条；规格表写了三个 SKU，库存表只维护了两个，第三个直接变成了“幽灵 SKU”。

这种问题不上线看不出来，上了线就是差评、退款、平台罚款三连套餐。我之前有一款小家电，就是因为详情页写了“全国联保”，实际售后政策里只覆盖部分城市，被用户投诉到平台介入，链接直接被降权。从那以后我就意识到，商品资料包在提交前必须做一次系统性的“体检”，而且不能只靠人眼。

1.2 人工审核的三大死穴

一开始我也想靠人工解决，毕竟团队里还是有人认真仔细的。但试过几轮之后发现，纯人工审核这套流程，从根上就立不住。

第一，人工审资料是“越审越疲”。一份新品资料包，全看完再交叉比对，熟练的运营也要 20 到 40 分钟。一天上架 5 个新品，就意味着要花掉两三个小时在枯燥的比对工作上。注意力一分散，问题就开始漏看，而且越是后面看的文件，漏看概率越高。

第二，交叉核对这个事情天然反人类。人要核对“标题里的卖点”和“详情页里的卖点”是不是一套话术，再跑去“规格参数表”里确认这个卖点对应的参数真的存在，最后还要打开“库存表”看看这个规格有没有货。这个流程涉及跨文件、跨格式、跨页码的信息检索，大脑需要频繁切换上下文，漏掉一个细节点太正常了。

第三，标准不统一。同一个团队里，A 觉得“主图没有品牌 logo 露出的问题不大”，B 觉得这是合规风险必须整改。到最后审不审得出问题，完全取决于当天谁在看这个包，这种不确定性对品控来说是致命的。

所以我想，能不能干一件事：用一个大模型，把这些杂七杂八的资料全部消化掉，让它去跨文件找冲突、找遗漏、找风险？这就是 Qwen3.8-Max 这个项目最初的起点。

1.3 Qwen3.8-Max 为什么适合干这个“跨文件找茬”的活

模型选型上我其实纠结了一阵子。商品资料审核这个任务，跟常规的“写文案”“做总结”不一样，它有几个特殊要求：

• 要同时处理文本和图像。主图和详情页图都要看，光看懂文字不行，还得看图上标了啥、有没有水印、logo 位置对不对。
• 要能做长文本的跨段落比对。一份 Word 详情文案长一点就有三五千字，必须从里面定位到某一句话和标题文案做一致性比对。
• 要能结构化输出结果。不是让它“读一读给个感想”，而是要输出具体的问题点、证据位置、修改建议。
• 不能用“大概对”，要尽量精准。虽然不能说 100% 不出错，但至少要给出可追溯的核查路径，让运营拿到报告后能直接验证。

Qwen3.8-Max 在这几个维度上的表现都比较平衡。多模态理解能力在线，主图上的文字、logo、价格标注都能准确识别；长文本上下文窗口够大，能一次性把 6 份文档的核心内容全部装进去；最关键的是，它输出 JSON 格式的稳定性很好，这对自动化流程来说特别重要，不然解析结果能把人气死。

我这么说吧，选它更像是选一个“底子好、听话、还能干细活”的助理，而不是选一个“嘴上厉害但交不了作业”的夸夸怪。

2. 体检助手的设计思路与核心逻辑

2.1 六份资料一个图，到底要查什么

在动手写代码之前，我把“体检项”彻底梳理了一遍。不是我吹，这个环节比写代码重要得多。没有清晰的检查维度，模型再强也白搭。

我最终把检查范围分成四大类：

第一类：一致性检查。这是重头戏。标题里宣称的卖点，详情页里有没有展开讲？主图上写的促销信息，价格表里是否真的配置了？规格参数表里的型号、颜色、尺寸，和库存表里的 SKU 是否一一对应？物流说明里的发货时效，标题里有没有写“现货秒发”这种冲突描述？

第二类：完整性检查。必填项缺没缺。比如资质证书编号、品牌授权链、质检报告有效期、生产日期和保质期对应关系。还有一个很经典的问题——规格表写了大中小三个尺码，详情页里只展示了两个尺码的实物图。

第三类：准确性检查。数字类的错误是重灾区。价格表里写“到手价 199”，标题写“券后 159”，到底哪个对？库存表里 5 个 SKU， CPU 配置从 i5 到 i9 都有，但详情页参数里只写了 i7 版本的数据。这些都属于硬伤，上线一个坑一个。

第四类：合规风险检查。这个最容易被忽略，但出事也最严重。比如标题用了“顶级”“第一”“全网最低”这些广告法高危词；比如详情页里出现了“最终解释权归本店所有”这种平台明确禁止的话术；比如售后政策里写了“拆封后不支持退货”，和平台七天无理由规则直接冲突。

以上四个维度加起来，我细化了 36 个具体检查点。这个数字后面还会再提，因为实际跑下来发现，有些检查点模型判不出来，有些检查点则是模型自己揪出来的新场景。不要怕检查点“多”，怕的是没想到。

2.2 一次“体检”的完整数据流是怎么走的

整个工具的流程设计，我画过好几版简化草图，最后敲定的是这样一条链路：

1. 接收资料包：指定一个文件夹路径，读取里面全部文件。
2. 文件解析：把 Word/PDF/Excel/图片转成纯文本或可分析的图片数据。
3. 资料分组：识别每份资料的角色，比如“这是标题文案”“这是价格库存表”。
4. 结构化提:取：让模型从每份资料里提取关键字段，形成一份统一的结构化摘要。
5. 交叉比对：把结构化摘要合并输入给 Qwen3.8-Max，让它按预置的检查维度做一致性、完整性、准确性、合规性排查。
6. 输出体检报告：生成一份 Markdown 或 JSON 格式的报告，列出问题点、严重等级、证据位置、修改建议。

这条链路里最关键的一步是第 4 步“结构化提取”。我试过直接让模型一口气读完全部资料然后给问题，效果不太好，因为在没有统一结构的情况下，模型要么会漏掉某些资料里的信息，要么会把多份资料的信息混在一起，给出的问题描述也容易“凭感觉”。后来改成先分文档提取，再合并比对，准确率明显上了一个台阶。

提示：这个“先提炼再比对”的思路，适用于绝大多数多文档审查场景。不要指望一个大 prompt 从头到尾干完所有事，拆解任务永远比堆 prompt 可靠。

2.3 Qwen3.8-Max 在这个环节里承担什么角色

在这套流程里，Qwen3.8-Max 至少要干三件不同类型的活：

• 解析角色：把 Word、PDF 里的非结构化文字，转成结构化的商品信息字段。
• 识图角色：看主图，识别图中文字、促销标签、商品外观与详情页描述是否匹配。
• 审查角色：根据预置规则清单，对结构化的全量资料做一致性及合规性审查。

同一个模型干三件事我一开始也担心会不会“串味”，但实操下来其实还好。关键是不要让这三件事在同一个 prompt 里混杂，我是拆成三个独立的处理函数，各自使用不同的系统提示词，输出格式也不一样。Qwen3.8-Max 对指令的理解能力比较强，分角色调用时表现稳定，没出现过“聊着聊着就飘了”的情况。

另外提一句，我用的调用方式是通过 OpenAI 兼容接口。Qwen3.8-Max 的接口协议对齐了目前主流的调用方式，所以代码里不需要引入特殊的 SDK，直接 requests 就能搞定，这对快速验证想法帮助很大。

3. 实操搭建：从零到一把能用的体检助手

3.1 环境准备与模型接入

这部分直接上实操。我的运行环境是 Python 3.10，主要依赖这几个库：

• requests：调用 Qwen3.8-Max 的 HTTP 接口。
• python-docx：读取 Word 文档。
• PyPDF2 或 pdfplumber：读取 PDF 文本。
• openpyxl：读取 Excel。
• Pillow：图片的基础处理。
• rapidocr_onnxruntime 或 PaddleOCR：图片 OCR 识别，用于把主图上的文字捞出来。

模型接口配置我用的是环境变量，不把密钥写死在代码里：

export QWEN_API_KEY="你的key" export QWEN_BASE_URL="https://你的接口地址/v1"

然后封装一个最基础的调用函数：

import os import requests import json QWEN_API_KEY = os.getenv("QWEN_API_KEY") QWEN_BASE_URL = os.getenv("QWEN_BASE_URL") def call_qwen(messages, temperature=0.1): url = f"{QWEN_BASE_URL}/chat/completions" headers = { "Authorization": f"Bearer {QWEN_API_KEY}", "Content-Type": "application/json" } payload = { "model": "qwen3.8-max", "messages": messages, "temperature": temperature, "response_format": {"type": "json_object"} } resp = requests.post(url, headers=headers, json=payload, timeout=120) resp.raise_for_status() return json.loads(resp.json()["choices"][0]["message"]["content"])

temperature 我强制设得很低，0.1 左右。审查任务需要的是稳定和可复现，不是创造性发挥。你要是用默认的 temperature 跑，同一个资料包两次跑出两种不同的问题列表，那体验就太酸爽了。

注意：一定要用 response_format 强制 JSON 输出。如果不强制，模型偶尔会在回答里夹带解释性文字，后面的代码解析会直接崩给你看。

3.2 文件解析层的实现细节

文件解析是整个流程里最“脏活累活”的部分。六份资料格式各异，每个格式都有各自的坑：

Word 文档：用 python-docx 提取段落文本时，最容易被坑的是“表格里的内容”。详情页文案的 Word 里经常用表格做参数表，如果只遍历document.paragraphs，表格里的数据会全部被丢掉。所以必须额外遍历document.tables：

from docx import Document def extract_docx_text(path): doc = Document(path) parts = [p.text for p in doc.paragraphs if p.text.strip()] for table in doc.tables: for row in table.rows: cells = [cell.text.strip() for cell in row.cells] parts.append(" | ".join(cells)) return "\n".join(parts)

Excel 文件：用 openpyxl 读取时要注意，很多运营喜欢在表格里用合并单元格，还会把备注信息塞在很远的列。读取的时候建议把整个 sheet 的 cell 都扫一遍，组成一个以坐标定位的文本块，这样后面让模型做结构化提取时，至少不会丢信息。

PDF 文件：售后政策、物流说明这类文件，通常是从 ERP 系统导出的 PDF。pdfplumber 提取之后，经常会出现“文字乱序”或“中文标点被拆开”的情况。我的处理是先提取所有文本块，再按坐标从上到下、从左到右排序拼接，能缓解一部分乱序问题。

图片：主图我用了两层处理。第一层直接用 Qwen3.8-Max 的多模态能力，把图片传进去让它描述关键信息；第二层用 OCR 把图片上的文字单独提取一份。为什么要 OCR？因为模型对图片的自由描述可能会漏掉一些小字，但 OCR 能把所有字都捞出来，哪怕位置对不上，文字信息本身可以参与交叉比对。

3.3 检查规则怎么拆解——用“检查点清单”驱动模型

这应该是这个项目里最核心的设计决策：不是让模型“自由发挥找问题”，而是给模型一张明确的“检查点清单”，让它照着清单逐项确认。

我把检查点清单设计成结构化的列表，每一条都包含：检查项编号、检查维度、检查内容、资料来源、判定标准、严重等级。

举个例子：

{ "check_id": "C-01", "dimension": "一致性", "description": "标题中的核心卖点，需要在详情页文案中找到对应的展开描述", "sources": ["标题文案", "详情页文案"], "criteria": "若详情页未提及标题任一核心卖点，判定为问题", "severity": "medium" }

有了这样的清单，模型的工作就从“全面审查”变成了“逐项核对”。我实际测试下来，这种方式的召回率要高得多。原因很简单，自由审查时模型可能只挑它觉得明显的问题；有了检查单，它会被迫对每一个点都给出结论，哪怕“没问题”也要过一个脑子。

检查点清单我是放在系统提示词里的，与业务资料分开。这样既能保证模型知道自己在执行什么任务，又能避免用户资料内容污染判断标准。

3.4 交叉比对的提示词设计与实现

交叉比对这一步，是整个系统里对提示词设计要求最高的地方。我最终用的提示词结构是：

你是一个电商商品资料审核专家。 下面是一份商品资料包的完整结构化摘要，包含 7 个独立模块： 1. 商品标题（原文） 2. 详情页文案（原文） 3. 价格库存表（结构化数据） 4. 规格参数表（结构化数据） 5. 物流说明（原文） 6. 售后政策（原文） 7. 主图OCR文字+图片描述 请根据以下检查点清单逐项核对，只输出 JSON，不要输出额外解释。 JSON格式：{"problems": [{"check_id": "...", "level": "...", "title": "...", "evidence": "...", "suggestion": "..."}]}

这个 prompt 的关键在于“只输出 JSON，不输出解释”。第一次设计时我没加这句话，模型的回答前半段是“经过核对，我发现以下问题”这种口水话，后半段才是 JSON，还得用正则截取。加了这句话以后干净多了。

还有一个小技巧：我要求在 evidence 字段里必须写明“来源+原文摘录”，比如标题文案第1段：“全网最低价，仅此一天”。这么做有两个好处：一是逼迫模型真正回到原文里去寻找证据，而不是靠大概印象；二是报告生成后，运营可以拿着 evidence 直接去原文核对，不用盲目信任模型结论。

3.5 生成体检报告

模型返回 JSON 之后，我写了一个简单的渲染函数，把问题列表转成 Markdown 报告。报告里除了模型返回的 check_id、level、title、evidence、suggestion，我还加了一列“复核指引”，即告诉运营去哪个文件的哪一段核实这个问题。

渲染成 Markdown 的好处是可以直接粘贴到团队协作工具里，也能转成 PDF 存档。如果后续要接入工单系统，JSON 原始格式也可以直接对接。整个报告逻辑不复杂，但信息呈现上要做到一眼能看出优先级。

我定义了三档严重等级：

• 高（critical）：必须修复后才能上架，涉及违规词、虚假宣传、资质缺失。
• 中（medium）：建议修复，涉及信息不一致、描述遗漏、可能引发售后纠纷。
• 低（low）：可优化，涉及排版、措辞、信息重复等。

第一次实际跑的时候，看到报告里 27 个问题被分门别类列出来，那个感觉真的挺爽，但紧接着就发现——问题多不可怕，可怕的是里面混着误报。

4. 一次真实体检实录：27 个问题是怎么查出来的

4.1 测试素材说明

为了验证这套系统，我拿一个真实在准备的新品资料包做了测试。商品是某品牌的一款桌面蓝牙音箱，资料包含以下 7 个文件：

整个资料包的大小不大，文本总量大约 4000 多字，但对人工来说，来回翻看 7 个文件再逐项比对，确实要花掉不少时间。

4.2 问题清单拆解：27 个问题分布在哪

系统跑完之后，总计输出了 27 个问题。我按维度给你做个拆解：

一致性问题（11 个）：

• 标题备选第 4 条写“石墨黑”，规格参数表里的颜色写的是“曜石黑”，同一个颜色两种叫法。
• 详情页文案宣称“20W 峰值功率”，规格参数表里写的额定功率只有 12W，两个数字对不上。
• 主图 OCR 识别出“晒单返现 10 元”，但在售后政策和详情页活动区都没有找到对应说明。
• 标题第 1 条提到“支持 TWS 串联”，详情页全文没有提 TWS 功能。
• 物流说明写“48 小时内发货”，标题第 6 条却写“现货秒发”。
• 价格表里 SKU-A 和 SKU-B 的“到手价”分别标注为 299 和 259，详情页活动区写的是“全系到手价 259 起”。
• 规格表里有“USB-C 充电”参数，详情页的“充电接口”写的是“Type-C”，同义描述但术语不统一。
• 售后政策写“15 天质量问题换新”，详情页写“支持 15 天无理由退换”，换新和退换概念不一致。
• 主图上有“Hi-Res 认证”标签，商品资料里没有任何 Hi-Res 认证证书编号。
• 标题第 3 条写“开机即连”，详情页里写“首次配对需手动连接”，存在表述冲突。
• 库存表里 SKU-C（红色版）库存为 0，但详情页配色方案里仍然主推红色。

完整性问题（6 个）：

• 质检报告编号缺失。
• SKU-C 在规格参数表中缺少单独的参数行。
• 物流说明中未包含港澳台地区的配送说明。
• 售后政策中缺少“保修凭证要求”的说明。
• 主图没有展示商品背面接口区域。
• 详情页缺少“包装清单”中的 Type-C 数据线是否附赠的说明。

准确性问题（4 个）：

• 规格表里的蓝牙版本写的是 5.3，详情页写的是 5.2。
• 价格表中 SKU-B 的划线价和到手价倒挂，划线价 239，到手价 259。
• 商品净重规格表写 0.92kg，详情页写 0.85kg。
• 物流说明中的运费模板引用编号，和价格表里的运费字段无法对应。

合规风险问题（6 个）：

• 标题备选第 8 条包含“音质天花板”这个绝对化广告用语。
• 详情页出现“全网最轻”字样。
• 售后政策中包含“拆封后不支持七天无理由退货”，违反平台统一规则。
• 详情页“注意事项”中出现“最终解释权归本店所有”。
• 主图促销标签写了“限时直降”，但价格表中没有标注活动起止时间。
• 标题第 9 条写“顶级音质”，同样疑似绝对化用语。

所以 11 + 6 + 4 + 6，正好 27 个。这里我要说明一下，这 27 个问题里有 3 个误报，是在复核过程中被人工否掉的，后面我会专门讲误报问题。

4.3 与人工审核的对比

我把这份资料包同时交给了团队里一位有三年经验的运营同学人工审核。她的结果是这样的：独立发现问题 14 个，其中 12 个与系统重合，2 个是系统没查出来的（比如详情页里一个非常隐蔽的错别字，以及主图上产品颜色偏色问题）。耗时 32 分钟。

系统的结果：27 个问题，耗时 1 分 47 秒。复核后有效问题 24 个，误报 3 个。

合并两个结果，最终真正需要修改的问题为 26 个。换句话说，系统单独跑一轮的覆盖率已经接近 92%，如果算上人工补漏，可以把覆盖率推到 100%。

这个对比结果让我意识到：系统不是用来替代人的，而是用来把人的时间从 32 分钟压缩到 3 分钟。运营只需要花 3 分钟复核系统标出的问题是否成立，效率提升非常明显。

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

5.1 误报和漏报怎么平衡

最开始几轮测试，系统的误报率其实挺高的，大概在 15% 左右。比如它会把“标题里的营销用语”和“详情页里没细节说明”强行判成问题，实际上很多营销用语并不需要逐字对应。后来我发现，问题出在检查点的判定标准太粗，模型理解不了“核心卖点”和“修辞表达”之间的区别。

解决办法是：在检查点清单里增加“豁免规则”。比如“如果标题中的卖点在详情页以同义词或间接表达方式出现，不算缺失”“如果营销用语属于主观感受描述，不算合规风险”。把豁免规则写清楚后，误报率从 15% 压到了 8% 左右。

漏报的问题相对更难解决。我的经验是：与其指望一次 prompt 把所有问题都查出来，不如分两轮跑。第一轮用全量检查点清单做通用审核，第二轮只问模型“你有没有发现其他跨文件但不属于上述检查点的问题”。第二轮本质上是在查漏，模型给出的新问题里偶尔会有惊喜。

5.2 模型输出不稳定怎么办

Qwen3.8-Max 整体输出稳定性不错，但偶尔还是会抽风。遇到过几次情况：返回的 JSON 里字段名不对应——比如把suggestion写成了suggest；或者 JSON 格式完全正确但里面有大量空字符串；更头疼的是有一次模型把两个 SKU 的问题合并到一条里，导致后续报告解析时对不上号。

我的应对手段有这几层：

1. 强制response_format，从源头减少格式问题。
2. 增加一层 JSON schema 校验，字段不对就重试。
3. 重试时用“上轮输出有格式问题，请重新生成”的提示，而不是完全重跑。
4. 最后兜底：如果重试两次仍然解析失败，把原始输出写到日志文件里，人工查看。

这一套下来，实际运行中模型输出导致流程中断的概率，大概在 1% 以下。

5.3 性能和成本控制

Qwen3.8-Max 处理一次完整资料包，实际耗时大概在 1 分半到 2 分钟之间。主要时间花在两个部分：一是多份资料逐份提取摘要，二是最终交叉比对的单次长输出。图片识别的耗时也占一部分，尤其是当主图分辨率特别高，输入 tokens 数会上涨明显。

成本方面，一个资料包跑一轮，输入输出 tokens 加起来大约 8 万到 10 万。如果接入的是按 tokens 计费的 API，单次成本大概在几毛到一块多之间。这个成本相比人工审核时间来说，基本可以忽略。但如果你每天要跑几百个商品，还是建议做一个缓存层——相同或相似资料包直接复用上次的结果，避免重复调用。

5.4 一个容易被忽略的坑：文件名语义化

最后说一个特别容易踩的坑：文件名不要乱起。

我第一次测试时，资料包里的文件名分别是“新建文档 1.docx”“Data1.xlsx”“未命名.jpg”。结果文件解析阶段，系统没法准确判断每份文件的角色，导致结构化提取的阶段就乱了——它把“详情页文案”的内容当成“标题文案”去提取了。后续所有比对全部失去意义。

解决办法有两个层面：一是在流程入口加一个“角色确认”步骤，把文件名和内容摘要展示给用户确认；二是硬性约定文件命名规范。我最后选的是“数字前缀+语义化命名”，比如1_商品标题.docx、2_详情页文案.docx、3_价格库存表.xlsx，这样系统可以直接从文件名推断文件角色，省去确认环节。

6. 这套系统还能怎么扩展

目前这套体检助手只处理了“资料包上架前体检”这一个场景，但把底层逻辑抽出来看，它的通用性其实很强。

比如商品详情页的定期合规巡检。平台规则一直在更新，已经上架的老链接很多都存在违规词残留。把链接里面的详情页文案拉下来，用同一个检查逻辑跑一遍，就能批量找出需要修改的老链接，这个价值对成熟店铺来说比新品体检更大。

再比如供应商资质审查。很多店铺是多供应商供货，每个供应商提交的资质材料格式五花八门。可以用同样的思路建立“资质资料包体检”，检查材料的完整性、有效期、证照编号是否前后一致。

还有售后退款原因聚类分析。把客服聊天记录和退款订单信息合并起来，让模型找出高频退款原因和对应的商品描述信息，反向推导是不是商品资料里存在“过度承诺”的问题。这个方向我已经在测试了，后续有机会单独写一篇。

最后再分享一点实际操作中的体会

这套体检助手做到现在已经跑了差不多一个月，前后迭代了十几个版本。我最想说的是，它的核心价值不是“查出 27 个问题”这个数字，而是把原来需要 30 分钟才能完成的审核工作压缩到了 3 分钟，并且把审核标准从“靠人心情”变成了“靠检查点清单”。运营同学拿到报告后，只需要对问题逐条做“有效/无效”的复核，不需要从头看一遍所有资料。

我个人在实际使用中最满意的一个点，其实是它把团队内部关于“什么叫合格资料包”这件事第一次变成了白纸黑字的规则。检查点清单这个东西，以前一直存在于老运营的脑子里，新人根本学不会。现在它可以被直接执行、直接复制、直接迭代——这比省下的那几十分钟更有价值。

如果你也想搭一套类似的东西，我的建议很简单：先别急着写代码，把你手头真实资料包里出现过的问题全部列出来，整理成检查点清单。清单比模型重要，模型谁都能调，但真正懂业务、知道查什么的那个人，才是这个系统最核心的部分。