前言

昨天我們終於完成第一個功能了！也就是「新增一筆帳」。

但...難道這樣就完了嗎？不，我們接下來要來做功能迭代，讓 AI 可以幫我們把其他剩餘功能給他完成。

雖然你可以一句話搞定：「請你閱讀 @SPEC.md 把剩餘功能開發完畢。」

但實際上這並不是非常推薦，因為這樣很容易讓你不知道它改了什麼，當出現問題時，你也很難去追蹤跟除錯，進而導致你花更多心力在找問題上，而不是專注在功能的開發上。

所以今天的重點並不是功能上，而是將這些開發的過程拆成三輪，並且每一輪都要有明確的 Prompt 去引導 AI 可以清楚知道該怎麼開發才符合你的需求。

好 Prompt 三大要點

基本上我個人認為一個好的功能開發在 Prompt 上會有三大要素：

1. 現況： 清楚描述畫面上現在有什麼、這次要動的是什麼。
2. 要什麼： 這次的開發目標是什麼，具體的欄位與行為是什麼。
3. 驗收標準： 這次開發怎樣才算怎樣算做好？

一開始可能會稍微有點難理解為什麼這三大要素會是好的功能開發，其實這三大要點都在避免一個狀況，也就是...

避免 AI 腦補太多，導致你跟它的想法落差太大。

儘管現在 AI 很聰明，但有時候也很容易「聰明反被聰明誤」，所以你必須要把你想要的東西描述清楚，這樣 AI 才能夠幫你做出符合你需求的功能。

除此之外，這邊我也想特別補充說明一下，也就是關於 「現況」 的部分。

現況的意思是，請你基於你目前所看的到的東西、狀況去描述就好，像是...

• 畫面哪邊怪怪的。
• 哪一顆按鈕點下去沒有反應。

你完全不需要去查程式碼放在哪個資料夾、檔名又是什麼，這完全不符合 Vibe Coding 的精神，因為你要做的事情是引導 AI 去做你想要的功能。

畢竟對於 AI 來講，專案就在它眼前，它自己會去讀，你講不出檔名它也找得到；反過來說，真正的問題點是

你腦中想要的畫面它是看不到的，這才是你該花力氣描述的部分。

了解以上之後，我們就來試著體驗看看這三大要素的實際應用吧～

第一輪開發：分類佔比

首先，你必須養成一個良好的習慣，只要開始一個 「新的功能開發」 時，你就要輸入 /clear，讓你有一個乾淨的桌面，避免前面的討論、開發過程，影響你這一次的功能開發，而這個影響就是我們所謂的 「雜訊」。

把這個桌面清理乾淨之後，我們就來準備做第一輪的功能開發。

昨天做完「新增一筆支出」之後，首頁已經有本月總額跟記帳明細了，所以你知道這個月花了多少：

但是一個記帳 App 怎麼可能這麼單純呢？空有本月總額跟記帳明細還是很難看出錢到底花去哪了，所以接下來我們要接著製作「分類佔比」的功能，讓使用者可以清楚知道錢花在哪一類。

所以接下來我們要把 SPEC.md 的「分類佔比」給做出來，這邊你可以參考以下我的 Prompt 寫法（丟給 AI 之前別忘了打開 Plan Mode）：

首頁目前有本月總額跟本月的記帳明細了，但是我看不出來錢是花在哪一分類比較多。

所以我要請你閱讀 SPEC.md 的第 5.1 節的「分類佔比」，並且幫我把它做出來，位置你可以參考 SPEC.md 上方的示意圖（位置放在總額下面、明細上面）。

底下是驗收的標準：

1. 這個月記飲食 120、飲食 80、交通 100，畫面上要是兩條橫條，飲食 $200 在上、交通 $100 在下，飲食那條比較長
2. 這個月沒花到的分類不要出現，不要列一排 0
3. 百分比四捨五入到整數就好，三個分類各記 100 的時候顯示 33%、33%、33%，加起來 99% 是正常的，不用硬湊成 100%
4. 上個月的資料不列入計算

那麼上面的 Prompt 其實正在跟你傳達三大要素：

1. 現況：首頁有本月總額跟記帳明細，但看不出我錢花在哪一類比較多。
2. 要什麼：請 AI 在總額下面加一排分類佔比橫條。
3. 驗收標準：四個驗收條件。

你會發現我根本沒有講到「請你幫我改某某檔案、某某元件」，因為這些東西我們要讓 AI 自己去找，重點是你要告訴它你想要的畫面長什麼樣子，只要有不確定的（如樣式） AI 一樣會問你：

雖然 Plan Mode 的計畫書很長，但其實你也不用逐字精讀，只要抓三個地方就好：

• 它要動哪些檔案？
• 不做的事？
• 驗收標準是什麼？

其他的部分呢？大概掃過去有個印象就可以了。

如果你看一看沒有問題的話，你可以直接按下 「Yes, and use auto mode」 了，讓它開始開工啦～

這邊你會發現它放行之後沒有馬上改程式，而是先產出一個 docs/plans/02-分類佔比.md，這是昨天我們寫進 CLAUDE.md 的那條規則在生效，所以從今天開始你都不用再交代這件事情了。

最後我們就可以看到它幫我們把分類佔比的功能給做出來啦～

第二輪開發：修改與刪除（含一個刻意保留的 bug）

前面我們完成了一個分類佔比的開發，接著要來進行第二輪的開發，也就是針對帳目的修改與刪除，畢竟有時候我們是會記錯帳、打錯金額的，所以這個功能是非常重要的。

到這邊為止，你應該很清楚知道要進入下一輪開發之前要幹嘛了，也就是先輸入 /clear，讓你有一個乾淨的桌面。

接下來切換到 Plan Mode 之後，你可以試著參考我以下的 Prompt 來進行第二輪的開發：

首頁的列表清單目前點下去沒有任何反應，所以請你閱讀 SPEC.md 中的 第 5.1 節的「流水清單」跟第 5.3 節的「刪除」。

只要使用者點擊列表上的任何一筆資料就會打開編輯表單，表單會出現四個欄位，這些欄位帶入那筆原本的資料，使用者編輯完畢後，按下儲存就會關閉表單，除此之外編輯表單也要多一個「刪除」按鈕，按下去會跳出確認提示，使用者確認後就刪掉該筆資料並關閉表單。

這邊也要請你注意一下，我要請你刻意製造一個可控除錯練習，所以你要刻意用「這是畫面列表上的第幾筆」當作編輯與刪除的識別，不要用每一筆資料的 id，並且在相關程式旁邊加上註解「TODO 後面練習用：改成用 id」，請你先不要修成 id。

驗收標準：連續記三筆同一天的支出，點中間那一筆會打開編輯表單、點刪除會跳出確認是否刪除，刪除成功後表單會關閉，首頁列表清單只會少中間那一筆，如果是按下取消，那就什麼都不會變。

這過程應該你會遇到詢問你彈跳視窗的部分：

這邊一樣你可以選擇「推薦」就好，除非你有其他想法。

然後這邊要特別說明一件事情，正常來講使用 index 去刪除並不是一個好的方式，這是我刻意設計出來的一個已知錯誤，正確來講必須使用 id（唯一值）去處理，但 AI 本身也會去修正這個問題，所以才要特別跟它講請它刻意犯錯。

那...如果你無法理解 index 與 id 彼此之間的差異的話，舉例來講...班上有 30 個學生，然後你每次都用「第幾個學生」去做點名，那如果他們偷偷換座位的話，你就很難點到正確的學生，所以你也可以把 id 想成是學生的學號/姓名，這樣就算他們換座位你也可以正確點到人。

理解這個概念之後，接著你應該會取得這一份 Plan Mode 的 計劃書，那麼一樣看一看沒問題的話，就可以按下「Yes, and use auto mode」讓 AI 幫你做。

為什麼要這樣設計情境呢？我想你應該會有這個疑問，其實就是想讓你體驗到一件事情：

驗收會過，不代表沒 Bug，只是剛好你沒有測到那個情境而已。

你等 AI 開發完畢之後，請接著跟 AI 說：

請幫我 commit 當前進度，名稱為：「練習： 修改與刪除，暫留 index bug」

這樣未來要請 AI 或者讓你自己尋找 Bug 的時候，你就會知道這個版本是有 Bug 的。

你可能有注意到這個訊息不符合 CLAUDE.md 定的「功能名稱：簡短描述」格式，這是刻意的：用「練習：」開頭，之後在 git 歷史裡一眼就能認出這顆是教學用的地雷版本，不會跟正常的功能 commit 混在一起。

第三輪開發：月份切換

接下來第三輪開發其實跟前面差不多，先 /clear，然後切換到 Plan Mode，接著你可以參考我以下的 Prompt 來進行第三輪的開發：

首頁最上面現在固定顯示本月，沒辦法看到其他月份的資料。

請你閱讀 SPEC.md 第 5.1 節的「月份切換」，在年月那一行的左右各加一個箭頭可以切換上／下個月，另外再加一顆「本月」按鈕可以一次跳回來。

驗收標準：連按左箭頭切到三個月前，總額、分類佔比、清單都要跟著換成那個月的資料；這時候點一次「本月」就會直接回到當前月份，而且回來之後「本月」按鈕會消失，可是左右箭頭的位置不會因此位移。

過程其實跟前兩輪差不多，我就不贅述了。

跑完月份切換功能之後，這三輪的開發你應該會有一個很深刻的體驗，也就是「一次做一個功能」的好處。

flowchart LR
    A["/clear 開新對話"] --> B["切換到 Plan Mode 模式"]
    B --> C["prompt 三要素<br>現況、要什麼、驗收標準"]
    C --> D["讀計畫，沒問題才放行"]
    D --> E["AI Agent 開發功能"]
    E --> F{"依照驗收標準進行驗收"}
    F -->|"通過"| G["進行 commit 存檔"]
    F -->|"不通過"| H["說明落差/問題，請 AI 修正"]
    H --> E
    G --> A

為什麼每次都要輸入 /clear？

經過這三次的功能開發迭代，我都有特別強調要先使用 /clear。

這邊這個行為其實就跟 Day 6 講的 Context Window（一張有極限的桌子）概念有關係，前面 AI Agent 所開發的內容（Context）是會污染接下來的開發內容的，所以通常我們每次進行每一輪新的需求開發時，都會做一次 /clear，確保前一輪的需求開發不會影響到當前這一輪的需求開發。

那我們的專案共識會被清除嗎？當然是不會。

當你呼叫 /clear 的時候，雖然 AI 會把它的桌面清理乾淨，但也會重新把 CLAUDE.md 給放進來，接著當你開始進行新的一輪開發時，就會基於 CLAUDE.md 的內容去進行開發（同時也會掛入 SPEC.md），這樣就不會有前一輪的開發內容影響到當前這一輪的開發。

所以可以完完全全安心的使用 /clear，不會有任何的問題。

Note
注意一下，這邊一直在強調的「一次做一個功能」並不是代表功能要切到跟小黃瓜一樣碎掉。
而是切的顆粒要抓在「一次做完、一眼驗收得完」就好，分類佔比是一輪、修改刪除是一輪，可是「刪除按鈕的顏色」就不用自成一輪，跟著那一輪順便做掉就好。

那麼到這邊為止，如果你是完全跟著內容去做的話，你的 git 歷史裡應該會有一顆「練習： 修改與刪除，暫留 index bug」的 commit，這就是全系列唯一一顆會活過一個晚上的地雷，明天我們就會把它引爆、然後修掉。

結語

終於到 Day 11 了，這邊我們跑了三輪的功能開發，而這些功能開發都是同一套手法：

1. /clear 清乾淨桌面（開始新的對話），切換到 Plan Mode，接著基於 Prompt 三要素（現況、要什麼、驗收標準）去描述需求，讀完計畫才放行，做完照標準驗收，過了就 commit。
2. 每一輪需求的開始都開 Plan Mode，計畫可能會比較長，但是隨著專案地基越打越穩之後，需要看的內容也就會隨之變少。
3. 不要怕 /clear 清掉重要資訊，每次清除都會重新把 CLAUDE.md 放進來，真正該留下來的共識，我們也早就寫進 SPEC.md 跟 CLAUDE.md 裡了。

基本上我們已經把 SPEC.md 第 3 節「做」清單上的六件事都做完了，這個記帳 App 已經能夠做到「新增、修改、刪除、切月份查看」，並且資料也會保存下來。

但這個專案裡還埋著我們預留的那顆地雷，明天就來直播一場完整的修 Bug 流程，記得先忍住不要偷修唷。