客服工单、App Store 评论、社群吐槽、客服邮件、用户群里那句"这个功能太反人类了"--反馈散在五六个渠道，产品同学每周人工扒一遍，分类靠手感，bug 经常拖到下周才被发现，紧急投诉凉在群里没人接。把所有反馈堆进一张表更糟：几千条混在一起，没人分得清哪条该先处理、哪条是重复、哪条藏着真 bug。这个 n8n 工作流把多渠道反馈统一收口，自动去重脱敏，用大模型按"类型/情感/紧急度/产品模块"四维打标，bug 直接建 GitHub Issue，P0 紧急投诉推企微群并 @到人，其余进汇总表做周报和趋势分析。产品/运营/客服团队反馈量越大越省人力，一条反馈从入库到分派能压到分钟级，再也不靠"谁喊得响谁先被处理"。
工作流链路
多渠道接入（Webhook 收客服工单 / App Store RSS / 社群机器人转发 / 邮件 IMAP）-> Code 节点字段归一 + 去重 + PII 脱敏 -> LLM 四维分类（类型：投诉/建议/bug/夸赞；情感：正面/中性/负面；紧急度：P0/P1/P2/P3；产品模块）-> IF 紧急度=P0 推企业微信群 -> IF 类型=bug 建 GitHub Issue -> 全量入飞书多维表格汇总 -> Schedule 每周聚合周报，按模块统计反馈趋势。
这套链路最大的价值不是省了人工分类那一下，而是把"散点反馈"变成"可统计的资产"：每条反馈都带类型/模块/紧急度三个标签，周报能直接拉出"本周 bug 集中在支付模块""P0 投诉环比涨了三成"这种结论，反过来逼产品排优先级，而不是谁声音大谁先被处理。
下载模板
使用步骤
- 导入：n8n -> Workflows -> Import from File，选 workflow-customer-feedback-analysis.json
- Webhook 节点：复制 Production URL，接到客服工单提交后端 / 社群机器人转发逻辑。多渠道接入的关键是字段统一，不同渠道原始字段名不一样（工单叫 content、App Store 叫 review、社群只有纯文本），先在 Code 或 Set 节点归一成统一 schema：feedback（正文）/ source（渠道）/ user_id（可选）/ created_at
- 去重+脱敏节点：Code 节点对正文主干做 hash 去重（去标点空格后取特征串，同一条反馈多渠道转发只算一次），并正则脱敏手机号/邮箱/身份证号。脱敏后的 [PHONE] / [EMAIL] / [ID] 占位符不影响 LLM 理解语义，PII 不外送
- LLM 分类节点：填 Kimi / DeepSeek / Qwen key，8k 上下文够用，Prompt 见下。类目必须冻结为"投诉/建议/bug/夸赞"四类，覆盖九成场景；如果你的产品反馈量大，可在 bug 下再细分"崩溃/卡顿/数据错误"，但别在第一层就开五六个类目，模型会乱
- IF 紧急节点：取 LLM 返回的 urgency，P0 走推企微分支
- 推企微节点：企业微信群机器人 webhook，消息带 source + module + summary 三要素，方便群里人一眼判断要不要接；@ 人用企微的
<@userid>语法，按 module 映射到对应产品负责人 - IF 是 Bug 节点：取 type=bug，走建 Issue 分支
- 建 GitHub Issue 节点：HTTP Request 调 GitHub REST API，title 带 [反馈] 前缀，labels 打 from-feedback + 产品模块，body 写原文（脱敏后）+ 紧急度 + 来源。开发同学复现 bug 时最缺的就是用户原话和触发场景，原文一定带上
- 入汇总表节点：飞书多维表格用 HTTP + OpenAPI；Notion 用官方节点；Postgres 用 Postgres 节点。全量反馈都进表，不丢任何一条；重复反馈标"重复 N 次"也入表，用于热度统计
- 周报节点（可选）：Schedule 每周一定时，聚合上周反馈按类型/模块出统计。别只看"这周总共多少条"，按模块维度看"哪个模块反馈最多"更能反向驱动产品优先级
- 试运行：手动 POST 一条测试反馈（含一条 bug + 一条投诉），看企微是否收到 P0 推送、GitHub 是否建了 Issue、汇总表是否两条都在
配套 Prompt（LLM 四维分类）
你是客户反馈分析师。读下面这条反馈文本，输出 JSON：
- type：投诉 / 建议 / bug / 夸赞（四选一，不得自创类目；如不属于四类归入最接近的一类并在 summary 注明）
- sentiment：正面 / 中性 / 负面
- urgency：P0（崩溃/数据丢失/大面积无法使用）/ P1（核心功能受阻）/ P2（体验问题）/ P3（锦上添花）
- module：产品模块名，从文本推断，未知标 unknown
- confidence：0-1，你对自己分类的把握
- summary：20 字内一句话概括
规则：类目必须从给定四类选；置信度 < 0.7 时 summary 前加 [需复核]；不编造文本中没有的事实；仅基于原文判断。
反馈文本：{{feedback}}踩坑
- 类目不冻结就乱套：让 LLM"自由分类"，第一周看似灵活，第二周统计就崩了，产品要"投诉占比"，你说"抱怨和吐槽算不算投诉？"。Prompt 里把类目写死成枚举，并加一句"不得自创类目，归入最接近的一类并注明"，一致性立刻上来。还有一个常见坑是类目粒度太细，开到"性能/安全/UI/交互/文案"七八类，模型在边界 case 上反复横跳，不如先粗分四类跑稳了再按需下钻
- LLM 误判加置信度阈值：模型把"加载慢"判成 bug，其实是 P3 体验问题；又或者把夸赞里的"这功能真不赖"误读成负面。加 confidence 字段分层处理：P0 自动推群可以宽（0.6 起推，宁推勿漏），自动建 Issue 要严（0.8 起，否则 GitHub 堆一堆误报开发会嫌），低置信度的统一进人工复核队列，每天清一次
- PII 脱敏是红线：用户反馈里常带手机号、订单号、邮箱，直接喂外部 LLM 违规。脱敏必须在送 LLM 之前做，不能指望 LLM 自己忽略 PII；脱敏后原文单独存内库（带 PII），LLM 只看脱敏版，回访用户时再从内库取原文。脱敏规则参考《个人信息保护法》最小必要原则
- 去重别只看正文：同一条吐槽在客服工单、社群、App Store 三处出现，正文会被改写。用"用户 ID + 模块 + 时间窗"做去重键比正文 hash 稳；重复反馈本身是信号，标"重复 N 次"入汇总表不丢，周报里"高频重复反馈 Top 5"比"新增反馈数"更能说明问题
- 闭环别断在分流：bug 建了 Issue 没人跟、P0 推了群没人回访，反馈就烂尾。Issue 节点加 assignee 默认值，企微推送 @到人；最易被忽视的一环是回访，用户报了 bug 你修了不告诉他，下次直接差评，Issue 关闭后接一个 HTTP Request 回写反馈渠道告诉用户"你反馈的 XX 已修复"
- App Store 评论拉取限频：Apple 的公开 RSS 更新有延迟（最快 1-2 小时），别设成每分钟拉，Schedule 设每小时一次就够了；国内安卓市场没统一 RSS，华为/小米/OPPO/vivo 各有开发者后台但 API 基本不开放，建议人工每周导出一次走 webhook 批量进表
- 分类标准要版本化：业务跑两周发现"建议"里混着"功能请求"，要拆类目时，Prompt 改一版记一个版本号到汇总表的 prompt_version 字段，回溯历史数据时按版本号重新跑分类，别拿今天的标准评判昨天的数据
模板是骨架，webhook 接入点、LLM key、GitHub repo、企微机器人地址都是你自己的。跑通后建议加两个节点：一是低置信度反馈进飞书人工复核表，每天早班客服按模板复核并打正确类目，这些人工标注攒下来就是微调分类模型的语料，攒够几百条可以拿去 fine-tune 一个专属小模型替换通用 LLM，成本和稳定性都更优；二是 Issue 关闭后自动回访原反馈用户（如果有渠道），把"反馈->处理->回访"闭环补上。每月用历史标注数据回测一次分类模型，统计准确率和类目分布，防止模型漂移导致"bug 突然变多或变少"的假象。
参考来源
- n8n Webhook 节点文档：https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.webhook/
- n8n Code 节点文档：https://docs.n8n.io/code/builtin/code-node/
- n8n IF 节点文档：https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.if/
- GitHub REST API 创建 Issue：https://docs.github.com/en/rest/issues/issues#create-an-issue
- 企业微信群机器人 webhook：https://developer.work.weixin.qq.com/document/path/91770
- 飞书多维表格 OpenAPI：https://open.feishu.cn/document/server-docs/docs/bitable-v1/bitable-overview
- n8n 官方 Workflow 模板库：https://n8n.io/workflows