前幾天一路測下來，我慢慢整理出一套自己希望 AI 寫 Code 時遵守的 Workflow。

從一開始直接叫 AI 實作，到後來要求它先做 Impact Analysis、比較 Existing Behavior、遇到無法從 Code 確認的需求先問我，Day 6 我又多想了一件事：

如果每個需求都做完整分析，AI 可能只是看得更多、花更多 Token，但不一定真的比較好。

所以我希望它可以根據 Task 自己調整分析深度。

小需求就只看必要的 Code，真的發現 Dependency、Shared Logic、Existing Behavior 或 Side Effect，再往外擴大。

今天我決定把這些規則第一次整理成 Codex Skill。

從 Prompt 變成 Skill

我建立了一個 adaptive-android-development Skill，核心概念其實很簡單：

Task
 ↓
Minimum Context
 ↓
目前資訊夠嗎？
├─ Yes → 停止擴張，完成最小修改
└─ No  → Expand Context
          ↓
        Impact / Existing Behavior
          ↓
        必要時再詢問需求

另外也加了一些前幾天實驗累積下來的規則：

• 優先沿用 Existing Architecture
• 不要為小需求做過度抽象
• Code 能確認的事情不要全部反問我
• 真的有 Architecture Trade-off 時，才提供 2～3 個方案
• 修改 Feature 時注意 Existing Behavior、Business Rule、UI Feedback、Data 與重要 Edge Case

但其中我最想測的不是「AI 有沒有記住更多規則」。

而是：

它能不能自己判斷這次到底需要想多少？

Test 1：一個真的很小的修改

第一個需求我故意選得非常簡單：

請把番茄鐘設定 Dialog 的確定按鈕文字改為「確認」，並且寫入 strings.xml

這次 Codex 一開始就說：

我會依 adaptive Android workflow，只檢查這個 Dialog 與相應字串資源，採最小變更。

接著找到 PomodoroFragment 與 Dialog，確認目前的字串使用方式後，只修改了 Layout 與 strings.xml。

沒有去讀 ViewModel、Repository、TimeManager，也沒有突然提供三種 Architecture。

這其實就是我想看到的結果。

以前我一直希望 AI 「多想一點」，但這次反而是：

它知道不用想那麼多。

第一個 Test 看起來成功。

Test 2：如果需求本身是一條 Business Rule 呢？

第二個需求我刻意換成：

請把正計時結束時「少於 5 分鐘不建立紀錄」的規則改成「少於 3 分鐘不建立紀錄」

這個需求表面上也不大。

AI 很快找到 StopWatchFragment 裡的 MINIMUM_RECORD_MILLIS，同步修改門檻與提示文字，Build 也成功。

但這次我發現問題了。

因為 Project 裡的 Pomodoro 本來也存在：

少於 5 分鐘不建立紀錄

也就是說，這不只是一個單純的數字。

它其實是一條與 Existing Feature 相似的 Business Rule。

我原本期待 Skill 的流程是：

找到 Stopwatch 的 5 分鐘規則
 ↓
發現這是 Business Rule
 ↓
搜尋 Similar Existing Behavior
 ↓
發現 Pomodoro 也是 5 分鐘
 ↓
修改後兩邊會不一致
 ↓
這個差異是刻意的嗎？
 ↓
Code 無法回答 → 問我

但實際上 AI 做的是：

找到 Stopwatch
 ↓
找到 5 分鐘
 ↓
改成 3 分鐘
 ↓
Build Success

它完成了需求，卻沒有真的往外找。

Minimum Context 太成功，也可能變成另一個問題

這時我才發現，我在 Skill 裡一直強調：

Start with minimum context.

以及：

Stop expanding when there is enough evidence to safely understand and implement the requested change.

對 AI 來說，找到 StopWatchFragment 裡的門檻之後，其實已經「足夠完成需求」。

所以它停下來了。

問題不是它沒有遵守 Skill。

某種程度上，它可能正是在遵守 Skill。

只是我真正想要的不是：

永遠少看 Code。

而是：

知道什麼時候少看就夠了，什麼時候應該再多看一點。

Skill v0.2：把 Business Rule 當成 Expand Signal

所以我又調整了一版 Skill。

加入：

When changing an existing business rule,
briefly search for the same rule, threshold,
validation, or user-facing behavior in similar
or adjacent features.

意思是，如果只是改一個 Dialog 文案，不需要因此掃其他 Feature。

但如果改的是：

5 分鐘 → 3 分鐘

這種 Threshold / Business Rule，就應該稍微搜尋 Project 裡有沒有相同或相似規則，即使它們沒有共用同一份實作。

另外我也補了一條：

如果修改後會讓原本一致的 Similar Feature 出現不同 Business Rule，不要直接假設這個差異就是需求本意。

理想情況下，AI 應該告訴我：

Stopwatch = 1 min
Pomodoro = 5 min

原本兩者都是 5 min

然後問：

這次只修改 Stopwatch，還是兩邊應該一起調整？

而不是自己決定。

結果呢？

我重新測了一次。

它還是只處理了 StopWatchFragment。

甚至這次它發現「提示文字已經是 1 分鐘，但實際門檻還是 3 分鐘」，於是把兩者修正一致，最後 Build Success。

這件事情本身做得沒錯。

但我真正想測的：

會不會主動找到 Pomodoro 的相似 Business Rule？

還是沒有發生。

所以今天的 Skill v0.2，還不能算成功。

Skill 不是把 Prompt 存成檔案就結束了

我原本以為，把 Day 3～Day 6 累積的 Workflow 整理成 SKILL.md，接下來就是看看 AI 有沒有照著做。

實際開始測才發現事情沒有這麼簡單。

規則寫得太少，AI 不知道什麼時候該深入。

規則寫得太多，又可能讓每個小需求都變成大型分析。

分析太少
←──────────────→
分析太多

        ↑
   我想找的位置

而且「請比較 Existing Behavior」這種對人來說很自然的句子，對 Agent 而言還有很多細節：

什麼情況才算值得比較？

要搜尋多大的範圍？

找到相似規則後要直接一起改，還是先問？

什麼程度的不一致才值得打斷 Implementation？

這些其實都還需要繼續調整。

今天反而驗證了一件更重要的事

第一個 Test 告訴我：

Minimum Context 的方向是有作用的。

第二個 Test 則告訴我：

When to Expand Context 還不夠。

所以目前這個 Skill 比較像：

adaptive-android-development v0.2

✓ 小需求不要看太多
✓ 優先做 Minimum Change
△ Business Rule 主動比較
△ 什麼時候 Expand Context
△ 什麼時候應該停下來問我

至少它讓我第一次開始把「我希望 AI 怎麼寫 Code」從一串 Prompt，變成一個可以重複測試、修改，再 Regression Test 的 Workflow。

而今天最大的收穫反而不是 Skill 寫好了。

而是：

「少看一點」不是目標，「知道什麼時候該多看一點」才是。

明天再繼續看看，要怎麼讓這個 Skill 不只是會控制 Context，而是真的能判斷什麼時候值得往外找。