前言

SPEC.md、CLAUDE.md、專案環境以上都完成差不多了，接下終於要準備正式進入開發啦！

那我們第一個要開發的功能就是「記一筆帳」，這個功能是整個專案的第一個功能，所以我們會先以這個功能為主，來示範如何使用 Plan Mode 來進行開發。

把 SPEC 的一條功能變成 prompt

首先，我們先來看一下 SPEC.md 中的「範圍」區塊：

## 3. 範圍

### 做

- 新增一筆支出
- 編輯已記錄的支出
- 刪除已記錄的支出
- 切換月份，看該月的總支出與分類佔比
- 一鍵回到本月
- 看該月的流水清單

這邊是我們「必須製作」的功能清單，但在開始之前需要請你務必確認 AI 的模式已經是「plan mode on」（還記得嗎？只需要按下 Shift+Tab 即可切換），這樣才能夠讓它進入規劃模式

確認進入 Plan Mode 後，我們就可以開始進行功能開發的第一步了，也就是把 SPEC.md 的功能清單轉換成 prompt，但這邊要注意，我們這一篇並不會一次性全部功能都叫 AI 做完，而是先以「做」清單的第一項「新增一筆支出」為主，因為它是整個專案的第一個功能，所以我們會先以這個功能為主，來示範如何使用 Plan Mode 來進行開發。

如果沒有問題的話，那麼你可以試著在 Claude Code 中輸入以下 prompt：

請你依照 SPEC.md「做」清單的第一項「新增一筆支出」，幫我寫一個開發計畫，並列出這次會做與不會做的事，並且附上驗收標準。

沒錯，就單純這樣子而已。

「欄位、分類這些記帳必備的東西不用講嗎？」

我知道你可能會這樣好奇，但其實完全不用，畢竟在前面討論 SPEC.md 的時候就已經規劃進去了。
你不相信嗎？你看，SPEC.md 第 5 節的這些欄位的規則早就寫好了啦～

**欄位規則**

| 欄位 | 必填 | 預設 | 規則 |
|---|---|---|---|
| 金額 | 是 | 空 | 正整數，須 > 0 |
| 分類 | 是 | 無 | 六選一，用按鈕不用下拉選單 |
| 日期 | 是 | 今天 | 原生 `<input type="date">` |
| 備註 | 否 | 空 | 單行文字，上限 50 字 |

這就是為什麼我不需要再跟 AI 說......

• 欄位是什麼
• 分類是什麼

因為這些我們在前面就已經花了時間討論過了，SPEC.md 裡面已經有完整的規格了。

如果你還在這一次的 Prompt 打一次相關的內容，那就會發生兩個問題：

1. 重複寫同一件事，浪費時間
2. 兩邊哪天不一致的風險

所以前面一開始的打底就是如此的重要，這也是為什麼我們會花時間把 SPEC.md、CLAUDE.md、專案環境都先準備好，這樣在開發的時候就可以直接進入正題。

送出之後：它先反問，不急著給計畫

送出剛剛的那一段 Prompt 之後，它有可能不會馬上給出計畫書，而是像之前那樣先跳出選擇題，一題一題跟你確認。

以我來講，我的題目就是：

1.「新增一筆支出」要驗收，就得看得到新增的結果。這次的範圍要不要一併做出唯讀的流水清單與本月總額？
2. src/composables/useRecords.js 這次要寫到什麼程度？

通常遇到這些反問的時候，基本上就是要你停下來好好思考一下、翻一下 SPEC.md 並思考一下，因為這些問題都有可能是你當初沒有想到的部分，這個就是為什麼我們需要一直建立驗證流程的原因（當然過程有遇到看不懂的，也可以直接問它，這樣就可以避免你在開發的時候才發現問題），每一個選項都有可能增加一個功能的複雜度、難易度，甚至是工作量，更不用說你少寫的部分並沒有憑空消失，只是在另一個時間點被問出來，這就是 Plan Mode 的價值。

了解它想怎麼蓋房子

接下來你應該會看到 AI 給你一份開發計畫，我個人會非常建議你 好好閱讀 它（這一份計劃書等一下我們會把它存成檔案留下來，別急）

請不要看到「Yes, and use auto mode」就無腦按下去。

雖然計畫內容有點長，但我認為滿值得你花一點時間閱讀看一下，例如裡面寫著...

• 分類寫死在 src/constants/categories.js，當作唯一來源。
• src/composables/useRecords.js 是唯一碰 localStorage 的地方。

大概看這兩行你應該就心很累了，畢竟數量非常多，而且裡面有很多專業術語，自然會看的很痛苦是很正常的，但你也可以請它修改成「更容易理解的版本」，它會幫你把計畫內容拆成更容易理解的方式，例如...假設你今天是第一次看到 composable，你就可以在「Tell Claude what to change」裡面輸入：

composable 是什麼？為什麼要多一個 useRecords.js 檔案，localStorage 又是什麼？請用更容易理解的方式解釋給我聽。

接著你就會得到一個很詳細的白話文版本解釋：

看完解釋之後，你應該就可以理解它並不是隨便拆的，而是有考量到各種因素才決定這樣設計。

如果如果......你理解完了，也看完了，但就是沒想法的話，那你可以選擇「推薦」這個選項就好，因為畢竟「推薦」就是它認為最適合的做法，除非你可以提出更好的理由，否則就直接按下去就好。

到這邊為止，請先不要按下「Yes, and use auto mode」，因為我們還要做一個「可控失敗的練習」。

可控失敗練習：親手讓範圍膨脹，再踩煞車

接下來我們要來做一個「可控失敗的練習」，也就是刻意讓計畫膨脹，然後再踩煞車回來。

所以要請你在「Tell Claude what to change」裡面輸入：

回到剛剛的計畫模式，既然都要做表單了，順便加上預算超支提醒，還有記錄收入的功能。
請更新計畫，先不要執行。

送出後，請不要急著按下「Yes, and use auto mode」的按鈕，先體驗、先看一下計畫膨脹的部分，同時你應該會看到 AI 跟你講：

### 不做（v1 明確排除）

| 不做的事 | 原因 |
|---|---|
| 記錄收入 | 只回答「錢花去哪」，不做資產負債 |
| 帳戶 / 付款方式 | 一加就會延伸出「各帳戶餘額」，MVP 撐不住 |
| 預算與超支提醒 | 先讓人記得住帳，再談控制 |
| 跨月趨勢圖 | 沒有幾個月的資料前沒有意義 |
| 分類的新增 / 刪除 / 改名 | 內建固定幾組就夠，省掉一整個管理介面 |
| 帳號、雲端同步、多裝置 | 單人單機 |

很有趣吧？AI 竟然會阻擋我們提出這個需求，因為它知道這些功能不在這次的範圍內，而手癢想要擴充功能的我們，正好可以藉此練習「踩煞車」的動作，只要你不接受、不允許那麼就沒問題。

體驗過這個需求控制以及計畫膨脹之後，你可以按下 Esc 或者找到「Tell Claude what to change」的輸入框，輸入以下內容：

剛才只是範圍控制練習而已，預算提醒跟記錄收入都在 SPEC.md 第 3 節的不做清單，請全部拿掉。

回到原本的「新增一筆支出」，列出這次會做與不會做的事，再交一版計畫。

這樣它就會恢復原本的計劃書了，只是你應該會看到 AI 特別寫了一段話：

雖然這個小練習體驗很小，但意義非常大，因為有時候需求爆炸並不一定是 AI 造成的，反而是使用者臨時想到 （就跟老闆一樣），但這件事情好處就在於，事情還沒開始做之前就先踩煞車了。

放行、看它蓋

如果前面計畫看完沒問題，你就可以按下「Yes, and use auto mode」讓它開始執行計畫，這時候你就可以看到它開始在專案裡面新增檔案、修改檔案，直到完成（當然，如果你想每一步修改都親眼看過，選 manually approve 也完全可以，只是速度會慢一些）。

完成後 npm run dev 打開瀏覽器，畫面上應該有首頁、有「＋ 記一筆」的按鈕，記完一筆之後下面那份陽春清單也會出現資料。

把計畫留下來

先別急著驗收，這邊有一件很多人會漏掉的事情要先做，也就是...

剛剛那份計畫，你不留它就沒了。

因為計畫是在對話裡產生的，等你 /clear 之後，它就跟著桌面一起被清乾淨了，但這份東西後面其實很有用，例如...

• 出 Bug 的時候可以翻出來，對照它到底有沒有照計畫做。
• 過幾個月回頭看，可以知道當初為什麼要這樣拆檔案。

所以請你跟 AI 說：

請把剛剛那份計畫原文存成 docs/plans/01-新增一筆支出.md，內容不要重寫或摘要。

「內容不要重寫或摘要」這句話一定要加，不然它很容易好心幫你濃縮成三行，那就失去存檔的意義了（我的那一份放在 day10#docs/plans）。

存完之後你的專案就會多一個資料夾：

money-note/
└─ docs/
   └─ plans/
      └─ 01-新增一筆支出.md

那...難道每次都要自己講一次嗎？當然不用，這種會一直重複的慣例，就是 CLAUDE.md 的守備範圍，所以接著再丟一段 Prompt 給它：

請幫我加入以下開發規則到 CLAUDE.md 裡面，並且每次對話都要遵守這個規則：

- 每次 Plan Mode 的計畫放行之後，第一件事是把計畫原文存成 docs/plans/NN-功能名稱.md（NN 從 01 開始接續編號），存完再開始改程式
- 計畫檔要跟該功能的程式碼放在同一個 commit

這一招跟 Day 9 我們往 CLAUDE.md 塞開發規則是一模一樣的，而這件事情也剛好證明了一件事：

CLAUDE.md 不是寫完就固定不變的，而是發現有值得的慣例可以補一條進去。

之後每一輪的功能開發，它就會自己把計畫存好，你不用再交代第二次哩～

驗收功能

接下來就是驗收的部分，這時候你應該會想說...

「我還要自己花時間驗收？」

不，不對，其實你的 Plan Mode 計畫裡已經幫你列好驗收標準了，就是剛剛計畫裡那 13 條：前半段對應 SPEC.md 第 7 節的驗收條件，後半段是它自己補的邊界檢查，每一條都是打開瀏覽器就能親手確認的行為。

AI 做完之後會跟你說它自己驗過了，先別急著全信（為什麼？Day 12 你就會知道了），所以這邊我自己還是會親手打開來測試，特別是這幾條：

• 按「＋」→ 輸入金額 → 點分類 → 存檔，三個動作內記完一筆
• 剛剛那筆立刻出現在清單最上方，本月總支出也跟著增加
• 把日期改成上個月存進去，那筆不會出現在本月清單

Note
這邊的驗收標準是「行為」而不是「code」，所以你不需要去看它的 code 寫得對不對，重點是它做出來的東西符不符合驗收標準。

如果跑完全部都沒問題，AI 也會詢問你是否要 commit，畢竟我們的計畫裡「收尾」那一節就有提到：

上面 13 條全過之後，commit 一次。訊息格式照 CLAUDE.md：

新增支出：表單、資料層與流水清單

而這一條其實就是來自 CLAUDE.md 憲法規範：

**每完成一個功能、驗收通過後就 commit 一次。** 不要累積好幾個功能才一起提交 —— 一個 commit 對應一個可驗收的功能，出問題時才回得去。

結語

那時間也差不多了，恭喜你完成了第一個功能開發。

其實你應該也體驗到儘管 Vibe Coding 是一個 AI 開發模式，但它並不是完全自動化的，還是需要你去思考、去判斷、去驗收，這樣才能確保開發出來的功能符合你的需求。

所以這邊我也條列一下整個過程的節奏，讓你在之後開發其他功能時可以參考：

1. Prompt 只要指到 SPEC.md 的哪一條功能就好，然後請它列出這次會做與不會做的事，並且附上驗收標準，不要反覆給它新的規則避免與 SPEC.md 衝突
2. 如果它有反問你問題，請你停下來想一下，也可以回去翻一下 SPEC.md，畢竟每一個選項都會影響到後面的工作量
3. 計畫裡面有看不懂的地方就直接問，問到懂為止
4. 拿到計畫之後好好讀過一遍，特別是資料結構的部分
5. 如果發現範圍變大了，不管是 AI 提的還是你自己臨時想加的，就直接打回去重新規劃
6. 計畫存成 docs/plans/NN-功能名稱.md 留著，這條慣例也寫進 CLAUDE.md，之後不用再交代
7. 驗收的時候看的是行為而不是 code，全部跑過沒問題之後再 commit

透過上面七個步驟，你其實就正在慢慢建立一套 Vibe Coding 的開發流程了。

那麼時間也差不多了，恭喜你的專案有了第一個 commit，希望這一篇有讓你順利完成第一個功能哩～