不知不覺，這次的鐵人賽已經來到第 29 天。

從一開始認識 Vibe Coding，到後來接觸 Prompt、Context、Coding Agent、MCP，最後甚至真的做出了一個網站收藏管理器。

回頭看這段過程，會發現 AI 確實改變了不少開發習慣。

不過，經過這幾天的介紹和實作，也讓我開始思考一個問題：

Vibe Coding 真的有想像中那麼方便嗎？

今天就先不寫程式，來整理一下這次學習過程中觀察到的優點，以及一些沒有想像中美好的地方。

Vibe Coding 的優點

首先，最明顯的優點就是開發門檻降低了。

以前如果想做一個網頁，可能需要先熟悉 HTML、CSS、JavaScript，遇到不會的功能還得自己查文件、找範例。

現在則可以先把想法描述給 AI，讓它產生第一版程式，再透過對話慢慢調整。

像 Day 23～28 製作的網站收藏管理器，就是從一句「我想做一個收藏常用網站的網頁」開始，逐步整理需求、產生畫面，再加入功能。

對於想快速驗證想法的人來說，這種方式確實方便不少。

另一個優點則是減少重複性的工作。

前面我們試過讓 AI 幫忙 Debug、Code Review、產生 README，甚至整理 Git Commit Message。

這些工作並不是完全不需要技術，但有些內容確實可以先交給 AI 處理，再由我們確認結果。

尤其是一些簡單的小工具或練習專案，能夠省下不少從零開始摸索的時間。

但 AI 也不是萬能的

不過，Vibe Coding 最大的問題之一，就是 AI 寫出來的東西，不代表一定正確。

例如 Day 27 的 Debug 實作，我們故意讓收藏資料無法正常保存，再請 Agent 找出原因。

這次的問題很單純，只是少了一次 saveBookmarks() 呼叫。

但如果換成更大型的專案，錯誤可能同時牽涉多個檔案，甚至是不同功能之間的相互影響。

這時候如果完全不理解程式，只靠 AI 不斷嘗試修改，就有可能陷入：

發現 Bug
   ↓
叫 AI 修復
   ↓
原本的 Bug 修好了
   ↓
其他功能又壞掉
   ↓
繼續叫 AI 修復
   ↓
...

最後花在修復問題上的時間，說不定比自己動手還多。

而且 AI 有時候也會過度熱心。

明明只要求修改一個按鈕，它卻順便調整整個版面；只是想增加一個功能，結果連原本的程式結構都一起改掉。

這也是為什麼前面會特別介紹 Rules / Instructions。

AI 的自由度越高，我們越需要清楚地告訴它哪些事情可以做、哪些事情不要碰。

會寫 Prompt，就等於會寫程式嗎？

這也是我覺得值得討論的地方。

Vibe Coding 確實讓不熟悉程式語言的人，也有機會做出可以使用的作品。

但如果完全不理解程式在做什麼，當 AI 產生錯誤、使用不安全的寫法，或是做出不符合需求的功能時，就很難判斷問題在哪裡。

例如這次收藏管理器使用 LocalStorage 保存資料，如果不知道它只是瀏覽器端的儲存空間，可能就會誤以為資料能自動同步到其他電腦。

所以我認為，Vibe Coding 可以降低「開始寫程式」的門檻，但不代表程式設計的基礎知識就完全沒有價值了。

至少需要理解自己的專案大概在做什麼，才能知道 AI 給出的結果是不是合理。

那到底什麼情況適合 Vibe Coding？

整理這幾天的內容後，我會把不同情況簡單分成這樣：

對我來說，Vibe Coding 比較像是多了一位可以隨時協助開發的夥伴。

它能幫忙寫 Code、整理需求、分析問題，但不應該把所有決定都交給它。

尤其當專案越來越複雜時，開發者仍然需要負責判斷需求、確認程式品質，以及驗證最後的成果。

最後的想法

經過這 28 天，我覺得 Vibe Coding 最有價值的地方，不是讓人從此不用學寫程式，而是讓我們可以把更多時間放在「想做什麼」，而不是一直卡在「這段程式該怎麼寫」。

當然，前提是我們願意花時間檢查 AI 的成果，而不是看到它說「完成了」，就直接相信一切都沒問題。

所以如果要回答今天一開始的問題：

Vibe Coding 好用嗎？

我會說，好用，但不是無腦好用。

它可以讓開發變得更快、更容易開始，卻沒有辦法替我們承擔所有的判斷與責任。

而明天就是這次鐵人賽的最後一天了。

Day 30，我們就來回顧這 30 天到底學到了什麼，以及從第一天的一句 Prompt，到最後真正完成一個小專案，整段過程帶來了哪些收穫。