Instagram Direct 的 Android 客戶端在 2026 年 10 月被 InfoQ 報導完成一項大規模前端改造：把长期以来依賴的 Android View 系統（Android 最早期的指令式 UI 框架，需要開發者一步步呼叫方法去更新畫面元素）換成 Jetpack Compose。Compose 是 Google 官方推廣的宣告式 UI 框架，開發者用 Kotlin 描述「畫面在某個狀態下應該長什麼樣子」，框架負責在狀態改變時更新畫面，而不是由開發者手動指揮每一個元件。Instagram 工程團隊給出的成果數字相當醒目：UI 程式碼量減少 50%，每次 AI 代理工作階段的 token 成本下降 33%。所謂 token 是大型語言模型計價與計量的最小文字單位，程式碼送進模型越多、消耗的 token 越多，因此這個數字直接對應到團隊日常使用 AI 工具的開銷。
這項遷移真正特別的地方，在於它的目標不只是把舊框架換成新框架，而是把整份程式碼庫改造得讓 AI 編碼代理更容易理解、修改與維護，也就是所謂 AI 原生架構。Instagram 工程師強調，與其逐零星元件地對代理下提示詞要求搬移，更應該先評估底層架構本身有沒有讓「正確的實作」容易產生。他們的觀察是，AI 工具天然會走最小阻力的路徑，如果這個路徑通向偷懶寫法，就會引入細微的 bug、技術債與效能退化。因此所謂為 AI 優化程式碼庫，具體含義是在狀態管理周圍建立清楚的架構邊界、確保行為可預測，並界定哪些開發模式是預期做法，使得代理的最小阻力路徑恰好也是最正確的轉換結果。換句話說，設計目標是理解代理實際上如何修改程式碼：讓阻力最小的寫法通往高品質程式，同時讓糟糕的設計決策難以表達、代價高昂，而不是等 AI 事後去打補丁填補設計缺口。
第二個關鍵原則是降低對特定 codebase 知識的依賴，讓代理優先使用業界既有的最佳實務與熟悉模式，而不是必須先掌握 Instagram 內部獨有慣例才能寫對，這類熟悉模式通常能帶來更穩定的產出。在執行層面，遷移並未打斷其他團隊的既有節奏，工程師持續開發新功能；同時 AI 輔助的工作流程被標準化，以確保產出符合共用的架構慣例與最佳實務。整體成效除了前述程式碼量與 token 成本之外，還包括 AI 代理的執行時間縮短 35%、工程師與代理之間的往復對話次數減少 32%，代表每一次人機協作需要的溝通輪次也變少了。
遷移過程中最大的技術挑戰是不能讓效能倒退。團隊盯住三項生產環境指標：time to interact（畫面開啟到可操作所需的時間）、time to fully load（畫面所有內容載入完成所需的時間），以及 scroll performance（捲動的流暢程度）。這三項都在執行期於正式環境持續量測，因此可以對新的 Compose 介面與舊介面跑 A/B 測試，直接比較效能影響。過程中一個重要發現是，只有當整張畫面完整移植到 Compose、不留任何殘餘的舊 View 元件時，效能數據才可靠，因為混雜的舊元件會扭曲量測結果。這也意味著 Compose 元件必須抽象於外層容器框架之外，同時相容於舊的 RecyclerView（Android 傳統的列表容器）與 Compose 原生的 LazyColumn（只渲染可見項目的懶加載清單），並且能透過 feature flag 在執行期切換，A/B 測試才有意義。最終團隊把作為容器的 RecyclerView 換成 LazyColumn，完成收尾。
另外，Compose 有運行期的初始化成本，但這筆成本每個應用程式工作階段只需支付一次，因此其他已改用 Compose 的畫面會直接受益於已完成初始化的運行環境，整體啟動表現也隨之改善。不過限制也必須說清楚：33% 的 token 成本與 35% 的執行時間屬於相對比例，取決於代理工作負載的組成，文章並未給出絕對數值與樣本期間；效能結論要求整屏遷移完成後才成立，代表混合架構期間無法得出可信評估，遷移週期因此被拉長；成果同時來自架構邊界、流程標準化與框架替換三者的合力，不能單純歸因於 Compose；而「代理會走最小阻力路徑」這項前提，也需要在不同模型與任務型態下持續驗證。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。