Bug 报告从哪来？用户群里一句"崩了"、客服工单里一段复现描述、测试同学往群里丢的截图、监控告警自动触发的工单、外部用户提交的表单——散在五六个入口，研发同学谁来分？人工读一遍再判断优先级，十条以内还能扛，一天涌进来三十条以上就开始漏：紧急的 P0 被压在队列底部、重复报的同一个崩溃没人合并、缺复现步骤的报告卡着等追问。更头疼的是"谁负责"这件事本身就得来回问一圈：前端还是后端？支付模块还是登录模块？能不能复现？等问清楚，线上已经烧了半小时。
这个 n8n 工作流把多源 bug 报告统一收口，进来就自动拆字段、用大模型判断严重级别（P0-P3）+ 模块归属 + 是否可复现，P0/P1 立即通知值班并建高优 issue，其余按模块路由到对应负责人队列，最后自动回复提交者"已收到 + 预期处理"，状态回写闭环。一条 bug 报告从提交到分派到人压到分钟级，紧急 bug 不再靠"谁喊得响"被发现。
工作流链路
Webhook 触发（bug 报告表单 / 邮件转发 / IM bot 提交 / 监控告警转发）-> Code 节点提取字段（title / description / environment / repro_steps / reporter，归一多源 schema）-> LLM 分类（severity P0-P3 + module + reproducible + missing_info 缺失信息检测）-> IF 紧急（P0/P1）-> 立即通知值班（Slack / 飞书 / 电话 webhook）+ 建高优 issue（HTTP Request 调 issue tracker）-> 否则 Switch 按模块路由到对应负责人队列 -> 自动回复提交者（已收到 + 预期处理时间）-> 状态回写。
这条链路和已有的 GitHub Issue 自动分类工作流的核心区别：后者只处理 GitHub 单一来源的 issue，分类后打 GitHub label 回写；本工作流面向多源 bug 报告（表单/邮件/IM/监控），增加字段提取、复现性判断、模块路由、提交者回复四个环节，做的是"报告进来就分到人"的端到端分流。
下载模板
使用步骤
- 导入：n8n -> Workflows -> Import from File，选 workflow-bug-triage-automation.json
- Webhook 节点：复制 Production URL，接到 bug 报告提交入口。多源接入的关键是字段统一：表单提交通常是结构化 JSON（title/description/environment/steps 都有），邮件转发只有 subject + body 纯文本，IM bot 转发可能是截图加一段话。不管哪个渠道最终都进 Webhook，由 Code 节点归一
- 提取字段节点（Code）：把多源 payload 归一成统一 schema——title、description、environment、reproSteps、reporter、reporterContact、source。邮件来的从 subject 取 title、body 取 description；表单来的直接映射。同时做标题加环境的 hash 去重，同一个崩溃被三个人报了只算一条但记重复次数
- LLM 分类节点：填 Kimi / DeepSeek / Qwen key，8k 上下文够用。Prompt 见下，要求模型输出 severity（P0-P3 枚举）+ module + reproducible + missing_info。missing_info 是关键：如果报告没有复现步骤、没有环境信息，模型标出来，自动回复时一并追问
- IF 紧急节点：取 severity 等于 P0 或 P1 走紧急分支
- 通知值班节点：Slack / 飞书 / 钉钉群机器人 webhook，消息带 severity + module + summary + reporter + source，值班一眼判断要不要拉群。P0 建议配电话告警（PagerDuty / Opsgenie webhook），别只推 IM 消息——凌晨三点 IM 通知等于没通知
- 建高优 Issue 节点：HTTP Request 调 issue tracker（GitHub / GitLab / Jira）的 API，title 带 [severity] 前缀，labels 打 bug + auto-triaged + module + priority。body 结构化写入描述 / 环境 / 复现步骤 / 缺失信息，开发同学拿到就能直接上手
- 按模块路由节点（Switch）：P2/P3 不紧急，按 module 路由到对应负责人。模板里给了 frontend / backend 两个示例分支加默认队列，实际按团队结构加——infra / data / mobile / api 都行。每个分支接一个 HTTP Request 通知对应 Slack 频道或飞书群
- 自动回复提交者节点：HTTP Request 调回复接口（邮件 API / 表单回填 / IM bot 私信），内容是"已收到 + 编号 + 严重级别 + 预期处理时间"。预期处理时间按 severity 映射：P0 立即响应、P1 当天处理、P2 本周排期、P3 下个迭代评估。如果 missing_info 非空，回复里追问"请补充：复现步骤 / 浏览器版本 / 账号 ID"
- 状态回写节点：HTTP Request PATCH 回 bug 记录系统，标记 status=triaged + severity + module + triaged_at。闭环的关键——报告提交后状态从 new 变 triaged，提交者和团队都能查到当前分流结果
- 试运行：手动 POST 一条 P0 bug（含复现步骤）加一条 P2 bug（缺环境信息），看值班是否收到紧急通知、issue tracker 是否建了高优 issue、P2 是否路由到模块负责人、提交者是否收到自动回复、状态是否回写
配套 Prompt（LLM Bug 分流分类）
Prompt
你是 Bug 分流工程师。读下面的 bug 报告，输出 JSON：
- severity：P0（崩溃/数据丢失/安全漏洞/大面积不可用）/ P1（核心功能受阻）/ P2（次要功能受损）/ P3（外观/体验问题）
- module：frontend / backend / infra / unknown（四选一，从描述推断）
- reproducible：yes（有明确复现步骤）/ no（明确无法复现）/ unknown（信息不足判断）
- confidence：0-1
- summary：30 字内概括
- missing_info：缺失的关键信息数组（如复现步骤为空加入 repro_steps，环境为空加入 environment，空数组表示齐全）
规则：severity 必须从给定四级选；不编造报告中没有的事实；仅基于原文判断；信息严重不足无法判断 severity 时默认 P2 并在 summary 前加 [信息不足]。
Bug 标题：{{title}}
Bug 描述：{{description}}
环境：{{environment}}
复现步骤：{{reproSteps}}进阶
- SLA 计时：在状态回写后加一个 Schedule + Code 节点，每小时扫一遍未关闭的 bug，超过 SLA 阈值（P0 1 小时、P1 8 小时、P2 3 天、P3 1 迭代）自动升级通知。SLA 超时比"新 bug 进来"更值得告警——前者是漏了，后者是正常流程
- 去重：Code 节点已做标题加环境 hash 去重，但同一个 bug 不同人描述不一样。进阶做法是 hash 命中后把新报告 append 到已有 issue 的评论里（GitHub Issues API POST /repos/.../issues/:number/comments），不重复建 issue 但保留所有报告人信息，issue 关闭时统一通知所有报告人
- 与 oncall 排班联动：通知值班节点不要写死 webhook URL，而是先 HTTP Request 查 oncall 排班系统（PagerDuty / Opsgenie / 自建排班表），取当前值班人再推到对应渠道。轮班制团队不配这个的话，半夜 P0 推到上个星期的值班人等于白推
- 趋势统计：所有分流后的 bug 入汇总表（飞书多维表格 / Notion / Postgres），每周按 severity 加 module 维度出统计。"本周 P0/P1 数量环比变化""哪个模块 bug 密度最高"比"本周总共多少 bug"更能驱动质量改进
- 置信度分层：LLM confidence < 0.7 时不自动建 issue，走人工复核队列。攒下的人工标注数据可以微调一个专属分类小模型替换通用 LLM，成本和稳定性都更优
踩坑
- severity 标准要写死在 Prompt 里：别只说"判断严重级别"，P0/P1/P2/P3 的定义必须在 Prompt 里写清楚（崩溃=P0，核心功能受阻=P1），否则模型会把"按钮颜色不对"判成 P1。定义跟着团队 SLA 走，改了就记 prompt_version 到汇总表
- missing_info 是分流质量的关键：报告缺复现步骤是常态，不是异常。LLM 检测到 missing_info 后，自动回复里追问比 issue 里标 needs-info 标签有效得多——前者是主动触达提交者，后者要提交者自己去看 issue 状态
- 电话告警别省：P0 只推 IM 群，凌晨没人看等于没推。P0 的通知值班节点配双重通道：IM 推送加电话告警（PagerDuty / Opsgenie），电话告警的 escalation policy 设 5 分钟无人响应升级到下一个值班人
- 模块路由别开太细：frontend / backend / infra 三类覆盖九成场景，开到 React / Vue / Node / Go / K8s / DB / Cache 七八个分支，Switch 节点维护成本高且模型在边界 case 上横跳。先粗分三类跑稳了再按需下钻
- 自动回复别过度承诺：回复提交者说"已收到加预期处理时间"就够了，别说"我们正在修复"——P2/P3 可能两周后才排上，过度承诺引来追问"修好了没"。回复里带 bug 编号让提交者能自助查状态
- 闭环别断在分流：分流到人不等于处理了。状态回写标记 triaged 后要有人认领（assigned）才进入处理。在汇总表里加一列 assigned_at，triaged 后超过 X 小时未 assigned 自动升级通知——分流了没人接比不分流还糟
参考来源
- 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/
- n8n Switch 节点文档：https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.switch/
- GitHub REST API 创建 Issue：https://docs.github.com/en/rest/issues/issues#create-an-issue
- 飞书群机器人 webhook：https://open.feishu.cn/document/client-docs/bot-v3/add-custom-bot
- PagerDuty Events API：https://developer.pagerduty.com/docs/events-api-v2/trigger-events/
- n8n 官方 Workflow 模板库：https://n8n.io/workflows