其實 AI 有發現問題癥結點也是無法解決：
「移除所有主題系統引用 - 不再使用 MaterialTheme.colorScheme」
但是他其實根本沒有真正移除掉，他留了最上層的 system design 的 theme 在那邊，或許對於 AI 來說這才是基本預設的設計
但是對於先前沒在管 system design ，單一元件單一背景調整顏色與樣式的狀況，這等於是雪上加霜
最後，我決定把自己降級為專案經理團隊裡的小M (Manager)，一個親力親為、把目標切到最小、把 Scope 框到最死的主管。我的新戰術很樸實，甚至有些笨拙：
同時，我祭出了 Jetpack Compose 的一個樸實無華卻極其好用的功能：@Preview。
我要求 AI 必須為所有實作的 UI 加上預覽，讓我可以透過人工的方式，像審批零件一樣，在不實際運行的情況下，快速判斷哪個元件合格、哪個有問題，最後再把它們組裝起來。
@agent-pm 我希望每個元件都可以再拆出來，請幫我協同 @agent-android-dev 拆分更細小的元件，然後記得要補上 @Preview 讓我可以查看最小單位的元件
然後他在最後給予了這個回應：
- 為所有 Compose 畫面添加 @Preview
已為所有 15 個畫面添加預覽功能：
- IndexScreen（首頁）
- LeaderBoardScreen（排行榜）
- ProfileScreen（個人資料）
- ResultScreen（結果頁）
- RankListScreen（排名列表）
- 以及其他 10 個畫面
現在你可以：
- 不會再閃退 - RankListViewModel 參數問題已修復
- 在 Android Studio 中預覽所有畫面 - 使用 Split 或 Design 視圖查看
- 自行調整顏色 - 在預覽中即時看到變化
編譯成功，沒有錯誤，只有一些既有的 deprecation 警告（不影響功能）。
然後，AI 給了我一個看似完美的回應。它宣稱已為所有 15 個「畫面」添加了預覽功能，並解決了閃退問題。
他確實為每個「頁面 (Screen)」加上了 @Preview，但我的本意是「元件 (Component)」啊！結果就是，預覽功能不僅有 Render Issue，我看到的依然是一整個混亂的頁面，而不是我想要的、那個可以獨立驗收的「最小單位」。
這就是馴獸失敗的現場：我們說著同樣的詞，腦中卻是完全不同的東西。
至此，我明白了，我必須把指令的精確度，提升到「不容任何模糊解釋」的程度。我發出了最後通牒，這一次，我不要它猜，我要它寫下來：
@agent-pm 我希望每個元件都可以再拆出來，請幫我協同 @agent-android-dev 拆分更細小的元件，然後記得要補上 @Preview 讓我可以查看最小單位的元件
以及
@agent-pm 你能協同 @agent-system-architect 與 @agent-android-dev 幫忙把要拆出來的元件裂成表且放到 md 文件裡嗎
這份文檔包含了：
1. 36+ 個元件的詳細表格，包括：
- 元件名稱
- 來源位置
- 功能描述
- 參數列表
- 依賴關係
- 目前狀態（✅ 已完成 / 📝 待處理）
2. 元件分類：
- 核心 UI 元件：圓形選擇器等（4個，已完成）
- 卡片元件：ActionCard、ActivityCard 等（3個，已完成）
- 媒體元件：VideoPlayer、CameraPreview（2個，已完成）
- 視覺化元件：RopeCanvas 等（2個，已完成）
- 畫面專屬元件：25個待拆分
3. 實施計畫：
- 第1週：核心元件
- 第2週：畫面專屬元件
- 第3週：結果與分析元件
- 第4週：優化與文檔
4. 開發指南：
- 命名規範
- 參數設計原則
- 預覽要求
- 測試策略
5. 成功指標：
- 70% 元件重用率
- 50% 減少重複程式碼
- 20% 建置速度提升
當拆分文件與畫面截圖都已經 ready 後，接下來就是等他拆分的每個段落的實作
然後下面附上目前的成果圖
因為太多了所以附上幾張來代表代表
當拆分文件與畫面截圖都準備就緒後，整個專案的樣貌瞬間清晰了起來。接下來，就是驗收成果的時刻。附上目前幾個已完成的元件預覽圖，雖然只是冰山一角，但每一個都是在清晰指令下誕生的完美結晶。
這次的慘痛經驗也實際告訴我們一個真理：與 AI 協作，我們不能期待它能讀懂人心。我們必須將模糊且範圍龐大的需求，盡最大可能地拆分釐清。你給的 Scope 有多清晰，AI 的產出就有多精準。
iThome鐵人賽
看影片追技術