写在前面
好久没写文章了，难得有空闲时间，那就坐下来好好和各位小伙伴聊聊最近一年工作的感受和变化吧。
我是一名Android 开发者，哦，不对，现在好像也不能这么介绍了，自从有了AI Agent之后，我们开始去搞IOS 、Flutter 、鸿蒙、uni-app等等，已经不再局限于Android原生开发。如果换做之前，我可以毫不犹豫地说自己是纯粹的Android开发，因为那时候工作边界是非常清楚的，Android就该干属于它的活，偶尔项目需要适配iOS端，也往往是重新组一个团队，或者安排专门的人去开发跟进。
但现在，应该说是2026年之后，甚至于2025年中后，这种边界明显开始松动了。碰到其他端的需求，也不一定非得等专门的人到位，自己先借助AI摸一摸，好像也能做起来。为啥？大家心里都已经清楚了，AI发展太快了。
尤其AI开始真正进入日常开发之后，我越来越觉得，我们之后也不会再那么强调："我是Android开发"。更可能变成："我是做应用开发的，或者说全栈，只不过Android是我最熟的部分。"
对于现在的我们来说，有了AI，跨技术栈已经是家常便饭了。
AI来了以后，最先变化的其实不是技术，而是工作方式
记得之前刚开始用AI写代码的时候，大伙都觉得挺新鲜的，那时候就是简单的提示词工程，确实用起来很爽，但说白了，只是比之前的代码补全更高级一点。
- "写一个实体类，根据JSON生成Data Class。"
- "帮我补一个Retrofit接口。"
- "这个崩溃是什么原因导致的？"
等等，诸如此类。
但是，如果AI只是发展到这里，对于开发来说，其实并不会有多大的影响。真正让我觉得开发方式开始发生变化，就是现在AI已经从"帮我写一段代码"，逐渐变成了"帮我完成一个任务，甚至帮我完成一整个项目"。比如说现在笔者常用的Claude Code 和Codex，已经可以结合项目上下文拆解多步骤任务、修改多个文件、修复问题，在接好工具和设备之后，还可以结合Emulator或者真机对修改结果进行验证。
这个变化说起来其实蛮大的，因为自己就是程序员，所以我还是从技术开发的角度来聊。以前咱们开发的过程大致就是：需求评审->写代码（写bug）->编译->报错->修改->运行->测试。现在更多的是：拿到需求->描述目标、方向->Agent拆任务->AI修改工程->自动编译运行->自动测试验证->人进行Review。
当然人依然在里面，只不过从原来主要负责执行写代码的人，变成了要做统筹决策的人。以前我们最重要的是：我能不能把代码写出来，如何写比较好 ，而现在最重要的是：我知不知道应该写什么，这样写对不对。这两个能力看起来很像，但其实完全不是一回事。
Android CLI 出现以后，这件事情更明显了
今年我觉得一个特别值得Android开发 关注的东西，那就是Google推出的Android CLI 。这可不是之前单纯的adb 工具、gradlew ，而是Google开始提供一个更偏向Agent-first的Android命令行入口。 这具体是干啥用的呢？其实就是把Android开发中常用的工具能力整理成统一入口，让Agent、脚本和CI都能调用。配置环境、创建项目、管理Emulator和SDK、安装运行应用、读取当前页面的UI Layout，这些都有对应的命令，也能通过它获取官方的Skills和开发资料。官方是这么解释的哈：
这时候可能有同学就会说了，这些事情无非就是多几行命令，好像效率也没提升多少吧。单看某一个动作，确实如此，咱们之前用脚本一样能完成很多事情。但把这些动作接到Agent后面，开发过程就有点不一样了。
之前咱们是人工操作AS进行打包，出错了看debug日志，自己改完再点一次运行。现在可以让Agent修改代码后调用Gradle构建，把生成的APK通过CLI安装到设备，再读取页面布局、检查运行结果。中间哪里出了问题，它可以直接拿到反馈后继续处理，咱们也就少了一些复制报错、来回切窗口的操作。这里顺便提一嘴，CLI里的运行命令负责安装和启动APK，构建那些还是得要交给Gradle完成，它说白了就是个中间人。比如咱们做一个登录页，预览里看着没毛病，真机上键盘一弹起来，底下的登录按钮被挡住了。以前可能得自己截图、描述问题，再把图片丢给AI。现在工具接好以后，可以让它在设备上打开页面、聚焦输入框，把这个状态也检查一遍，发现问题后继续调整修改。
所以我觉得值得关注的是这一整段流程能不能连接起来。AI执行完最终结果交接回来的时候，除了代码，还能给出运行截图和检查结果，那Review的时候就有东西可看了。也别只验页面打开了就没毛病，登录按钮到底能不能点、点了以后能不能整个流程能不能走通，有没有边界问题等等，都还得试。
相信AI,但不要过于相信AI。
Agent之后，又出现了一个挺重要的东西：Skill
都说到这里了，那就得简单聊聊Skill 了。如果把Agent 当成一个刚加入项目的同事，那Skill就有点像咱们提前整理好的开发规范文档：碰到这类需求，先看什么，再改什么，做完以后怎么检查。
比如说我直接丢一句"帮我优化一下这个App"，那这个范围就太大了。AI不知道你想要达到什么效果，没有明确的参数。它可能去拆组件，也可能去改缓存，改完一大堆文件，你再问它到底快了多少，它未必拿得出准确的结果，或者拿去的数据也是不太可靠的。但如果把性能排查的步骤写清楚，想要的结果效果一开始写好，要求先复现卡顿、采集Trace、找到耗时位置，再考虑怎么修改，至少这个任务从一开始就有了明确的方向。
另外，谷歌也已经有了自己的Android Skills仓库，里面包括AGP 9升级 、Edge-to-Edge适配、Navigation 3 、R8分析 、测试配置等具体场景。这些Skill按照开放的Agent Skills标准组织，除了说明，还可以配上参考资料和脚本，供支持的工具使用。
当然，装了Skill也不代表就能放心让它一路改到底。拿AGP升级来说，老项目里用了哪些插件，有没有自定义构建逻辑，这些都得结合项目看。官方的流程可以拿来参考，团队自己的约定、踩过的坑，也得慢慢补进去。
我觉得这件事真的还挺适合咱们开发者做的。之前费劲解决过的问题，往往就留在聊天记录或者某篇笔记里，过几个月再碰到，还得翻半天进行查漏补缺。现在可以把那些反复用到的步骤，那些重复任务都整理成Skill ，不要一听到Skill 就觉得它多么复杂，其实这些Skill 就是把你的那些提示词整理成文档，下次直接让Agent照着执行一遍，做完再检查结果，比每次都从头琢磨一大段提示词其实要省心很多。
以后咱们的项目，可不只有代码，还有给AI看的规则
Skill适合处理某一类任务，但项目里还有些约定是每次修改都应该知道的。比如网络层已经封装好了，新增接口就沿用现有写法；页面状态放在哪里，公共组件去哪个目录找；这次只改UI，就千万别顺手把业务逻辑也重构了，这样线上出了问题，重新排查，又无形中增加了开发周期。
当然这些话，如果每次都要重新说，其实也挺烦的。尤其换一个对话之后，刚刚强调过的事又得解释一遍。所以项目里可以放一份AGENTS.md，把常用入口、目录职责、代码规范和验证方式写清楚。AS里的Gemini也支持读取这类项目说明，具体加载方式可以看官方文档。
这里我倒觉得不用一上来就写得多么多么宏大，多么多么高深，什么"你是世界顶级Android架构师，你是资深的Android开发工程师"，这是写给你们团队自己看的，还不如直接告诉它："登录态统一从这里读，别再另外存一份或者自己调整","修改数据库字段要检查Migration""改完这个模块，需要跑哪些测试"。都是小事，但真漏掉了就够咱们返工喝上一壶了。
就比如设计说只要求改一下会员弹窗的样式，背景换个颜色，按钮挪个位置。AI看着旧代码不太顺眼，顺手把点击逻辑也整理了，结果原来应该带过去的商品信息没带，埋点也少了一条。你只看截图还真发现不了，等测试点到购买那一步才知道出问题了。所以"这次改到哪里、哪些行为要保留"，也得给它说清楚。
规则写完也要跟着项目维护。目录搬了、方案换了，项目说明还停留在半年前，AI照着做照样会出问题。而且这份文件本身也不会强制拦住错误操作，该配的权限、该做的Review，还是要有的哈。
所以开发者的执行力，也在重新定义
以前觉得一个同学执行力强，通常就是需求下来很快开工，代码写得快，提测也快。现在AI把写代码的速度提上来以后，光看这一项，好像已经不太够了。
就拿一个登录需求来说，页面、接口、验证码倒计时，AI都能写。但咱们得先确认，登录成功以后回哪里，游客数据要不要合并，Token过期了怎么处理，用户连续点击会怎么样。如果这些没想清楚，它很快就能给你一个看起来完整的登录页，联调的时候却发现到处都得补。
所以现在拿到需求，我觉得更应该先把这些问题理顺，再决定交给AI做到哪一步。界面和接口可以在约定好数据格式后分别推进，但登录态、权限这些关联比较多的地方，就得有人盯着整体流程。让几个Agent同时开工也一样，分工没说清楚，两个都去改同一个公共类，收拾起来未必比自己写省事。
AI写得快的时候，人很容易跟着着急，看到"已完成"就想继续下一个任务。但它说完成了，和这个功能真的能交付，中间还差着咱们的检查。代码是谁写的可以变，出了问题，负责的人还是咱们。
对于自己来说，AI最大的价值之一，是让Android开发更容易跨出去了
前面说了那么多，对于我自己来说，感受最明显的还是开头提到的事：开始愿意去碰其他技术栈了。
以前一个Android 开发要去做iOS，光是Swift 、SwiftUI 、Xcode 这一套摆在面前，就会觉得要重新学好多东西。工作本来就忙，如果没有项目硬性要求，很容易想着等有空再说，然后就一直没空，一直拖着，当然也跟工作太忙有关，哪有那么多时间；亦或者说光是Android 这个领域的东西都学不完，哪有时间接触其他的。Flutter、鸿蒙、前端、后端，其实也是类似的情况。
现在有了AI后可以从自己熟悉的领域的角度出发。比如一个页面在Compose 里是怎么管理状态的，换到SwiftUI以后应该怎么组织；Android里熟悉的生命周期、异步任务，到了另一个平台需要注意哪些区别。先让AI帮忙解释，再做一个小功能，把代码和运行结果对着看，比一开始就啃完整套资料更容易进入状态。
当然，类比只能帮咱们入门，不能直接把两个平台当成一回事。Demo能跑起来以后，签名、权限、后台行为、上架流程这些问题还是会接着来，碰到不确定的地方也得回去查官方文档。只是之前可能卡在"这东西我没接触过"，现在能先动手做，再带着问题补知识。
举个具体点的例子，假设Android端已经有了音频续播，现在要补一个IOS版本,聪明的你会怎么办呢？
咱们要知道，这个功能是要记住当前播放位置的，退出页面再回来还能接着听，就可以先把这段业务流程交给AI，让它帮忙找到IOS侧对应的实现方式。接着再验证锁屏后还播不播、来了电话怎么处理、进度什么时候保存。这样每一步都有一个要解决的问题，学起来就不会那么散。
对开发来说，愿意动手这一步其实挺关键的。真做出一个小功能以后，再往下学就具体多了，然后你就会发现原来Android里积累的网络、存储、状态管理经验，有不少地方是用得上的。
那Android还要不要继续深挖？
我知道肯定很多人都会这么问的，有了AI,我是不是就不用学习了呢？我的想法是，当然要。不能因为现在能写几个端了（要知道这些都是AI帮我们写的)，就把自己最熟的东西也放下。捡了芝麻，丢了西瓜。
要知道，让AI写一个列表页面，大部分时候基本都不难。但如果上线以后用户反馈滑动卡顿，或者只有部分机型出现ANR，这时候就得看咱们有没有能力把问题查清楚了。日志怎么看，线程为什么阻塞，内存为什么没有释放，哪些修改只是让现象暂时消失，这些都需要咱们的基本功，要足够扎实。
比如发现Flow重复收集，如果自己不理解生命周期和协程的关系，就很容易接受一个"加个标记位避免重复"的修改。表面上正常了，退出页面再回来却收不到数据，问题只是换了个地方出现。AI可以帮忙分析，但它给出方案以后，咱们得看得懂，也得知道具体该怎么验证。
所以我觉得，不要因为工具和写的语言多了，就着急给自己列一长串学习清单。Android这边，Kotlin 、协程、Framework 、性能和工程架构，该继续学咱还是得继续学，深入学习，不要浅尝辄止，因为AI时代下更得弄懂其中的原理，CRUD的东西它比你快得多得多。其他方向可以从项目里一个真实的小需求开始，比如补一个后台接口，或者给已有功能做个IOS版本，做完再慢慢往外扩。
咱之前又不是一天之内就能把Android学明白的，换个平台也没必要要求自己马上什么都会，这可太难了，一切都是循序渐进的，咱们又不是超人。绮玉也是日复一日的练习才这么强的，天赋固然重要，但那就本就占少数，普通人该努力还得努力。
更有意思的是：以后我们开发的App本身，也要给Agent用
前面一直在聊怎么用Agent开发App，需要注意什么以及一些个人感受。其实还有一个方向也挺有意思，就是做出来的App，可能也要提供能力给Agent*调用。
Google在推进的AppFunctions 就是在做这件事。开发者可以把App里适合开放的功能提供给系统，让有权限的调用方发现并执行。比如创建一条笔记、添加一个待办，用户表达完需求后，Agent可以调用对应功能，不一定每次都要带着用户打开页面、找按钮。目前它仍处于实验预览阶段，完整的Agent接入也有开放范围的限制，不能理解成随便一个App接上以后，所有用户立刻就能用。具体的同学们可以去官网看看吧。
从开发的角度看，这已经多了一类需要考虑的问题。以前做"创建笔记"，咱们会先想到输入框、保存按钮、页面跳转。现在如果要让Agent调用，就还得把参数说明白，保存失败返回什么，重复调用会不会创建两条，以及哪些数据可以让它访问。
特别是发送消息、删除内容这种操作，怎么确认用户的意思，哪些步骤需要再次确认，也得在设计的时候想好。否则页面上原来有的确认弹窗，换了调用入口以后被绕过去了，功能虽然执行成功，用户可不一定愿意。
所以哪怕现在暂时还用不到AppFunctions ，也可以看看自己的业务逻辑是不是全挤在点击事件里。如果创建笔记这件事离开了页面就没法调用，那以后无论接Agent，还是补自动化测试，恐怕都得先把这部分拆出来。
所以，我反而觉得这是Android开发很有意思的一个阶段
在AI时代下，焦虑肯定是有的。特别是看到AI几分钟写完以前自己半天才能完成的代码，说完全没有压力肯定是假的，自欺欺人。其实每次我都会反问自己：
- 团队以后还需不需要那么多人？
- 初中级开发岗位会不会减少？
- CRUD这类工作，以后还能有多少竞争力？
关于这些担心，我也没法用一句"拥抱变化"就给自己解决掉。AI工具越来越强，公司对交付速度的要求可能也会跟着变高，原来只需要负责Android的工作，以后会不会顺带把其他端也交过来？多会了一些东西，压力也可能跟着多一些。
但如果回到自己想做的事情上，又确实有值得高兴的地方。以前想做个小产品，Android端能做，后端怎么办，其他端怎么办，往往想到这里就先搁着了。现在至少可以借助AI把范围收小，先做出一个能用的版本，再看有没有人愿意用、愿意给反馈。
当然，这些不等于一个人就能顶一整个团队。以笔者目前的水平还做不到一人开发成熟的商业化产品。产品做出来以后，还得维护、处理问题、倾听用户的意见反馈。但对于咱们这种已经有一丢丢开发经验的人来说，能独立尝试的事情确实变多了，我觉得这个机会还是应该抓一抓的。
至于以后到底该叫Android开发、客户端开发还是全栈，我现在倒没那么纠结了，无所谓，这只是一个称呼而已。项目需要什么，自己感兴趣什么，就借着这些工具往前多走一点。原来觉得"这个我不会，得找别人"的事情，现在就可以先自己试试，真卡住了再去学、再去请教，也挺好的。
这里奉上在网络上看到的AI生成的一张趣图
也许说不定，明年今日我就在给大家送外卖了。😊😊 你胆子真是肥嘟嘟的
最后想说的话
就聊到这里吧，今年最大的感受，其实不能说Android 开发没落了，也不会说有了AI,以后就不需要开发者。我只想说的是,之后我们可能是一名以客户端为核心的AI工程师，Android 是我们最熟悉的领域，IOS 、鸿蒙、KMP 、Flutter 、React Native 等等是新的边界，Agent 是新的执行者，CLI 是Agent 的手，Skill 是我们沉淀给Agent 的经验，MCP 是它连接外部世界的方式。而我们不在亲手敲击代码，需要逐渐转向:定义问题、设计系统、组织执行、判断结果 。当然代码还是需要懂的，Android 还是得继续深入。只是以后，我们真的很少会再说："这个不是Android的事情，我不会，你找别人吧。"
因为AI时代真正有价值的能力，越来越不是，我们会哪一个平台。而是面对一个陌生的问题，我们有没有能力快速理解它、拆解它，然后把它做出来。这或许是我说了这么多想表达的，也许这才是2026之后我这种Android开发者最值得拥抱的变化吧。