先说结论AI 替代的从来不是“程序员”这个职业而是编程工作中那些高度套路化的部分。前后端岗位之所以感觉被冲击得最凶是因为大量业务开发本质上就是“把需求翻译成 CRUD”这种工作模式恰恰是 AI 最擅长的。而 Android 系统开发——我说的是从 AOSP 源码、系统服务、HAL 层一直到编译工具链、性能调优、设备适配这一整条链路——恰恰是 AI 目前最难啃的骨头。这篇文章我想从自己的观察和实操经验出发聊聊为什么在 AI 写代码越来越像人的时候系统开发反而成了硬通货。完整标题是“当 AI 开始替代前后端的时候为什么 Android 系统开发反而成了香饽饽”这个选题我关注了很久因为这不是一个简单的“哪个方向好”的问题而是在 AI 生产力爆发之后软件行业的人才价值坐标被重新标定的问题。无论你是正在选方向的学生、被裁员焦虑裹挟的初中级开发还是已经在系统层边缘试探但没下定决心的应用层工程师这篇内容应该都能给你一个相对清晰的坐标系。1. 先看清楚 AI 替代的到底是什么不是“写代码”而是“翻译需求”1.1 前后端为什么首当其冲因为业务开发的本质是“结构化的翻译”过去十年前后端岗位之所以量大面广是因为互联网行业的大部分需求都落在同一个模式里页面长什么样、接口返回什么、数据怎么存、权限怎么控。这些需求一旦被产品经理写成 PRD剩下的工作其实就变成了从“人类语言”到“代码语言”的翻译——而这恰恰是 LLM 最擅长的事。我身边真实发生的例子上个月让一个实习生用 AI 辅助重构一个后台管理系统的用户列表页面。原来的实现是传统的 Table Pagination要新增多条件筛选和服务端排序。实习生花了两天其中一天半是在跟 AI 对话调整 prompt最终交付的代码质量居然不错甚至把接口字段命名规范都对齐了。这就是典型的“AI 替代”场景——因为这类任务的输入输出都是高度结构化的接口文档在、组件库在、设计稿标注在AI 只需要在既定框架内做组合。所以你要理解一个关键点AI 替代的不是程序员替代的是“把明确需求变成合格代码”这一层执行工作。这层工作在前后端业务开发里占比最高所以前后端的冲击感知最强。1.2 AI 吃不下的是什么不确定性、实时反馈和物理世界的约束但如果你尝试让 AI 处理下面这些任务它就会露馅“为什么这个设备在亮屏瞬间偶尔丢一帧而其他设备正常”“这款三方的 SoC 在低内存场景下为什么 statfs 返回的可用空间和实际分配不一致”“客户反馈待机一晚掉电 15%怎么从 trace 和 wakeup source 定位到具体是谁在拉 wakelock”这些问题有一个共同点答案是藏在运行时的、非结构化的、需要和硬件/系统/编译产物反复交互才能逼近的。AI 可以给你一版“看起来合理的排查思路”但它无法替你做真机复现无法感受设备温度无法理解某个 OEM 的电源管理策略在特定硬件平台上的表现更不可能在每次修改后立刻拿到真实的 trace 数据来做下一步决策。我把这个总结成“AI 能力的边界模型”它擅长从“结构化输入”到“结构化输出”但系统开发里大量工作是“非结构化输入 物理反馈 长链路因果推理”。在这个领域AI 目前最多是副驾连自动驾驶都算不上。1.3 一个容易被忽略的事实被替代的往往不是岗位而是“岗位里的那部分技能”很多人担心的是“岗位消失”但实际观察到的现象是“岗位的技能结构在剧烈变化”。以前一个业务团队需要 10 个 Android 应用开发现在可能只需要 5 个因为 AI 把写页面、写接口、写工具类的效率提上来了。但这 5 个人的门槛变了以前会调 API、会写 RecyclerView 就能干活现在得懂性能优化、懂架构设计、懂如何把 AI 写的代码 review 出问题来。而那些真正深入到系统层的工程师呢他们的岗位数量没有减少反而因为应用层开发效率提升业务方有更多精力去做系统级体验优化、做多端适配、做底层定制。我上一家公司就是一个典型案例APP 日活几千万但应用开发团队在 AI 辅助下两年没扩编甚至略缩。可系统组呢从 4 人扩到了 11 人主要工作量是功耗优化、开机速度、大版本 AOSP 升级适配、以及为新的折叠屏产品做窗口框架适配。这个方向不是风口但它是刚需——只要还有设备要出货只要 Android 还在迭代这活儿就得有人干而且不能用 AI 生成的东西直接上产线。2. 系统开发为什么“反脆弱”AI 越强它的护城河反而越深2.1 先定义清楚Android 系统开发到底指什么很多人一听“系统开发”就以为是做 ROM、做刷机包这个认知太窄了。在 Android 生态里系统开发至少包含下面这些层次层次典型工作内容AI 可替代性我的评分内核与驱动Kernel 适配、设备驱动、电源管理、内存回收策略极低依赖硬件反馈HAL / 硬件抽象Camera、Sensor、Audio、Fingerprint 的 HAL 层实现极低每家硬件都不一样系统服务AMS/WMS/PMS 等生命周期、窗口管理、权限策略、任务调度低逻辑复杂状态极多框架 API 与 SDK公开 API 演进、兼容性维护、CTS/GTS 适配低必须跑完整兼容性测试编译与构建系统Soong、Make、ProGuard/R8、资源编译、分模块构建中等AI 能辅助脚本但排查编译问题很头疼系统应用与核心组件SystemUI、Settings、Launcher 的深度定制中低UI 部分 AI 能帮不少忙但系统交互逻辑复杂性能与稳定性卡顿优化、ANR/crash 治理、功耗优化、Selinux 策略极低长链路排查注意看“中等”和“中低”那一两行——这些是 AI 未来可能逐步渗透的领域但渗透的速度远远赶不上它在业务代码里的速度。因为系统开发有一个天然壁垒你修改的每一行代码最终都要跑在真实设备上经过完整的启动、休眠、唤醒、多任务、兼容性测试闭环。AI 生成的代码可以在代码审查层面“看起来合理”但没法在硅基世界里模拟所有真实硬件的怪异行为。2.2 核心逻辑AI 把应用层门槛打下来了系统层的稀缺性反而被放大了这个逻辑其实很反直觉但它在多个行业里都被验证过当一个领域的生产力工具大幅普及时该领域里“非工具能覆盖的部分”会变得极度值钱。以摄影为例手机拍照的 AI 算法让所有人都能拍出不错的照片但专业摄影师没有失业反而那些懂布光、懂色彩科学、懂物理镜头特性的人更吃香了——因为“用 AI 出图”和“知道为什么这个场景要这么拍”完全是两个层次的能力。AI 让工具的普及率上升但工具的普及没法替代人类对物理世界、对复杂场景的深度理解。同理AI 让“做出一个 Android 应用”这件事的门槛变得极低于是市场上充斥着大量同质化的应用和应用开发者。但“做一个让百万级设备稳定运行的系统版本”这件事门槛没有任何变化——它依然需要理解 Binder 通信、需要理解进程优先级与 LMK 策略、需要理解 zygote fork 机制的局限、需要理解 SurfaceFlinger 的合成流程、需要理解 AVB 签名与 OTA 升级的完整链路。当供给端应用开发被 AI 放大而需求端系统级工程质量没有同步被放大时供需关系就会倒挂。这就是“香饽饽”的本质不是系统开发变得更简单了而是会做系统开发的人相对变少了。2.3 为什么 AI 学不会系统开发的“私有知识”我见过不少人对 AI 有一种迷思它能学习所有代码那我不懂的系统知识它应该都能给我答案。真实情况恰恰相反。Android 系统开发里大量关键知识根本不是公开代码能覆盖的某颗 SoC 的电源域划分和调频策略那是芯片厂商的私有文档某个运营商对 VoLTE/WiFi Calling 的认证要求那是运营商私有规范某款设备在特定场景下的功耗异常原因那是我们自己抓 trace 一点点总结出来的经验库某个系统服务在高并发场景下的死锁那是结合业务特征才暴露的运行时问题。这些知识没有出现在 AOSP 公开仓库里也没有形成足够多的公开训练语料。AI 模型可以给你讲清楚 Binder 的基本原理但遇到自家定制平台上的诡异问题它给不出任何有价值的建议——因为它没见过你手头这块板子。这就是系统工程师的经验壁垒你对特定硬件平台、特定业务场景的深度理解是 AI 无法从公共语料里学到的东西。这也是为什么大厂和硬件厂商愿意为系统工程师开高价——这些人手里的经验就是公司的私有资产。3. 我在实际项目里体会到的“AI 辅助系统开发”到底是什么状态3.1 场景一AI 写 AIDL 接口和系统服务骨架——真的好用但要立刻改造前面说了很多 AI 的不足但别误会我在系统开发里也用 AI而且用得很勤。最典型的场景是当你新增一个系统服务时需要写一堆样板代码AIDL 定义、服务端实现、ServiceManager 注册、权限声明、Selinux 策略。以前我纯手写大概需要一整天。现在我用 AI 先出第一版可能两小时就拿到一个可编译、逻辑结构完整的骨架。但这只是开始AI 生成的权限配置往往不是过粗就是过细AIDL 里的 callback 回调方式可能不符合我们内部对匿名 binder 对象的管理规范Selinux policy 的 allow 规则也基本是错的因为它不知道我们系统里的 domain 划分。所以 AI 在这里的角色是“快速铺底”它把最花时间的结构性样板活干掉了但每一个文件我都必须重新 review 并修正。这个 review 和修正的过程恰恰是系统工程师的核心价值。3.2 场景二AI 分析 ANR / Tombstone / trace 日志——能指方向不能下结论系统开发绕不开稳定性治理。有一次车机项目上报了一个诡异的 ANR主线程卡在 Input 分发但 Suspend 的线程是 SystemServer 里的 PackageManager进一步追溯发现它在处理 binder 调用时阻塞。我用 AI 把 tombstone 和 ANR trace 丢给它它两三分钟就给出了“可能是 PackageManager 在锁竞争、建议抓带锁信息的 trace”这类结论。说实话这个方向是对的但仅停留在“可能”的层面。真正定位到是那个三方应用在安装时触发 dex2oat 导致 IO 拥塞、SystemServer 在等待安装服务完成安装通知、而它又持有 PMS 锁阻塞了 Input 通道——这一步靠 AI 给不出因为它拿不到我们车机平台独有的服务依赖图和业务优先级。这需要工程师把 trace 里的线程栈、Binder 事务日志、IO 时间线、系统服务调用链串起来在脑内形成一张动态图才能定位到根因。老实说这个环节 AI 帮我的主要是“把 trace 显示得更规整”和“把常见模式先列出来”真正的破案过程还是人肉推理。3.3 场景三AI 帮写编译脚本和 Soong 配置——效率提升明显坑也明显平时要做系统单模块编译、生成产品镜像、跑 CTS 专项这些脚本配置 AI 生成很快比如 Blueprint 的cc_binary/android_app模块定义格式它很熟。但一旦涉及产品定制变量PRODUCT_PACKAGES、PRODUCT_COPY_FILES、BoardConfig.mk里的 flagAI 经常给出“通用但不符合我们项目规范”的写法。我在一次 AI 生成的bpf相关配置里踩过坑它生成的内容从语法上完全正确但因为我们项目的内核版本和用户空间的 bpfloader 版本不匹配编出来的系统起不来开机 log 直接卡在 init 阶段的 bpf 加载。这种坑排起来极费时间后来养成了习惯——AI 生成的构建配置进入代码库之前必须用 diff 仔细对比团队里已有的同类配置。3.4 我的体会AI 是系统工程师的“杠杆”不是“替代者”综合下来我自己的判断是在系统开发这个领域AI 更像是一个能力放大器。它把一个资深系统工程师从“写样板代码、查基础文档、生成格式正确的配置文件”这类低价值工作中解放出来让 TA 有更多精力投入到真正值钱的环节定位疑难问题、设计系统架构、权衡性能与功耗、跟进硬件平台演进。而反过来一个只会调 API 的应用开发如果发现 AI 能写大部分业务代码TA 的不可替代性确实在快速下降。这不是贩卖焦虑是这两年我观察到的真实分化。系统开发今天之所以“香”恰恰因为它是这个行业里少数不能靠提示词替代的领域。4. 从应用层往系统层钻一条被低估的进阶路线4.1 为什么大多数人卡在“想转但没转”的状态我见过很多 Android 应用开发想往系统层转但大部分人很快就放弃了。原因不外乎几点源码太大不知道从哪读起编译环境重、迭代慢不像应用开发改一行代码热更新就能看到效果调试方式完全不同——应用可以打 log、断点系统层经常要面对“改了之后系统起不来”的窘境加上网络上“系统开发”的系统性教程确实比应用开发少导致入门成本看起来高得吓人。但我不想只说“这东西难”来劝退因为根据我自己和身边人的经验应用层工程师切入系统开发其实有一条相对平滑的路径不需要从头啃完 AOSP也不需要重新学操作系统原理。关键是找对抓手。4.2 第一步先理解应用和系统的“边界层”而不是立刻扑向底层很多人的误区是一上来就去看ActivityManagerService怎么管理任务栈、WindowManagerService怎么合成窗口。这些当然重要但如果你对“应用进程到底是如何与系统服务通信的”没有体感看这些源码就是雾里看花。我建议的第一步是搞透Binder 与 AIDL——这是应用与系统之间的“官道”。你先在应用层写一个绑定本地 Service 的 Demo在 Service 里实现一个跨进程回调亲手感受一下transact过程中主线程的行为变化然后看系统中真实存在的 AIDL比如IActivityManager、IPackageManager理解哪些调用会导致应用进程 binder 阻塞进而引发 ANR。这个阶段不需要你把 AIDL 源码全读完重点是建立“跨进程通信是有代价的、系统服务状态是被所有应用共享的”这个心智模型。有了这个模型你读系统源码的时候会突然清晰很多因为你会发现系统服务的很多复杂逻辑本质上都是在处理“多进程并发访问同一状态”的问题。4.3 第二步选一条垂直链路深挖形成正反馈系统开发的源码体量太大不可能线性地从头读到尾。我的经验是选一条跟你的应用开发经验强相关的链路先挖到能解决实际问题的深度再横向扩展。以性能优化为例你平时做应用优化肯定听过Systrace、Perfetto。现在往上走一层读帧时从 App 绘制到SurfaceFlinger合成再到显示驱动的完整链路。然后你会发现应用层的掉帧很多时候不是 App 本身的问题而是BufferQueue的配置、Vsync信号的调度、窗口缩放策略共同作用的结果。这时候你再回来看应用代码很多“为什么这么写更流畅”的疑问会迎刃而解。再比如做功耗优化你在应用层用Battery Historian看过耗电现在去读PowerManagerService的 wakeup source 管理逻辑理解wakelock超时、alarm对齐、Doze 模式的判定条件。理解之后你会发现应用层的很多耗电问题根本不是应用写错了而是系统策略与硬件平台特性没配合好。这种“从自己熟悉的领域出发向系统层延伸”的学习方式反馈周期短成就感来得快不容易半途而废。4.4 第三步主动承担“应用与系统的交界问题”积累调试经验最直接的练兵场其实就是你现在手头的应用项目。你不需要等公司给你派系统开发的活下面这些问题只要你愿意深挖都属于系统开发的范畴应用在后台被系统杀死后重启时的状态恢复不了——去查ActivityManagerService的任务恢复机制应用在某些设备上出现窗口尺寸异常——去查WindowManagerService的窗口显示区域计算和DisplayCutout兼容逻辑应用的音视频不同步播放时掉帧——去查AudioFlinger和SurfaceFlinger的时钟基准对齐问题应用偶发 ANR但 logcat 里看不出问题——去抓 /data/anr/ 下的 traces 文件学会从内核线程栈反推用户态问题。这些问题看起来是“应用问题”但多数已经需要你跨到系统层去理解才能解决。当你习惯了用adb shell dumpsys、debuggerd输出的栈信息、systrace的时间轴来定位问题你其实已经一只脚踏进系统开发了。4.5 用得上的一些工具与学习抓手如果你真的决定往这个方向走下面这些东西建议尽早接触AOSP 源码阅读工具如 cs.android.com和代码检索能力编译构建至少要把 Android 的单模块编译跑通理解mmm/make的基本概念以及soong生成的文件如何被打包进系统镜像调试工具adb shell dumpsys家族activity、window、power、battery、package 等、systrace/Perfetto、tombstone分析、Selinux的 avc log 查看系统定制相关的模块APEX理解系统模块如何独立升级、AVB系统镜像的签名与验证、OTA 升级理解全包与差分包怎么做A/B 分区机制推荐一个直接可练手的入口自己动手在 AOSP 里增加一个系统服务从 AIDL 到打印日志到系统启动时初始化最后在应用层调用它。这个 1-2 周能完成的迷你项目比读一百篇源码分析文章都有效。从应用层到系统层不需要去拿“系统架构师”这种遥不可及的 title只要把上面这些能力实实在在地掌握你在团队里的价值就已经从“写业务代码的”变成了“能搞定疑难问题的”。5. 对还在观望的人说几句实在话最近总有人私信问我“现在转系统开发还来得及吗AI 会不会很快把这块也替代了”我的回答一直是只要 Android 设备还由真实硬件组成系统开发就需要人来做判断只要还需要人对物理世界的反馈做推理AI 在这里的角色就是工具而非主体。这话听起来可能有点绝对但你可以自己做一个实验随便找一个系统开发中你熟悉的 bug 场景比如设备无法开机、系统 UI 卡死、某个传感器上报异常用 AI 完整地描述一遍排查过程看看它给你的是“教科书式的通用排查步骤”还是“针对这个设备的深入分析”。大多数情况下你会得到前者。而厂商真正花钱雇人解决的永远是后者。如果你现在还在做应用层开发不必焦虑到立刻裸辞转行但确实该给自己加一层“系统思维”。哪怕只是每周花两三个小时学一点系统服务的工作原理试着去解决一两个应用与系统边界的疑难问题你的护城河就会比那些只会跟着 AI 写 CRUD 的人深得多。我自己这两年最大的感受是AI 让“一般水平”的代码产出变得廉价但让“能在物理世界里稳定运行、在极端条件下不崩溃、在复杂场景下完成高质量体验输出”的工程能力变得更加昂贵。前后端被替代的话题之所以热是因为那里聚集了大量一般水平的产出而系统开发之所以变成了香饽饽恰恰因为它一直是那个无法被标准化、无法被提示词化的领域。如果你愿意在这条路上投入时间我的建议是先不要急着买一堆“深入理解 Android”的书从头啃到尾——找一台能 root 或者有调试口的 Android 设备随手抓一个当前应用里的痛点掉帧、耗电、启动慢、崩溃难定位然后用系统层的方式去把它彻底解决一遍。在那个过程里你自然会知道下一步该学什么。最后分享一个实际经验我带的两个应届生一个跟着 AI 做应用开发一个跟着我做系统稳定性治理半年后的差别已经非常明显。用 AI 写业务代码那个同学确实产出很高但遇到线上模块崩溃、需要看 tombstone 定位问题时完全无从下手而另一个同学在被我带着排查了两个月的功耗和 ANR 之后已经能独立完成“从 trace 到根因”的分析报告。这半年里 AI 模型的版本更新了很多次但它始终没能帮第一个同学提升排错能力也没能取代第二个同学的分析判断。技术趋势这个东西追风口容易抓本质难。在 AI 开始替代前后端的时候系统开发之所以成了香饽饽不是因为系统开发本身有多难而是因为它挤满了太多 AI 暂时替代不了的“脏活累活”真实硬件的意外、碎片化场景的冲突、长链路因果的推理、物理世界与数字世界的缝隙。希望这篇分享能帮还在犹豫的你看到这条路上的价值也看到一条可以一步一步走进去的入口。