用 AI 写 Android 需求：少踩坑的实战心得

先说结论

用 AI 写 Android 代码这事，我折腾了一段时间，最大的感受就是------AI 写出来的代码质量，八成取决于你怎么"喂"它。

很多人第一次用的时候都会觉得"哇好厉害"，第二次就开始骂"这写的什么玩意"。其实不是 AI 变笨了，是你第一次恰好问了一个它训练数据里烂大街的问题（比如写个 RecyclerView adapter），第二次碰到了你项目里特有的逻辑，它就开始胡编了。

所以这篇文章不是教你怎么用 AI 工具，而是聊聊怎么才能让 AI 生成的代码真正能用，而不是看着像那么回事、一跑就崩。

一、最重要的一件事：让 AI 知道你的项目长什么样

这一点怎么强调都不过分。

你想想，你让一个刚入职的校招生写代码，你不给他看项目代码、不告诉他架构分层、不说命名规范，他写出来的东西能直接用吗？AI 也一样，甚至比校招生更需要这些信息------因为校招生好歹会自己翻翻项目，AI 不会，你不喂它就真的不知道。

具体怎么做：

把你项目中已有的同类代码 直接贴给它当范例。比如要新写一个 Service，就把已有的 DepartmentService.java 丢给它，跟它说"照着这个风格来"。这比你用文字描述半天架构有用得多。

再比如我们项目里日志统一用 WwLog.i(TAG, msg)，你不说的话 AI 百分百给你写成 Log.d("tag", "xxx")------它又不知道你项目里有自己的日志工具。

二、需求一定要拆，别一口气让它全写了

我之前犯过一个错误：需求评审完，我直接把 PRD 里一整段功能描述丢给 AI，让它"帮我实现一下"。结果它确实洋洋洒洒给我生成了好几个文件，但代码之间的调用关系是乱的，数据模型和后端接口也对不上，基本等于白写。

后来摸索出来的经验是：按"数据模型 → Service/Repository → ViewModel → UI"的顺序，一步一步来。

每生成一步就编译一下，确认没问题再继续。这样做看起来慢，实际上比一把梭然后花两小时 debug 快多了。

举个例子，假设需求是做一个会议预约功能：

scss 复制代码

第一步：先定义 MeetingInfo 数据类，把 proto 文件里的字段贴给 AI
第二步：在 MeetingPluginService 里加 createMeeting() 方法
第三步：注册到 ServiceManager（告诉 AI 参考现有的注册方式）
第四步：写 ViewModel
第五步：写 UI

每一步都是小的、可以独立验证的。AI 最擅长的就是这种"边界清晰、上下文充足"的小任务。

三、Android 的坑，你不提 AI 是真的不会注意

这是我吃过很多次亏之后的总结。AI 对 Android 开发有一些"系统性盲区"，以下这些你不在 prompt 里主动提醒，它大概率会忽略：

生命周期问题：AI 经常在回调里直接更新 UI，完全不管 Activity 是不是已经被回收了。我之前让它写的一个网络回调，线上直接崩了一片------就是因为页面已经 destroy 了，回调还在往 TextView 上 setText。现在我每次让它写异步逻辑，都会加一句"需要检查生命周期状态，页面销毁后不执行 UI 操作"。

线程问题：AI 生成的代码有时候会把网络请求写在主线程，有时候在子线程里直接操作 View。你得明确告诉它"网络请求走 IO 线程，UI 更新切回主线程"，最好直接告诉它用协程还是 RxJava，别让它自己选。

RecyclerView 复用 ：这个坑经典到不行了。AI 写 onBindViewHolder 的时候，很喜欢只设置"有值"的情况，不处理"没值"的情况，导致滑动的时候数据错乱。每次涉及列表，我都会提醒"在 onBindViewHolder 中重置所有控件状态"。

Context 使用：让 AI 写单例或者工具类的时候，它特别喜欢持有 Activity Context，内存泄漏就这么来的。

说实话这些坑，对有经验的 Android 开发来说都是常识。但问题是 AI 没有经验，它只有训练数据。你得把你的经验"翻译"成它能理解的指令。

四、一个容易被忽视的大杀器：让 AI 反过来审查代码

代码写完之后不要急着提交，把生成的代码再丢给 AI，让它扮演 Code Reviewer 的角色：

"检查这段代码有没有空指针风险"
"这里有没有线程安全问题"
"跟这个 proto 定义对一下，字段映射齐不齐"

我实际操作下来，这一步能发现大概 30% 的问题。有点像自己写完文章再通读一遍------写的时候沉浸在逻辑里容易忽略细节，换个视角就能看到。

当然 AI 审查也不是万能的，业务逻辑对不对这事还是得你自己把关。AI 能帮你抓空指针、抓线程问题、抓资源泄漏，但它判断不了"这个场景下到底应该弹 Toast 还是弹 Dialog"。

五、把团队踩过的坑沉淀成"AI 规则"

这是我觉得 ROI 最高的一个动作。

很多 AI 工具支持项目级的配置文件（比如 .cursorrules、.codebuddy/rules），你可以在里面写上团队的编码规范和历史教训。这样每次 AI 生成代码的时候，这些规则会自动作为上下文注入，不用每次都手动提醒。

比如我们项目之前踩过的坑：

TopBarView 里 setPadding 没考虑 RTL 布局导致阿拉伯语环境下界面错乱，后来统一改成了 setPaddingRelative
ExternalPayService 的回调没做生命周期检查，页面关了回调还在执行，直接崩

这种项目特有的坑，你不写下来，每个新需求 AI 都有可能再踩一遍。写进规则文件里，一劳永逸。

六、我现在的工作流

复制代码

拿到需求
  ↓
拆成 5~8 个小步骤
  ↓
每个步骤准备好上下文（范例代码 + proto + 约束条件）
  ↓
让 AI 逐步生成，每步编译验证
  ↓
生成完让 AI 自查一轮
  ↓
自己再过一遍业务逻辑
  ↓
提交

整个流程跑下来，我的感受是：写代码的时间确实缩短了不少，但省下来的时间大部分花在了"准备上下文"和"验证结果"上。总体效率提升大概在 30%~50%，主要看需求的复杂度------越是模式化的代码（CRUD、列表页、表单页），AI 的加速效果越明显；越是涉及复杂业务逻辑和边界条件的，人工介入越多。

最后说两句

AI 编程工具发展很快，但至少在现阶段，它的定位更像是一个特别能干但需要详细指导的初级开发。你给它清晰的上下文、明确的约束、合理的任务粒度，它就能输出高质量的代码；你要是什么都不说就让它自由发挥，那出来的东西大概率要你花更多时间去修。

说白了，用好 AI 的关键不是学会什么高级 prompt 技巧，而是把"我脑子里知道但没说出来的东西"整理清楚，显式地告诉它。这个过程本身，其实也在帮你把需求和技术方案想得更透彻------这算是一个意外的收获。