崩溃治理长期困在看不全、修不完的循环里。Bugly 自动修复尝试打破这个循环自动发现问题 自动修复问题一体化闭环。 AI 圈定问题、分析根因、生成修复代码并提交 MR——开发者只需审核确认。一、崩溃治理的两大困境发现不全修复太慢Bugly 每天为成千上万个应用提供质量监控服务。在与大量开发团队的接触中我们观察到一个普遍现实崩溃治理的瓶颈不只是修不完更是发现不全。困境一发现问题——你以为都关注了其实并没有大部分团队的崩溃处理流程是这样的测试团队在验收阶段关注重点功能路径上的异常上线后开发团队在 Bugly 上筛选 Top 崩溃问题进行处理。这套流程默认了一个前提值得关注的问题都已经被关注了。但现实并非如此。生产环境的崩溃很多是测试阶段从未遇到的。特定机型上的内存不足触发 OOM、某个厂商 ROM 的生命周期回调时序差异、低内存下的后台进程被杀——这些问题在测试环境几乎无法复现只有线上真实用户才会触发。Top 问题占用了全部注意力其余问题无人知晓。团队通常只关注影响用户数最多的 Top 崩溃大量影响少量设备的长尾问题从未被看到。但低频不等于低风险——今天只影响 2 台设备的空指针异常明天一次配置变更可能让它波及上万用户。这意味着如果一个崩溃没有出现在测试验收环节也没有进入 Top 榜单它大概率会被彻底遗漏——直到某次大范围爆发。困境二修复问题——成本高差异大发现问题靠人工走查不现实修复问题同样成本高昂。2026 年的行业数据清晰地揭示了修复成本的严峻现实单个生产环境 Bug 的修复全流程耗时 2-10 小时bugstack 2026 数据其中写修复代码只占 10-15% 的时间绝大部分花在搞清楚问题在哪和等流程走完上。更关键的是修复成本的个体差异极大。同样一个 Native 崩溃资深开发者可能半小时定位根因初级开发者可能折腾一天也摸不到头绪。这种差异不是能力问题而是经验差距——对代码库的熟悉程度、对异常模式的认知、对系统底层机制的理解都会直接影响定位速度和修复质量。发版后的高压时刻发版是崩溃问题的集中爆发点。根据 Bugly 对接入应用的扫描数据新版本上线首日的新增崩溃 Issue 数量因应用规模和版本变化幅度而异——少则几十个多则几百个。几个开发面对上百个新增崩溃只能优先处理 Top 问题其余全部积压。长尾问题持续堆积沉默地拖累整体崩溃率等待某次环境变化突然放大影响。自动修复要解决的根本问题崩溃治理的两大瓶颈——发现不全和修复太慢——本质上是同一件事人力不够经验不均。Bugly 自动修复的解决思路是自动发现基于平台沉淀的崩溃数据按场景自动圈定值得关注的问题消除人工筛选的遗漏和延迟自动修复通过持续更新的专家知识库驱动「智能修复 Agent」使其始终维持在一个高阶且稳定的开发者水平——无论实际处理的开发者经验深浅自动修复输出的归因分析和修复方案都是同一质量标准抹平经验差异让每一个崩溃都能被高效发现和修复——这是自动修复的核心价值。二、自动修复三大核心能力Bugly 自动修复的核心思路针对每一个可自动修复的崩溃 Issue让 AI 走完从分析根因到提交 MR之间最繁琐、最复杂、最耗时的路开发者只需要做两次关键决策——确认修复计划 Code Review。发现问题 → AI 分析根因 → AI 生成修复方案 → 开发者确认计划 → AI 生成代码并提 MR → 开发者 CR → MR 合入自动修复有三大核心能力能力一智能圈定不遗漏任何一个值得修的问题问题发现的关键不只是看到数据而是判断哪些值得修。不同场景下值得关注的判断标准不同新版本发版后哪些是本次发版引入的新增崩溃哪些需要优先修复指标异常时崩溃率突然飙升是哪些 Issue 驱动的哪个问题贡献了最大增量长尾积压时大量低频崩溃长期堆积哪些具备修复价值、修复成本又可控自动修复针对不同场景采用不同的圈定策略自动筛选出值得关注的问题生成自动修复报告。开发者不再需要手动翻阅问题列表、逐个判断是否值得处理。当前 MVP 版本率先支持新版本新增问题场景——新版本发布后自动扫描该版本所有新增崩溃 Issue无论是影响数万用户的高频问题还是只影响 2 台设备 的长尾问题全部纳入扫描范围。更多场景将陆续开放。能力二深度归因不只是看堆栈传统崩溃分析中开发者只能看到一行行堆栈信息然后靠经验去猜根因。但堆栈只能告诉你崩溃发生在哪里无法回答为什么这里会崩溃。自动修复会结合堆栈信息、源码上下文、附件日志、关联业务日志、进程信息、线程信息、FD 信息、用户操作路径等异常现场做深度归因分析——这些信息在传统分析中需要开发者手动拼凑现在由 AI 自动整合给出完整的诊断根因是什么不只是这里空指针了而是告诉你为什么这里会是空——比如用户在低内存场景下触发后台网络请求此时 Activity 已被销毁导致回调中访问了空对象触发条件在什么系统版本、什么操作路径下会触发——比如Android 12 的受限后台启动机制下特定厂商 ROM 的生命周期回调时序差异影响评估影响多少用户、多少设备、严重程度如何修复方案具体改哪个文件、怎么改、给出修复代码风险和置信度修复可能引入什么副作用AI 对这个方案有多大把握但归因的实际效果与崩溃本身的类型强相关。不是所有崩溃 AI 都能分析到位——差异的关键在于定位根因需要看代码还是看现场崩溃按根因的定位方式大致分为两类逻辑异常—— 代码逻辑本身的错误如类型转换异常、空指针等属于 看代码就能定位 。堆栈和源码提供了足够的推理依据一般的 AI Agent 也能处理。运行时异常—— 与运行环境相关的崩溃如内存溢出引发的段错误、内存泄漏等必须 看现场 才能定位根因。进程状态、线程调度、内存占用、资源泄漏……现场信息散落在多种附件中不同异常类型需要提取不同的信息组合分析门槛远高于逻辑异常。归因质量取决于异常现场的数据质量和代码完整度逻辑异常只需要堆栈和源码一般的 AI Agent 也能处理。但运行时异常的分析深度取决于你能拿到多少现场数据——这正是 Bugly 做自动修复的核心优势所在。第三方 AI 代码工具只能看到你贴进去的堆栈文本但 Bugly 作为崩溃监控平台天然拥有最完整的崩溃上下文——不只是堆栈还包括 tombstone 中的信号与寄存器状态、ANR 的消息调度时序、内存镜像中的对象引用链、线程快照中的竞争关系、用户操作路径还原的场景上下文等。这些数据无需开发者手动拼凑由平台自动采集和组织正是运行时异常归因能力提升的关键支撑。业务可以将代码仓库授权给 Bugly 平台这样所有的分析和修复都可以在云端执行。除此之外业务也可以选择在本地执行问题分析和代码修复。只需要使用Bugly提供的Agent通过一行 report-analyze 即可完成报告中所有问题的分析。确认修复计划后再通过一行report-repair命令批量执行报告中所有已确认的修复计划。更重要的是归因分析不是一次性的。如果开发者对 AI 的第一次分析结论不认可可以触发重新分析也可以在本地结合完整代码上下文做更深入的分析。所有分析记录完整保留形成可追溯的分析历史支持对比、采纳和切换。能力三代码修复 MR 提交走通最后一公里开发者确认修复计划后自动修复会自动生成代码、执行编译检查、提交 MR。一个 Issue 一个 MR干净清晰。开发者只需要做 Code Review审核通过即可合入。即使 AI 判断某个问题不建议自动修复比如修复风险高、改动范围大开发者仍然可以选择强制修复让 AI 强制执行修复方案并提交 MR协作修复开发者与AI协作修复后将 MR 链接登记到 Bugly后续自动追踪 MR 状态和修复效果无论自动修复还是人工修复流程完全打通——MR 提交后的状态追踪、合入监控全部自动化。三、案例走读一次新版本发版的崩溃修复全流程让我们用一个真实的场景走一遍自动修复的完整流程。Step 1自动发现问题生成修复报告新版本发布后Bugly 后台自动扫描该版本所有新增崩溃 Issue生成自动修复报告。报告不是一次生成的快照而是持续更新的——新版本发布后的连续 7 天内每天自动扫描新增问题并更新报告确保不会遗漏延迟暴露的崩溃。圈定问题后Bugly 会在云端自动逐个执行归因分析生成修复计划。开发者要做的只是打开报告看结果。报告中每个 Issue 会根据归因分析结果自动标注处理建议处理建议含义可自动修复AI 已完成归因分析并生成修复方案确认修复方案后可自动执行需本地分析云端无代码权限需在本地补充分析建议人工修复AI 判断修复风险较高如涉及核心逻辑、跨模块影响等建议开发者自行处理Step 2查看修复方案快速决策点击某个可自动修复的 IssueAI 已经把根因分析、修复代码和风险评估都准备好了。开发者只需要做一件事判断这个方案能不能接受。大多数情况下扫一眼归因逻辑和修复代码——方案合理风险可控点击 「采纳此方案」 确认执行。如果对方案有疑问可以触发重新分析AI 会基于新的推理路径给出替代方案也可以先跳过后续再处理。一个 Issue 可以有多次归因分析每次分析都是独立的修复方案。开发者可以对比多次分析的结论选择最满意的方案采纳。确认采纳后后续执行阶段会使用用户选定的方案。如果用户没有主动选择执行阶段默认采用最新的归因分析结果。决策权始终在开发者手里。Step 3批量确认AI 执行修复对多个可自动修复的 Issue开发者可以逐个确认也可以批量确认。确认后AI 自动执行修复拉取分支为每个修复创建独立分支应用修改根据修复方案修改代码文件提交 MR每个 Issue 一个独立 MR方便逐个审核和回退更新报告MR 状态实时同步到修复报告开发者可以在报告中直接追踪每个修复的审核和合入进度从确认到 MR 提交全程无需开发者动手写代码。Step 4本地补充分析覆盖无代码权限的问题对于标记为需本地分析的 Issue原因是云端没有代码仓库权限AI 无法读取源码上下文无法给出完整归因。这类问题需要开发者在本地补充分析。通过一条命令批量分析报告中未生成修复计划的问题cd xx/skills/bugly-issue-analyze xx/binaries/python/versions/3.14.3/bin/python3 scripts/run.py report-analyze --product-id xxxxxx --report-id 146 --code-root xx/BuglyProDemo本地分析 Agent 结合完整代码上下文进行分析生成修复方案后自动同步到云端报告。开发者回到 Web 页面确认并执行修复流程与云端一致。确认修复计划后通过一条命令批量执行修复计划cd xx/skills/bugly-issue-analyze xx/binaries/python/versions/3.14.3/bin/python3 scripts/run.py report-repair --product-id xxxxxx --report-id 146 --code-root xx/BuglyProDemo本地修复同样遵循一 Issue 一分支一 MR的原则代码始终留在本地不出域。Step 5人工修复兜底流程同样打通对于建议人工修复的 IssueAI 判断修复风险较高——可能涉及核心业务逻辑、跨模块影响、或者需要业务方确认的决策。这类问题建议开发者自行分析并手动修复。手动修复并不意味着脱离自动修复的流程。开发者在代码仓库提交 MR 后可以在自动修复报告中登记 MR 链接。此后这个 MR 的状态追踪待审核 → 已合入 / 已拒绝与自动修复完全一致纳入统一的修复效果观测。无论是 AI 修复还是人工修复所有修复动作都在同一份报告中可追溯、可度量。四、适用场景不只是新版本发版自动修复当前首发的场景是新版本新增问题全量处理——因为这是开发者痛点最集中、收益最直接的场景。但自动修复的能力底座是通用的后续将覆盖更多场景场景痛点自动修复的价值新版本新增问题当前支持发版后崩溃量激增人手不足全量识别批量修复快速收敛历史长尾问题定期清理大量低频崩溃长期堆积拖累整体崩溃率智能筛选低风险 改动小 收益大的高性价比问题进行批量清理指标告警后应急修复崩溃率突然飙升需要紧急定位和修复自动识别导致指标劣化的 Top 问题加急修复开发阶段日常新增问题开发阶段发现的问题修复成本低但容易被遗忘每日构建后自动扫描在开发阶段就修复避免流入线上防患于未然是自动修复的长期目标——在问题还是小问题的时候就修掉不让它有突变为大故障的机会。欢迎感兴趣的团队找 Bugly客户经理 了解详情Buglyhttps://bugly.tds.qq.com) 是专业的监控定位分析平台作为腾讯端服务联盟https://tds.qq.com) 的重要成员提供研发全流程、全平台、智能化的监控定位分析解决方案助力全球开发者高效地构建高质量应用。