compose_skill 和 android skills，對 Android 專案幫助極大的專家級 AI 技能
最近發現了一個非常不錯的 Compose AI Skills 專案 compose_skill，這個技能可以針對你的 Compose 專案生成一份評分報告，例如下面就是我在這個技能下得到的 Compose 專案評分：
- 性能：4/10
- 狀態管理：5/10
- 副作用：6/10
- Composable API 品質：5/10
技能檢查後的整體評價是：專案已經是相當完整的 Compose 多模組應用，結構合理，但在列表性能、狀態收集方式、可重用元件的 API 設計，以及 ViewModel/模型穿透 UI 的方式上，都存在系統性問題。最關鍵的是這些問題不是零星個別發生，而是在多個 feature 中重複出現，所以總分只有 46/100。
compose_skill 整體可信度還不錯，它不是只透過提示詞和規則來評審，而是會透過內建的 Gradle 初始化腳本，直接產生並解析 Compose 編譯器的報告（Reports）和指標（Metrics）。主要評判維度有：
- 性能 (35%)：檢查 Compose 中的耗時操作、Lazy 列表的 Key、穩定性（Stability）、強跳過模式（Strong Skipping）
- 狀態管理：稽核狀態提升（Hoisting）、單一事實來源（single source of truth）、以及生命週期感知的狀態收集
- 副作用（Side Effects）：檢查 Effect API 的正確使用、Key 的選擇、回調捕獲
- API 品質：審查 Modifier 規範、參數順序、Slot API 設計
然後技能會生成一份名為 COMPOSE-AUDIT-REPORT.md 的報告，報告不只有分數（0-100），而是每一項扣分都會附帶程式碼位置和官方文件引用（References），例如我的檢查裡：
<div><div><div></div><span>less</span></div><div><div> <span>體驗AI代碼助手</span></div><div> <span>代碼解讀</span></div><div>複製代碼</div></div></div>State management: Android screens collect flows without lifecycle awareness
- 為什麼這很重要：
collectAsState()即使畫面已停止也會持續 collect，這會浪費工作並可能使畫面狀態比預期保持活躍（hot）更久。 - 證據：
app/src/main/java/com/shuyu/gsygithubappcompose/MainActivity.kt:49、feature/search/src/main/java/com/shuyu/gsygithubappcompose/feature/search/SearchScreen.kt:34、feature/detail/src/main/java/com/shuyu/gsygithubappcompose/feature/detail/RepoDetailScreen.kt:106、feature/profile/src/main/java/com/shuyu/gsygithubappcompose/feature/profile/ProfileScreen.kt:28 - 修復方向：新增
lifecycle-runtime-compose並將 Android UI 的收集器改為使用collectAsStateWithLifecycle()。 - 參考：https://developer.android.com/develop/ui/compose/state
最重要的是，它還能從審計結果篩選出影響力最大的修復點，同時預測修復後對 skippable%（可跳過率）指標的提升效果。
相比那些只透過提示詞和規則的技能，這個技能之所以能做到深度的專家級稽核，主要是因為：
- Gradle：專案內帶有
scripts/compose-reports.init.gradle，在使用技能時 AI 會透過--init-script執行專案的 Gradle 任務，將編譯器報告的設定動態注入到建置流程中，在不改動程式碼的情況下取得部分資料。 - 靜態原始碼分析：它定義了一套詳盡的 Ripgrep (rg) 搜尋策略，涵蓋從
derivedStateOf濫用、remember缺 Key 到Scaffold忽略內邊距等數十種常見問題。 - 評分機制：不是主觀評價。在性能評分中，如果
skippable%低於 50%，或不穩定類的數量超過閾值，性能得分會被強制「封頂」（例如最高只能給 4 分），無論其他地方寫得再好也不行。 - 知識圖譜與官方文件掛鉤：該專案維護了一份
canonical-sources.md，將所有審計規則直接關聯到 Android 官方文件與 AndroidX 原始碼中的 API 指引。
所以相較於單純的 AI 評價，它會更專業和全面；而與一般的 Linter 比較，它結合了編譯器的真實資料 + AI，不僅能告訴你「這個類可能不穩定」，還能透過編譯器報告指出是哪個屬性導致不穩定。
當然，它在視覺能力（視覺一致性、佈局審核）方面會比較弱，作者也維護了另一個叫
material-3的技能，該技能會針對 Material 3 的合規性、配色或排版進行評分。
這個技能可以看成是資深工程師的經驗（如何看編譯器報告、如何找狀態提升問題、如何優化副作用）固化成可執行的腳本與規則，再由 AI 做量化判斷，可以說是無私的奉獻：
你可以把它當作每次提交代碼後的自動審查工具，或是在接手一個混亂的舊專案時，用它快速定位性能瓶頸與架構風險。
總之，如果你正在使用 Compose，這個技能絕對不能錯過。
我那個糟糕專案的報告可見： github.com/CarGuo/GSYG…
最後，Android 官方也發布了對應的 skills，目前主要用於幫助 AI 升級與適配的技能，例如：
- 將 Android 專案升級到 Android Gradle Plugin (AGP) 9，包含 DSL 遷移、內建 Kotlin 遷移、KSP 適配等複雜步驟
- 提供將舊版 XML 視圖遷移到 Jetpack Compose 的結構化工作流程，定義了一套包含 10 個步驟的方法論，確保 UI 的視覺一致性與功能完整性
- 其他還涵蓋 Navigation 3 導航系統、R8 分析器 性能優化以及 全螢幕顯示（Edge-to-Edge） 適配等場景
這些技能主要透過各種結構化的技術文件來告訴 AI 應該如何處理升級與適配、需要遵循哪些規則。每個技能都包含詳細的前置需求、具體步驟、操作準則和驗證方法，所以它不僅告訴 AI「要做什麼」，還明確規定了「不能做什麼」，例如：
在 AGP 升級中禁止編寫 Python 腳本。
技能文件中大量引用了 references/ 目錄下的技術參考資料，例如在 XML 遷移技能中，會引用專門的「分析專案佈局」與「設定 Compose 相依性」的子文件。
所以這裡最重要的是，官方已經強烈暗示你：「migrate-xml-views-to-jetpack-compose」，畢竟在 AI 場景下，XML 的確漸漸跟不上了。
總的來說，android skills 偏向通用的升級與適配場景，內容主要是文件與資料；而 compose_skill 則是專家級的經驗檢測，能快速幫你找出需要優化的問題並給出建議。
我已經開始好奇了，你的專案能得幾分 ~
連結
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
