當你同時扮演架構師、開發者、測試員時，如何快速學習新技術？
讓 AI 成為你的學習夥伴。
經過上週的翻車和反思，我終於放下 Java 習慣，擁抱 Kotlin 哲學了。
但問題來了。
作為一人公司的架構師，我要如何快速掌握 Kotlin Multiplatform (KMP) 的最佳實踐？
特別是在 2025 年這個時間點，KMP 生態系統快速演進，Compose Multiplatform for iOS 剛達到穩定版本，各種最佳實踐也在不斷更新。一個人要如何跟上這些變化？
答案是：讓 AI 成為你的學習研究助理。
故事從一個簡單的問題開始。
「我的 UI 程式碼應該放在 shared 模組還是平台特定模組？」
這看似簡單的問題，實際上涉及了整個 KMP 架構哲學。讓我們看看如何透過 AI 輔助來找到答案。
與其漫無目的地學習，不如從實際問題開始：
我：「符合 Kotlin Multiplatform (KMP) 的最佳建議實作？
要參考新的做法（今年是 2025 年）
要附上 best practices 資訊來源」
AI：「讓我搜尋最新的 Kotlin Multiplatform 最佳實踐...」
關鍵是：
AI 找到的資訊需要驗證，我的做法是要求多個來源：
我：「請搜尋 JetBrains 官方文件和社群最佳實踐」
AI 回應的資源：
- JetBrains 官方: Compose Multiplatform 1.8.0 Release (2025.05)
- 官方 Roadmap: KMP Development Roadmap for 2025
- 社群實踐: KMP Architecture Best Practices
找到資源後，要深入了解細節：
我：「請從 Compose Multiplatform 1.8.0 Release 文章中提取：
1. iOS 支援的官方狀態
2. 推薦的專案結構
3. UI 共享 vs 分離的最佳實踐」
AI：關鍵發現：
- iOS 支援已達「Stable」狀態
- 96% 團隊無重大效能問題
- 僅增加 9MB 相較於純 SwiftUI
首先，我請 AI 幫我分析現有架構。
我：「分析 Grimo 專案的現有架構，識別哪些是 UI 相關、哪些是業務邏輯」
AI 分析結果：
- 多個 UI 檔案在 shared/commonMain（違反最佳實踐）
- domain、core、data 層符合規範
- 需要將 presentation 層分離
接著評估不同的架構選項。
共享 UI (Compose MP) 可以達到 95% 的程式碼共享率，適合新專案和快速開發。而且在 2025 年，iOS 支援已經穩定了。
分離 UI (Platform Native) 的共享率約 60-70%，但能提供深度整合和原生體驗，比較適合現有專案整合。
基於研究結果，執行架構重構：
// Before: shared/commonMain/kotlin/.../presentation/
@Composable
fun ProjectListScreen() {
// UI 邏輯錯誤地放在 shared 中
}
// After: desktopApp/jvmMain/kotlin/.../presentation/
@Composable
fun ProjectListScreen() {
// UI 正確地放在平台特定模組
}
實際遷移了多個核心檔案：
透過 AI 輔助研究，我整理出以下關鍵發現。
Compose Multiplatform for iOS 終於達到穩定版了（2025.05）。生產環境就緒，96% 團隊沒有效能問題，而且僅增加 9MB 大小。
Kotlin-to-Swift Export 也在 2025 年推出首個公開版本，大幅改善 iOS 互操作性。
your-kmp-project/
├── shared/ # 純業務邏輯（無 UI）
│ ├── commonMain/ # 跨平台業務邏輯
│ └── platformMain/ # 平台特定實作
│
├── composeApp/ # Compose Multiplatform UI（可選）
│ ├── commonMain/ # 共享 UI（95% 共享）
│ └── platformMain/ # 平台調整
│
└── platformApp/ # 平台進入點
什麼時候選擇共享 UI？
新專案開發、需要快速原型、團隊熟悉 Compose、可接受 95% UI 共享時。
什麼時候選擇分離 UI？
現有原生應用整合、需要 100% 原生體驗、有複雜的平台特定功能時。
好的提問方式：
「搜尋 2025 年 Kotlin Multiplatform 最佳實踐，
特別是 UI 分離架構，需要官方來源」
不好的提問：
「KMP 怎麼寫？」
我：「給我看 expect/actual 在 2025 年的使用範例」
AI：
// commonMain
expect fun getPlatformName(): String
// iosMain
actual fun getPlatformName(): String = "iOS"
// androidMain
actual fun getPlatformName(): String = "Android"
永遠確認資訊的時間點。
2023 年的教學可能過時了。2025 年的官方文件和最新版本的 Release Notes 才是可靠的。
經過這次 AI 輔助學習和實際重構，我的專案怎麼了？
符合最佳實踐了。UI 層完全分離、業務邏輯純淨、平台邊界清晰。
也為未來做好準備。可輕鬆加入 Android/iOS、可選擇共享或分離 UI、架構彈性大幅提升。
最重要的是學習效率。從過去需要幾天研究文件，到現在幾小時就能掌握。而且獲得最新資訊（2025.05 的更新），有具體實作參考，不再盲目摸索。
透過 AI 找到的寶貴資源：
作為一人公司的架構師，我沒有團隊可以討論，沒有前輩可以請教。
但我有 AI 作為學習夥伴。
關鍵不是 AI 有多厲害，而是你如何使用它。明確你的問題，從實際需求出發。要求資訊來源，可驗證的知識才有價值。深入關鍵細節，不要停留在表面。實踐驗證，動手做才是真學習。持續更新，技術在演進，學習不能停。
最重要的是，AI 是助理不是導師。
它幫你快速收集資訊、整理知識，但架構決策還是要靠你自己的判斷。
就像這次重構，雖然 Compose Multiplatform for iOS 已經穩定，但考慮到 Grimo 的定位和我的資源，我還是選擇了分離 UI 的架構。這不是 AI 能替你決定的，但 AI 能幫你做出更明智的決定。
「AI 時代的學習，不是讓 AI 替你思考，而是讓 AI 幫你更快地思考。」
關於作者：Sam，一人公司創辦人。正在打造 Grimo，一個智能任務管理和分配平台。
專案連結：GitHub - grimostudio
iThome鐵人賽
看影片追技術