AI辅助Android开发实战：提示词、代码生成与审查

聊起Android开发，现在已经很少有人能绕开AI编程这个话题了。我从最早用代码补全功能，到后来把AI当成日常开发里的“结对同事”，前后折腾了一年多，踩过不少坑，也整理出一套比较顺手的流程。今天这篇就想围绕“用AI进行Android编程”这一个核心主题，把我实际在Android Studio里怎么配置AI、怎么写提示词、怎么让AI生成能落地的代码，以及遇到的一堆稀奇古怪的报错，全部摊开聊一聊。不管你是刚上手AI辅助开发的新手，还是已经用了一段时间但总觉得AI生成的代码不听话的老手，这篇文章里应该有可以直接照抄的经验。

1. 用AI做Android开发的核心思路与场景

1.1 为什么现在AI辅助Android开发是可行的

先聊一个基础问题：AI到底能不能真的帮上Android开发的忙？我的答案是能，而且现在正是性价比比较高的阶段。

原因有三点。第一，大模型本身的能力已经发生了质变。早两年的代码补全基本只能接着你写了一半的变量名往下猜，现在的主流AI编程助手已经能做到“你给它一个功能描述，它给你一段完整可编译的代码”，这个差距是跨级别的。第二，Android开发本身有大量“模板化”工作。布局XML、ViewHolder、Adapter、ViewModel的样板代码、网络请求封装、数据类定义，这些内容重复度高、结构性强，恰好是大模型比较擅长的领域。第三，Android生态的公开样本足够多。从官方文档到开源项目，再到Stack Overflow上无数问答，AI训练语料里Android相关的代码覆盖率非常高，所以它生成的Kotlin代码通常像模像样。

打个比方，现在的AI编程助手就像一个“熟手实习生”：你给它交代清楚需求，它能很快把初稿写出来，但交出的东西能不能用、有没有踩坑，仍然需要你来验收。理解这个定位很重要——AI不是要替代你，而是帮你把写“流程代码”的时间节省下来，让你把精力放在架构、业务逻辑和代码质量这些更值得投入的地方。

1.2 AI在Android开发中最能省时间的几个场景

用了这么久，我总结出几个AI真正能明显提升效率的场景，按省时间程度从高到低排：

• 生成布局XML：你描述一个卡片布局或列表页面，AI直接给你一套带约束布局的XML，比自己手写快非常多。
• 写样板代码：Data class、RecyclerView.Adapter、ViewHolder、ViewModel这些固定结构，AI几乎不会出错。
• 网络层搭建：Retrofit接口定义、数据模型、响应状态封装，只要把接口文档丢给它，基本能一步到位。
• 单元测试生成：给AI一个类的代码，让它写边界用例和异常分支的测试，能覆盖到很多你原本懒得写的情况。
• 解释报错：Logcat的堆栈信息扔给AI，省掉自己去查源码定位的时间。
• 代码重构：把一坨写得很乱的逻辑丢给AI，让它拆分函数、消除重复，具备参考价值。

反过来，也有一些场景我不建议交给AI，比如涉及支付、登录鉴权这类对安全性要求极高的核心链路，以及公司内网私有化的业务规则。这些地方我还是坚持人肉review为主，AI只用来做辅助讨论。后面第6节我会再展开聊。

2. AI编程工具选型：哪个更适合Android

2.1 主流AI编程助手横向对比

市面上的AI编程工具不少，关键是要选一个能跟Android Studio生态无缝配合的。我把用过的几个整理成了一张表：

实话说，工具没有绝对的好坏，关键看你的使用习惯和工程环境。如果你想把AI融入日常Android开发的每一个动作，那选择一款能直接装进Android Studio的插件是更实在的方案；如果你更习惯把需求整理成文档再交给AI做整体设计，那一个对话能力更强的通用AI产品会更顺手。

2.2 我的选择与理由

我现在的主力方案是“Android Studio + 通义灵码”打底。主要原因是它跟Android Studio的集成比较深，补全、行内对话、代码解释都够用，而且中文理解能力强，我给它写中文提示词它能直接生成中文注释的代码，这点对团队协作很有价值。之前的项目我也用过GitHub Copilot，它的补全确实灵敏，但和团队内其他同事的工具统一性、License成本这些现实问题叠加起来，最后还是换掉了。

对话式的AI我习惯用国产通用大模型产品来处理“整体设计类”的问题，比如“设计一个支持搜索和缓存的新闻列表模块”，这类问题需要多轮讨论、输出方案文档，而我日常打开Android Studio的时间已经很长了，把这类问题放在聊天窗口里反而更专注。所以要问我的建议，就是两条线并行：IDE插件负责代码级协作，通用对话AI负责方案级讨论，两者形成互补。

3. AI辅助Android开发的实操要点

3.1 提示词怎么写，AI才能真的懂你

很多人在抱怨AI生成的代码没法用，其实根源多半不在AI，而在提示词质量。就像带实习生，你说“帮我做个列表”，他可能给你一个写死的线性布局；你说清楚“我要一个分页加载的RecyclerView，数据来自网络接口，加载失败要显示重试按钮”，他才能给你像样的东西。

我总结了一套亲测有效的提示词四要素：角色设定 + 明确需求 + 约束条件 + 输出格式。拿写一个新闻列表举例，低质量的问法是这样：

code复制帮我写一个RecyclerView列表。

这种提示词能返回的只有通用代码，大概率还得你自己改半天。换成下面这种写法，效果完全不同：

text复制你是一名熟悉Kotlin和Android开发的资深工程师。现在需要实现一个新闻列表页面，使用RecyclerView展示新闻卡片，具体要求如下：

1. 每个条目显示标题、来源、发布时间和封面图。
2. 使用ViewModel + StateFlow管理UI状态，支持分页加载。
3. 数据通过Retrofit请求接口，接口路径为 GET /news?page={page}。
4. 已有 NewsService 接口，方法为 suspend fun getNews(page: Int): NewsResponse。
5. NewsResponse 包含 data: List<NewsItem>，NewsItem 包含 title、source、publishTime、coverUrl 字段。

约束条件：
- 使用Kotlin语言，不要使用Java。
- 不使用DataBinding，使用ViewBinding。
- 注意空安全和协程，所有IO操作放在Dispatchers.IO。
- 只需要输出ViewModel和Adapter的核心关键代码，不用输出布局文件。
- 关键逻辑要加上中文注释。

看到差别了吗？角色设定让AI进入Android工程师的状态；明确需求列出了数据源、接口、字段；约束条件排除了你不想要的技术方案；输出格式则帮你过滤掉无关内容。这样得到的代码，可用率会高很多。

3.2 从设计到代码：一个完整的AI辅助开发链路

我经常看到有人把AI当成“一次性问答工具”，问完一个就完事。但实际上，把AI嵌入到开发流程里，价值才会被放大。我现在的标准链路是五步：

• 需求澄清：先把自己的需求用两三句话发给AI，让它反问澄清问题。这一步能发现自己遗漏的边界条件，比如空列表怎么显示、加载失败要不要重试、分页大小默认多少。
• 架构设计：让AI给出模块划分、类职责和关键接口，先不要急着写代码。等宏观设计确认了，再进入编码。
• 代码生成：把大需求拆成小任务，一点一点让AI生成。一次让AI写整个模块，它很容易自己前后矛盾，拆小之后每段质量都更高。
• 代码审查：把AI生成的代码再丢回AI，让它站在审查者角度找问题。我经常让它“检查这段代码是否有内存泄漏、线程安全问题、空指针隐患”。
• 单测生成：最后让它补一组单元测试，覆盖正常、异常、边界三种场景，完整度比自己写高不少。

这套链路的核心思想是把AI当作一个可以无限对话的协作者，而不是一个“搜索按钮”。刚开始会感觉多花了一点时间，但长期执行下来，代码质量和研发速度都能明显提升。

4. 实战案例：用AI从零实现一个新闻列表模块

4.1 需求描述与第一版提示词

纸上谈兵没意思，我拿一个实际做过的功能来演示。假设我们要在App里增加一个新闻列表模块，包含下拉刷新、分页加载、加载失败重试三个能力。我按下述提示词给AI：

text复制你是一名资深Android工程师。请实现一个新闻列表模块，使用Kotlin + MVVM架构。具体要求：

1. 页面由Fragment承载，使用RecyclerView展示列表。
2. 数据源使用Retrofit，已有接口 NewsService.getNews(page: Int, pageSize: Int): NewsResponse。
3. NewsResponse 结构为 data: List<NewsItem>，NewsItem 包含 title、source、publishTime、coverUrl、url 字段。
4. 使用ViewModel + StateFlow实现UI状态管理，状态包括 Loading、Success、Empty、Error 四种。
5. 支持下拉刷新和上拉加载更多，分页大小为20。
6. 使用ViewBinding，不引入额外的框架。
7. 重点关注空安全、协程调度和页面销毁时的数据安全问题。
8. 请输出 NewsViewModel、NewsAdapter、NewsFragment 三个类的完整代码，以及必要的状态定义。

这算是一个中等复杂度的需求。AI给的第一版代码里，NewsViewModel的逻辑基本是对的——用MutableStateFlow保存状态，用viewModelScope发起请求，Success时更新列表，Error时置为错误状态。NewsAdapter也正确实现了DiffUtil和加载更多脚布局的逻辑。整体跑起来没问题，但细看有几处只能靠人来发现的问题。

4.2 AI生成的代码如何审查与迭代

第一版代码能编译能跑，但不代表可以拿去上线。我审查时发现了几个问题，这里列出来给大家当参考：

• 分页数据重复：AI在加载更多成功时直接用了 _list.addAll(response.data)，但如果触发刷新后还没清空旧列表，就会造成数据重复。我让AI加了 clear() 逻辑，并且用请求编号来区分刷新和加载更多。
• 线程调度问题：第一版里所有逻辑扔在 viewModelScope.launch(Dispatchers.IO)，但更新StateFlow时没有切回主线程。虽然StateFlow本身线程安全，但后续在Adapter里直接操作列表就可能出问题。我让AI把IO调度只用在网络请求处，UI更新留在主线程。
• 图片加载依赖未声明：AI在Adapter里顺手写了 ImageLoader.load(coverUrl)，但这并不是我项目里存在的方法。它是根据自己的训练知识编了一个通用工具类出来。这种情况必须替换成项目里真正在用的Glide或Coil。

发现这些问题后，我直接把审查意见返回给AI：

text复制你的代码有以下问题，请修改：
1. 刷新成功后需要清空旧数据再添加新数据，加载更多时按页码追加。
2. Retrofit请求不要直接放在IO线程，请使用Flow的flowOn(Dispatchers.IO)，在collect时保持主线程。
3. 图片加载请改成Coil的加载方式，假设 context 已经通过扩展函数获得：imageView.load(url)。
4. 增加请求状态去重，避免刷新和加载更多同时触发。

这样一轮迭代下来，AI第二次给出的代码就可以直接进入Code Review了。整个过程大概十来分钟，比自己从头写还是快了不少。

4.3 效果验证与最终代码结构

最终模块的代码结构长这样：

text复制news/
├── NewsFragment.kt
├── NewsViewModel.kt
├── NewsAdapter.kt
├── NewsItem.kt
├── NewsRepository.kt
└── NewsService.kt

关键代码可以简化成下面这些片段，方便你感受AI协作的产出质量。先看ViewModel的核心：

kotlin复制class NewsViewModel(
    private val repository: NewsRepository
) : ViewModel() {

    private val _uiState = MutableStateFlow<NewsUiState>(NewsUiState.Loading)
    val uiState: StateFlow<NewsUiState> = _uiState.asStateFlow()

    private var currentPage = 1
    private var isRefreshing = false
    private var isLoadingMore = false

    fun refresh() {
        if (isRefreshing) return
        isRefreshing = true
        viewModelScope.launch {
            repository.getNews(1, PAGE_SIZE)
                .onStart { _uiState.value = NewsUiState.Loading }
                .catch { _uiState.value = NewsUiState.Error(it.message ?: "unknown error") }
                .collect { response ->
                    isRefreshing = false
                    currentPage = 1
                    if (response.data.isEmpty()) {
                        _uiState.value = NewsUiState.Empty
                    } else {
                        _uiState.value = NewsUiState.Success(response.data)
                    }
                }
        }
    }

    fun loadMore() {
        if (isLoadingMore || _uiState.value !is NewsUiState.Success) return
        isLoadingMore = true
        viewModelScope.launch {
            repository.getNews(currentPage + 1, PAGE_SIZE)
                .catch { isLoadingMore = false }
                .collect { response ->
                    isLoadingMore = false
                    currentPage += 1
                    val oldList = (_uiState.value as NewsUiState.Success).data
                    _uiState.value = NewsUiState.Success(oldList + response.data)
                }
        }
    }
}

这段代码已经是我和AI一起迭代后的结果，核心逻辑没有太大问题。但注意我这里故意保留了一个隐患：没有处理“刷新成功但返回空数据时，当前列表应该清空显示空页面”的情况。实际项目里这种边界逻辑非常多，如果你完全信任AI生成的一次性代码，就很容易翻车。

5. 常见问题与排障实录

5.1 生成代码报错的排查思路

AI生成代码不可能一次跑通，报错是常态。常见报错可以归成几类，我整理了一个速查表：

遇到报错时，我的排查习惯是先把AI生成的代码再扔回AI，让AI自己解释报错原因。多数时候它能直接指出问题在哪里。如果它自己都解释不了，就用官方文档兜底，去查当前SDK版本下正确的API调用方式。

5.2 AI“幻觉”代码的高发点与应对

AI“幻觉”在编程场景里其实很常见，表现就是生成了一个根本不存在的类、方法或参数，但看起来很合理。最典型的就是我前面遇到的 ImageLoader.load()。这类问题的背后机制是，大模型训练时见过大量代码，它会按“概率最高”的组合方式生成内容，而不是真的有逻辑地查证这个方法在你的项目里是否存在。

几个高发点需要重点警惕：

• 第三方库API：特别是那些更新频繁的开源库，比如图片加载、网络请求、数据库框架，AI经常会把老版本API和新版本API混在一起。
• Android新版本特性：AI对比较新的SDK版本的掌握往往滞后，容易生成基于旧版本API的代码。
• 自定义类/方法：AI很容易根据上下文“脑补”出并不存在的封装方法。

应对方法也很朴素：在提示词里明确告诉AI不要自己创建新工具类；如果用了第三方库，要求标注出库名和版本；生成的代码里出现任何没见过的类，第一反应是回头查文档，而不是相信它。“AI生成代码没问题吗”这个问题的答案其实是：有时候问题很大，所以要习惯对每段生成的代码做代码审查。

6. 经验总结与建议

6.1 适合用AI的场景与不适合用AI的场景

用久了之后，我对AI能力的边界认知越来越清晰。它适合处理的是：

• 信息密度低但不允许出错的模板代码
• 技术调研和API用法的快速验证
• 单元测试和注释的补全
• 代码解释和文档生成
• 让你快速搭建一个可运行的原型

不适合的是：

• 核心业务规则和计费逻辑
• 任何涉及用户敏感信息的处理流程
• 需要深入业务上下文才能做的架构决策
• 性能瓶颈的排查和优化方案

最危险的一种使用方式是：让AI写一段涉及业务规则的核心代码，然后不审查直接上线。AI会认真地把代码写完，但它的“认真”不等于“理解”，业务边界错了，它可以在代码层面毫无破绽。

6.2 建立自己的AI协作流程

如果你看完前面的内容只记住一句话，我希望是：AI编程的核心不是“让AI写代码”，而是“建立一套围绕AI的协作流程”。

我自己现在的工作方式是这样的：先把需求文档化，把功能拆成足够小、可验证的任务；每个任务交给AI之前，我会想清楚验收标准；AI给出代码后，第一步不是运行，而是先做代码审查，带明确目的去查数据安全、线程调度和边界条件；确认没有明显问题后，再编译运行；运行通过后，让AI补一圈单元测试。整套流程走下来，AI的可用率大大提升，而我也始终没有失去对代码的掌控力。

7. 最后再分享一点个人体会

玩AI编程这一年多，我最大的感受是：工具变化快，但基本功永远重要。提示词写得再花哨，如果自己看不懂生成代码的问题，那AI只会放大前期设计上的错误。反过来，只要你自己肚子里有货，知道什么代码是好的、什么方案有隐患，AI就是一个非常省力的助手。

我最后建议每个Android开发者都找时间把市面上能装进Android Studio的AI插件挨个试一遍，不用多，每个花一两天感受一下补全质量和对话能力，然后选定一个主力工具，坚持用上两周。那时候你自然会形成自己的提示词习惯和审查流程，也就真正体会到“用AI进行Android编程”这件事的价值了。