android-clean-architecture

android-clean-architecture 技能概覽

android-clean-architecture 技能可協助你把 Android 與 Kotlin Multiplatform 應用程式建立在清楚的邊界之上，而不是靠零散堆疊的功能碼來撐起架構。它最適合需要一個務實起點的工程師，協助規劃模組、依賴規則、UseCases、Repositories 與資料層設計，而不是上了一堂空泛的理論課。

這個 android-clean-architecture 技能的用途

當你需要判斷邏輯應該放哪裡、各模組之間應該如何依賴，以及如何避免 UI、domain 和 data 的責任混成同一層時，就適合使用 android-clean-architecture。如果你正在為新程式碼庫建立標準，或要重構一個逐漸膨脹的應用，這個技能尤其有用。

最適合哪些人

這個 android-clean-architecture 技能很適合正在打造 Android app、KMP 共用程式碼，或以 Compose 為核心、但已經開始出現過度耦合問題的產品團隊。當你在 feature modules、分層 modules，或較簡單但仍保有清楚邊界的 single-module 架構之間做選擇時，它也很實用。

主要差異

不同於模糊的架構提示，android-clean-architecture 會聚焦在具體結構：模組配置、允許的依賴關係、repository 放置位置，以及 Room、SQLDelight、Ktor、Koin 或 Hilt 要接在哪一層。當你想避免過度設計，或避免層與層之間不小心滲漏時，這種做法更有決策價值。

如何使用 android-clean-architecture 技能

安裝並啟用它

先用你的 skills manager 走 android-clean-architecture 的安裝流程，接著打開 skill 檔案，並在規劃或編輯架構時讓它保持在上下文中。如果你的環境支援透過 path 載入，就指向 skills/android-clean-architecture/SKILL.md，讓模型在任務中遵守這些架構規則。

給它一個具體的架構任務

android-clean-architecture 的使用方式，最適合搭配明確產出，例如模組拆分、依賴關係對應，或層級放置。好的輸入會清楚點出平台、現有技術棧，以及限制條件。

範例提示詞：

• “Design an android-clean-architecture module layout for a Compose + Hilt app with offline sync.”
• “Refactor this KMP feature into android-clean-architecture layers using Room on Android and SQLDelight in shared code.”
• “Review these modules and point out dependency rule violations.”

先讀對的部分

先從 SKILL.md 開始，再聚焦在定義何時啟用、建議結構與依賴規則的章節。這些內容會直接影響實作選擇。如果你的 repo 只有這一個檔案，就把那些章節視為唯一依據，並依照你自己的 package 名稱與 build 設定進行調整。

提供能提升輸出品質的資訊

先給這個技能一份簡短清單，列出現有內容：模組、儲存工具、DI 框架、網路堆疊，以及應用是只有 Android，還是 KMP。也要說明你希望保留什麼，例如既有的 feature 邊界或公開 API。你目前狀態描述得越具體，android-clean-architecture 指南就越不容易憑空加出不必要的層級。

android-clean-architecture 技能 FAQ

android-clean-architecture 只適合新專案嗎？

不是。android-clean-architecture 技能對綠地開發與重構都很有用。當你需要替一個已經變得混亂的既有 app 建立邊界時，它特別強，因為它能幫你決定哪些該移動，而不必一次全部重寫。

這和一般提示詞有什麼不同？

一般提示詞也可以要求分層架構，但 android-clean-architecture 會提供更聚焦的 Android 與 KMP 決策結構。這代表你在依賴方向、模組命名，以及 data source 與 repository 程式碼放置位置上，會得到更精準的指引。

這適合初學者嗎？

可以，但前提是你願意從具體的模組地圖開始。若你想要的是沒有實作細節、只談概念的 Clean Architecture 高層說明，它就不那麼適合。初學者在用它驗證簡單、明確的結構時，通常能得到最大的價值，而不是拿它去包住一個過於龐雜的設計。

什麼情況下不該用它？

如果你的 app 很小、團隊本來就刻意避開分層架構，或你只是想快速做出一個功能、沒有模組設計需求，就不要用 android-clean-architecture。在這些情況下，這個技能可能會帶來你其實不需要的結構。

如何改進 android-clean-architecture 技能

先說出你需要哪個架構決策

提升 android-clean-architecture 輸出的最快方法，是一次只問一個決策：模組邊界、依賴圖、資料流，或 DI 串接。如果你問的是「最佳架構」，結果通常不如直接問「在這個 KMP repository 設定裡，cache 應該放哪裡？」來得實用。

把你的真實限制講清楚

把重要的技術棧與限制一併說明：只做 Android 還是 KMP、Compose 還是 XML、Room 還是 SQLDelight、Ktor 還是 Retrofit、Hilt 還是 Koin，以及是否必須支援 offline-first。這些細節會改變建議的結構，也能避免 android-clean-architecture 指南過度貼合錯誤的後端或儲存模型。

注意常見失敗模式

最常見的錯誤，是讓每個 feature 都各自擁有一套迷你架構，卻沒有共享規則。另一個錯誤，是為了圖快，把 business logic 寫進 presentation code。要儘早用這個技能檢查邊界，再配合你實際的 package tree 和 build files 進行修正。

用接近 repo 結構的方式持續迭代

第一次輸出後，可以再要求依賴審核，或對照你目前的目錄樹，做一份逐檔案的放置計畫。例如：“Map these existing packages to the android-clean-architecture layout and flag anything that should move to domain or data.” 這類追問能把這個技能從概念指南，變成真正的遷移工具。