崩溃报告自动关联Git提交定位嫌疑改动

原文要点

来源是n8n免费模板，流程为：webhook接收移动端崩溃上报（Crashlytics、Sentry、Bugsnag均可），规范化载荷并提取堆栈帧，按配置的appOwnedPathPrefixes路径前缀筛出属于自家代码的嫌疑帧；对每个候选文件调GitHub API查近期提交和文件元数据；把崩溃上下文与Git证据交给Anthropic Claude，要求返回JSON：最可疑提交/作者、置信度分数和修复建议；达到minConfidenceForAutoAssign阈值就在任务系统建单并自动指派，否则不指派留待人工分诊；最后向Slack频道推送嫌疑文件/作者、置信度和提交链接。需配置repoOwner、repoName、lookbackDays、taskProviderBaseUrl、slackChannelId等值，凭据含GitHub、Anthropic（x-api-key头）、任务工具（Header Auth）、Slack OAuth。

这次做成什么

照着本页在本机n8n里搭一条崩溃归因练习流：手动触发喂入合成崩溃JSON，筛帧、查GitHub提交、让Claude返回结构化归因，按置信度走指派/人工两条分支，最后拼出Slack消息文本。原模板没有提供可下载的工作流文件，本页是本站按其说明独立设计的等效练习，节点命名与参数请以你自己导入或对照原模板为准。

准备什么

• 一个可登录的n8n实例（云端或自托管均可），能创建Webhook和HTTP Request节点
• GitHub个人访问令牌，且对目标仓库有读取提交历史的权限
• Anthropic API密钥，用作HTTP Header Auth的x-api-key
• 一个测试用Slack工作区及可发消息的OAuth连接，没有可先用Set节点模拟输出
• 用于练习的虚构崩溃上报JSON和真实存在的测试仓库

具体怎么做

1. 建触发与合成输入

   新建工作流，加一个Manual Trigger或Webhook节点。练习阶段用Manual Trigger，后面接Set节点粘贴下方artifacts里的合成崩溃JSON，字段包含crash_id、device、stack_frames数组。这样不依赖Crashlytics真实推送也能跑通全流程；上线时再换成Webhook并把崩溃工具的POST地址指向该URL。

2. 筛自家代码嫌疑帧

   加一个Code节点，读取配置的appOwnedPathPrefixes（例如["com.example.shop/","app/src/main/"]），遍历stack_frames，过滤出file字段以前缀开头且非系统库的帧，按堆栈顺序取前1至3个作为候选，输出candidate_files数组（file、line、symbol）。配置值集中放在一个Set节点里，含repoOwner、repoName、lookbackDays、minConfidenceForAutoAssign、taskProviderBaseUrl、slackChannelId，后续节点统一引用。

3. 查GitHub近期改动

   用Split In Batches遍历candidate_files，每个文件发HTTP Request到GitHub API的commits端点，query参数带path=该文件路径、since=当前时间减lookbackDays天，Header带GitHub令牌；再取每个提交的sha、author、date、message，汇总成一个evidence数组回主流。注意这是原模板声明的做法，具体节点参数以你导入的模板为准。

4. 让Claude归因并解析JSON

   用HTTP Request调Anthropic消息接口，Header放x-api-key，body里messages的user内容填入下方Claude归因提示词，并注入崩溃上下文与evidence数组。要求模型只输出JSON。后接Code节点用JSON.parse解析，得到suspect_commit、suspect_author、confidence（0到1）、fix_suggestion四个字段；解析失败走错误分支记日志。

5. 按置信度分支建任务

   加IF节点判断confidence是否大于等于minConfidenceForAutoAssign（练习设0.75）。真分支：向taskProviderBaseUrl发POST，body含name、description、priority、assignee（取suspect_author映射到任务系统账号），原模板说明字段为name/description/priority/可选assignee，若你的系统schema不同需自行调整。假分支：只建未指派任务或不建单，标记manual_triage。

6. 推送Slack结果

   用Slack节点（或HTTP Request到Slack）向slackChannelId发消息，文本拼上嫌疑文件、作者、置信度百分比、提交链接和修复建议摘要；两个分支合流后统一发送，消息里注明是否已自动指派。手动执行一次，核对Slack消息字段与合成输入一致。

可直接复制的材料

{
  "crash_id": "CRASH-2026-0417-001",
  "app_version": "3.8.2",
  "device": "Pixel 7 / Android 14",
  "exception": "java.lang.NullPointerException",
  "message": "Attempt to invoke virtual method on a null object reference",
  "stack_frames": [
    {"file": "com/example/shop/cart/CartRepository.java", "line": 87, "symbol": "CartRepository.refreshCart"},
    {"file": "com/example/shop/cart/CartViewModel.java", "line": 142, "symbol": "CartViewModel.onCheckout"},
    {"file": "android/os/Handler.java", "line": 938, "symbol": "Handler.handleCallback"}
  ]
}

你是一名移动端崩溃分诊工程师。下面给出一个生产崩溃的上下文，以及疑似相关文件在GitHub仓库中的近期提交证据。请判断最可能导致该崩溃的改动，并【只输出一个JSON对象】，不要输出任何其他文字。JSON字段：
- suspect_file：最可疑文件路径
- suspect_commit：最可疑提交的sha（必须来自证据列表，没有把握就填null）
- suspect_author：该提交作者
- confidence：0到1之间的小数，证据不足时低于0.5
- reasoning：不超过80字的中文理由
- fix_suggestion：不超过120字的中文修复建议

崩溃上下文：
{{ $json.crash_context }}

近期提交证据：
{{ $json.github_evidence }}

{
  "repoOwner": "your-org",
  "repoName": "shop-android",
  "appOwnedPathPrefixes": ["com/example/shop/", "app/src/main/"],
  "lookbackDays": 14,
  "minConfidenceForAutoAssign": 0.75,
  "taskProviderBaseUrl": "https://tasks.example.internal/api",
  "slackChannelId": "C0123456789"
}

输入与输出示例

本站虚构演示，非原作者运行结果，Claude实际输出会不同，未在本站实测。

输入

使用上方合成崩溃JSON：crash_id为CRASH-2026-0417-001，崩溃在CartRepository.java第87行NullPointerException，GitHub证据为该文件近14天内有提交a1b2c3d（作者li.wei，message：购物车接口超时后不再预填缓存）。

对应输出

{"suspect_file": "com/example/shop/cart/CartRepository.java", "suspect_commit": "a1b2c3d", "suspect_author": "li.wei", "confidence": 0.82, "reasoning": "超时后跳过缓存预填使refreshCart读到空对象，与87行空指针吻合", "fix_suggestion": "在refreshCart入口对缓存结果做非空判断，超时分支回填空列表而非null"}
0.82≥0.75走自动指派分支，Slack消息：疑似CartRepository.java / li.wei / 置信度82% / 提交链接 / 已自动指派。

做完检查这些

• 筛帧后candidate_files只含com/example/shop/下的两个文件，android/os/Handler.java被过滤
• Claude返回的文本能被JSON.parse成功解析，且confidence在0到1之间
• confidence=0.82时IF走真分支并发出带assignee的任务请求；把输入改成证据不足的崩溃时应走假分支
• Slack消息中包含嫌疑文件名、作者、置信度百分比和提交链接四要素

容易卡住的地方

• 任务系统的建单字段若不是name/description/priority/assignee这套schema，必须改请求体，否则建单失败
• Claude偶发在JSON外包裹解释文字，解析节点要容错或提示词里强调只输出JSON
• GitHub的since参数按UTC计算，lookbackDays跨时区时注意边界
• 置信度阈值是流程配置值，不代表归因准确率；作者未承诺定位正确的比例
• 多个候选文件时需要合并各自证据再一次性给Claude，逐文件单独提问会丢上下文