用 AI 写代码一年后，Android 工程师的真实体验

用 AI 写代码一年后，Android 工程师的真实体验

2025 年是 AI 编程工具爆发的一年。Copilot、Cursor、通义灵码轮番出圈，朋友圈里"AI 替代程序员"的声音此起彼伏。作为一个写了多年 Android 的工程师，我决定认真用一年，再来说说心里话。

最初的抗拒

说实话，最开始接触 AI 写代码的时候，我的第一反应是："这玩意儿能懂 Android？"

毕竟 Android 生态够复杂：Jetpack 各种组件、Gradle 构建体系、各厂商的适配坑……这些东西光靠搜索引擎都经常找不到答案，AI 能行？

但身边的同事越用越上头，我也就硬着头皮试了。这一试，就是一整年。

写 Compose UI 的体验

如果要说 AI 在 Android 开发中最能打的场景，我毫不犹豫地说：写 Compose UI。

Compose 的声明式写法天然适合 AI 补全——结构清晰、模式固定。你只需要用注释描述想要的效果：

// 一个带头像、昵称和简介的用户卡片，支持点击跳转 @Composable fun UserCard(user: User, onClick: () -> Unit) {

剩下的 AI 几乎可以全部帮你填完，而且效果相当不错。以前写一个稍微复杂点的自定义 UI 组件要半小时，现在10分钟出头，剩下的时间用来改细节和调样式。

模板代码的效率提升

Android 里有大量模板代码：Retrofit 接口定义、Room DAO、各种 Builder 模式……以前写这些是真的无聊。

现在我的习惯是：写好一个接口的注释，让 AI 直接生成整个 Retrofit Service，包括参数类型和注解。准确率大概在 85% 以上，剩下的手动微调就行。

写单元测试也是一样。把被测方法贴进去，让 AI 生成测试用例，它会自动处理 Mock 和边界情况，我只需要检查逻辑是否合理。这一块效率提升最明显，以前能拖就拖的测试，现在反而愿意写了。

AI 的幻觉问题

当然，也有很多翻车时刻。

印象最深的一次：线上有个偶现的 ANR，堆栈指向一个很奇怪的地方。我把堆栈和相关代码都贴给 AI，它信誓旦旦给了一个解决方案——修改一个完全不相关的线程池配置。

我照着改了，当然没用。最后自己排查了两个小时，发现是某个第三方 SDK 在主线程做了 IO。

⚠️ 经验教训：AI 最怕的是复杂的运行时问题和多线程 Bug。这类问题还是得靠自己的 systrace、perfetto 老老实实分析，别指望 AI 一眼看穿。

还有一次让它帮我写一段兼容 Android 9 和 Android 14 的权限申请逻辑，结果它给的代码在 Android 12 上直接崩溃，原因是没考虑 `BLUETOOTH_CONNECT` 的新权限变更。Android 碎片化的问题，AI 的知识库有时候是跟不上的。

效率的变化

用了一年，我的感受是：

变快了的： 模板代码、UI 组件、单元测试、文档注释、正则表达式、SQL 查询……凡是"有规律可循"的东西，效率至少提升 50%。

没变化的： 复杂业务逻辑的拆解、架构设计、性能调优、多线程问题排查。这些本质上是思维密集型工作，AI 只能打打辅助。

反而变慢的： 理解 AI 生成的代码。有时候 AI 用了一个我不熟悉的写法，我得花时间搞清楚它在做什么，再决定要不要用。这个隐性成本不可忽视。

会被替代吗

被问过很多次：AI 会替代 Android 工程师吗？

我的答案是：替代那些只会写模板代码的工程师，是迟早的事。 但真正理解业务、能做系统设计、有调优经验的工程师，短期内不会。

更重要的是思维方式的转变——从"我来写代码"变成"我来描述需求、审查代码、把控质量"。AI 是一个执行力很强但判断力很差的实习生，你得学会当好 Tech Lead。

会用 AI 的工程师，和不会用的工程师，产出差距会越来越大。这才是真正值得警惕的地方。

最后

用 AI 写代码这一年，我没有变得更懒，反而思考更多了——因为把时间从"敲模板代码"解放出来之后，我有更多精力去思考架构、读源码、做深入优化。

工具从来不是威胁，停止成长才是。

如果你还没开始认真用 AI 辅助开发，现在是最好的时机。如果你已经在用了，不妨想想：你有没有把省下来的时间，用在更值钱的地方？

— END — 觉得有用的话，点个在看 👇