昨天我讓 AI 在寫 Code 前先分析需求，有不確定的地方就先問我，結果確實比直接開始實作好很多。原本 Day 3 要到實際操作才發現的 Pomodoro 和正計時互相影響、進入畫面要不要自動開始、背景要不要繼續計時，Day 4 都在寫 Code 前就先被提出來了。

但最後還是有東西漏掉。

原本 Pomodoro 有「少於 5 分鐘不記錄」的規則，也有手動新增專注紀錄的功能，但 AI 完全沒有問我正計時需不需要相同的行為。

所以昨天最後留下了一個問題：

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

今天決定換一個方式試試看。

不只看 Impact，去找 Project 裡已經存在的相似功能

這次一樣先不要讓 AI 修改 Code，不過除了分析正計時會影響哪些既有功能，我又多加了一個要求：

請另外找出 Project 中與正計時功能相似、相鄰或共用流程的既有功能，逐項比較它們目前具有的行為與規則。

如果既有類似功能存在某些額外行為，而目前需求沒有說明正計時是否也需要，請不要自行假設，列出來詢問我。

最後我還要求它把結果分成三類：

1. 可以從現有 Code 確認的行為
2. 需要我確認的需求
3. 可能被遺漏，但值得確認的既有功能或規則

Day 4 比較像是從「我要加入正計時」開始，往外找這次 Change 會影響到誰。今天則多了一個方向，不只是看正計時本身，而是回頭看看 Project 裡已經存在的相似 Feature 是怎麼做的。

這次真的找到昨天漏掉的東西了

AI 重新閱讀後，除了 Day 4 已經找到的共用 TimeManager、背景計時、Notification、紀錄方式和 Pomodoro 互斥問題，這次真的多找出了一些原本沒有被注意到的規則。

其中一個就是昨天漏掉的：

「少於 5 分鐘不記錄」是番茄鐘的既有規則，手動新增的非番茄鐘紀錄也要求至少 5 分鐘。正計時結束時是否也要套用最短時長限制？

這比我原本預期的還多了一步。

我原本只是注意到 Pomodoro 有少於 5 分鐘不記錄的 Dialog，但 AI 不只找到 Pomodoro，還發現手動新增的「非番茄鐘紀錄」其實也有相同的最低時間限制。

也就是說，它找到的可能不只是：

Pomodoro 有這個功能，Stopwatch 要不要也照著做？

而是開始看到：

「專注紀錄至少 5 分鐘」可能本來就是 Project 裡更共通的一條規則。

除此之外，它還找到 Pomodoro 提早結束時有「提前完成／放棄」流程、不同紀錄對 Label 的處理方式、Pomodoro 專用的設定選單、正計時應不應該納入總專注時長和圖表，甚至連 App Process 被終止之後計時能不能恢復都列了出來。

這些都不是我原本寫在「加入正計時」需求裡的東西。

問得比較完整，最後真的會做得比較完整嗎？

不過只會問問題還不夠。

Day 4 我最後有真的讓 AI 實作，再 Build、實際操作，所以今天我也決定把流程走完。我回答完它提出的問題後，再讓它開始修改 Code。

這次我確認正計時也要遵守少於 5 分鐘不記錄，超過 5 分鐘才建立專注紀錄，而且正計時要算進總專注時間，但不能增加番茄數。

Build 成功後實際測試，這些規則真的有被做進去。

正計時不到 5 分鐘就結束時，畫面會出現提示，也不會建立紀錄。超過 5 分鐘後結束則會正常建立正計時紀錄，番茄數也沒有跟著增加。

所以這次不是只有「AI 多問了幾題」。

Existing Behavior Comparison 找到的新規則，真的影響了最後的 Implementation。

而且這一版在正計時進行中時，Pomodoro 無法使用的畫面提示，我自己也比 Day 4 的版本更喜歡。

看到這裡，本來又很容易得到一個結論：

那以後叫 AI 找相似功能不就好了？

結果繼續操作，又看到新的問題。

Behavior 對了，畫面卻不一定一致

這次 AI 有正確處理兩種計時不能同時進行。

正計時正在跑時，Pomodoro 不能開始。Pomodoro 正在跑時，正計時也不能開始。

功能上看起來是一樣的規則，但兩邊 Disabled 的畫面卻長得不一樣。

其中一邊連時間文字都會一起變成淡灰色，很明顯可以看出目前不能操作。另一邊時間文字還是原本的樣子，只有開始按鈕變淡並且不能點擊。

也就是：

Behavior 一致，不代表 UI Feedback 也一致。

另外我還發現一個原本就存在的時間格式問題。Pomodoro 超過 60 分鐘時，畫面會顯示 70:00，但 Notification 顯示的卻是 01:10:00。

AI 在分析時其實有注意到正計時畫面和 Notification 的時間格式不同，也有詢問我要使用哪一種格式，但它沒有再往外多走一步，檢查 Project 裡不同計時畫面的 Formatting Rule 本身是不是一致。

至於正計時超過一小時之後實際會顯示什麼，這次我沒有真的等一個小時測，所以先不把它當成已驗證的結果。

「找相似功能」也不是一句話就能全部找完

還有一件滿有趣的事。

這次 AI 確實找到「手動新增專注紀錄」這個既有流程，甚至從裡面發現非番茄鐘紀錄也有 5 分鐘限制，但最後正計時的 ViewPager 裡還是沒有手動新增的入口。

這不一定代表它做錯了，因為我並沒有明確確認正計時一定需要這個入口。

但它也讓我看到另一件事：

AI 發現某個 Existing Behavior，不代表它一定會把所有相關的 Requirement Question 都推導出來。

回頭看今天的結果，我覺得 Day 4 和 Day 5 做的事情其實不太一樣。

Day 4 的問題比較像：

這次 Change 會影響哪些東西？

Day 5 則多了一個：

Project 裡類似的 Feature 已經有哪些規則，而新的 Feature 是否也需要？

前者是 Impact Analysis，後者比較像 Existing Behavior Comparison。

加入這一層之後，AI 的確找到更多原本沒寫進需求的規則，最後的實作也真的比前一天完整。

但今天實際操作後，我又發現「相似」本身其實還可以拆成很多東西。

Existing Behavior
├── Business Rule
├── Interaction
├── UI Feedback
├── Data / Record
└── Edge Case

AI 這次找到不少 Business Rule、紀錄和操作上的關係，卻還是可能漏掉 UI Feedback、入口和 Formatting 這些一致性問題。

所以今天我想替目前的 Workflow 再多留下一層：

不要只問這次修改會影響什麼，也要回頭比較 Project 已經存在的相似行為。

但同時也不能因為 AI 列了一大串 Existing Behavior，就以為它已經把所有相似的地方都看完了。

從 Day 3 一路測到現在，我的 Prompt 好像越來越長了。

如果之後每次開發 Feature，我都要重新提醒 AI「先讀 Code」、「先分析 Impact」、「找相似 Feature」、「不確定的先問我」，好像也有點麻煩。

那這幾天真的測過、留下來的規則，是不是可以開始整理成一套固定的 Workflow？

明天來整理看看。

下一集見 :)