前言

倒數第二天了，我們就來整個回顧一下開發的流程步驟吧！

也算是替這一整個 Vibe Coding 系列做個收尾，讓你未來可以直接照著走，而不用再回頭翻 Day 1 ~ Day 28。

六步驟總覽

從前面章節開始，其實我們一直反覆在做這六個步驟：

• 想清楚
• 打地基
• 先計畫
• 小步跑
• 建立關卡
• 上線系統

而每一個階段都有它合適的、擅長的工具，這邊整理成一個表格：

基本上這個流程與我們實際開發也是雷同。

儘管 Vibe Coding 讓開發速度變得非常快，但是放手給 AI 去做之前每個階段都會有一些檢查點，像是規格接住方向、Git 接住失誤、計畫接住範圍、驗收跟測試接住品質、部署流程接住上線，這些檢查點就像是煞車一樣，讓你敢開快車。

不過這邊你要注意，這六大步驟並不是一條直線，而是會一直轉下去的圈，上線之後的每一次改版，都是從第一步重新開始。

嗯？很像 Scrum（敏捷開發）？沒錯，其實概念上是差不多的，只是這邊把每個步驟拆得更細，並且針對 AI 開發的特性做了調整。

Note
敏捷開發比較像是一套理念（價值觀跟原則），Scrum 則是實踐敏捷的其中一種框架，這邊的六步驟是我自己整理出來的流程，並不是官方文件裡的說法。

每一步是怎麼來的呢？

那接下來當然要來聊一下每個步驟的來源，讓你可以體會到這套流程不是憑空想出來的，而是踩過坑才有的。

第一步：想清楚

如果你只是跟 AI 說「幫我把這個頁面做得更好看，你自己決定」，那 AI 基本上就是「腦補」。

所以你就會一直反覆說：不對、不對、再改、再改，接著你就開始浪費無意義的 Token 以及時間，就跟你對著工程師說你要做一套系統，但你卻沒講清楚你要幹嘛，工程師只好腦補空窗的那一段。

所以你使用 AI 的時候，其實就體現出你平常到底是怎麼與他人溝通交代需求的。

第二步：打地基

需求討論完畢就要來打地基囉，這邊的地基就是：

• Git：讓你可以回到過去的存檔點。
• CLAUDE.md：把你跟 AI 講好的原則寫進去，讓它每次開新對話都能讀到。
• DESIGN.md：把畫面長怎樣寫進去，讓它每次開新對話都能讀到。
• SPEC.md：把需求寫進去，讓它每次開新對話都能讀到。

不過這邊要注意，Claude Code 開新對話的時候只會自動讀 CLAUDE.md，所以 DESIGN.md 跟 SPEC.md 要在 CLAUDE.md 裡面用 @ 掛進來（例如寫一行 @SPEC.md），AI 才會一起讀到。

而這階段也會把使用的技術討論清楚，千萬不要 AI 講什麼技術就用什麼技術，而是要先問它這個技術的優缺點，然後由你來拍板。

第三步：先計畫

接下來直接針對 SPEC.md 的需求開始直接開發嗎？

不，別忘了 AI 的能力是有限的，尤其是對於大改動，它可能會漏掉一些細節，或是做出你不想要的東西。

所以你應該要先請它幫你做一份計畫，列出它要動哪些檔案、哪些是它不會做的事、驗收標準是什麼，然後你再來審查。

並且請它把這些 Plan Mode 的計畫存進 docs/plans/，之後出 bug 還能翻出來對照它有沒有照計畫做，甚至拿出來打臉你自己 明明就是你自己說要這樣做，但卻又怪罪 AI 做錯。

第四步：小步跑

計畫看完沒問題，當然就可以開始做了，但這邊我會建議你一次只做一個功能。

為什麼呢？就像你一次吃了三種沒吃過的東西，結果蕁麻疹，但你根本不知道是吃哪一個導致的，這件事情放到 AI 也是一樣，一次請 AI 改 N 個功能也一樣，壞掉的時候你根本不知道是哪一個改壞的。

所以每一輪的節奏會是這樣：

• 先 /clear 把上一輪的對話清掉，換一張乾淨的桌子。
• 請 AI 只做一個功能。
• 你親手驗收，過了才 commit。

而驗收的時候要特別注意，驗收會過不代表沒有 Bug，很可能只是你剛好沒測到那個情境而已，所以驗收條件裡要刻意放幾個容易出事的情況，像是跨日期的資料、上個月的資料、金額剛好等於預算，另外舊功能也要順手點一點，確認沒有被這次的改動弄壞。

真的壞了也不用擔心，但你絕對不能說「壞了，修一下」就叫 AI 去改，因為這就跟你去看醫生只說「我不舒服」一樣，醫生也只能用猜的，所以你必須描述清楚壞掉的情況。

1. 怎麼重現
2. 你預期看到什麼
3. 實際上看到什麼

這其實就是一套固定的除錯 SOP。

如果來回幾次還是修不好可以換個方向問、把範圍縮小，再不行就用 git 把壞掉的檔案還原，回到上一個存檔點重新再來。

第五步：建立關卡

功能做完了，那品質要靠什麼呢？難不成都由你自己來檢查嗎？

不可能，人都會忘了何況是 AI，你每天下班之前跟同事說「下班記得關冷氣」，大多時候都會記得，可是總有忘記的那一天，而 Hook 就很像是冷氣設定定時關機，時間到了它就一定會關。

所以每次都要檢查的像是排版、測試，就不要只寫在 CLAUDE.md 裡拜託 AI 記得做，而是交給 Hook，讓它時機一到就自動執行。

不過這邊不是說你就不用驗收了唷，新功能你還是要親手點過一次，只是那些每次都要重複的檢查，就交給機制來顧，畢竟 Vibe Coding 本來就不太會一行一行去看 AI 寫的程式碼，你沒看到的地方，總要有人幫你盯著。

這邊的關卡我會分成這幾道：

• Hook：每次都一定要做的事，像是 AI 改完檔案就自動排版、做完一輪就自動跑測試。
• 測試：讓程式自己檢查自己，把 SPEC.md 裡的驗收條件寫成測試，尤其是金額計算這種算錯就會出事的地方。
• code-reviewer：一個只看不改的 Subagent，用一雙乾淨的眼睛幫你審 AI 寫的程式碼。
• PR：開 PR 之後，GitHub Actions（GitHub 幫你自動跑指令的服務）會自動跑測試跟 build，CodeRabbit（會自動幫你做 Code Review 的 AI 服務）也會再審一次。

這邊要特別注意，code-reviewer 跟其他關卡不太一樣，它不會自己跑，要你叫它才會出動，而且主 Agent 有時候會覺得自己審就好（固執），根本沒有派給它，所以功能做完之後，最好直接用 @ 點名它，才保證派得到。

那為什麼要開 PR，而不是直接 push 到 main 呢？因為 main 一 push 就會自動部署，等於直接上線給所有人看，所以平常會從 develop 開一個分支出來做事，做完再開 PR 申請合併回 develop，PR 你可以想成是一張申請單，關卡都跑完、你也看過結果了，才按下合併。

另外機制掛上去，也不代表它就照你想的在跑。

就像家裡裝了煙霧偵測器，可是你從來沒按過測試鈕，等到真的失火才發現電池早就沒電了。

像我們的排版 Hook，檔案看起來排得整整齊齊，可是後來才發現 Prettier 根本沒有設定檔，一直用它自己的預設值在排版，引號跟分號都跟專案原本的寫法不一樣，偏偏這種問題又不會讓功能壞掉，所以一直沒有人發現。

所以關卡掛上去之後，記得回頭看一次它是不是照你要的規則在做事，測試跟 GitHub Actions 也一樣，故意把程式改壞一次，看它會不會亮紅燈，確認抓得到之後再改回來，畢竟沒親眼看過它抓到錯，你怎麼知道它不是一直在放水呢？

真的亮紅燈的時候也不用緊張，先不要合併，把錯誤訊息貼給 AI 修好，再 push 到同一個分支重跑一次就好。

至於 code-reviewer 跟 CodeRabbit 給的報告則是要看，但不用全部照修，先處理比較嚴重的就好（像是 CodeRabbit 標成高、中等級的），低的再跟 AI 討論看看是不是真的需要修，畢竟 AI 給的等級只是它的意見，並不是聖旨，最後要不要改還是你來決定。

第六步：上線系統

關卡都過了，終於可以上線了，不過 Actions 全綠不代表你的網站就沒問題唷。

這就像外送 App 顯示「已送達」，不代表餐真的到你手上，搞不好放錯樓層了，你還是要開門看一眼。

意思是 Actions 全綠只代表部署流程跑完了，像是部署到 GitHub Pages 的時候，網址會多一層專案名稱（例如 /money-note/），如果 vite.config.js 沒有設定 base，打開就是一片白畫面，可是 Actions 照樣全綠，所以打開正式網址親手點過一次才算數。

另外走 PR 流程之後，把 develop 合併進 main 的那一刻就等於上線了，所以前面那些關卡，一定要在按下合併之前全部過完。

如果是第一次把專案公開，push 之前也要先請 AI 檢查 commit 歷史裡有沒有金鑰、密碼、.env 這些不該公開的東西，因為推上去之後，就算再把檔案刪掉，commit 歷史裡還是看得到。

然後回到第一步

上線之後要做下一個功能，或是要改舊功能，一樣從第一步開始，而且記得一個大原則：

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

為什麼呢？因為 AI 每次開新對話都是看 SPEC.md、CLAUDE.md 這些文件來做事，就像師傅是照設計圖施工，你想改格局卻沒改設計圖，師傅當然還是照舊的蓋。

像我們的預算提醒，一開始故意塞進計畫裡，就被 SPEC.md 的不做清單擋了下來，後來真的要做的時候，就是先回到第一步把規格改好，才順利做出來的。

至於下一圈要做什麼，也不一定要憑空想，盤點技術債時存下來的 docs/TODO.md 就是現成的候選清單，挑一條最小、風險最低的開始就好。

Note
以後遇到新的坑，也請你把它寫進流程裡，讓流程記住這次的代價，而不是靠你自己記住。至於寫在哪裡，可以照前面教過的分法：要做什麼寫進 SPEC.md、畫面長怎樣寫進 DESIGN.md、需要判斷的原則寫進 CLAUDE.md、每次都一定要發生的事交給 Hook、同一件事講三遍以上就收成 SKILL、算錯會出事的邏輯就補上測試。

步驟可以瘦身，但不要跳過

看到這邊你可能會想，改一個按鈕的顏色也要走完六步，也太累了吧？

其實每一步的份量都可以跟著功能大小調整，像預算提醒這種小功能，訪談只問了八個左右的問題就對齊了，計畫也只確認範圍合理就放行，官方的最佳實踐也有類似的說法，如果是一句話就講得完的改動，就不用先計畫了。

那多大才算大改動呢？我自己的標準是會動到兩個以上的檔案、不熟悉的專案，或是我自己心裡也沒什麼想法的時候，就先開 Plan Mode。

可是瘦身跟跳過是兩回事，就像出門一樣，去巷口買個早餐不用拖行李箱，可是鑰匙跟手機不管去哪都要帶，而驗收條件就是那把鑰匙，再小的功能都不能省，因為每次你心存僥倖跳過的那一步，通常就是後來出事的那一步（別問我怎麼知道的）。

下一個專案的 SOP 檢查清單

這邊我把六步收成一份清單，下一個專案每做一個功能，就照著逐條問自己一次：

• [ ] 想清楚：說得出做完要看到什麼嗎？SPEC.md 有寫要做、不做跟驗收條件嗎？
• [ ] 打地基：開工前 git 是乾淨的嗎？講好的決定都寫進 SPEC.md、CLAUDE.md 或 DESIGN.md 了嗎？
• [ ] 先計畫：會動到兩個以上的檔案、不熟悉的專案，或是你心裡還沒什麼想法嗎？是的話先看計畫：動哪些檔案、不做什麼、怎麼驗收。
• [ ] 小步跑：這一輪只做一個功能嗎？有親手驗收，連容易出事的情況跟舊功能都點過，才 commit 嗎？
• [ ] 關卡：npm test 是綠的嗎？有用 @ 請 code-reviewer 審過嗎？有從 develop 開分支、開 PR，看過 Actions 跟 CodeRabbit 的結果嗎？
• [ ] 上線：合併進 main 之後，有打開正式網址親手點過一次嗎？

是的，就這樣，就這六條。

結語

那時間也差不多到結尾了，這邊也幫你總結一下：

• 我的 Vibe Coding 流程是想清楚、打地基、先計畫、小步做、設關卡、上線，然後回到第一步。
• 每一步都是踩過坑才有的，以後遇到新的坑，就把它寫進流程裡。
• 步驟可以瘦身，但不要跳過，驗收條件怎樣都不能省。
• 重複在做的流程可以收成 SKILL 交給 AI，可是驗收跟要不要合併上線，還是你自己決定。
• 資源清單收好，遇到技術問題永遠先查官方文件。

明天就是最後一天了，我會把 30 篇整理成一份目錄，之後要回來查東西會比較方便～

希望這一篇有讓你把這 30 天的做法帶走哩～

我們明天見囉～