很多人一談到 AI 寫 code，就會自然地把它想成一個生成器：把需求丟進去，模型吐出 patch，然後再看看能不能編譯。這種想像放在小型專案裡，有時候還能勉強成立；但若場景換成 Android Framework，事情就完全不是這樣。因為 Android Framework 的問題，往往不是不會寫，而是先要知道該去哪裡看、該改哪一層、哪一段 call path 才是這次修改真正的主線。
因此，把 AI 應用於 Android Framework 底層的修改，不是先談 generation，而是先談 understanding。不是先叫模型寫程式，而是先讓模型進入正確的工作流：理解 source tree、做 retrieval、做 localization、整理 patch planning，最後才把 handoff bundle 交給 LLM。這也是 Moko365 在 AFV100、AFV101 與 AFV102 這三門課裡，一直反覆強調的主線：先建立共同語言，再進入 Android Framework 的專門場景，最後把這套能力推進到日常工作流。
先定義問題：AI 在 Android Framework 底層究竟要做什麼？
若用一句話來說，AI 在 Android Framework 底層最有價值的角色，不是直接接管修改，而是協助工程師完成從理解到交接的前半段工作。這包含了幾件非常具體的事：幫你快速看懂 source tree、幫你找到 entry point、幫你縮小相關檔案與方法範圍、幫你整理既有模式與相鄰實作，然後再把這些資訊收斂成一份可交給 LLM 的 handoff bundle。
換句話說，AI 真正適合處理的，不是「我完全不知道要改哪裡，你幫我從零開始猜」，而是「我已經知道大方向，現在需要一個夠懂 source tree、夠懂 call path、也夠懂修改邊界的副駕」。這個差別非常重要。前者把 AI 當黑箱，後者才真正進入工程協作。
Android Framework 的 AI 工作流，不是讓模型硬讀整棵 AOSP；而是先讓系統看懂程式、找對位置、縮小範圍，再把整理過的 truth 交給 LLM。
為什麼不能直接叫模型改？
因為 Android Framework 不是一個只有幾個檔案的專案。它有 service、binder、permission enforcement、JNI、HAL bridge，也有大量跨層 call path。很多看起來像小改動的需求，真正落到 source tree 裡，往往會牽涉到多個 service、多段 method flow，甚至還需要先釐清這次修改究竟屬於 framework、system service，還是更底層的 bridge。
這也是為什麼 AFV101 會把課程主線拉成：AST → Source Understanding → Code Indexing → Retrieval → Patch Planning → AI Handoff。這條線的意思很清楚：AI 要先具有閱讀能力，才有資格進入修改。沒有 AST、沒有 source-level indexing、沒有 retrieval 與 localization，模型就很容易在龐大的 source tree 裡失焦，最後產出一段看起來合理、實際上卻落錯位置的 patch。
因此，真正穩定的方法，不是讓 LLM 一開始就接管，而是讓小模型或專門的檢索層先處理 source understanding。當程式結構、相鄰實作、關鍵 method 與 patch 邊界都已經被整理出來，LLM 才適合進場做推理、說明、規劃與組合。
一個 Android Framework 的實作範例
假設你的團隊要修改某個 system service 的行為。需求看起來很簡單：當系統收到特定事件時，要補上一段額外的檢查流程與記錄邏輯。若你只是對 AI 說「幫我改 Android Framework，加上這段檢查」，模型很可能會先給你一份語氣很篤定、位置卻不一定正確的答案。
但在真正的 Vibe Coding 工作流裡，你不會這樣做。你會先整理幾個關鍵問題：這次修改屬於哪個子系統？entry point 在哪個 service？call path 會穿過哪些 class 或 method？既有的 permission check 與 logging pattern 是怎麼寫的？這次 patch 的邊界應該停在哪裡？哪些檔案只是看起來相關，實際上不應碰？
接著，retrieval 系統會把真正相關的 code path、相鄰方法、既有 pattern 與 local patch prior 拉出來。到這一步，工程師就能整理出一份 handoff bundle：需求、目標 service、關鍵 method、相鄰實作模式、不可破壞的限制條件，以及這次 patch 應停留的範圍。這時，LLM 接手的就不再是一句模糊需求，而是一份已經過 source understanding 與 patch planning 的修改任務。
差別就在這裡。Vibe Coding 的核心，不是叫 AI 直接改 framework，而是先把 Android-specific truth 整理好，再交給 AI 做真正擅長的推理與組合。這樣做出來的結果，不只比較接近可用，也更容易 review、refine 與 apply。
這件事為什麼適合用課程方式學？
因為這不是單一工具的教學，而是一條工作流。AFV100 的角色，是先把 Vibe Coding 的通識建立起來：理解小模型與 LLM 的分工、理解 retrieval、localization、patch planning 與 handoff bundle。AFV101 則把這套方法帶進 Android Framework 的 AST、indexing 與 retrieval 層。到了 AFV102，重點就不再只是模型鏈本身，而是如何把 Code Reading Mode、Architecture Analysis Mode 與 Implementation Assist Mode 整理成團隊可操作的日常方法。
也因此，這條學習路徑的重點不是記住幾句 prompt，而是建立一種工程判斷：什麼時候該先讀 code，什麼時候該先找 call path，什麼時候該讓 retrieval 縮小範圍，什麼時候才適合交給 LLM。當這些判斷建立起來之後，AI 才會從新玩具，慢慢變成 Android Framework 研發流程的一部分。
AI 真正能帶來的，不只是速度
很多人對 AI 的期待，第一時間想到的都是速度。這當然沒有錯。可是對 Android Framework 底層修改來說，AI 更大的價值常常不是幫你快一點寫完，而是幫你更快看清楚結構、看清楚修改位置、看清楚哪些地方不該碰。速度只是表面，真正高價值的，是理解密度與協作品質。
因此，若要用一句話總結：如何將 AI 應用於 Android Framework 底層的修改，答案不是先讓 AI 寫 patch，而是先讓 AI 進入 source understanding、retrieval、patch planning 與 handoff 的工作流。 這也是為什麼 Moko365 在 Vibe Coding 系列裡，一直強調先建立方法，再談工具；先建立工作流，再談生成。
快速整理
- AI 在 Android Framework 底層最有價值的角色，不是直接接管修改，而是先協助理解、定位與交接。
- 真正穩定的方法，是 AST → Source Understanding → Retrieval → Patch Planning → AI Handoff。
- 沒有 source tree 的理解層，LLM 很容易在大型 Framework 裡失焦。
- Vibe Coding 的核心，是先把 Android-specific truth 整理好，再交給 AI 做推理與組合。
- AFV100、AFV101 與 AFV102 三門課，正好對應從通識、索引到日常工作流的完整學習路徑。