Instagram 重写安卓界面：代码少一半，AI 写代码的 token 账单降 33%

让 AI 改代码，最怕的不是它写不出来，而是它写得太顺。它总会挑阻力最小的那条路：复制一段旧模式、绕过一层抽象、在某个角落里塞一个临时判断。单看每一处都能跑，攒上几个月，技术债就像水管里的水垢，越积越厚。Instagram 安卓团队最近做了一次反向操作：不是让 AI 适应代码，而是把代码改成 AI 容易写对的样子。

他们把 Direct 功能的安卓界面从旧的 Android View 体系整体迁移到 Jetpack Compose，得到一个“AI 原生”的 UI 代码库。结果是：UI 代码量减少 50%，每个 AI 智能体会话的 token 成本降低 33%，智能体执行时间缩短 35%，工程师与智能体的交互次数减少 32%。

一分钟速览

• Instagram Direct 安卓 UI 全量迁移到 Jetpack Compose
• UI 代码量减少 50%，AI 智能体执行时间缩短 35%
• 每个智能体会话的 token 成本下降 33%，人机交互次数减少 32%
• 迁移期间团队照常发布新功能，没有停摆
• 核心方法：让“最小阻力路径”正好通向高质量实现

问题的根子不在模型，在架构

Instagram 工程师的判断很直接：AI 工具天然倾向最小阻力路径。如果代码库里的最小阻力路径是复制粘贴、是绕过封装、是留下一个没人看得懂的兼容层，那么 AI 就会稳定地生产这些东西，最后变成隐蔽的 bug、技术债务和性能退化。

所以他们没有采用“逐个组件迁移”的零敲碎打方式，而是先问一个更根本的问题：现有架构是否便于生成正确的实现方案？如果答案是否定的，那就先改架构，再让 AI 进场。

具体做法是建立清晰的架构边界：状态管理要可预测，行为要稳定，开发模式要统一。目标不是让 AI 去弥补糟糕的设计，而是基于“AI 实际会怎么改代码”来设计代码库，让糟糕的设计决策变得难以实现、代价高昂。

减少上下文依赖，是另一种提示工程

第二个原则是最大限度地减少上下文依赖。换句话说，不要让 AI 智能体必须掌握某个代码库的私有知识才能干活，而是让它优先采用经过验证的最佳实践和熟悉的模式。这样生成的代码更可靠，也更容易被别人接手。

配套的是标准化的 AI 辅助工作流：统一的架构规范、统一的实践约定，让不同人、不同会话里产出的代码保持一致。这一点在多人协作的项目里比单点提效更重要——AI 写得快不难，难的是十个人用 AI 写出来的东西像一个人写的。

性能不能退化，这是迁移的生死线

UI 框架迁移最怕的是“功能都对，就是变卡了”。团队盯住三个生产指标：交互响应时间，即打开屏幕到可用的时间；完全加载时间，即所有内容加载完成的时间；滚动性能，即滑动是否流畅。

这些指标通过运行时监控追踪，并借助功能开关做 A/B 测试，把迁移后的 Compose 界面和旧版界面放在同一批真实用户面前比较。

他们还发现一个关键细节：只有把整个屏幕都迁移到 Compose，性能评估才可靠。只要还残留旧的 View 组件，测量结果就会被污染。因此 Compose 组件需要从所在框架中抽象出来，同时保持与 RecyclerView、LazyColumn 的兼容，并能在运行时通过功能开关切换。最终，传统的 RecyclerView 被 LazyColumn 替换。

意外收获是启动性能：Compose 运行时的预热开销每个应用会话只需承担一次，其他基于 Compose 的界面可以直接复用已初始化的环境，不必重复付出这份成本。

趋势洞察

“AI 原生架构”正在从一个口号变成具体的工程指标。过去我们评价一个代码库，看的是可读性、可测试性、耦合度；现在可能还要加一条：AI 智能体修改它时，需要多少上下文、多少轮对话、多少 token。

这条指标很现实。当企业开始按 token 结算 AI 编程工具的费用，代码库的设计质量就不再只是工程师的审美问题，而是直接写进账单的成本项。Instagram 这次迁移省下的 33%，本质上不是模型变强了，而是代码变“好改”了。

对国内团队来说，这个案例的启发不在于要不要用 Compose，而在于顺序：先问架构是否适合 AI 修改，再决定让 AI 改多少。反过来做，通常是用更快的速度积累更多的债。