在电商运营中，商品评论不仅反映消费者对产品的真实体验，也会直接影响商品转化率和店铺评分。尤其是负面评价，如果不能及时发现和处理，可能持续影响后续消费者的购买决策，也会错过联系消费者、排查商品问题和采取补救措施的最佳时间。

淘系后台本身提供评论数据和评价分析能力，但评论情感标签存在一定延迟。部分新增评论发布后，需要等待几天才能看到平台给出的评价态度。为了解决这个问题，影刀 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": f"Bearer {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
        },
        timeout=30
    )

    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、评论日期、评论内容和订单号等关键信息，方便收到消息后快速定位问题。

发现新的负面评价，请及时处理。

平台：天猫
商品：某某商品
商品 ID：XXXXXXXX
评论日期：2026-07-29
评论内容：使用后没有明显效果
订单号：XXXXXXXX

通知发送完成后，飞书工作流将当前记录的通知状态更新为“已通知”，避免定时任务重复发送同一条差评。

正面评价和中性评价只写入多维表，不触发通知。这样既能保留完整评论数据，也不会让普通评论占用运营注意力。

八、开发过程中遇到的问题

1. 模型回复格式不稳定

Prompt 已经要求只返回固定标签，但模型仍可能增加前缀、标点或解释内容，例如：

判断结果：负面评价

或者：

负面评价，因为产品没有达到预期效果。

如果直接保存模型原始内容，飞书工作流的条件判断可能失效。因此，接口结果必须经过标准化处理，再写入多维表。

2. 接口请求超时

批量处理评论时，偶尔会出现网络波动或接口响应超时。如果没有异常处理，一条评论失败就可能导致整批 RPA 任务中断。

解决方式是设置合理的超时时间，并增加有限次数的重试。连续重试失败后，将当前评论标记为“待人工判断”，保证后续评论仍然能够继续处理。

def classify_with_retry(comment, retry_count=3):
    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 负责执行固定流程，大模型负责处理非结构化文本，业务系统负责承接结果，能够让传统自动化覆盖更多需要语义判断的业务环节。