Vibe Coding：從工具操作到目標導向的開發思維轉變
混沌時代的 AI 編程經驗
在 vibe coding 被廣泛討論之前，以及 AI 編輯器能夠自動建立檔案並放上合適程式碼的機制被普遍接受之前，我是在一種相對原始的互動模式中工作。那時，我使用網頁環境開啟對話，一段一段地把程式碼貼到網頁上取得結果，然後再複製回實際的開發環境中執行。在這種缺乏完整專案情境的工作方式下，我個人偏好 Claude，因為它即使在缺乏 Context 的情況下仍能產出恰到好處的程式碼。
不同的 AI 模型在面對有限情境時有著截然不同的表現。Gemini 系列服務常因「句點」問題而被人揶揄，無法提供連貫解答；而 ChatGPT 系列的表現則相當波動，取決於專案是否恰好符合它的專長領域。雖然 ChatGPT 較容易產生「幻想」，但其龐大的使用者基礎也讓大眾逐漸學會如何與 LLM 互動，甚至將處理幻想視為使用這類工具的必要成本。
與 AI 共處的實用智慧
學習如何與 LLM 互動，並且讓其他人可以接受以這種方式產出的混沌時期，實際上培養了我這個早期使用者與 AI 助手友善相處的能力。我學會了驗證結果、檢查依據是否正確，以及設計可明確驗證的成果。在軟體開發中，這表現為要求 AI 撰寫測試案例，並提供測試執行指令作為驗證機制。這些經驗形成了一套獨特的使用智慧，是經歷技術發展初期的使用者所特有的優勢。
開發範式的根本轉變
隨著 vibe coding 討論的深入，我逐漸意識到開發方式正在發生根本性變化。過去我專注於掌握操作技法，配合精心設計的 IDE 以提高開發效率；而現在，這種模式正被簡單編輯器搭配 AI agent 的方式所取代。許多過去學習的操作技巧可能不再必要，甚至特定程式語言的專屬 IDE 也變得不那麼重要。
有趣的是，AI 編輯器的出現也改變了模型間的競爭格局。編輯器能夠提供大量專案情境作為 Context，讓原本在程式寫作品質上表現優異的 Claude 雖然仍保持優勢，但其他模型也因此拉近了差距。這種情境補充機制讓其他類型的模型成為可行的替代方案，也就是許多開發者選擇使用 Gemini 系列搭配 Cline 作為免費的替代選項。專案 Context 的自動補充某種程度上彌補了我們過去提供太少資料而導致模型無法充分發揮幫助我們的問題。
從指令輸入到目標描述
本質上，我需要那些開發技法主要是為了突破將腦中想法轉化為實際程式碼的瓶頸，希望用最少的輸入達到等價的結果。而現在，我不再專注於直接描述實作細節，而是更注重目標的清晰表達。與 AI agent 的互動更像是與技術同事溝通，而非一步步指導小學生完成任務。
目標導向帶來的變革
當我將視角提升到更接近最終目的的目標管理層次，會帶來幾個明顯的改變：
縮減了依賴人類重複輸入所導致的冗長實作時間
測試案例的開發變得更為全面，能更快速地窮舉邊界條件並適當挑選等價集合案例
最重要的是，擺脫了機械性、重複性的勞動後，我的心力可以更加投入在真正重要的事情上——推進目標、思考問題本質
在這種新型態的開發環境中，「理解問題本質」和「清晰表達目標」的能力，可能比「熟練掌握特定語言語法」更為重要。vibe coding 不僅改變了我寫程式的方式，也正在重塑軟體開發的核心技能。
超越功能實作：目標管理與認知負擔的平衡
當我把視角放在目標管理之上時，我不再只是處理字元層級的細節調整，而是描述對於目標的各種陳述。在這個階段，我想分享我在各種 side project 中使用 vibe coding 的經驗。描述目標是需要練習的技能，與過去練習操作技法是完全不同的事情。
目標描述有時會顯得抽象，但它又與現實世界緊密連結。這有點像 SOLID 這類設計原則的理解過程——很難不透過實踐來真正掌握其概念，但因為我經歷過並見識過符合這些品質標準的成果是什麼樣子，才能夠清晰地描述出來。
值得注意的是，我在文章中提到的目標管理並非僅限於「把東西做出來」，它還包含了成品的可維護性，確保專案能夠持續發展。最關鍵的是，即使在沒有 AI agent 輔助的情況下，人類也能夠輕鬆接手維護。
我認為好的目標管理不僅關注功能是否符合需求，還包括內在實作是否會帶來額外的「認知負擔」。而這種認知負擔不僅影響人類開發者，實際上也會顯著影響 AI agent 的效能。
我自己用 vibe coding 寫了一個貪食蛇的 side project 作為實驗。在這過程中，我讓 Claude 規劃功能並幫我標好了 to-do list，方便我與 AI agent 依照進度推展。單純順著 to-do list 把功能疊加上去相對簡單，但是到了第二輪實作，也就是規格變更的時候，情況就完全不同了。
我發現無論如何修改 prompt，AI agent 的效能都大幅下降，很難再把事情依序做對。主要原因是所有邏輯都擠在 game loop 之內，這樣的認知負擔太過沉重。即使是人類來修改也會很吃力，雖然我們可以靠毅力把它改好，但對 AI agent 來說就不同了——它通常只有一次做對的機會，一旦出錯，又要從頭來過。
因此，為了減輕認知負擔，我學到了一個重要經驗：至少要選擇性地把 SOLID 或其他更具體的設計要求融入實作指示中，對 AI agent 下好「指導棋」。這不僅有助於生成更易維護的代碼，也能提高 AI agent 在迭代開發中的效能。
未來技能樹的重新定位
常聽人說「時間花在哪裡，成就就在哪裡」。對應到這個 vibe coding 盛行的年代，也許它最終不會保持這個名稱，朋友間提起時可能會稱之為「AI 驅動開發」之類的東西。無論如何，這個時代所需的技能樹已經不同了。
在這種開發模式中，我們追求的是目標管理與可持續性。從打字的苦勞中解放後，我得以專注在更高階的目標描述以及目標之下的品質要求表達。這些能力都是可以透過練習培養的，但無法避免的是——你仍需要大量閱讀，以及更多的輸出練習。只是這個時候的「輸出」不再是過去那種辛苦打字、按下編譯執行按鈕、轉頭看程式執行畫面，再從冗長的錯誤日誌中挖掘程式不如預期的原因。
新的「輸出練習」，是透過 vibe coding 寫出有品質且可維護的專案。而那些我們過去推崇的提升品質的各種書籍原理原則，無一例外地仍然重要——SOLID、設計模式、測試驅動開發——這些原則依然是我們無法逃避的課題，只是現在我們需要學習如何將它們清晰地傳達給 AI agent，讓它能夠理解並實踐。
不同經驗開發者的適應策略
對於資深開發者而言，如果你尚未掌握這類品質要求的清晰描述能力，這無疑是一種警訊。沒有這項能力，你不僅難以寫出可維護的程式，即使勉強達到品質標準，龐大的認知負擔也會讓你使用 AI agent 的效能遠低於他人。
而對於新手開發者，vibe coding 剛好解放了部分電腦操作不熟的焦慮感。特別是對於那些與手機接觸時間遠大於實體電腦鍵盤的年輕人——我知道你們大多數人打字效率不高，儘管最終你還是得練習它。但現在程式開發大部分不再僅靠打字速度取勝。真的不行，你可以嘗試語音輸入。重點是，除了日常打字速度的提升外，你不必再投入過多時間學習開發工具的各種技法，而是可以直接越過那一階段，轉向大量學習品質要求的表達與實踐。
只要你能夠在這個關鍵領域建立優勢，在相對短的時間內成為領域中的資深者是完全可行的。
近期的 vibe coding 練習專案
https://github.com/qty-playground/kana-battle
https://github.com/qty-playground/the-snake-game