程式碼減半、Token 省三分之一：Instagram Direct 遷移 Compose，帳記在架構上

UI 程式碼量減少 50%，AI Agent 執行時間下降 35%，工程師與 Agent 的往返次數減少 32%，單次 Agent Session 的 Token 成本降低 33%。十月上旬，Meta 公開了 Instagram Direct 遷移 Jetpack Compose 的這組數據。四個百分比的方向一致，而這段期間 Meta 沒有更換底層模型，提示詞也沒有繼續加長，投入改動的標的是 Android 端的程式碼結構本身。

這組數字因此值得換一個讀法。當多數團隊把 AI 編碼的成本管理押在規則文件與提示詞工程上，Meta 把同一筆帳記到了架構科目。規則的約束力發生在生成之後，結構的約束力發生在生成之前，這是兩條路線成本曲線分岔的起點。

四個百分比的分母是同一件事

先看數字本身。程式碼量減半，分母是原本以 XML 加命令式 View 寫成的 UI 層；執行時間下降 35%，量測對象是同批遷移任務交給 Agent 執行的耗時；往返次數減少 32%，對應工程師人工覆核與修正的介入頻率；Token 成本降低 33%，則是單次 Session 的計費基礎。

四組數字量的是同一個動作：把訊息元件從 View 體系搬進宣告式 UI。實驗組與對照組之間唯一被更動的變數，是程式碼結構。Meta 給出的因果方向相當直接，當代碼庫本身對 Agent 更友善，Agent 的產出速度、正確率與計費量同步改善。

放到更長的時間軸上看，Jetpack Compose 於 2021 年 7 月釋出 1.0，Google 以宣告式範式取代 XML 佈局搭配 findViewById 的組合，更早之前 React 已用同一套範式改寫 Web 前端近十年。在 Agent 出現之前，這場遷移的賣點是開發者體驗與狀態管理的一致性。Agent 出現之後，多了一層計價：程式範式決定了模型讀寫這份代碼的成本。Instagram Direct 這份數據，等於替這層計價補上了實測值。

規則堆疊路線的邊際成本

市面上常見的做法是舊專案保持原樣，往上疊 AGENTS.md、rules、architecture skill、state-management skill，以及各種「請不要這樣寫」的說明。Meta 的經驗對這條路線給出兩個否定性的測量結果。

其一，這些說明每次都有機會進入 Context，本身消耗 Token。Meta 在分享中明言，Skills 存在 Context 成本，載入過多規則反而降低 Agent 表現。其二，當 Agent 在程式裡撞上陌生的歷史抽象，它仍傾向選擇最容易編譯通過的方案，規則攔不住這個傾向。Meta 對此的觀察更直白：AI 遇到阻力時，會想辦法繞過你的規則繼續完成任務，只靠 Skills、提示詞與工程規範，無法保證長期生成正確代碼。

對應的解法是把約束下沉到架構層。這與 MCP 把 Agent 工具整合的乘法改回加法 屬於同一個方向：把反覆出現的協調成本，從每次對話的 Context 裡搬走，放進一次性的結構決策。差別只在 MCP 動的是協議層，Meta 動的是代碼層。

一層抽象，兩種容器

具體做法上，Meta 沒有把 RecyclerView 裡的 XML 直接替換成 Composable。工程團隊先做了一層可以同時跑在 RecyclerView 與 LazyColumn 上的 UI 抽象，讓幾百種訊息元件逐個遷移，過程中線上 A/B 測試持續並行。

支撐這層設計的是 Instagram Direct 的複雜度基數：單一會話頁面要處理超過 200 種 message type，單一 UI Component 的狀態組合超過 160 種。在這個量級上，一次性重寫的風險與分批遷移的相容需求，都指向同一個中間層。

Meta 舉的缺陷案例發生在 XML 與 Compose 直接混用的階段。Agent 要給聊天 Item 加一個置頂狀態，最自然的產出是把 isPinned 宣告成 ChatItem 類別的成員變數，再於 @Composable 函式裡讀寫。這段代碼可以編譯、可以運行，問題藏在 RecyclerView 的回收機制裡：Item 被重新 bind、復用到另一行之後，狀態跟著物件一起存活，於是出現偶現、滾動幾下才復現、難以穩定重現的狀態洩漏。這類缺陷的除錯成本極高，因為它只在高頻回收的路徑上現身。

Meta 後來保留了 ChatItem 這層抽象，但把 Composable 內容限制在建構時傳入的 lambda 裡，UI 看得到的只剩 uiState、顯式依賴與事件 callback。成員欄位從此失去存放 mutable state 的空間，置頂狀態只能以 state.isPinned 的形式從上遊傳入，狀態的生命週期跟著資料走。同一條約束寫成規則文件，Agent 有機率遵守，也有機率在一次長任務的後段遺忘；結構化之後，遵守率這個變數被直接移除。

風險分數翻倍，兩種代碼的衰減差三倍

Meta 給程式碼檔案維護了一套 risk score，這個機制附帶了一組少見的實證數據。當檔案風險分數翻倍，Agent 在傳統 Android Views 代碼上的資源效率下降約 30%，在 Compose 代碼上只下降約 9%。

這組對照有兩層解讀。在簡單頁面上，宣告式 UI 的優勢大約就是少寫一些代碼；到了歷史包袱重、狀態多、抽象多的檔案，差距會被複雜度放大。換一個說法，代碼庫的範式選擇實際上決定了它把複雜度傳導給 Agent 的係數：同一份複雜度，View 體系把它轉成 30% 的效率損失，Compose 轉成 9%。

這對技術債的計價有直接影響。過去技術債的利息以工程師工時計價，現在同步以 Agent 效率計價，而後者的衰減速度在 View 代碼上快了三倍有餘。債務排序由帳齡與改動頻率，移往 Agent 效率衰減的斜率。

帳往哪裡移

大型 App 團隊的 AI 工程化預算是最直接的受惠方。重構支出原本掛在技術債科目下，缺乏立即的回收論據；四組百分比提供了換算基礎，risk score 進一步給出排序工具，優先遷移 Agent 效率衰減最陡的檔案。宣告式 UI 生態同受其惠，Compose 與 SwiftUI 這類框架多了一條與開發者偏好脫鉤的採購理由，買單的論述從工程體驗換成 Agent 成本。維護混編橋接層的工具鏈與中介方案，也會隨遷移專案的數量增加而擴大需求。

承壓的一側，以規則文件為中心的提示詞工程周邊首當其衝。若約束持續搬回架構，rules 與 skills 的堆疊需求成長受限。選擇不動舊碼、只往 Agent 疊配置的團隊，邊際成本會隨代碼複雜度上升，Meta 的數據等於把這條曲線畫了出來。抽象層本身也是新增的中間層，雙軌並行期間的維護工時，是遷移帳上容易被略過的固定支出。

Token 單價的走向還會改變這筆帳的權重。前沿模型 API 輸入牌價兩年下跌約三百倍，單位 Token 節省的價值持續縮水。但四組數字裡 Token 只佔其一，執行時間與人工往返對應的是工程師小時成本，這個單價並未跟著下降。模型越便宜，結構決定的效率項在總帳裡的佔比越高。

兩種情境

情境一，AI-native 重構成為獨立預算科目。團隊以 risk score 排序，逐季把 Agent 效率衰減最陡的檔案遷往宣告式結構，四組百分比成為驗收指標，遷移進度與 Agent 帳單直接掛鉤。情境二，抽象層標準化。宣告式與命令式容器之間的橋接層由框架或工具鏈內建，單一團隊不再需要自製 ComposeItem 這一層，遷移的固定成本下降，中型專案也負擔得起。

兩個情境共用同組檢驗指標：其他大型 App 公布的遷移數據是否落在相近區間，以及各團隊規則文件的平均長度是否停止增長。前者驗證效果的可複製性，後者驗證約束是否真的從 Context 搬進了結構。在 Meta 的版本裡，答案已經寫在那 33% 的降幅裡：省下來的 Token，多數本來就花在替錯誤結構擦屁股。