前言

哇！我們 Week 2 告一個段落了～

回頭看一下 Day 8 那天我們手上只有一份 SPEC.md，今天手上已經是一個能記帳、能改能刪、能看統計、關掉重開資料還在的 App 了，一週就做出一個簡單堪用的東西滿有趣的吧？

所以今天我們要來做一點收尾，也就是拿 SPEC.md 做總驗收、回顧一週的狀況，然後回答一個最多人有的疑問：

這堆不是我寫的 code，我到底還要不要看？

MVP 總驗收

前面我們 Day 8 將想法轉換成了規格（SPEC.md），規劃時，同時也建立了驗收條件，你可以試著打開 SPEC.md 然後找到第 7 節就可以看到了：

## 7. 驗收條件

v1 完成的定義：

1. 手機開啟，按右下角按鈕 → 輸入 120 → 點「飲食」→ 存檔，三個動作內記完一筆
2. 新記的那筆立刻出現在清單最上方，本月總額同步增加
3. 圓餅圖的扇形大小與明細的百分比正確反映該月各分類金額
4. 點清單任一列可以修改金額／分類／日期／備註，存檔後清單與統計同步更新
5. 刪除會先跳確認，確認後該筆從清單與統計中消失
6. 重新整理頁面，所有資料還在
7. 切到沒有記錄的月份，顯示空狀態而不是壞掉的圖表
8. 把某筆的日期改成上個月，該筆會從本月消失、出現在上個月
9. 連按 `◀` 切到數個月前，點一次「本月」即回到當前月份；此時「本月」按鈕消失，
   且月份切換列的左右箭頭位置不位移
10. **新增一筆支出後切到統計頁，總支出、記帳筆數與圓餅圖都反映最新資料**
11. 在統計頁切換月份，三個數字與圓餅圖同步換成該月；切分頁不會把月份重置回本月

你可能會認為感覺我們畫面不怎麼樣、功能也沒什麼特色諸如此類的，但實際上我們這邊是驗收「核心 MVP」的功能。

什麼是「核心 MVP」呢？其實就是一個記帳軟體最基本最基本的功能

• 新增、修改、刪除支出
• 切換月份、統計各分類佔比
• 資料保存（關掉重開資料還在）

這些都是一個記帳軟體最基本的功能，沒有這些就不能算是「能用的記帳軟體」，所以這邊把它定義為「核心 MVP」。

但這個核心 MVP 並不代表旅程到此為止，而是我們後面要搭配一些東西，如視覺規範等，讓整體看起來更像一個產品，這些會在後面兩週補齊。

看看你的一週軌跡：git log 就是你的進度條

你可以在終端機輸入以下：

git log --oneline

Note
這邊截圖只是示範而已，並不是你專案的實際輸出，請自己在專案裡跑 git log --oneline 看看。

當然，你也可以直接叫 AI 幫你跑。

透過 Git，你可以看到你整個 Vibe Coding 的軌跡，當專案越來越大後，這些軌跡會越來越有價值（當初出事時，你可以回到某個 commit 重新開始，或是把某個 commit 的程式碼拿出來當作範例），所以每次 commit 都要寫清楚訊息，這樣才有意義。

大哉問：AI 寫的 code 要不要看？

我想差不多該來回答「AI 寫的 code 要不要看」這個問題了，畢竟經歷了前面那幾天之後，其實應該滿多人都會對這件事情充滿疑惑。

我直接講一個結論：

要看，但這個「看」不是逐行逐字看。

畢竟你可能連 computed、console.log 或 ref 等這些語法都不知道，硬要你一行一行閱讀根本就是折磨、拷刑一樣，可是如果跟你說，你可以完全不看這樣也不對，這樣就跟開一台沒有儀表板的汽車一樣，現在油箱多少、時速多少通通都不知道，接著遇到警察時，警察把你攔下來問：「你剛剛開多少你知不知道？」你會連這種基本問題都回答不出來。

所以這邊所謂的 「看」 是至少你可以用白話講出這段程式碼在幹嘛，像是...

• 資料存在哪裡
• 格式長怎樣
• 從使用者按下「記一筆」到畫面更新，中間經過哪些檔案

這些你都是可以理解的，但不是要你把程式碼每個細節、每個字的實作細節全部看懂。

那...所以有哪些要講得出來、哪些可以放過呢？

這邊我用兩個問題來區分：

1. 這段程式碼（功能）錯了痛不痛？
2. 你看不看得懂？

剛好這兩個問題可以形成一個四象限：

剛開始 Vibe Coding 的人，手上的程式碼大多都是在右邊那兩格（看不懂那一格），因此：

• 錯了會痛的叫它解釋給你聽，直到你能理解為止。
• 錯了不痛先放生，反正後面在請 AI 協助調整。

因此隨著時間迭代，你的知識跟認知就會慢慢往左邊區塊（看得懂）去，所以一開始並不用太擔心。

Note
「痛與不痛」的門檻是基於專案大小而變的。
如果你只是想快速驗證一個想法、做完就丟，那就不需要太擔心，可是如果這個東西你會一直用且開放給別人用，或是你想從這之中學東西，那這個門檻就會拉高許多。

Week 2 動手檢查清單

接下來 Week2 的結尾也提供一份動手檢查的清單給你，讓你試著檢查一次：

• [ ] SPEC.md 的核心驗收標準逐條通過，MVP 跑得起來。
• [ ] git log 看得到一週的 commit 軌跡。
• [ ] 能簡單用白話文解釋出自己記帳資料存在哪裡。
• [ ] 經歷過至少一次：計畫打回、用除錯三劍客回報 bug。
• [ ] npm run build 成功（也可以請 AI 幫你跑）。

結語

時間也差不多了，我們 Week2 就到這邊收工啦～

我們用一週的時間將一份 SPEC.md 快速轉換成一個能用的 MVP，雖然畫面還很陽春，但至少功能上是完整的，這就是我們這週的成果：

• 把流程跑順：
  • 從規格 → 打地基 → 規劃計畫 → 小步功能迭代 → 建立 Debug 流程 → 跑驗收，且每步都要有 commit。
• 程式碼不需要逐行看，但至少要知道他在幹嘛。

那麼希望這一篇對你有幫助，我們下一篇見～