Day 09 把 API 說清楚以後，AI 要真正開始改程式，而改動結果範圍可能超過你的需求。你可能只想把一段摘要顯示得更清楚，AI 卻順手整理送出邏輯、改掉資料格式，或動到另一個它認為「應該一起一致」的頁面。

• 第三代同時有 12 項既有功能要拉皮，以及新增編審放流程兩大任務。
• 我用前後端分開發、Spec／Plan 寫清楚異動範圍，再用 Git diff 和頁面操作確認，來控制 AI 的改動。
• 專案成員管理的 057 是一個刻意切小的案例：只改一個 Vue 檔中的摘要顯示，既有 API 與 payload 保留。

同樣是改畫面，工作其實差很多

第三代的我，同時面對兩種完全不同的工作。

一邊是第二代留下的 12 項既有功能，要把畫面拉皮、換成新的介面。這些功能原本就有後端 API，這階段主要是調整前端呈現。

另一邊是新增編審放流程。資料怎麼存、單據怎麼建立、審核關卡怎麼往下走，前後端都要重新開發。

這篇先談第一種：既有功能的小範圍變更，怎麼讓 AI 有清楚的工作邊界。

057：我只想把「人數」改成「成員清單」

主案例是第三代 12 項既有功能拉皮中的一份 Spec，功能是專案成員管理。

原本使用者送出後，最後摘要只會顯示新增與移除的人數。這對系統來說或許夠，但送出的人還是得回頭想：剛才到底加了誰、移除了誰？

我要改的事情很小：新增成員不要只寫人數，改為列出成員清單；移除成員也一樣。如果清單是空的，就明確顯示 —。

原本
新增成員數：2 人
移除成員數：1 人

調整後
新增成員：成員 A、成員 B
移除成員：成員 C

這次只是讓既有資料，在送出後被呈現得更清楚。

實作前，我先把不該改的地方寫下來

057 的 Spec 先把範圍框出來：影響的是一個 Vue 頁面；要改的是送出後摘要的文字；原本送出的新增與移除成員資料必須維持不變。Plan 再往下收斂，只處理摘要組裝的兩個欄位和一個本地格式化 helper。

用這種方式告訴 AI：你的工作不是「改善這個功能」，而是「在這個頁面的這個位置，把這一段資訊換成另一種呈現方式」。

驗收條件也跟著這個限制走：多位成員要能完整列出；只有新增或只有移除時，空的一邊要清楚顯示；送出的內容則必須維持原本的結構。

Anthropic 在 Claude Code: Best practices for agentic coding 裡建議，交給 agent 的工作應具體指出既有程式模式、相關檔案與限制。這和我的經驗很接近。給 AI 一個模糊方向，它會努力幫你補完；把要改和不該改的範圍列出來，它才知道該停在哪裡。

AI 說做完後，我先看 Git diff，再看頁面

我目前沒有一個「AI 把小改動做成大事故」的故事可以分享。原因很樸素：我每次都把改動切小。到目前為止，我已經累積超過 100 份 Spec；這不是要證明數量有多厲害，而是它已經變成我控制改動的方式。

LLM 完成後，我先看 Git diff。以 057 來說，我預期它只動到專案成員管理那一個 Vue 檔；如果出現其他檔案，我不會先假設它的「順手優化」是對的，而是回頭確認那是不是這次範圍的一部分。

接著我會實際操作頁面。多位成員時，摘要是否完整列出？只有新增或只有移除時，空的一邊是否明確顯示？送出後流程是否還照原本方式走？這些才是我判斷它有沒有符合需求的地方。

回頭看 057 留下的 Task 紀錄，頁面實作、build 和 Scenario 都被勾選，資安審查沒有被勾選；Spec 的狀態也仍顯示進行中。這件事要說清楚：057 很適合用來說明一個工作如何限縮範圍，卻不能被我寫成所有驗證都完整留痕的成功案例。

diff 確認改了哪裡；頁面操作確認改完後看起來是否符合需求。兩件事要一起做。

今天可以做的：先做一張 Change Boundary

今天不用把一個大功能拆到只剩一個檔案。選一個真正想調整的既有頁面，例如按鈕文字、摘要資訊，或一個不改資料模型的操作流程。

在叫 Claude Code 改之前，先把這次工作寫成一張 Change Boundary：

# Change Boundary｜功能名稱

## 這次要改
- 頁面／主要檔案：
- 使用者看得到的變化：
- 完成條件：

## 這次不改
- API／payload：
- 其他頁面：
- 不可改的既有行為：

## 實作後怎麼確認
- diff 預期只出現：
- 要操作的頁面情境：
- 若看到其他檔案被改到，要先停下來確認：

接著先請 Claude Code 提出方案，不要讓它立刻改程式：

請讀取這次的 Spec、Plan、Scenario 與指定頁面。
先提出最小修改方案，列出預計修改的檔案與不會修改的 API／payload／其他頁面。
資訊不足時列出問題；暫時不要修改程式碼。

我想讓讀者練習的不是把 prompt 寫得很長，而是先看 AI 打算動哪些地方。它列出的檔案只要超出你的預期，就先停在 Plan，不要急著讓它進入實作。

小結：範圍小，工作才真的能被確認

057 的改動很小，但它不是一句「把人數改成清單」就結束。需求先收斂為摘要顯示；Spec 和 Plan 排除 API、payload 與其他頁面；前後端分層讓這個界線有地方可以落下來；最後我看 diff，也實際操作頁面。

這不是萬用公式。新增一條流程，尤其牽涉資料與前後端時，不能假裝它只是一次 UI 拉皮。不過在既有功能的局部調整裡，把範圍縮到人能清楚 review 的程度，會讓 AI 的工作更容易被確認。

下一篇要再往前一步：我看過頁面後覺得「大致對了」，但怎麼把這種感覺寫成每次都可以重做的驗收條件？Day 11 會從 Scenario 開始。

參考資料

• Anthropic. Claude Code: Best practices for agentic coding.
• Anthropic. Effective context engineering for AI agents.