這個系列寫到第十天，剛好可以回頭看一下最開始的問題：

AI 都已經會寫 Code 了，我為什麼還想更懂 Android？

這幾天其實沒有做什麼很大的功能，大部分時間都在拿一個原本就有 Pomodoro 的小 Project，讓 AI 幫我把 Stopwatch 接起來，再慢慢調整我跟 AI 合作的方式。

但就是這些不大的修改，反而讓我越來越確定一件事。

AI 可以讓我更快寫出 Code，但沒有讓「理解 Code」這件事變得不重要。

AI 寫出第一版真的很快

一開始我只是告訴 AI：

幫我加入正計時功能。

它很快找到 TimeManager、TimeService、Fragment，也知道可以沿用原本的計時架構。

如果只看產生 Code 的速度，確實比我自己從頭找快很多。

但後來實際跑起來，問題也開始出現。

Stopwatch 和 Pomodoro 共用了計時狀態，切換頁面後顯示互相影響，AI 還自己決定進入 Stopwatch 就開始計時。

Code 可以 Build，但功能並不代表真的正確。

這也是我第一次很明顯感覺到：

AI 幫我省下的是「寫」的時間，不一定是「判斷」的時間。

如果我不懂 Android，我甚至不知道該懷疑哪裡

例如看到 Fragment 切換後 Stopwatch 的狀態還存在，我需要知道這可能不只是畫面文字沒有更新。

我會開始往下想：

Fragment
↓
ViewModel
↓
TimeManager
↓
LiveData
↓
TimeService

到底誰真的持有計時狀態？

Fragment 被重新建立會怎樣？

Service 是負責計時，還是只負責通知？

為什麼兩個頁面會看到同一份時間？

這些問題 AI 當然也可以回答。

但前提是，我得先知道這裡「有問題值得問」。

如果完全不知道 Fragment Lifecycle、ViewModel、Service 或狀態管理，我可能看到畫面可以動、Build 也成功，就覺得功能完成了。

我需要懂的東西，好像也跟以前不太一樣

以前學 Android，很容易把目標放在：

這個 API 怎麼寫？

這段語法怎麼用？

這個功能要怎麼實作？

現在這些問題 AI 通常很快就能給出第一版答案。

所以我反而更想知道：

為什麼這個 Project 要這樣設計？

例如為什麼 Timer 狀態放在 TimeManager？

為什麼 Fragment 只 observe LiveData？

為什麼 TimeService 不自己維護另一份 Timer？

如果今天要加 Stopwatch，應該沿用哪一層，又有哪些行為其實不應該共用？

這些「Why」會直接影響我能不能判斷 AI 寫出來的 Code 到底適不適合目前的 Project。

AI 越快，我越不能只看結果

這幾天我也一直遇到同一種情況：

Build Success
≠
Feature Correct

再往下甚至是：

Feature Correct
≠
Integration Correct
≠
Requirement Correct

AI 可以很快讓某一段 Code 編譯成功，但它不一定知道 Stopwatch 和 Pomodoro 應不應該同時執行，也不一定知道少於 5 分鐘不建立紀錄是不是兩個功能都應該遵守的規則。

有些答案藏在 Existing Code 裡，有些答案則根本不在 Code 裡。

這也是為什麼後來我開始要求 AI 先分析影響、比較既有功能，再慢慢整理成自己的 Skill。

目的不是讓 AI 每次都做更多事情，而是讓它在寫得很快的同時，不要跳過原本應該做的判斷。

所以我現在還想更懂 Android 嗎？

答案其實比 Day 1 更明確了。

我不一定需要跟 AI 比誰比較快寫出一個 Fragment，也不需要把每一個 API 都背起來。

但我需要看得懂它做了什麼，也要知道：

State 應該由誰持有
資料為什麼這樣流
Lifecycle 會造成什麼影響
哪些東西應該共用
哪些東西不該耦合
現在的 Architecture 為什麼存在

因為 AI 越能幫我完成 Implementation，我真正需要負責的部分反而越往「理解與判斷」移動。

寫到第十天，我目前對這個實驗最大的感覺大概就是：

我不是因為 AI 不會寫 Code，才需要懂 Android。

而是因為 AI 已經很會寫 Code 了，我才更需要知道它寫的東西到底對不對。

接下來還有二十天，我想繼續試看看：如果把更多「理解、判斷、驗證」的方法整理出來，我能不能真的建立一套適合自己使用 AI 開發 Android 的方式，而不只是讓 AI 幫我把 Code 寫得更快。