Android Studio的11种双子星工作流程：测试、预览、智能体模式以及崩溃处理。

Android开发者几乎不需要另一份精巧的AI提示词列表。真正有帮助的是更少的上下文切换、更快的反馈循环，以及能节省在机械性任务上的时间。正因如此，Android Studio中的Gemini才显得不可或缺。

不要把它当作可以让你放手不管、独自完成功能的队友，而应视其为IDE内的高效协作编程伙伴。它擅长分析陌生的代码、起草重复性工作内容、解读混乱的错误信息，还能将多个小步骤整合成一份可供审查的差异对比。

精确性正是两者之间的区别所在。像“开发这个功能”这样的请求太过模糊，无法直接执行；而要求Gemini遵循状态流程、提出最小的修复方案、运行相关测试并展示差异对比，这才体现了真正的工程实践价值。

截至2026年9月，Android Studio中的Gemini可在Agent模式下处理多个文件，同时进行多轮对话，生成单元测试和Compose预览，帮助解决构建问题及Logcat错误，分析App Quality Insights中的崩溃情况，更新依赖项，甚至还能部署到连接的设备上并与之交互。这些都是有文档记载的产品功能，而非臆想的演示，Gemini的功能概览中也列出了这些功能。实际问题在于如何使用它们，以避免因使用这些功能而产生的审核工作量超过其节省的工作量。

以下工作流程在日常的Android开发中始终能带来实际效益。

1. 为Gemini提供一次项目结构说明

最有效的提示往往并非文字提示，而是一份与代码一同提交的简短AGENTS.md文件。

Gemini 会读取工作目录及其所有上级目录中的 AGENTS.md 文件。这样你就可以在仓库根目录放置通用规则，而在各个模块中添加更具体的指导说明。由于该文件与代码存储在一起，整个团队都能通过版本控制获得相同的说明。代理文件的相关文档中会有详细内容。

# Android project guidance
- Kotlin only.
- Follow the existing Clean Architecture boundaries.
- Keep business logic out of Composables and Activities.
- Expose immutable UI state from ViewModels.
- Collect Flow with lifecycle awareness.
- Prefer the libraries already used in the target module.
- Make the smallest safe diff; do not reformat unrelated files.
- Add or update tests for changed behavior.
- Before finishing, run the narrowest relevant Gradle test task.

在多模块应用中，可在规则不同的地方添加本地文件：

AGENTS.md
player/AGENTS.md
androidtv/AGENTS.md
billing/AGENTS.md

此处简洁为要。值得包含的内容有：架构决策、各模块的起始位置、您偏好的测试库，以及严禁他人触碰的区域。200行的宣言很快就会变成过时的参考信息。

请核实版本细节。从 Android Studio Narwhal 4 Feature Drop Canary 4 版本起，文档 AGENTS.md 即被支持，而 Narwhal 3 Feature Drop 版本则要求使用单一的 AGENT.md 文件。在认定该文件有效之前，请先确认您的 IDE 版本。

2. 使用四行任务简述

更长的提示语并不一定更好。一种可靠的简短格式包含四个部分：

Goal: Add retry support to PlaybackRepository.
Context: Inspect PlaybackRepository, its interface, and existing tests.
Constraints: Preserve public APIs; use the existing coroutine/test stack; minimal diff.
Verification: Add failure-then-success tests and run the relevant module test task.

它的有效性在于消除了四种常见的歧义：需要改变什么、去哪里查找、什么必须保持稳定，以及“完成”意味着什么。

对于高风险工作，还需添加一行内容：

Before editing, explain the likely root cause and propose a plan.

对于常规任务，不必繁琐流程，直接询问差异即可。提示语的规模应与风险程度相匹配。

3. 保持上下文简洁并分离线程

如果提供的上下文大多与问题无关，反而会降低回答质量。当这些信息足以用于分析变更时，只需附上ViewModel、状态模型、仓库契约及相关测试，其余应用程序部分则无需包含。Android Studio允许直接将项目文件附加到查询中。

为不同的任务使用独立的线程，例如：

• 播放故障处理
• 依赖项迁移
• 测试生成
• Compose界面开发

Gemini能够记住对话历史。Google指出，通过将上下文限制在当前主题内，不同的对话线程可以提高响应质量；而当聊天内容偏离主题时，清除过时的历史记录也有帮助。详情请参阅“与Gemini聊天”。有一个简单的规则：如果你的下一个提示词需要包含“忽略以上所有内容”这样的短语，那就开启一个新的对话线程。

4. 让“下次编辑预测”处理繁琐的后续修改

自动补全功能是在光标位置起作用的，而“下次编辑预测”则更进一步，能够猜测文件或项目中其他地方可能需要进行的相应修改。在以下类型的修改之后，它尤其能发挥重要作用：

• UI状态新增的属性
• 被重命名的密封类实例
• 被修改的函数签名
• 刚刚更新过的重复映射中的某个分支
• 相邻位置也需要使用的相同防御性检查

当编辑器显示“按 Tab 键移动”时，第一次按下 Tab 键会跳转到建议的修改位置，第二次按下则应用该修改。如果猜测有误，请按 Esc 键。可以在 AI 编辑器设置中暂停预测功能，并调整请求发送前的延迟时间，相关说明可见“下次编辑预测”页面。

习惯性立即接受建议是个坏毛病。哪怕只是快速进行了一次错误的编辑并复制到多个文件中，依然属于功能退化。

5. 从错误信息入手提问

当 Gradle 同步失败或应用崩溃时，IDE 已经掌握了结构化的上下文信息。此时可直接使用“询问 Gemini”功能，而无需将杂乱的信息粘贴到聊天框中。

在 Logcat 中，Gemini 可以接收相关的堆栈跟踪信息，并用通俗的语言给出总结、可能的原因以及建议的解决方案。Logcat 集成文档中有相关说明。后续提出疑问进行追问的功能也运行良好：

Trace this to the first frame owned by our app. Explain the state that makes it fail.
Propose the smallest fix, identify any behavior change, and add a regression test.
Do not hide the problem with a broad try/catch or a non-null assertion.

那条最终指令可以避免两种常见的“绿色构建、糟糕修复”的情况。

当构建失败时，让 Gemini 区分根本错误与其引发的连锁故障。通常修复最早出现的有效错误比处理40条后续错误信息要快。

6. 根据行为而非实现方式生成测试

Kotlin或Java编写的完整单元测试类，包括初始化代码、模拟对象以及各个测试用例，都在 Gemini 的处理能力范围内，而且它会根据项目的现有配置进行相应调整。谷歌仍将整个流程称为预览版，并为 Android Studio Panda 4 Canary 3 或更高版本提供了相关文档。单元测试生成页面上有详细说明。

一个不明确的请求示例如下：

Write tests for PlaybackViewModel.

一个实用的样子如下：

Generate unit tests for PlaybackViewModel.
Cover observable behavior:
- initial state;
- successful playback start;
- repository failure;
- duplicate play requests;
- cancellation when the ViewModel is cleared.
Use the test libraries and coroutine dispatcher pattern already present in this module.
Do not test private methods or reproduce the implementation in the assertions.
Use deterministic virtual time and verify emitted UI states in order.
Run the narrowest relevant test task after editing.

仔细审查其生成的代码。思考每个测试是否可能因合理原因而失败。常见的问题包括过宽松的模拟环境、与测试设置重复的断言、真实的延迟、未覆盖取消操作，以及过度依赖私有实现细节的测试。

AI很擅长消除开发中的冗余障碍，但它并不能决定你的测试策略。

7. 在打开模拟器之前生成 Compose 预览

预览是获取 Compose 开发反馈的廉价方式，但编写真实的预览数据却是一项枯燥的工作。Gemini 可以为单个 Composable 或文件中的每个符合条件的组件生成预览，并包含用于预览参数的模拟数据。你将以差异对比的形式查看结果，进而决定是否接受。详情请参阅“生成 Compose 预览”。

仅凭正常流程的测试几乎无法证明什么，因此需要获取状态矩阵的完整信息：

Generate previews for compact phone, tablet, and Android TV widths.
Include loading, populated, empty, long-title, and error states.
Use the existing theme and PreviewParameterProvider pattern.
Do not call a ViewModel, network layer, or dependency injection from previews.

预览功能实际上起到了低成本设计测试的作用。在处理过长的标题、空白内容、焦点控制以及大屏幕场景时，布局假设往往会出现问题。

针对Android TV，应明确要求生成有焦点和无焦点的版本。在触摸操作下表现良好的布局，一旦用遥控器的方向键来导航，就可能会崩溃。

8. 将智能体模式应用于有限的垂直范围

在智能体模式下，Gemini能够为多步骤任务制定计划、编辑多个文件、运行工具、构建项目，并在出现故障时重新尝试。如智能体模式文档所述，同时进行多轮对话也是可行的。

最佳做法是限定在一定的垂直范围内处理，而非试图“实现应用现代化”。例如：

Add a Saved Episodes filter to the Downloads screen.
First inspect the existing state, reducer/ViewModel, domain model, repository, and tests.
Reuse the current filter component and architecture.
Do not change persistence or navigation contracts.
Implement the smallest complete slice, add tests, build the module, and summarize every file changed.
Pause before any public API or database schema change.

这样的任务规模适中，适合通过跨文件协作来完成，同时又小到足以让人亲自审查。

仅对独立的任务启用并行处理，例如在一个线程中生成测试用例，同时另一个线程处理无关的构建警告。若有两个智能体同时处理重叠的文件，就容易产生相互矛盾的假设。

9. 要求智能体在设备上验证 UI 变更

代码差异并不能证明 UI 功能正常运行。

Android Studio 中的智能体可以将构建结果推送到连接的设备上，查看屏幕内容、截取截图、读取 Logcat 日志，并通过输入工具操控设备。在完成 UI 修改后，这样的验证提示就能形成完整的闭环：

Build and run the app on the connected device.
Open the Downloads screen, apply the Saved filter, and verify the empty and populated states.
Capture a screenshot of the final state and check Logcat for new errors.
If verification fails, stop and report what you observed before making another broad change.

凡是涉及登录、购买、破坏性操作或真实用户数据的情况，都应让相关人员参与审批流程。虽然能够访问设备会提升智能体的功能，但这并不意味着它就值得信赖。

10. 将生产环境中的崩溃数据作为分析起点

在 App Quality Insights 中，你可以让 Gemini 对崩溃情况进行总结，指出问题出现的文件，描述可能的原因，并起草代码修改方案。Google 的崩溃分析指南会对这些步骤进行详细说明。

一些有用的后续问题包括：

What evidence in this stack trace supports that root cause?
Which assumptions are you making?
Could this be lifecycle-, concurrency-, process-death-, or device-specific?
What telemetry or test would distinguish the alternatives?

生产环境崩溃往往暴露出单条堆栈跟踪信息无法解释的时序与状态问题。摘要能节省阅读时间，但相关假设仍需验证。

11. 每次只更新一个受限的依赖组

依赖管理工具可以查找兼容的更新版本，修改项目代码，处理由此产生的构建错误，运行测试，并生成包含每份文件差异对比的报告。相关内容详见“自动化依赖更新”部分。

虽然功能强大，但仍需控制影响范围：

Update only Kotlin coroutines and the related test artifact.
Do not update AGP, Kotlin, Compose, Gradle, or unrelated libraries.
Read the relevant migration notes first.
Build affected modules, run their unit tests, and report behavior or API changes.
Stop if the update requires a public API, minSdk, targetSdk, or build-system change.

避免那种将AGP、Kotlin、Compose、序列化、依赖注入以及二十多个库混为一谈的“全面更新”式审查。差异可能几分钟内就会显现，但仍需有人去理解这些差异。

在优化提示词之前保护上下文

当项目上下文共享功能开启时，.aiexclude文件决定了Gemini可以读取哪些内容。其语法与.gitignore类似，每条规则都适用于包含该文件的文件夹及其下的所有内容。AI功能无法看到开放项目及其关联的版本控制根目录之外的任何内容，但这些范围内的敏感文件仍应通过名称被排除。.aiexclude设置页面上有相关操作步骤。

*.jks
*.keystore
local.properties
secrets/
**/production-config.json
**/customer-data/

这两个文件无法互相替代，因此不要将它们混为一谈。在将专有代码或生产数据传送到其他地方之前，先了解您的组织允许的做法。就个人使用层面而言，谷歌的隐私政策说明提示信息、输出结果、使用详情及反馈都可能被人工审核人员收集和查看，同时建议不要输入机密或个人信息。企业协议可能会有所不同，因此请仔细阅读与您账户相关的条款。

审查 AI 修改的60秒规则

在接受 Gemini 的修改结果之前，先问自己六个问题：

1. 该修改是否仅限于您要求的内容？
2. 模块与架构的边界是否保持完整？
3. 它是否创建了新的 API、依赖项或规范？
4. 错误是否真的得到了处理，还是只是被忽略了？
5. 如果功能出现异常，新的测试是否会失败？

构建、测试运行和设备检查能否验证该变更？

如果无法快速得到答案，说明变更规模过大，需将其拆分。

逐步推进的工作流程

最有效的方法是采用简单循环：

说明 → 规划 → 编辑 → 测试 → 运行 → 检查 → 总结。

Gemini在缩短Android Studio内的循环流程时作用最大；而当它提供一大段尚未被存入仓库或实际运行过的Kotlin代码时，作用则最小。

提高打字速度并非提升效率的关键。真正的效率提升来自更早获得的可靠信息：逻辑清晰的堆栈跟踪、能成功编译的测试用例、包含真实数据的Compose预览、来自设备的截图，以及易于阅读的差异对比结果。

让 Gemini 负责处理从初始构想到验证其可行性的整个机械性流程。架构设计、权衡取舍以及责任界定仍是工程师的工作。