AI Bug修复与测试生成：从崩溃日志到修复PR的自动化 | AI提效Android开发(5)

AI提效Android开发系列 · 第5/5篇（完结篇）

从需求到上线，用AI重塑Android开发全流程

第1篇：AI提效Android开发全景图：从需求到上线的AI工具链

第2篇：AI驱动需求梳理与Spec编写：让PRD自动变成技术方案

第3篇：AI编码提效实战：Skill、Rule与上下文工程

第4篇：AI Code Review：让每一行代码都有AI审查员

第5篇：AI Bug修复与测试生成：从崩溃日志到修复PR的自动化（本篇 · 完结）

周五晚上十一点半。电脑已经合上了，你正准备出门。手机震了一下------Bugly 告警推送：线上新版本 Top 1 Crash，影响用户数 3,200+，曲线还在往上走。

你叹了口气，重新打开电脑。堆栈一百多行，Java/Kotlin 混合调用链，横跨三个模块。你开始做那个最痛苦的事情------在脑子里当 debugger，一帧一帧地回溯执行路径，试图找到那个"不该是 null 但偏偏是 null"的鬼地方。

四十分钟后定位到了根因。又花二十分钟写修复。然后你看了一眼时间------凌晨十二点半了。要不要补个测试？算了，先提 hotfix MR，明天再说。

然后明天就没有了。"明天"永远不会来。这个修复就这样裸奔上线了，直到下次类似的问题再次出现。

这是「AI提效Android开发」系列的完结篇。前四篇走完了需求→编码→Review 的流程，这一篇补上最后一块拼图：Bug 修复和测试生成------看看 AI 能不能帮我们把"周五半夜救火"变成"周一早上审查 AI 的修复方案"。

一、修 Bug 的时间到底花在哪了

不着急上 AI。先拆解一下从"收到崩溃告警"到"修复代码合入"这个链路。我统计了团队最近两个月的 12 次线上 Crash 修复，时间分布大致是这样的：

• 告警识别 + 信息收集（15-30 分钟）：看堆栈、查设备分布、翻用户反馈、确认影响范围

• 根因定位（30 分钟 - 3 小时）：顺着堆栈看代码、追数据流、尝试复现

• 编写修复（15-45 分钟）：写修复代码，通常改动不超过五个文件

• 验证 + 测试（30 分钟 - 1 小时）：跑现有测试、手动验证、偶尔补个测试

• 提 MR + Review + 合入（1-4 小时）：等人看、等人批、等 CI 跑完

一个反直觉的发现：写修复代码的时间只占总时间的 10-15%。绝大部分时间花在了"搞清楚问题在哪"和"等流程走完"上。

而这两个环节，恰好是 AI 最能发力的地方------分析能力强、不需要等人、可以同时做多件事。

二、AI 崩溃分析：不只是"把堆栈丢给 ChatGPT"

很多人试过把 Crash 堆栈直接丢给 ChatGPT 或 Claude，得到一个半对半错的分析，然后就放弃了："AI 不靠谱嘛"。

问题不在 AI，在于你喂进去的信息太少了。一个堆栈只是冰山一角，AI 看着一堆 at com.example.app.xxx，它不知道这些代码长什么样、最近改了什么、项目架构是怎么设计的。

2.1 构建"崩溃上下文包"

真正有效的做法是给 AI 构建一个完整的"崩溃上下文包"：

# crash_context_builder.py

def build_crash_context(
    crash_stack: str,
    project_root: str
) -> dict:
    """从堆栈中提取涉及的源文件，
    打包完整分析上下文"""

    # 1. 解析堆栈中所有本项目的调用帧
    our_frames = extract_project_frames(
        crash_stack,
        package_prefix="com.example.app"
    )

    # 2. 读取涉及的源文件完整内容
    source_files = {}
    for frame in our_frames:
        path = resolve_source_path(
            frame.class_name, project_root
        )
        if path and path.exists():
            source_files[str(path)] = \
                path.read_text()

    # 3. 找到相关的数据类和接口定义
    # （崩溃经常涉及数据层）
    related_types = find_related_types(
        source_files, project_root
    )

    # 4. 最近 7 天相关文件的 git log
    # （大部分线上 Crash 和最近提交有关）
    recent_changes = get_recent_changes(
        [f.file_path for f in our_frames],
        days=7
    )

    return {
        "crash_stack": crash_stack,
        "source_files": source_files,
        "related_types": related_types,
        "recent_changes": recent_changes,
        "project_rules": load_project_rules()
    }

每一项都有明确的作用：

• source_files：让 AI 看到完整代码逻辑，不靠猜

• related_types：数据类定义------NPE 经常是因为某个字段声明为非空但运行时为空

• recent_changes：最近的 git diff，帮 AI 判断是不是回归 bug

• project_rules：CLAUDE.md 或编码规范，确保生成的修复代码风格正确

我实测过有无上下文包的分析准确率差异：只给堆栈的准确率约 45%，加上完整上下文后提升到约 80%。差距惊人。

2.2 让 AI 像侦探一样推理

prompt 不能只说"分析这个崩溃"。你得给 AI 一个推理框架，逼它一步步推导，而不是直接跳到结论：

"""
你是 Android 崩溃分析专家。
请严格按以下框架分析：

### 1. 崩溃分类
- 异常类型（NPE/OOM/ANR 等）
- 精确触发位置（类名 + 行号）
- 影响范围（UI 线程/后台/全局）

### 2. 根因推理链（最重要）
用"因为→所以"的链式推理：
- 直接原因：哪个变量/状态异常
- 为什么异常：追溯赋值/初始化路径
- 触发条件：什么操作/时序/状态组合
- 是否回归：对照 recent_changes 判断

### 3. 修复方案（必须双方案）
- 方案A：修复根因
- 方案B：防御性保护
- 每个方案给具体代码 diff

### 4. 风险评估
- 修复的副作用和兼容性
- 是否需要灰度验证

### 5. 测试建议
- 必须覆盖的回归场景
"""

这里有两个设计意图：

**"根因推理链"**是核心。不让 AI 直接蹦答案，而是让它像侦探破案一样展示推理过程。这样你一看就知道它的分析对不对------如果推理链中间有一步不成立，整个结论就不可信。

**"方案A + 方案B"**是防御。很多时候根因修复不能一步到位（比如需要服务端配合），防御性保护至少能先止血。如果 AI 只给了一个方案，多半漏了什么。

2.3 实战：一个真实的 NPE 分析

来看一个真实案例。线上报了这样一个崩溃：

java.lang.NullPointerException:
  Attempt to invoke virtual method
  'java.lang.String
   com.example.app.model.UserProfile
   .getDisplayName()'
  on a null object reference

  at com.example.app.ui.chat
     .ChatViewModel.formatMessage
     (ChatViewModel.kt:142)
  at com.example.app.ui.chat
     .ChatViewModel$loadMessages$1
     .invokeSuspend
     (ChatViewModel.kt:87)
  at kotlin.coroutines.jvm.internal
     .BaseContinuationImpl.resumeWith
     (ContinuationImpl.kt:33)

把堆栈 + 完整上下文包喂给 AI 后，它输出的分析：

AI 根因分析

直接原因 ：ChatViewModel.kt 第 142 行调用 userProfile.displayName，但 userProfile 为 null。

推理链 ：loadMessages()（第 87 行）调用 userRepository.getCurrentUser() 获取用户信息 → 该方法在用户 token 过期时返回 null → 三天前的 commit a3f7b2c 移除了 formatMessage 中原有的空检查 → commit message 写着"用户登录态下 profile 不可能为 null" → 但忽略了 token 刷新窗口期：用户 session 有效但 token 恰好过期。

触发条件：用户 token 在 loadMessages 执行期间过期，且 token 刷新请求尚未完成。在登录超过 2 小时的用户中有约 0.3% 概率触发。

回归判定：是。commit a3f7b2c 引入。

你注意这个分析的质量：它不仅定位到了 NPE 的直接位置，还追溯到了三天前某个 commit 移除空检查的根因，甚至分析了触发概率。这比人工 debug 快至少十倍，而且推理链可验证------你去看 commit a3f7b2c 就知道 AI 说得对不对。

2.4 Android Studio + Gemini AQI：IDE 里的原生体验

不想自建分析流程？Android Studio Panda 把这套能力产品化了。App Quality Insights 面板对接 Firebase Crashlytics，Gemini 直接在 IDE 里分析崩溃：

• 打开 AQI 面板 → 选中一个 Crash → 点击 "Show Gemini Insights"

• Gemini 生成崩溃摘要、可能的根因、推荐的修复方向

• 点击分析中提到的类/方法名，直接跳转到本地源码

体验确实不错，但有两个实际限制。第一，分析深度取决于 Crashlytics 上传的信息量------如果混淆后没上传 mapping 文件，Gemini 也看不懂堆栈。第二，它不了解你项目的架构约定和业务规则。

我的建议：简单的 NPE / ClassCastException 用 AQI + Gemini 快速定位，复杂的并发/生命周期/跨模块问题用自建分析流程。不冲突，各取所长。

三、AI 生成修复代码：diff 比完整文件靠谱

分析完根因，下一步是让 AI 写修复代码。这里有个反直觉的经验：让 AI 输出 diff 格式比输出完整文件靠谱得多。

原因是修复通常只改几行。让 AI 输出整个 300 行的文件，它可能"顺手"改了其他地方------有时候是优化（比如加个 TODO 注释），有时候是破坏（悄悄改了一个不相关的条件判断）。限定为 diff 格式可以精确控制变更边界。

"""
基于你的根因分析，生成修复代码。

## 输出规则
1. 使用 unified diff 格式
2. 只改必要的行，不做无关重构
3. 同时给出根因修复 + 防御性保护
4. Kotlin 风格：?.let / ?: / when
5. 遵循项目规范：{project_rules}

## 硬约束
- 不引入新依赖
- 不改变公开 API 签名
- 不破坏向后兼容
"""

继续上面那个 ChatViewModel 的例子，AI 生成的修复：

// ChatViewModel.kt

// ── 方案A：根因修复 ──
// 确保 token 刷新完成后再取 profile
- val profile = userRepo.getCurrentUser()
+ val profile = userRepo
+     .getCurrentUserWithRefresh()

// ── 方案B：防御性保护 ──
// formatMessage 恢复空安全
 private fun formatMessage(
     msg: Message,
-    profile: UserProfile
+    profile: UserProfile?
 ): FormattedMessage {
-    val senderName = profile.displayName
+    val senderName = profile?.displayName
+        ?: "用户"
     // ...
 }

两个方案应该同时采用：方案A 解决根因（确保 token 刷新后再获取 profile），方案B 兜底（即使 profile 仍然为 null 也不崩溃）。这种"腰带 + 吊带"的修复策略，比单纯加个空判断要健壮得多。

四、端到端自动化：从告警到 PR

如果你想更进一步，可以搭建一个全自动 Pipeline：告警进来 → AI 分析 → AI 修复 → 自动跑测试 → 自动创建 MR。2026 年这已经不是 PPT------Claude Code 的自动修复 PR 功能、OpenClaw 的 cron 监控 + AI Agent 联动，都已经有成熟的实践案例。

# auto_fix_pipeline.py
# 告警 → 分析 → 修复 → 测试 → PR

async def auto_fix_crash(
    crash_report: CrashReport
):
    # Step 1: 构建崩溃上下文包
    context = build_crash_context(
        crash_report.stack_trace,
        project_root=PROJECT_ROOT
    )

    # Step 2: AI 分析根因
    analysis = await analyze_crash(context)
    if analysis.confidence < 0.7:
        notify_human(
            "AI 信心不足，需人工介入",
            crash_report, analysis
        )
        return

    # Step 3: 生成修复 diff
    fix = await generate_fix(
        analysis, context
    )

    # Step 4: 创建分支、应用修复
    branch = f"ai-fix/{crash_report.id}"
    create_branch(branch)
    apply_diff(fix.diff, branch)

    # Step 5: 生成回归测试
    tests = await generate_regression_test(
        analysis, fix, context
    )
    write_test_file(tests, branch)

    # Step 6: 跑测试（最多自动修正 3 轮）
    for attempt in range(3):
        result = run_tests(branch)
        if result.passed:
            break
        fix = await fix_test_failure(
            result, context
        )
        apply_diff(fix.diff, branch)

    # Step 7: 创建 MR
    mr = create_merge_request(
        branch=branch,
        title=f"[AI-Fix] {analysis.summary}",
        description=format_mr_desc(
            analysis, fix, tests
        ),
        labels=["ai-fix", "needs-review"]
    )

    # Step 8: 通知相关人
    notify_team(crash_report, mr)

这个 Pipeline 有几个关键设计：

• 信心阈值：AI 分析的 confidence 低于 0.7 就不自动修复，直接通知人工。不确定的时候不瞎搞

• "测试不过就再修一轮"：AI 生成的代码不一定一次过。让它看测试失败日志 → 自动修正，最多 3 轮

• MR 标签 needs-review：AI 修复的 MR 必须经过人类 Review 才能合入。这条底线不能破

• MR 描述包含完整分析：不只有 diff，还有根因推理链、触发条件、风险评估。Reviewer 一眼就能判断靠不靠谱

划重点：自动化的边界是"帮你干活"，不是"替你决策"。AI 创建的 MR 可以自动跑 CI，但合入按钮只有人类能按。

五、AI 测试生成：告别"来不及写测试"

Android 团队的测试覆盖率低是公开的秘密。不是不想写，是真的没时间。尤其是修完 bug 的时候------赶着上线，测试下次再补吧。然后就永远没有下次了。

AI 测试生成解决的核心痛点是：把"从零写一个测试"变成"审查和微调一个测试"。前者心理门槛高、耗时长，后者顺手就做了。

5.1 针对 Bug 修复的回归测试

比通用单测生成更有价值的场景是：修完 Bug 后自动生成回归测试。目标很清晰------确保这个 bug 永远不会再出现。

"""
根据以下崩溃分析和修复，生成回归测试。

## 崩溃根因
{analysis.root_cause}

## 触发条件
{analysis.trigger_condition}

## 修复 Diff
{fix_diff}

## 测试规则
1. 必须包含一个"修复前会失败"的测试
   （证明 bug 确实存在）
2. 覆盖所有已知触发条件
3. 覆盖修复引入的新代码分支
4. 使用项目测试框架：
   JUnit 5 + MockK + Turbine
5. 命名：test_动作_条件_预期结果
6. mock SUT 的依赖，不 mock SUT 本身
"""

AI 生成的回归测试（还是前面那个 ChatViewModel）：

class ChatViewModelCrashRegressionTest {

    private lateinit var viewModel:
        ChatViewModel
    private val userRepo:
        UserRepository = mockk()
    private val chatRepo:
        ChatRepository = mockk()

    @BeforeEach
    fun setup() {
        viewModel = ChatViewModel(
            userRepo, chatRepo
        )
    }

    @Test
    fun formatMessage_profileNull_
        returnsDefaultName() = runTest {
        // 修复前这个测试会 NPE
        val result = viewModel
            .formatMessage(
                testMessage, null
            )

        assertEquals(
            "用户", result.senderName
        )
    }

    @Test
    fun loadMessages_tokenExpired_
        triggersRefresh() = runTest {
        coEvery {
            userRepo
                .getCurrentUserWithRefresh()
        } coAnswers {
            delay(100)  // 模拟刷新耗时
            testProfile
        }
        coEvery {
            chatRepo.getMessages()
        } returns testMessages

        viewModel.loadMessages()
        advanceUntilIdle()

        // 确认调用了带刷新的版本
        coVerify {
            userRepo
                .getCurrentUserWithRefresh()
        }
    }

    @Test
    fun loadMessages_concurrent_
        noDuplicates() = runTest {
        // 模拟两次并发调用
        coEvery {
            userRepo
                .getCurrentUserWithRefresh()
        } coAnswers {
            delay(50)
            testProfile
        }
        coEvery {
            chatRepo.getMessages()
        } returns testMessages

        launch { viewModel.loadMessages() }
        launch { viewModel.loadMessages() }
        advanceUntilIdle()

        // 验证消息列表无重复
        val msgs = viewModel
            .messages.first()
        assertEquals(
            msgs.distinctBy { it.id }.size,
            msgs.size
        )
    }
}

注意第三个测试------AI 不仅测了修复点本身，还补了一个并发测试。因为我们在崩溃分析 prompt 里要求它识别触发条件（token 刷新窗口期的竞态），它就知道并发场景需要覆盖。Prompt 的分析深度决定了测试的覆盖质量。

5.2 小心"测了个寂寞"

AI 生成测试最常见的坑：它 mock 了被测对象本身，然后验证 mock 的返回值等于 mock 设置的值。等于自己出题自己答，测试全绿，但什么也没验证。

//  "测了个寂寞"
@Test
fun getUser_returnsUser() = runTest {
    val expected = User("test")
    coEvery {
        userRepo.getUser()
    } returns expected

    val result = userRepo.getUser()
    assertEquals(expected, result)
    // ← 你验证了 MockK 能工作
    //    不是验证你的业务代码
}

//  测真正的 ViewModel 逻辑
@Test
fun viewModel_loadsUser_updatesState() =
    runTest {
        coEvery {
            userRepo.getUser()
        } returns User("test")

        viewModel.loadUser()
        advanceUntilIdle()

        // 验证 ViewModel 状态变化
        assertEquals(
            "test",
            viewModel.uiState.value.userName
        )
    }

在 prompt 里必须加一条铁律：**"测试必须调用 SUT（被测系统）的真实方法，只 mock SUT 的外部依赖，绝不 mock SUT 本身。"**加了这条之后，"测了个寂寞"的概率大幅降低。

5.3 Meta TestGen-LLM 的启发

Meta 在 TestGen-LLM 论文中分享了几个关键发现：

• 覆盖率提升：在已有测试基础上，LLM 额外生成的测试平均提升 15.7% 行覆盖率

• 可编译率：67% 直接编译通过，一轮自动修复后提到 82%

• 人类评价：可编译的测试中，57% 被开发者评为"有用，愿意保留"

Meta 的核心 insight 是：别让 AI 从零开始，让它在已有测试上"改进"。给 AI 看你现有的测试风格和模式，让它补缺失场景，效果远好于凭空创造。这和我们第三篇讲的"上下文工程"是一个道理------AI 需要例子来学习你的风格。

六、变更影响分析：只跑该跑的测试

修完 Bug 跑全量测试？我们项目要 45 分钟。Hotfix 场景根本等不起。

AI 可以做变更影响分析------根据改了哪些代码，推断该跑哪些测试。

"""
分析以下变更的影响范围，
推荐精准测试集。

## 变更文件
{changed_files_with_diff}

## 模块依赖图
{module_deps}

## 分析维度
1. 直接影响：被改函数/类的测试
2. 上游影响：调用了被改代码的模块
3. 数据流：改了 data class → 序列化
   /API/DB 是否受影响
4. UI 层：Composable 的参数/状态变了

## 输出
{
  "must_run": ["必跑测试类"],
  "should_run": ["建议跑的测试类"],
  "estimated_minutes": 3
}
"""

在 CI 里集成精准测试，MR 级别的测试时间从 45 分钟缩短到 3-5 分钟：

# CI：智能测试选择
smart-test:
  stage: test
  script:
    # AI 分析影响范围
    - python scripts/impact_analysis.py
        --diff $CI_MERGE_REQUEST_DIFF_REF
        > test_plan.json
    # 核心测试（阻塞合并）
    - ./run_tests.sh
        --from test_plan.json
        --tier must_run
    # 扩展测试（不阻塞）
    - ./run_tests.sh
        --from test_plan.json
        --tier should_run
        --allow-failure

Reviewer 看到的 MR 状态是"核心测试 / 扩展测试运行中 ⏳"，可以马上开始 Review，不用枯等。

七、踩坑实录：AI 修 Bug 的四个真实教训

用了两个月，踩的坑比想象中多。分享四个最痛的。

7.1 AI 最爱"加个空判断了事"

给 AI 一个 NPE，它的第一反应是加 ?.let 或 ?: return。技术上正确------不崩了。但如果根因是上游数据源没初始化，你只是把崩溃变成了"功能默默失效"。用户从"闪退"变成"点了没反应"，体验可能更差。

对策：Prompt 里强制双方案。如果 AI 只给了防御性方案，追问"根因是什么？根因修复的方案是什么？"

7.2 ANR 分析准确率断崖式下降

Crash 分析准确率 80%，但 ANR 只有约 45%。原因是 ANR trace 包含所有线程的堆栈，动辄几千行，AI 容易"迷路"。而且 ANR 的根因经常不在主线程堆栈里------主线程被阻塞了，但阻塞它的锁可能在另一个线程。

对策：对 ANR trace 做预处理。只保留主线程 + 持有目标锁的线程 + Binder 调用链，并标注锁竞争关系。预处理脚本大概 50 行 Python：

def preprocess_anr_trace(
    full_trace: str
) -> str:
    threads = parse_threads(full_trace)
    main = threads["main"]

    # 找主线程等待的锁
    blocked_on = extract_lock_wait(main)
    if not blocked_on:
        return main.raw  # 没锁竞争

    # 找持有该锁的线程
    holder = find_lock_holder(
        threads, blocked_on
    )

    # 精简输出
    return f"""
== 主线程（BLOCKED）==
等待锁: {blocked_on}
{main.stack[:30]}

== 锁持有者: {holder.name} ==
{holder.stack[:30]}

== 锁竞争关系 ==
main --等待--> {blocked_on}
  --持有者--> {holder.name}
"""

预处理后再喂给 AI，ANR 分析准确率从 45% 提升到约 68%。还是不如 Crash，但已经能用了。

7.3 混淆堆栈一定要先 retrace

Release 包的堆栈是混淆过的------a.b.c.d()。AI 对着这个什么也分析不出来。Pipeline 里必须在分析前加一步 retrace。

如果用 Bugly，它的 API 可以直接返回还原后的堆栈。如果用 Firebase Crashlytics，确保上传了 mapping.txt。这一步看起来简单，但如果忘了，整个 Pipeline 就废了。

7.4 业务逻辑 Bug 不要指望 AI

"用户充值 100 元但余额只加了 10 元"------这种 bug 堆栈是正常的，代码也没崩，只是业务逻辑算错了。AI 不知道"100 元应该加 100"这个业务规则，它能看出代码在做乘法而不是加法，但不知道哪个是对的。

明确边界：AI 擅长分析技术性 Bug（NPE、OOM、并发、类型错误），不擅长业务逻辑 Bug。后者还是得靠人。

八、实践数据：两个月的效果

分享试点两个月的真实数据。

AI Bug 修复 Pipeline 实践数据

• 处理 Crash 总数：34 个（Top 10 或影响用户 > 500）

• 根因分析准确率：27/34 ≈ 79%（NPE 类 92%，并发类 71%，业务类 40%）

• 修复直接可用：18/34 ≈ 53%（人类 Review 后无需修改直接合入）

• 修复需要微调：9/34 ≈ 26%（分析正确，代码需要小幅调整）

• 完全不可用：7/34 ≈ 21%（分析偏差或修复不合理）

• MR 创建速度：从告警到 MR 创建，平均 12 分钟（传统 3.5 小时）

• AI 生成回归测试保留率：约 71%

几个 takeaway：

• NPE 效果最好：因果链明确，AI 几乎不会错

• 并发/时序类次之：AI 能定位问题，但修复方案的线程安全性需要人工把关

• 业务逻辑 Bug 最差：AI 不懂业务语义

• 53% 直接可用是个好数字：超过一半的线上 Crash，从告警到可合入的 PR 只要十几分钟

九、系列总结：AI 提效的完整拼图

五篇文章，走完了一个 Android 功能从零到上线再到维护的全流程：

第1篇 · 全景图：建立"需求→编码→Review→发布→修复"五阶段模型，定义了每个环节的 AI 切入点

第2篇 · 需求→Spec：AI 把模糊 PRD 转化为结构化技术方案，"开会三天"变成"AI 出初稿 + 人工改半天"

第3篇 · AI 编码：Skill + Rule + 上下文工程三板斧，让 AI 写出"能合入"而不仅是"能跑"的代码

第4篇 · AI Review：AI 做第一个 Reviewer，扫机械性问题，人类专注架构和逻辑

第5篇 · Bug 修复：从崩溃告警到修复 PR 的全自动 Pipeline，十几分钟完成过去半天的活

如果让我用一句话总结：

AI 不是来取代开发者的。 是来让开发者只做"只有人类能做的事"。

格式化代码、扫空指针、生成样板测试、跑回归验证------这些事情人可以做，但不该花时间做。交给 AI，你的精力就能集中在产品设计、架构决策、用户体验、技术创新上。这些才是开发者真正的价值。

2026 年的 AI 工具远不完美。它会误报，会幻觉，会生成看起来对但实际不对的代码。但它已经能每天帮你省下 1-2 小时的重复劳动。这条线只会越来越陡------今年省两小时，明年可能省四小时。

不是"要不要用"的问题，是"怎么用好"的问题。

感谢读完这个系列的每一位。如果你在实践中有更好的经验或踩了不同的坑，欢迎留言交流。下个系列见。

AI提效Android开发系列 · 完结

从需求到上线，用AI重塑Android开发全流程

第1篇：AI提效Android开发全景图：从需求到上线的AI工具链

第2篇：AI驱动需求梳理与Spec编写：让PRD自动变成技术方案

第3篇：AI编码提效实战：Skill、Rule与上下文工程

第4篇：AI Code Review：让每一行代码都有AI审查员

第5篇：AI Bug修复与测试生成：从崩溃日志到修复PR的自动化（本篇）

--- 技术博客 · 叶聪路 ---