技能介绍

解决什么问题

当应用崩溃、异常或关键链路报错时，开发者常拿到的是一堆看似彼此不同的错误：同一个根因可能因用户身份、浏览器、操作系统、SDK 版本或运行环境差异，生成多条重复 issue；而真正需要优先处理的高频崩溃，又容易被低价值噪声淹没。排障时还要反复确认“这是不是新问题”“哪个服务或团队负责”“相似堆栈到底归到哪条记录”，人工归并和指派既慢又容易出错。

这个技能面向这类真实运维场景：把 Sentry 的错误跟踪数据当作输入，而不是只做告警转发。它关心的不只是“有报错”，而是如何从 stack traces、用户信息和环境详情中提炼趋势，让相似崩溃能被识别，并让责任人自动落到对应代码所有者。

技能如何工作

技能的核心能力围绕三个动作展开：

错误趋势分析：连接 Sentry API v0，从 Sentry 收集到的错误报告中提取结构化信号，包括堆栈跟踪、用户上下文和环境信息，用于观察错误随时间、版本或功能模块的分布变化。
相似堆栈归并：利用 fingerprinting rules 对堆栈内容做指纹匹配。语义相近但文本不完全一致的 stack traces，可以被归入同一类问题，减少重复 issue 带来的干扰。
责任人自动指派：结合 GitHub 的 CODEOWNERS 集成，把归并后的 issue 自动指派给对应代码所有者。团队边界清晰时，排障不再需要人工猜测“这个模块归谁”。

一个典型工作流可以这样理解：应用接入 Sentry SDK 后，崩溃与异常会带着堆栈、用户信息和环境详情进入 Sentry；技能通过 Sentry API v0 读取这些数据，按指纹规则对相似堆栈分组，生成错误趋势视图；如果仓库配置了 CODEOWNERS，issue 会根据路径或模块映射到具体负责人，团队可以直接看到哪些崩溃影响最大、哪些问题需要优先修复。

适用边界与注意点

需要有效 Sentry 数据：没有真实错误报告时，趋势分析和指纹归并不会凭空产生价值；接入前要确认 Sentry 项目、issue 权限和 API 访问范围配置正确。
指纹规则决定归并质量：默认规则能处理常见相似堆栈，但业务异常、第三方 SDK 噪声或高度动态代码可能产生误合并。必要时需要维护或调整 fingerprinting rules。
CODEOWNERS 依赖仓库配置：自动指派效果取决于 CODEOWNERS 是否覆盖相关路径、团队边界是否清晰，以及 issue 是否能可靠映射到仓库模块。
先在上游项目确认行为：当前资料没有自动提取到可验证的安装或使用说明，建议先 review upstream project，再在敏感 workflow 中运行。