在电商运营中商品评论不仅反映消费者对产品的真实体验也会直接影响商品转化率和店铺评分。尤其是负面评价如果不能及时发现和处理可能持续影响后续消费者的购买决策也会错过联系消费者、排查商品问题和采取补救措施的最佳时间。淘系后台本身提供评论数据和评价分析能力但评论情感标签存在一定延迟。部分新增评论发布后需要等待几天才能看到平台给出的评价态度。为了解决这个问题影刀 RPA 每天自动抓取昨日新增评论再调用DeepSeek-V4-Flash判断评论的情感倾向。分类结果统一写入飞书多维表由飞书工作流定时检查。当发现负面评价时自动向运营发送通知。整套流程可以概括为影刀 RPA 负责评论采集和流程执行DeepSeek 负责文本理解飞书多维表负责数据沉淀飞书工作流负责差评通知。一、为什么没有使用关键词规则评论分类最容易想到的方案是根据关键词判断是否属于负面评价。例如当评论中出现“不好用”“质量差”“失望”“漏水”“破损”“不推荐”等词语时直接标记为负面评价。这种方案实现简单执行速度快也不会产生额外的接口费用。但在实际评论中消费者的表达方式非常复杂关键词规则很容易出现误判。例如本来以为不好用结果使用以后感觉非常不错。评论中出现了“不好用”但整句话表达的是正面态度。如果只根据关键词匹配这条评论就会被错误标记为负面评价。再比如包装没有破损密封也很好。虽然出现了“破损”但实际表达的是包装完好。否定关系一旦没有处理好分类结果就会完全相反。关键词规则还存在覆盖不完整的问题。很多负面评论并不会直接出现“差”“不好”“失望”等明显词语例如使用一次后就闲置了 和宣传内容不太一样 这个价格感觉不太值 客服处理问题的态度一般 宝宝一直不愿意使用这些内容已经表达出不满但很难依靠一套固定关键词准确识别。随着评论数量和商品类型增加关键词库需要不断补充否定词、转折词和商品场景也要增加额外规则后期维护成本会越来越高。部分词语在不同商品场景中还可能表达完全不同的含义。例如“太小了”可能是在抱怨尺寸也可能是在称赞产品小巧、方便携带。单纯根据某个词语很难判断评论的真实态度。因此评论情感分类更适合使用能够理解上下文、否定关系和整体语义的大语言模型。二、为什么选择大模型评论情感判断本质上是一个短文本分类任务。输入是一条消费者评论输出只需要保留正面评价、中性评价或负面评价三个标签。相比关键词规则大模型能够结合整句话判断评论的主要情绪。例如虽然物流有点慢但是产品效果很好。这条评论同时包含负面描述和正面描述。关键词规则可能因为“慢”将其判断为负面评价大模型则可以结合转折关系识别出评论主要是在肯定产品效果。实际评论中还存在大量没有明显褒贬态度的内容例如已经收到暂时还没有使用。 一般后续再看看。 还行没有特别明显的感觉。这类评论不适合强行归入正面或负面因此最终采用三分类正面评价 中性评价 负面评价正面评价用于记录明确的满意、认可和推荐中性评价用于记录“一般”“还行”“已收到”“暂未使用”等没有明显情绪倾向的内容负面评价用于记录产品质量、使用效果、包装、物流或服务方面的不满。三分类能够减少中性评论被误判为负面评价的情况也能避免飞书工作流产生过多无效提醒。三、为什么选择 DeepSeek-V4-Flash评论情感分类不需要生成长篇内容也不需要复杂推理。模型选型主要关注响应速度、调用成本、中文理解能力、输出稳定性以及是否适合高频短文本处理。DeepSeek-V4-Flash响应速度较快调用成本较低比较适合这种评论内容短、调用次数多、返回结果固定的任务。每条评论通常只有几十个字模型最终只需要返回一个分类标签单次请求消耗的 Token 很少。为了进一步减少输出消耗同时限制模型输出多余解释最大输出 Token 数设置为 4。当前分类标签均为四个汉字正面评价 中性评价 负面评价实际接入时需要先测试当前模型和接口网关的分词情况。如果出现标签被截断可以将最大输出 Token 调整为 6 或 8。相比极限压缩几个 Token分类结果完整和稳定更加重要。四、Prompt 如何设计这个场景中的 Prompt 不需要写得很长但需要明确分类标准和输出格式。提示词过于简单时中性评价和混合情绪容易出现不稳定结果提示词过长又会增加输入 Token 和维护成本。实际使用的系统提示词如下判断电商评论的整体情感倾向只回复以下一个标签 正面评价 中性评价 负面评价 判断标准 1. 明确表达满意、认可、推荐或效果良好返回“正面评价”。 2. 没有明显褒贬倾向或仅表达一般、还行、已收到、暂未使用返回“中性评价”。 3. 明确表达不满、失望、产品问题、质量问题、效果问题或服务问题返回“负面评价”。 4. 同时包含正面和负面内容时以整条评论的主要态度为准。 5. 只返回分类标签不要解释不要添加其他内容。评论原文直接作为用户消息传入模型。完整调用代码如下import os import time import requests API_URL https://api.deepseek.com/chat/completions API_KEY os.getenv(DEEPSEEK_API_KEY) SYSTEM_PROMPT 判断电商评论的整体情感倾向只回复以下一个标签 正面评价 中性评价 负面评价 判断标准 1. 明确表达满意、认可、推荐或效果良好返回“正面评价”。 2. 没有明显褒贬倾向或仅表达一般、还行、已收到、暂未使用返回“中性评价”。 3. 明确表达不满、失望、产品问题、质量问题、效果问题或服务问题返回“负面评价”。 4. 同时包含正面和负面内容时以整条评论的主要态度为准。 5. 只返回分类标签不要解释不要添加其他内容。 .strip() def normalize_result(content): 将模型返回内容转换为固定标签。 if not content: return 待人工判断 content content.strip() if 负面评价 in content: return 负面评价 if 中性评价 in content: return 中性评价 if 正面评价 in content: return 正面评价 return 待人工判断 def classify_comment(comment): 调用 DeepSeek 完成评论情感分类。 comment str(comment or ).strip() if not comment: return 无有效内容 response requests.post( API_URL, headers{ Authorization: fBearer {API_KEY}, Content-Type: application/json }, json{ model: deepseek-v4-flash, messages: [ { role: system, content: SYSTEM_PROMPT }, { role: user, content: comment } ], temperature: 0, max_tokens: 4, stream: False }, timeout30 ) response.raise_for_status() result response.json() choices result.get(choices, []) if not choices: return 待人工判断 content ( choices[0] .get(message, {}) .get(content, ) ) return normalize_result(content)temperature设置为 0主要用于降低输出随机性让同一条评论尽可能得到稳定结果。即使 Prompt 已经要求模型只返回固定标签程序中仍然需要进行结果校验。大模型偶尔可能返回“判断结果负面评价”或者在标签后补充解释。如果未经处理就直接写入飞书多维表工作流中的条件判断可能无法正常命中。标准化处理后无论模型返回的是“负面评价”“判断结果负面评价”还是“负面评价因为产品没有达到预期”最终写入多维表的内容都统一为“负面评价”。五、评论数据如何采集评论数据由影刀 RPA 从淘系后台自动采集。自动化任务每天定时运行进入评价管理页面筛选昨日新增评论再依次读取页面中的评论数据。根据当前飞书多维表的字段设计主要采集以下内容商品 ID 评论日期 评价内容 所属订单号 所属产品 所属平台 备注影刀 RPA 读取一条评论后先判断评论内容是否为空再调用 Python 脚本完成情感分类。模型返回结果经过标准化处理后写入当前数据的“评价态度”字段。商品 ID 和订单号是后续数据关联的重要字段。商品 ID 可以关联销售数据、退款数据、商品负责人和商品日报订单号则方便运营在收到通知后快速定位具体订单。部分订单只有评分没有文字评论平台可能显示“此用户未填写评价内容”。这类内容没有实际分析价值可以在调用模型前直接过滤避免产生无意义的接口请求。EMPTY_COMMENTS { , 此用户未填写评价内容, 用户未填写评价内容, 默认评价 } def is_empty_comment(comment): comment str(comment or ).strip() return comment in EMPTY_COMMENTS六、如何写入飞书多维表完成情感分类后影刀 RPA 将评论数据统一写入飞书多维表。当前“昨日评论数据”视图中包含商品 ID、评论日期、评价态度、评价内容、所属订单号、所属产品、所属平台和备注等字段。评价态度字段保存 DeepSeek 的分类结果正面评价 中性评价 负面评价 待人工判断 无有效内容正面、中性和负面评价属于正常分类结果待人工判断用于保存接口异常、空返回或格式无法识别的数据无有效内容用于保存没有评论正文的记录。飞书多维表不仅用于展示昨日评论也承担数据沉淀和后续协作的作用。通过评价态度、评论日期、商品 ID、所属产品和所属平台等字段可以快速筛选某一天、某个平台或某个商品的评论情况。如果需要继续完善差评处理闭环还可以增加处理状态、通知状态、运营负责人、通知时间、处理时间和处理结果等字段。处理状态可以设置为待处理 处理中 已处理 无需处理通知状态可以设置为未通知 已通知 通知失败这样不仅可以完成差评提醒还可以记录后续是否已经处理避免通知发送后没有进一步跟进。七、如何实现差评通知评论数据写入飞书多维表后飞书自动化工作流定时检查新增记录。工作流只筛选评价态度为负面评价、处理状态为待处理、通知状态为未通知的数据。满足条件后自动向对应运营发送飞书消息。通知内容保留平台、商品、商品 ID、评论日期、评论内容和订单号等关键信息方便收到消息后快速定位问题。发现新的负面评价请及时处理。 平台天猫 商品某某商品 商品 IDXXXXXXXX 评论日期2026-07-29 评论内容使用后没有明显效果 订单号XXXXXXXX通知发送完成后飞书工作流将当前记录的通知状态更新为“已通知”避免定时任务重复发送同一条差评。正面评价和中性评价只写入多维表不触发通知。这样既能保留完整评论数据也不会让普通评论占用运营注意力。八、开发过程中遇到的问题1. 模型回复格式不稳定Prompt 已经要求只返回固定标签但模型仍可能增加前缀、标点或解释内容例如判断结果负面评价或者负面评价因为产品没有达到预期效果。如果直接保存模型原始内容飞书工作流的条件判断可能失效。因此接口结果必须经过标准化处理再写入多维表。2. 接口请求超时批量处理评论时偶尔会出现网络波动或接口响应超时。如果没有异常处理一条评论失败就可能导致整批 RPA 任务中断。解决方式是设置合理的超时时间并增加有限次数的重试。连续重试失败后将当前评论标记为“待人工判断”保证后续评论仍然能够继续处理。def classify_with_retry(comment, retry_count3): for index in range(retry_count): try: return classify_comment(comment) except Exception as error: print(f第 {index 1} 次调用失败{error}) if index retry_count - 1: time.sleep(2 ** index) return 待人工判断重试次数不宜无限增加。接口持续异常时无限重试只会延长任务执行时间还可能导致当天评论无法全部处理。3. 接口返回空结果部分情况下请求返回成功状态但choices为空或者message.content没有内容。HTTP 状态码为 200只能说明请求已经完成并不能保证一定存在有效分类结果。因此choices、message和content都需要进行校验。无法获得有效标签时统一返回“待人工判断”不能直接默认为中性评价或负面评价。4. 重复采集评论影刀任务重跑、页面翻页异常或日期边界处理不准确都可能导致相同评论被重复采集。重复数据不仅会增加模型调用成本还可能导致同一条负面评价被重复通知。可以根据平台、订单号、商品 ID、评论日期和评论内容生成唯一标识。写入飞书前先检查唯一标识是否已经存在重复记录直接跳过。import hashlib def generate_comment_id( platform, order_id, product_id, comment_date, comment ): raw_value |.join([ str(platform), str(order_id), str(product_id), str(comment_date), str(comment) ]) return hashlib.md5( raw_value.encode(utf-8) ).hexdigest()去重最好放在调用模型之前这样可以同时避免重复计费、重复写入和重复通知。5. 中性评价边界不清晰“还行”“一般”“刚收到”“暂时没有使用”等评论没有明确的满意或不满情绪。如果只进行正面和负面二分类这些内容很容易被强行归入某一类。增加中性评价后评论分类更加符合实际情况也减少了普通评论误触发差评通知的问题。Prompt 中需要明确中性评价的典型表达否则模型可能在正面和中性之间产生波动。6. 讽刺和混合情绪仍然存在误差部分评论表面包含正面词语实际表达的是讽刺质量真不错使用一天就坏了。还有部分评论同时包含优点和缺点产品效果不错但是包装破损比较严重。大模型对这类评论的判断能力通常优于关键词规则但仍然无法保证百分之百准确。对于无法稳定分类的内容可以保留“待人工判断”状态避免错误结果直接触发后续流程。九、成本和速度怎么样评论内容通常较短Prompt 也相对固定模型只需要返回一个四字标签因此单次调用的 Token 消耗很低。相比运营每天进入多个店铺后台逐条查看评论接口成本处于可接受范围。成本控制的重点并不是继续压缩一两个输出 Token而是避免无效调用。空评论不提交模型重复评论不重复分类已经完成分类的数据直接复用接口失败只进行有限次数重试这些措施比单纯降低max_tokens更有效。在每天几十条或几百条新增评论的情况下逐条调用已经能够满足业务需求。整体耗时主要集中在页面加载、网络请求和飞书数据写入模型生成标签本身占用的时间并不长。如果后续评论量增长到每天数万条逐条串行调用的效率会明显下降。届时可以考虑并发请求、批量写入、接口限流、失败队列和结果缓存。当前业务量级下过早引入复杂架构只会增加开发和维护成本。十、最终效果流程上线后评论处理方式发生了明显变化。原有方式需要等待淘系平台生成情感标签再由运营进入不同店铺后台查看评论人工筛选负面评价后进行处理。整个过程依赖人工主动检查也受到平台分析延迟的影响。改造后影刀 RPA 每天自动抓取昨日评论DeepSeek 完成正面、中性和负面三分类结果统一写入飞书多维表。飞书工作流发现负面评价后自动发送消息通知运营。差评发现不再依赖平台几天后的分析结果运营也不需要反复进入后台检查。评论产生后的第二天即可进入内部处理流程负面评价能够更早暴露处理状态也可以在飞书多维表中持续跟踪。多维表中沉淀的评论数据还可以继续用于商品问题统计、不同平台评价对比、负面原因分类和处理时效分析。随着数据逐渐积累后续可以进一步增加质量问题、效果问题、包装问题、物流问题和服务问题等二级分类。十一、总结这套方案并没有让大模型生成复杂内容而是将大模型放在传统规则难以处理的文本判断环节。影刀 RPA 擅长页面操作、数据采集和流程执行但不擅长理解自然语言DeepSeek 擅长理解评论语义但无法独立完成后台采集、数据写入和消息通知飞书多维表负责保存结构化数据飞书工作流负责条件判断和通知触发。几个工具组合后形成了从评论采集、情感分类、数据沉淀到差评通知的完整流程。真正解决的问题也不只是评论分类而是淘系情感分析存在延迟、负面评价发现不及时以及评论处理过程缺少统一记录。同样的处理方式还可以复用到退款原因分类、客服工单分类、用户意图识别、售后问题归类和商品问题提取等场景。RPA 负责执行固定流程大模型负责处理非结构化文本业务系统负责承接结果能够让传统自动化覆盖更多需要语义判断的业务环节。