這幾天一直在調整我把需求交給 Coding Agent 的方式。
Day 3 我發現 AI 就算有先讀 Code，也不代表它真的理解整個需求。Day 4 開始要求它先做 Impact Analysis，把無法從 Code 判斷的需求先問我，結果確實改善很多。Day 5 又再多要求它比較 Existing Behavior，結果連原本沒注意到的「少於 5 分鐘不記錄」都被找出來了。
照這個方向繼續下去，好像只要一直要求 AI「再多看一點」就好了。
但我突然想到另一個問題：
如果每一個需求都要讀一大堆 Code、分析所有相似 Feature、列出 Edge Case 再問一堆問題，那一個很小的修改是不是也會消耗很多不必要的 Token？
我想要 AI 理解 Project，但好像也不是看越多越好。
假設今天的需求只是修改一個 Button 的文字，我其實不需要 AI 從 Fragment 一路找到 ViewModel、Repository、Database，再分析 Project 裡所有 Button 的設計方式。
找到這個文字從哪裡來，確認修改不會影響其他共用畫面，可能就已經夠了。
但如果需求是前幾天測試的「加入正計時」，情況就完全不同。它會碰到 Pomodoro、TimeManager、Notification、專注紀錄、統計，甚至還有 Lifecycle 和不同計時模式之間的互斥。
所以我開始覺得，真正想留下來的規則不應該是：
每次都盡可能閱讀所有相關 Code。
而比較像：
先從完成這次任務需要的最小範圍開始，只有發現 Dependency、Shared Logic、Existing Pattern 或可能的 Side Effect 時，再往外擴大。
簡單的需求就停在簡單的範圍，真的會影響其他 Feature 時才繼續往外找。
這樣 AI 需要做的不只是 Read Code，而是先判斷：
我現在知道的 Context 已經足夠了嗎？
另外一個我很在意的問題是 Over-engineering。
有時候一個需求明明只需要在現有流程多加一個判斷，最後卻多出新的 Manager、Helper、Interface 或 Wrapper。
這些東西不一定是錯的，但如果只是為了「未來可能會用到」而提前建立很多 Abstraction，最後反而會讓 Code 更難讀，也增加後續維護成本。
所以我希望 AI 優先做到的是：
Prefer the smallest change that fits the existing architecture.
先遵照 Project 現在的 Architecture、Naming 和 Pattern。如果現有結構可以合理承載需求，就不要因為這次修改另外包一層。
但「最小修改」也不是代表所有東西都塞進同一個地方。
如果某個需求已經可以合理預期之後會調整，例如計時模式可能增加、某個規則本來就是可設定的，那還是可以保留適當的調整空間。
我目前比較想要的平衡是：
對已知可能變動的地方保留彈性，不為純粹想像中的未來需求提前設計。
前幾天測試時還有一個感覺。
有些需求其實不只有一種實作方式，而我不希望 AI 每次看到這種情況就直接選一個，改完之後我才從 Diff 發現它做了 Architecture Decision。
如果真的存在有意義的 Trade-off，我反而希望它先給我 2～3 個適合目前 Project 的方案。
但我不只想看到：
A 比較簡單
B 比較有擴充性
我希望它可以順便告訴我，實際寫成 Code 大概會長什麼樣子。
例如一個計時模式的差異，如果目前 Project 已經使用 when：
when (mode) {
Mode.POMODORO -> handlePomodoro()
Mode.STOPWATCH -> handleStopwatch()
}
方案 A 可能就是沿用目前結構，在既有流程加入新的處理。
如果模式真的開始變多，另一個方案可能會把不同計時行為抽開：
interface TimerBehavior {
fun start()
fun stop()
}
class PomodoroBehavior : TimerBehavior
class StopwatchBehavior : TimerBehavior
我不需要 AI 在分析階段就把兩套完整 Code 都寫出來，只要用最小的程式碼讓我看得出：
選 A 之後 Code 大概會往哪個方向長，選 B 又代表什麼。
然後再告訴我兩個方案的修改範圍、優缺點和未來調整成本。
這對我來說不只是讓 AI 幫忙選 Architecture，也是我理解 Project 和學習不同做法的一部分。
當然，如果今天只是改一個 String，就不要突然給我三種 Architecture。
只有真的存在實質 Trade-off 時才需要選項。
Day 4 和 Day 5 讓我覺得「先問」這件事很有用，所以這部分我還是想保留。
但我不希望每次需求都收到十幾二十題問卷。
目前我比較希望 AI 區分兩種問題。
第一種是：
必須確認
如果不確認就很可能直接做錯，例如 Pomodoro 正在計時時到底能不能開始 Stopwatch。
另一種是：
建議確認
不一定會阻止目前實作，但從我的描述、Existing Behavior 或未來調整來看，可能有我還沒想到的地方，例如 Stopwatch 是否也需要手動新增紀錄。
這樣 AI 還是可以幫我從 User Behavior、Existing Feature、Error、Edge Case、Lifecycle、Data、UI Feedback 等不同面向延伸，但不需要每次把所有面向硬問一遍。
真正重要的是：
不要只回答我寫出來的需求，也幫我注意我可能還沒想到的地方。
除了寫出來的 Code，我也希望這套 Workflow 可以影響 AI 怎麼跟我說明。
如果它發現 Pomodoro 和 Stopwatch 會互相影響，比起直接告訴我：
TimeManager是 shared singleton，兩個 Fragment observe 相同 LiveData。
我會更希望它先說：
Pomodoro 和 Stopwatch 其實共用同一個計時器，所以啟動其中一個可能會影響另一個。
再告訴我這件事在 Code 裡是由 TimeManager 負責。
也就是：
先讓人理解 Why，再告訴我 Code 怎麼做到。
就算不是 Android Engineer，至少也可以先理解「為什麼這裡有問題」，而不是一定要先看懂所有 Class 才知道 AI 在講什麼。
整理到這裡，我發現前幾天一直增加的 Workflow 還缺了一個東西。
原本大概是：
Requirement
↓
Read Existing Code
↓
Impact Analysis
↓
Compare Existing Behavior
↓
Clarify
↓
Implementation
↓
Build
↓
Runtime Verification
但現在我比較希望它變成：
Requirement
↓
判斷任務範圍與風險
↓
Read Minimum Context
↓
Context 夠了嗎？
├─ Yes → 不再擴大
└─ No → Expand Context
↓
Impact Analysis
↓
Compare Existing Behavior
↓
Clarify Unknowns
如果過程中發現真的存在不同的結構選擇，再多一個：
Architecture Trade-off
↓
2～3 個適合目前 Project 的方案
↓
簡短 Code Example
↓
差異 / 成本 / 彈性
↓
我選擇
↓
Implementation
最後才回到 Build 和 Runtime Verification。
這樣的 Workflow 不應該讓每一個 Task 都變成大型 Code Review，而是要能根據需求自己調整深度。
簡單的事情快速完成，複雜的事情才多看、多問、多比較。
寫到這裡，我反而覺得一直把規則加進 Prompt 好像不是最終解。
因為我的目標不是做出一段「超完整 Prompt」，每次開發前複製貼上。
我想要的是一套 Coding Agent 能遵守的工作方式：
看得夠多，但不要什麼都看。
能自己推論，但不替我決定產品需求。
遵照 Project 架構，但不要 Over-engineering。
考慮未來調整，但不要為不存在的未來提前設計。
有重要選擇時讓我看到方案和 Code 長什麼樣，再讓我決定。
多想一些我沒有想到的地方，但不要每次都變成二十題問卷。
這大概就是目前的 Coding Workflow v0.1。
不過現在它還只是一堆我整理出來的規則。
下一個問題也很自然：
我能不能不要每次重新貼這些 Prompt，而是讓 Coding Agent 本來就知道這套 Workflow？
也許，是時候把它真的做成一個 Skill 了。
下一集見 :)
iThome鐵人賽
看影片追技術