前幾天一直在調整 AI 寫 Code 前要做多少分析。

一開始我遇到的問題是 AI 太快開始實作，後來要求它先分析影響、比較既有功能，再到昨天把這些規則整理成 Skill，希望它可以自己判斷什麼時候需要多看一點。

但做到這裡，我開始覺得還有另一個問題沒有處理：

就算 AI 找到了足夠的 Code，哪些事情可以自己推論，哪些事情還是應該由我決定？

這其實比「要不要多讀幾個檔案」更重要。

有些事情，其實不用每次都問我

如果現有 Project 已經有很明確的寫法，我不希望 AI 每改一個小地方就停下來問。

例如我要新增一個 Dialog 按鈕文字，而 Project 的字串本來就統一放在 strings.xml，那它可以直接沿用。

或是附近幾個相似畫面都有相同的命名方式、UI 寫法，這些通常也可以從 Code 找到答案。

這類事情如果每次都問：

要不要放進 strings.xml？
要不要沿用現在的命名方式？
要不要使用目前的 UI 寫法？

反而會讓開發變得很慢。

所以我希望 AI 可以自己推論的是：

Project 已經有明確慣例
↓
這次沒有改變功能行為
↓
沿用 Existing Pattern

這種情況，我比較在意的是它有沒有遵守目前的 Project，而不是每一件事都經過我同意。

但 Business Rule 不太一樣

如果今天改的是：

少於幾分鐘不建立紀錄

事情就不一樣了。

5 分鐘、3 分鐘或 1 分鐘，並不是從 Android Architecture 可以推論出來的。

AI 可以從 Code 發現：

Stopwatch：5 分鐘
Pomodoro：5 分鐘

它也可以告訴我：

如果只修改 Stopwatch，兩邊的規則會變得不一致。

但「要不要一致」這件事，不一定能從 Code 得到答案。

這時 AI 最有價值的地方不是幫我選，而是讓我看到：

這裡其實有一個我還沒做的決定。

我開始把問題分成兩種

目前我會先很粗略地分成：

Code 可以回答
→ AI 自己判斷

Code 只能提供線索
→ AI 找出差異，讓我決定

像是沿用命名、既有 Architecture、字串放哪裡、附近已經有明確 Pattern 的實作方式，通常比較接近第一種。

但如果會改變使用者實際行為、資料結果、不同 Feature 之間的規則，或是牽涉「產品應該怎麼運作」，就比較接近第二種。

這也讓我重新理解前幾天一直在講的：

不要自行假設需求。

它不是代表 AI 什麼都不能推論。

如果什麼都要問，那我只是多了一個一直丟問題回來的 Coding Agent。

真正想要的應該是：

Code 能回答的事情自己找答案，Code 不能替我決定的事情才來問我。

「知道很多」和「有權決定」是兩件事

這可能是我目前使用 AI 寫 Code 最容易混在一起的地方。

AI 可以讀完整個 Feature，知道 ViewModel 怎麼拿資料、TimeManager 怎麼計時、紀錄最後存去哪裡，也可以找到其他功能現在怎麼做。

但知道這些，不代表它就能決定：

Stopwatch 要不要自動開始？
兩種 Timer 能不能同時執行？
少於幾分鐘才不建立紀錄？
不同計時方式的規則要不要一致？

Code 可以幫忙找到這些問題，甚至提供做決定需要的資訊，但最後有些答案本來就不存在 Code 裡。

這也是我現在希望 Skill 慢慢做到的事情：

先讀 Code
↓
能確認 → 自己處理
↓
不能確認
↓
找出這個決定會影響什麼
↓
再問我

而不是兩個極端：

什麼都自己決定

或：

什麼都問我

我想要的不是更聽話的 AI

寫到第八天，我發現自己一直在調 Prompt、Workflow、Skill，但目的好像慢慢變得比較清楚了。

我不是想把所有開發規則寫得非常完整，讓 AI 只能照著固定步驟走。

我真正想要的是：

讓 AI 自己處理可以從 Code 判斷的事情，同時知道什麼地方不應該替我做決定。

這樣我才不用把每一個實作細節都寫進 Prompt，也不用在 AI 寫完之後，才發現某個原本應該由需求決定的行為，被它默默選了一個答案。

所以接下來除了繼續調整 Skill 怎麼找 Code，我也想慢慢把另一條界線整理清楚：

哪些是 Implementation Decision，哪些其實是 Requirement Decision？

這條線如果能分得更清楚，可能比單純讓 AI 看更多 Code 更重要。