規則寫得再多，AI 還是會繞過去：Meta 遷移 Compose 的經驗，重點不在那些數據

2026 年 10 月初，Meta 公開了 Instagram Direct 從傳統 Android Views 遷移到 Jetpack Compose 的經驗分享，掘金作者「戀貓de小郭」於 10 月 4 日整理了其中的重點。公布的數字包括：遷移後 UI 程式碼量減少 50%，AI Agent 執行時間下降 35%，工程師與 Agent 的往返次數減少 32%，單次 Session 的 Token 成本降低 33%。

這些百分比好看，但對一般開發團隊參考價值有限。真正值得看的是 Meta 處理「AI 寫程式碼」的思路，和目前多數團隊的做法剛好相反。

常見做法：往 Agent 身上疊規則

現在很多團隊導入 AI Coding 的方式，是舊專案一動不動，然後不斷往 Agent 上面疊東西：AGENTS.md、各種 rules、architecture skill、state-management skill，加上一堆「請不要這樣寫」的說明文件。這些內容每次都可能進入 Context，本身就消耗 Token，而且當 Agent 在程式碼裡碰到一個奇怪的歷史抽象時，它仍可能選擇那條最容易編譯通過的路。

Meta 在分享中說得很直白：AI 遇到阻力時，會想辦法繞過你的規則繼續完成任務。只靠 Skills、提示詞和工程規範，無法保證它長期生成正確的程式碼。Meta 還補了一句，過多規則本身就會降低 Agent 的表現。

用日常的比喻來說，這就像家裡小孩會亂放東西，你可以貼一百張便利貼提醒他，也可以直接把櫃子格局改成「東西只有一個地方能放」。前者靠記憶和自覺，後者靠環境本身。

讓架構承擔約束，而不是讓提示詞承擔

Meta 的做法是所謂的 AI-native codebase 工程化：與其塞更多規則，不如改程式碼結構，讓 Agent 沒有偷懶走偏的空間。

一個具體例子是聊天訊息的「置頂」狀態。在 XML 和 Compose 混用的階段，AI 很容易寫出把 mutable state 放在 ChatItem 成員欄位裡的程式碼。看起來自然，也能跑，但這個狀態跟 RecyclerView Item 的實例生命週期綁在一起，Item 被復用到另一行之後，狀態就跟著活下來，於是出現那種「偶現、滾幾下才出現、怎麼都難重現」的狀態洩漏問題。

Meta 後來保留了 ChatItem 這層抽象，但把 Composable 內容限制在建構時傳入的 lambda 裡，UI 能看到的只剩下 uiState、顯式依賴和事件 callback。成員欄位不再是能隨手藏 mutable state 的地方。換句話說，錯誤的寫法在結構上就寫不出來，不需要靠 Agent 記得規則。

抽象層與風險分數：兩個值得抄的細節

遷移策略上，Meta 也沒有把 RecyclerView 裡的 XML 直接換成 Composable，而是做了一層能同時跑在 RecyclerView 和 LazyColumn 上的 UI 抽象。這讓幾百種訊息元件可以逐步遷移，過程中還能做線上 A/B 測試。對 Instagram Direct 這種規模的產品，一個會話頁面要處理超過 200 種 message type，單一 UI 元件有 160 多種狀態組合，一次到位的改寫根本不現實。

另一個有趣的細節是 risk score。Meta 給程式碼檔案維護了一套風險分數，並觀察到：當檔案風險分數翻倍時，Agent 在傳統 Android Views 程式碼上的資源效率下降約 30%，在 Compose 程式碼上只下降約 9%。這意味著 Compose 在簡單頁面裡的優勢可能只是少寫一些程式碼，但在歷史包袱重、狀態多、抽象多的程式碼裡，差距會進一步拉開。

所以呢

對正在導入 AI Coding 的團隊，這份經驗的可用判斷大致是這樣：當你發現 rules 越疊越多、Agent 卻還是踩同樣的坑，問題可能不在提示詞不夠完整，而在程式碼結構本身給了它犯錯的空間。與其繼續加文件，不如把最容易出錯的路徑在架構層封起來。這比任何百分比都更值得帶回自己的程式庫。