前言

當系統上線之後就不會再變動了嗎？

不，你錯了。

系統上線之後反而更會變動，畢竟會需要依照使用者的需求、市場的變化、競爭對手的動作，甚至是法規的改變來做調整。

那在 Vibe Coding 的世界裡，上線之後要加新功能該怎麼做呢？

這一篇就來聊聊該怎麼做比較好。

先改規格再動手

假設你還有一點印象的話，Day 10 我們其實做過一次範圍控制的練習，我們刻意設計了一句要加預算提醒跟記錄收入，結果 AI 拿出 SPEC.md 裡面的不做清單把我們這個需求給擋了下來。

那......假設現在系統上線了，你又想加這個功能，該怎麼辦呢？其實很簡單，當我們要開始做需求擴充時，請一樣保持一個大原則：

規則文件先更新，再動手。

千萬千萬不要先改程式碼，這種習慣非常不好，很容易變成文件跟不上程式碼，接著就無法對照功能，接著往後的更新都像疊床架屋一樣。

所以我們現在該怎麼做呢？其實很簡單，請你先進入 Claude Code 之後，輸入 /clear 清空對話（確保 Context 乾淨），接著輸入以下 Prompt：

請你閱讀 @SPEC.md 之後，裡面有一個「### 不做（v1 明確排除）」的清單，我要請你把「預算與超支提醒」從不做清單裡移出來。
因為我現在要來製作「預算與超支提醒」這個功能，所以移出後，你要切換成「產品顧問」的身分。
針對我這個功能進行需求訪談一次問我一個問題，把需求釐清。
問到你覺得足夠具體之後，跟我說可以整理成 SPEC.md，並請我確認。

這時候你應該會好奇，這邊我們該不該切換成 Plan Mode 模式呢？

來，我們複習一下：

• Plan Mode： 是以規劃完畢就開工為導向，它會產出一份實作計畫（要動哪些檔案、步驟怎麼走），然後問你要不要照著做，雖然遇到模糊的地方也會反問你，但問的目的都是「為了把計畫定下來並開始實作」所需要的事。
• 訪談式 Prompt： 是以 釐清需求 為導向，它不以動工為目標，所以主要是產出一份需求規格書，先搞清楚 what（要做什麼） 就好，至於 how（怎麼做） 那是之後 Plan Mode 的事，而且這個提問的節奏是在你手上的，畢竟你規定它一次一題慢慢挖，而不是讓它自己決定問夠了沒。

再更簡化一點理解就是：

• 訪談問的是 what（要做什麼）
• Plan Mode 問的是 how（怎麼做）

所以我們目前連預算長怎麼樣、超支提醒要怎麼顯示都還沒釐清，這時候就不適合開 Plan Mode，因為 Plan Mode 只會急著幫你排實作步驟，可是需求根本還沒對齊，所以這邊只需要切換到 manual mode on 模式即可，接下來你就接受一個一個拷問吧。

以我自己來講，我大約被拷問了至少 8 個問題左右（每個人不同）。

用 Plan Mode 把功能做出來

接下來呢？其實就相對單純了，跟前面都差不多，你只需要切換到 Plan Mode 模式，然後輸入以下 Prompt 就可以了：

請依照更新後的 @SPEC.md 去製作預算提醒功能。

計畫沒問題讓 AI 下去做，做完之後一樣要做一些驗收，你可以設計一些邊界來做驗收，像是：

1. 本月總額先刻意弄到 1000，預算改成 1000，然後這時候預期是不能提醒。
2. 再新增 1 元，要顯示超出 1 元。
3. 重新整理，預算跟提醒都還在。
4. 把預算清成 0，提醒消失。

Note
這邊你可以把上面的邊界問題丟給 AI 讓 AI 使用 Claude in Chrome 套件自己操控畫面去測試。

接下來就簡單很多了，只要請 AI 進行 push 上線就好，因為 Day 25 我們已經設定好 GitHub Actions 自動部署了。

結語

這一篇相對單純很多，畢竟很多地方在前面章節都有說明過，所以這一章節比較面向複習，讓你知道未來上線之後要加新功能該怎麼做。

所以這邊也替你總結一下：

• 上線之後要加新功能，先改規格再動手，千萬不要先改程式碼。
• 釐清需求用訪談式 Prompt 問 what，需求對齊了才進 Plan Mode 問 how，兩個不要搞混。
• 小功能的訪談跟計畫都可以很小，但驗收條件不能省，動工前可以先想好幾個邊界情況。

那這一篇就簡單到這邊結束，我們明天見囉～