UGC 评论的 AI 分诊：把每天 1,400 条品牌提及压到 87 条人工审核

我们把每天 1,400 条品牌提及的人工审核量压到了 87 条。诀窍不是更聪明的审核员,而是在人工看到之前,先把大部分队列删掉。

大多数团队把 UGC（User-Generated Content, 用户生成内容）审核做反了。他们先招人,写一份 40 条的审核手册,培训审核员两周,然后三个月内队列翻倍。等到品牌在审核团队上花了六位数工资,领导层才会开始问:"AI 怎么还没搞定?"——AI 能搞定,但你得让 AI 干的不是审核员的活,而是"删掉审核员要干的活"。

真正能跑起来的模式是三层分诊(triage):路由——评论一落地就分桶;打标——把有风险信号的挑出来;升级——只把"人必须看的"那部分推给人工。其余的全部走自动归档、定时回复、或者礼貌的模板回复。

下面是具体的工作流。

第一步:按意图路由,而不是按长度

第一个错误是按"长度"做审核。长评论不是高风险,只是长。正确的维度是意图——这个人到底想干嘛?

我用一次 GPT-4o-mini 调用给每条评论分类,标签集是固定的。五个标签覆盖实际场景里约 96% 的品牌提及:

• praise —— 正面情绪,没有提问
• question —— 需要回答(产品、客服、价格)
• complaint —— 不满,可能公开
• crisis —— 法律威胁、安全问题、有病毒传播风险
• noise —— 垃圾、机器人、跑题、表情

Prompt 要短,这是故意的。大约 80 个 token,每个类给三个标注过的示例。Prompt 一长,模型就开始"表演深思",而不是做分类。让它傻一点;价值在于标签的互斥和穷尽(mECE, mutually exclusive and collectively exhaustive)。

实际的 prompt 结构,贴出来供参考:

你把品牌提及分成以下五类之一:
praise, question, complaint, crisis, noise。

定义:
- praise: 正面情绪,无提问
- question: 需要回答(产品、客服、价格)
...

示例:
"超爱这个品牌" → praise
"X 配 Y 能用吗?" → question
"物流三周才到,不开心" → complaint
"你们产品烫伤我了,要联系 FDA(食品药品监督管理局)" → crisis
"看我主页 🔥🔥" → noise

返回 JSON: {"intent": "", "action_required": }

注意 JSON 输出。强制结构,绝不让模型自由发挥。action_required 字段在同一次调用里就出来了——它是个便宜的二级信号,配合 intent 就能驱动下面的路由表,不用再调一次模型。

分桶完成后,每个桶的去向不一样:

意图	去向	SLA(服务等级协议)
praise	自动归档 + 每周高光报告	无
question	模板回复 + 进入队列	4 小时
complaint	人工审核	1 小时
crisis	值班审核员 + Slack 告警	15 分钟
noise	自动归档	无

一条"爱这个品牌"的提及,不应该占用和"你们产品让我孩子起疹子了"一样的审核注意力。路由这一步就是实现这个的关键。

第二步:叠在意图之上的风险打标

意图决定它进哪个房间,风险决定它坐哪个椅子。两者是不同信号,而且相乘。

第一层打标是 OpenAI Moderation API(免费,每次约 50ms)。每条评论都过一遍,不分意图。它能挡住显而易见的东西——仇恨言论、色情、自残——你不用想这层。我们这套流程里,光这一层就把 12-15% 的评论从人工审核中剔掉了,完全不用训模型。

第二层是一个自定义的 GPT-4o-mini 评分器,专门看"危机形状"的语言。比如:

• "律师"、"起诉"、"举报"
• "我遇到过"、"我女儿"、"不安全"
• 具体的监管机构名(美国 FDA 食品药品监督管理局,中国的 NMPA 国家药品监督管理局,等等)
• 截图或外部链接

只要触发任意一条,无视第一步的判断,直接升级到 crisis。意图分类是噪声大的单次读数,风险打标是 yes/no 的门。不要让一个模型同时决定两件事。

第三层是品牌专属词表。训一个小查表(Python 字典,不是模型),装上对你业务真正重要的词:产品 SKU(Stock Keeping Unit, 库存单位)、竞品名、内部代号、监管相关短语。字面字符串匹配比问 LLM(Large Language Model, 大语言模型)"X 产品里的同款成分"指不指你的 X 产品,要快得多、也审得过。

三层加起来,总共 ~150ms 的延迟(modest delay, 适度延迟)。一条评论在被推入队列之前,已经完成了分桶、筛选、风险评分。

第三步:只升级"人必须看"的

这是团队最容易过度投入的地方。本能是把 complaint 和 crisis 桶里的全部推给人工。不要。"你们物流太慢"和"你们物流太慢,我会在每个平台都留一星差评"不是一回事。

在分类里加第四个标签:action_required: yes/no。Prompt 检查:明确的诉求、截止日期式语言、公开威胁、具名的第三方、或者监管相关语言。一条都不命中,这条 complaint 就走模板致谢("感谢反馈,我们的团队会跟进"),进每日摘要,而不是实时队列。

结果是实时队列小得多。过去的 90 天:每天 1,400 条提及中,1,060 条自动归档,240 条走模板回复,87 条进人工,13 条触发值班危机通道。**人工团队每天看的是 87 条,不是 1,400 条。**真正需要人的那批,中位响应时间从 9 小时降到了 38 分钟。

如果你的队列规模和六个月前一样,你其实没有部署 AI。你只是给一个原本不需要的流程加了个 AI,然后让老流程继续并行跑着。

我实际在用的工具栈

说句实在话,工具都不稀奇:

• Mention 或 Brand24 做源采集(每平台一条评论,统一格式)
• OpenAI Moderation API 做第一道过滤(免费,可批量)
• 通过 OpenAI API 调 GPT-4o-mini 跑意图分类和风险评分(输入 token 大约 0.15 美元/百万,我们这个体量整套下来每月不到 50 美元)
• n8n 做编排——一个 webhook、三次 API 调用、一条 Slack、一行 Notion,这就是全部活
• Airtable 当人工队列。是的,Airtable。电子表格在任何 50 人以下的审核团队里都胜过"审核平台",因为工作流是你自己定义的。

有自建基础设施的话,用自托管模型替代 GPT-4o-mini 也行,但在每天 1,400 条的体量下,你省不下钱,反而失去 10 分钟换一次 prompt 的灵活性。

队列本身的 Airtable schema 是五个字段加一个状态列:

字段	类型	来源
comment_id	自增数字	采集
text	长文本	采集
intent	单选	分类器
action_required	复选框	分类器
risk_flags	多选	OpenAI Mod + 自定义评分器
escalated_to	单选(Slack 频道)	n8n
responded_at	日期	人工
archive_reason	单选	自动

就这样。完全不需要"审核平台"。状态列驱动工作流:new → in_review → responded → archived。视图上的筛选器就是审核员的岗位说明书。哪天有人问"审核团队到底干什么",你指向 Airtable 的视图就行。

整个流水线在 n8n 里大约 200 行就能跑完。webhook 进,三次 API 调用,一条 Slack,一行 Airtable。编排小到一个人就能拥有——这点比很多人想的更重要:审核工作流每个季度都会随着平台 API 变化而漂移,你要的是 Slack 消息级别的迭代闭环,不是工单级别的。

三个要注意的地方

1. 不要让模型给危机评论写回复。 模板致谢应付普通投诉没问题。crisis 桶里的全部交给人工,没得商量。真正的危机事件中发一条语气失当的自动回复,这个代价不是省下来的时间能换的。

2. 每月审计漏报。 每月从 auto-archive 里随机抽 200 条让人看一眼。如果超过 5% 本该升级,你的分类器漂了。重新调 prompt 或重新训练。漏报才是真正重要的指标;误报只是给模板引擎多一点工作量。

这次审计也是我发现一个差点让我们栽在 Q4 的 bug 的方式。一波"你们广告是误导的"评论被分进了 complaint 且 action_required: false,因为模型把这种固定说法当成了日常抱怨。这个 pattern 看起来像噪声,但 24 小时内从不同账号出现 40+ 次,其实是个协同投诉,本该被抓到。我们加了一条基于量的升级规则:24 小时内 10 条以上评论带相同根名词,自动呼叫值班。没有哪个模型能看见这个信号,只有队列能。

3. 不要把不同市场的 prompt 合并。 美国和中国的 prompt 第一天就会分叉。文化风险词、监管引用、连礼貌规范都不一样。跑两套分类器、两套风险词表、两条升级路径。为了"效率"把它们合在一起,就是那种同时用三种语言道歉的翻车剧本。

收尾的重新定义

AI 进审核,目的不是看得更快,而是删掉队列。如果你的审核员还在每天刷过 800 条"爱了爱了"去找那 3 条值得看的,你没有自动化审核——你只是自动化了击键。目标是一个小到人工团队真的能对每一条想一想的队列。

87 条一天够小。40 条也是。200 条也行,如果那 200 条是对的那 200 条。数字不重要,比例重要。

那些还在跑 1,400 条队列的品牌,要做的不是再多招几个审核员,而是让 1,300 条消失在人工视野之外。