実際操作後發現的事
最近持續用 Vibe Coding 開發，剛開始真的覺得相當便利。
畫面與處理很快就成形，開發初速非常快。
但當功能增加，困難的類型就會改變。
比較辛苦的不是「寫程式碼」本身，而是後續的設計、整合性、測試與審查。
以下依照開發流程，簡短整理我在實作過程中感受到的事。
-
首先重要的是，事先思考要做什麼以及以何種順序製作
在 Vibe Coding 中，隨性把想到的功能直接做起來，前期看起來會有不錯的進度。
但當功能越來越多時，沒有考慮開發順序本身就會成為問題。
要先做哪些功能、哪些東西要先共通化再做個別功能、如何整理相依性。
如果沒有先設計好這個順序，之後就很容易產生要重做或出現矛盾的情況。
-
即使是相同的錯誤，可能怎麼做都修不好
這種情況很常見。
對於相同的錯誤或功能，AI 可能重複多次也無法產出正確的程式碼。
會出現看起來合理的修正，但沒觸及根本原因，容易反覆產生類似的修正。
到某個階段，比起一直讓 AI 嘗試修正，更重要的是由人來切分與定位原因。
-
相同功能容易在各處重複
AI 在意識並整理共通功能方面不太擅長。
因此相同或相似的功能常常會在不同模組中被多次產生。
而且每次實作會稍有差異，之後要統一修正時就會變得困難。
一開始雖然開發很快，但越到後面這些差異影響會越大。
-
功能越多，功能間會互相衝突
開發前半段，逐一新增功能通常可以推進。
但到了後半，單一功能本身比不上功能間彼此關係來得複雜。
前提互相不一致、出現矛盾、改了一邊又影響到另一邊。
要妥善解決這類衝突並不簡單，這部分需要人來檢視設計才行。
-
開發越往後，AI 所需的時間越多
一開始用 AI 開發會覺得非常快。
但隨著功能與程式碼量增加，AI 需要的上下文也變多。
結果是，實作所需時間變長。
再加上修改的影響範圍擴大，一次修正往往無法結束。
-
因此，沒有測試機制就無法運作
AI 提升實作速度的同時，測試的重要性也提高。
程式碼增加的速度超過手動確認能追上的速度。
尤其到了後半，AI 所改的地方不只會影響本身功能，還可能波及其他功能。
如果要持續使用 Vibe Coding，我認為需要有效率運轉的測試機制是必須的。
-
但使用者介面的確認必須由人來做
另一方面，有些使用者介面（UI）的檢查單靠 AI 無法完成。
能正常運作的功能與使用上的便利性是兩回事。
版面配置、外觀、間距、操作感、錯誤提示、非同步處理時的易懂性。
這些部分需要最後由人實際操作並確認。
-
錯誤增加時，也需要設計修復的優先順序
錯誤還少的時候，發現就修可能還能應付。
但數量變多後，如果不考慮修正順序，整體就會無法有效運轉。
要先修影響範圍大的、容易再發的、或接近根本原因的錯誤？
還是先優先業務影響大的？
若不整理好這些，努力修了很多問題但整體改善有限的情況很容易發生。
-
人工審查也會逐漸變得困難
到了後半，AI 會一次產生相當大的差異。
若差異擴及數百行，若審查者不熟悉前提，很難做到完整審查。
結果可能只檢查細節，或在未掌握全貌下就放行，風險提高。
AI 能寫的東西與人能審查的能力是兩回事。
-
使用者介面/體驗及非功能性需求在後期會變得重要且繁重
實際開發中，功能能運作通常還不夠。
- 美觀與版面配置
- 錯誤處理
- 非同步處理
- 多檔案同時處理
- 多筆資料同時處理時的交易一致性
- 多人同時操作時的排他控制
- 對 Windows / Mac 等環境差異的因應
這類部分一開始較不明顯，但到了後半肯定會影響整體。
而且之後再集中修正會相當沉重。
まとめ
Vibe Coding 的確能大幅加速實作。
但持續使用時，變得困難的不是「寫程式碼」本身，而是：
- 要做什麼以及以何種順序去做
- 能否穩定修正相同問題
- 能否維持共通化
- 能否維持功能間的一致性
- 是否能執行測試
- 要以何種順序修正錯誤
- 是否能由人有效地審查
- 是否能兼顧使用者介面/體驗與非功能性需求
就我個人來說，Vibe Coding 在加速實作的同時，
反而會更強調設計、順序規劃、共通化、測試與審查的重要性。
剛開始會覺得相當輕鬆。
但真正差距會在後半顯現。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
