企业官网建设流程全解析

先说结论：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 未来可能逐步渗透的领域，但渗透的速度远远赶不上它在业务代码里的速度。因为系统开发有一个天然壁垒：你修改的每一行代码，最终都要跑在真实设备上，经过完整的启动、休眠、唤醒、多任务、兼容性测试闭环。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里的 flag），AI 经常给出“通用但不符合我们项目规范”的写法。

我在一次 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 暂时替代不了的“脏活累活”：真实硬件的意外、碎片化场景的冲突、长链路因果的推理、物理世界与数字世界的缝隙。希望这篇分享，能帮还在犹豫的你看到这条路上的价值，也看到一条可以一步一步走进去的入口。