应用商店差评自动归类成工程工单

原文要点

这是一个免费n8n模板：应用商店评论经路径/app-store-review-received的POST webhook进入，先由Anthropic Claude判断是否为真实技术投诉并给出模块、严重度和标准化问题摘要；非技术评论只记录不建单。技术类评论调用complaint-search接口取历史相似投诉，由Claude判断是否属于已有问题簇，再通过HTTP在bug系统中搜索已有工单并超过置信阈值才匹配；匹配则把评论作为证据追加并更新严重度，否则新建工程工单，最后按模块路由到对应Slack频道并把结果写入tracking-log接口。需要Anthropic凭据、各HTTP接口的header认证、Slack凭据。

这次做成什么

在n8n里搭建一条从应用商店评论到工程工单的自动化流水线：按来源说明依次接webhook、Claude分类、历史投诉查重、bug系统匹配/建单、Slack路由与日志记录。本站不提供可导入JSON，按节点手工搭建，并用合成测试评论验证每条分支。

准备什么

• 一个可运行的n8n实例（自托管或云版），能接收外部POST请求
• Anthropic API密钥，用于两个Claude分类与查重步骤
• 可访问的bug系统HTTP API（支持搜索、更新、新建）及header认证凭据
• complaint-search历史投诉接口与tracking-log接口的地址和认证
• Slack工作区凭据及已建好的各模块对应频道
• 测试用合成评论数据，不要直接用真实用户评论调试

具体怎么做

1. 建立webhook入口并规范字段

   新建工作流，添加Webhook节点，方法POST，路径设为/app-store-review-received。用一条合成评论测试触发，确认能拿到reviewText、rating、platform、appVersion、reviewUrl等字段；在后续Set节点里把这些字段统一命名并做类型转换，评分转数字，缺失字段给默认值。

2. Claude分类并过滤非技术评论

   添加第一个AI步骤，选择Anthropic Claude聊天模型，填入本站编写的分类提示词（见材料），让模型输出JSON：isTechnical、appArea、severity、issueSummary。接一个IF节点，isTechnical为false的分支直接走tracking-log接口标记log-only并结束，不进入建单流程。

3. 历史投诉查重与bug系统匹配

   技术分支先调用complaint-search接口（HTTP Request节点，header认证）取相似近期投诉，再用第二个Claude步骤判断是否属于已有问题簇，输出clusterMatch布尔值与理由。随后HTTP请求bug系统搜索接口，将返回的候选工单按置信度筛选，只保留高于阈值的第一个匹配。

4. 更新或新建工单

   加IF节点判断是否存在匹配工单：有则调用bug系统更新接口，把当前评论的reviewUrl、原文摘录作为证据追加，并写入Claude重新评估的severity；没有则调用新建接口，字段包含模块、严重度、标准化摘要和评论链接，取回新工单号。

5. Slack路由与结果落日志

   按appArea在Set节点里维护一张模块到Slack频道的映射表并设默认频道，Slack节点发送包含摘要、严重度、工单号和评论链接的消息。最后统一调用tracking-log接口，记录最终动作（updated/created/log-only）与工单号，便于核对漏单。

可直接复制的材料

你是一名移动应用质量工程师。请阅读下面这条应用商店评论，判断它是否属于真实的技术类投诉（崩溃、卡顿、功能异常、数据错误等），而不是退款、客服态度、内容喜好等非技术反馈。

评论内容：{{$json.reviewText}}
评分：{{$json.rating}}
平台：{{$json.platform}}，应用版本：{{$json.appVersion}}

只输出一个JSON对象，不要输出其他文字：
{"isTechnical": true或false, "appArea": "登录|支付|搜索|播放|消息|其他 之一", "severity": "critical|high|medium|low 之一", "issueSummary": "不超过40字的标准化问题描述", "reason": "一句话判断依据"}
严重度参考：无法使用核心功能为critical，功能受损但有绕行办法为high，体验明显变差为medium，轻微瑕疵为low。

以下是新收到的技术投诉摘要，以及从历史投诉接口取到的相似投诉列表（JSON数组）。请判断新投诉是否与其中某条属于同一个问题簇（同一模块、同一根本原因的可能性高）。

新投诉摘要：{{$json.issueSummary}}
相似投诉列表：{{$json.similarComplaints}}

只输出JSON：{"clusterMatch": true或false, "matchedComplaintId": "匹配到的投诉ID，无则null", "confidence": 0到1之间的小数, "reason": "一句话依据"}
仅在confidence不低于0.7时才允许clusterMatch为true。

{"登录": "#eng-auth", "支付": "#eng-billing", "搜索": "#eng-search", "播放": "#eng-media", "消息": "#eng-messaging", "其他": "#eng-triage-default"}

输入与输出示例

本站虚构演示数据，未实际运行该模板；工单号与接口返回均为示意。

输入

POST /app-store-review-received，Body：{"reviewText":"更新到5.2.1之后一点开支付页就闪退，重装也没用，安卓14","rating":1,"platform":"android","appVersion":"5.2.1","reviewUrl":"https://store.example.com/review/r1001"}

对应输出

Claude分类输出{"isTechnical":true,"appArea":"支付","severity":"critical","issueSummary":"安卓14上5.2.1版本进入支付页即闪退","reason":"核心功能完全不可用且为更新后新出现"}；bug系统无匹配工单时新建工单ENG-4821，Slack向#eng-billing发送含摘要与工单号的告警，tracking-log记录action=created、ticket=ENG-4821。

做完检查这些

• 用合成技术评论触发webhook后，能在bug系统看到一条新工单，字段含模块、严重度与评论链接
• 用合成的非技术评论（如抱怨价格）触发，流程只写tracking-log的log-only记录，不创建任何工单
• 同一问题用两条不同措辞的评论连续触发，第二条走了更新分支，在原工单追加证据而不是新建
• Slack消息出现在appArea映射对应的频道，消息里能点击到评论链接和工单号
• tracking-log中每条评论都有且仅有一条最终动作记录，与技术/非技术分支一一对应

容易卡住的地方

• webhook路径必须保持/app-store-review-received且评论来源要按约定字段名POST，否则后续字段映射全部失效
• 两个Claude步骤都要选Anthropic凭据与聊天模型，漏配会停在AI节点而不报错到上游
• complaint-search与bug系统的base URL是占位值，必须在配置处替换成真实端点并配header认证，否则HTTP节点直接失败
• 置信阈值决定是更新还是新建，设太低会把不同问题合并进同一工单，需按业务容忍度调整
• Slack频道必须先创建且机器人有发消息权限，频道名写错不会自动建频道
• 作者未给出处理耗时承诺，本条所有示例数值均为本站设定