昨天測試正計時功能時，我原本想知道 AI 會不會先理解既有 Code 再開始修改。結果它確實會先讀，也找到了正確的 TimeManager、TimeService 和相關 Fragment，但實際 Build 後卻出現不少奇怪的行為。

最後我留下了一個問題：

哪些地方 AI 可以根據 Code 自己推論，哪些地方應該停下來問我？

所以今天決定用同一個功能再測一次。

同一份 Code、同一個需求，只改 Prompt

為了讓兩次結果可以比較，我先把昨天 AI 做的修改 Rollback，另外保留在其他 Branch，讓今天重新從和 Day 3 完全相同的 Code 開始。

功能需求也沒有改：

請幫我加入正計時功能，進入畫面後從 00:00 開始計時，每秒增加 1 秒，並即時顯示目前經過的時間。

唯一不同的是，這次我多加了一段：

這次請先不要修改 Code。請先閱讀相關實作並分析這個需求可能影響到哪些既有功能。

如果有任何無法從現有 Code 確定、需要由需求決定的行為，請先詢問我，不要自行假設。等需求確認完成後再開始實作。

昨天我是讓 AI 自己決定怎麼開始，今天則刻意把「分析」和「實作」拆成兩個階段。

這次 AI 真的停下來了

收到需求後，AI 沒有修改任何 Code，而是先整理目前 Project 裡已經存在的功能。

它發現 TimeManager 已經有 STOPWATCH 模式，StopWatchFragment 也有開始、暫停、繼續和結束的 UI，背景的 TimeService 也已經支援顯示正計時通知。

更重要的是，它這次在修改以前就發現了昨天實際 Build 後才出現的問題。

例如 Pomodoro 和 Stopwatch 共用同一個 TimeManager，所以它主動問我：

如果番茄鐘或休息正在計時，使用者切到正計時時應該怎麼處理？

它也發現我寫的「進入畫面後從 00:00 開始」其實不夠明確，所以詢問正計時究竟是進入 Tab 就自動開始，還是由使用者按下 Start 才開始。

昨天 AI 直接把 00:00:00 改成 00:00，這次它則先注意到原本的格式不同，再詢問我要的是 MM:SS，還是維持原本的格式。

另外還問了離開 Tab 或 App 進入背景後要不要繼續計時、通知要不要保留、正計時結束後是否需要建立專注紀錄。

甚至還發現一個我昨天沒有注意到的地方：原本 Stopwatch 建立專注紀錄時，傳入的 isPomodoro 居然是 true。

看到這裡，我開始覺得昨天的問題可能不只是「AI 沒有理解完整」，也可能是我太快讓它開始寫 Code 了。

回答完問題，再讓它開始實作

這次我先把規則確認清楚，例如正計時必須由使用者按 Start 才開始，Pomodoro 和 Stopwatch 不能同時計時，切換 Tab 不會停止目前的計時，離開 App 後也要繼續，回來時不能重新從 0 開始。

需求確認完，我才讓 AI 開始修改。

Build 成功後實際操作，結果跟 Day 3 差異滿明顯的。

正計時可以正常開始、暫停和繼續，切換 Fragment 再回來不會歸零，App 切到背景後也會繼續計時，Notification 顯示的模式也正確。

當正計時正在進行時，Pomodoro 會變成 Disabled，而且 AI 還自己加了一行提示：

「正計時計時中，番茄鐘暫時無法使用」

反過來也一樣，Pomodoro 正在計時時，AI 也有處理 Stopwatch，避免使用者同時啟動兩種計時。

這點是我沒有逐項告訴它怎麼寫的，我只確認了「兩種計時不能同時進行」這個需求，至於畫面怎麼處理，則是由它根據這條規則完成。

但「先問」還是沒有解決所有問題

原本我看到這裡，差點以為今天可以得到一個很簡單的結論：

只要叫 AI 先分析、先問清楚，再開始寫，結果就會比較好。

但繼續操作後，我又發現了一些它完全沒有問到的地方。

原本 Pomodoro 有一個規則，如果專注時間少於 5 分鐘，結束時會出現 Dialog 提示不會留下紀錄。但 AI 在分析 Stopwatch 時，沒有注意到這個既有行為，也沒有問我正計時需不需要相同的規則。

Pomodoro 原本也有手動新增專注紀錄的功能，但它同樣沒有詢問 Stopwatch 是否需要。

有趣的是，正計時「自動建立紀錄」這件事它有處理，而且也正確區分成正計時紀錄，沒有再被當成 Pomodoro。

所以這次 AI 不是完全沒有理解既有功能，而是有些關聯它找到了，有些卻沒有。

AI 只能問出它有發現的問題

這讓我發現，「叫 AI 有問題就先問」其實還有一個前提：

它要先知道這裡有問題可以問。

Pomodoro 和 Stopwatch 共用 TimeManager，這個關係很直接，所以它發現了。

開始時機、背景計時、Notification、紀錄類型也跟這次需求直接相關，所以它都問到了。

但「少於 5 分鐘不紀錄」和「手動新增」比較像是既有 Pomodoro 裡額外存在的功能規則。AI 沒有把它們跟新增 Stopwatch 連在一起，自然也就不會問我需不需要保持一致。

所以今天的結果並不是「加一句不要自行假設，AI 就不會漏需求」。

比較像是：

把分析和實作拆開，確實可以讓很多原本 Runtime 才發現的問題，在寫 Code 前就先被提出來。

但它還是可能存在 Blind Spot。

昨天的 Workflow 是：

Requirement → Implementation → Build → Runtime 才發現問題

今天則多了一層：

Requirement → Impact Analysis → Questions → Implementation → Runtime Verification

至少這次，同一份 Code、同一個需求，只是改變開始寫 Code 前的流程，最後的結果就已經差很多。

而現在我又多了一個新的問題：

如果 AI 只能問出它有發現的問題，那我要怎麼讓它主動找到那些「它不知道自己漏掉了」的需求？

看來明天又有東西可以繼續測了。

下一集見 :)