幾個月前，我的 AI 寫程式工作流程大概是這樣的。
下提示詞。
產生。
複製。
執行。
出錯。
再下提示詞。
再產生。
弄壞別的東西。
修掉那個。
慶祝。如果你曾經用 AI 做過任何東西，你大概也經歷過這個循環。
老實說，我很喜歡，而且到現在還是很喜歡。Vibe coding 讓開發重新變得有趣。
那些以前要花我好幾週才能做出原型的點子，現在一個晚上就能活起來。與其花好幾個小時設定樣板程式碼，我可以直接開始創作。那種感覺就像有一位資深工程師 24 小時都坐在我旁邊。
有一陣子，我以為這就是軟體開發的未來。
然後我開始做更大的東西。就在那時，一切都崩了。
無限提示詞
我們先快速回顧一下，vibe coding 到底是什麼。
如果你曾經打開 Claude、Codex、Gemini、Cursor、Windsurf，或你最喜歡的 AI 寫程式工具，然後輸入類似「幫我做一個儀表板」這樣的內容，恭喜你。你正式成為一名 vibe coder 了。
這個工作流程簡單得很漂亮。你寫提示詞，AI 產生程式碼，你把它複製下來，執行，發現有點不對勁，微調提示詞，再產生一次，重複直到一切看起來「差不多夠好」，讓你說服自己之後會「再整理」。
劇透一下。
你永遠不會之後再整理。
老實說，這也不是在批評。這正是 vibe coding 之所以流行的原因。它去掉了開始時最無聊的部分。那些原本只能在筆記本裡躺幾個月的點子，突然就能在一個週末變成可運作的原型。與其花好幾個小時寫樣板程式碼，我們可以直接開始做。
那真的讓人感覺，軟體開發解鎖了創意模式。
壞掉導覽列的多重宇宙
一切都很美好，直到專案開始長大。你叫 AI 改一個按鈕，它把導覽列改了。你請它修導覽列。
結果驗證功能壞了。你修驗證功能，半數樣式又不見了。
到了這個時候，你的聊天紀錄看起來不像軟體開發，反而像是一場情侶諮商。
「我只叫你改一件事。」
「我知道，但我以為這樣會比較好。」
「我從來沒要你這樣做。」
是不是很熟悉？
有趣的是，我很長一段時間都在怪 AI。後來我看了一下自己的提示詞。
「幫我做一個專案管理應用程式。」
就這樣。沒有需求。沒有架構。沒有約束。只有感覺。
回頭看，我其實是在期待 AI 讀懂我的心思。結果看來，它連那個功能更新也跳過了。
我們需要更好的計畫
傳統軟體開發從來不是先從程式碼開始。它是從理解問題開始。使用者是誰？我們要做的是什麼？哪些功能真的重要？哪些可以等到第二版？
這就是軟體開發生命週期（SDLC）一直以來希望我們做的事。
在 vibe coding 裡，包括我在內的很多人，不小心把這個流程顛倒了。我們先產生程式碼，然後在對話到一半時才開始釐清自己到底要什麼。
如果只是快速原型？那完全沒問題。
如果是會持續成長的專案？那裂縫就會開始浮現。
我還注意到另一件事。對話越長，AI 就越容易忘記上下文，修掉一個問題同時又引入另一個問題，或是自信滿滿地產生我根本沒要求的東西。
一開始，我把這叫做幻覺。現在我認為，那些情況裡很多其實有另一個原因：我一開始就沒有給它清楚的計畫。
規格時代崛起
隨著 AI 生成的專案越來越大，開發者自然開始把更多工程實踐帶回工作流程中。
測試變得更重要了。
與其接受 AI 產生的任何內容，我們會去驗證它、撰寫測試、修正問題，然後持續迭代。這讓專案可靠得多，也減少了很多意外的 bug。
第一次，我感覺 AI 有了安全網。但我還是覺得少了點什麼。
測試只能告訴你，你是否把東西正確地做出來了。它不能告訴你，你是不是在做對的東西。
我仍然是在寫完程式碼之後才規劃，而不是在之前。那才是真正的問題。
有趣的是，我並不是某天早上醒來後突然想：
「今天就是我成為規格驅動開發者的日子。」
這是意外發生的。
在我最近的一個專案中，我發現自己在產生第一行程式碼之前，竟然花了快一個小時把需求寫下來。我到底需要哪些功能？哪些東西絕對不能改？哪些元件應該要可重用？成功到底長什麼樣子？
只有在回答完這些問題之後，我才請 AI 開始寫程式。
結果讓我很驚訝。
它並不完美。畢竟還是 AI。但我不再是把同一個畫面重生十次，而是在做小幅改進，而不是整個重寫。
然後我終於恍然大悟。
我的提示詞不是變得更好，而是變得更長了。它們其實也不再只是提示詞了。
它們是規格。沒意識到這件事之前，我不再要求 AI 幫我想清楚一切。
我開始給它一份藍圖。
終局
至少從我的角度來看，規格驅動開發並不是要取代 vibe coding。
它是替 vibe coding 指明方向。與其一開始就說：
「幫我做一個作品集網站。」
我現在會先回答一些問題。
這個作品集是給誰看的？
它應該包含哪些頁面？
應該使用哪些技術？
哪些元件應該保持可重用？
哪些東西之後不應該再改？
什麼才算真正成功的結果？
有些 AI 工作流程會把這些決策寫進像是 spec.md、requirements.md、tasks.md，或其他類似的規劃文件裡。檔名不是重點。
重點是思考方式。你不再叫 AI 把所有事情都想好。你是把藍圖交給它，而不是一塊空地。令人驚訝的是，當你變成更好的規劃者時，AI 也會變成更好的開發者。
那時候，我才終於懂了這篇文章標題的意思。
終局不是 Claude。也不是 Gemini。不是 Codex。不是更好的提示詞。甚至也不是 AI。
終局是：在叫 AI 幫我思考之前，先學會思考。
彩蛋片尾場景
現在，在我請 AI 寫程式之前，我通常會先花時間建立或審視實作計畫。
有時候我自己寫。有時候我先讓 AI 生成初稿，然後我再編輯。我要在產生第一行程式碼之前，刪掉不必要的功能、補上缺少的需求，並定義約束條件。
諷刺的是，在寫程式之前花更多時間，反而讓我更快把專案完成。我重生產的次數變少了。浪費的 token 更少了。我花在說這句話的時間也少了：
「不……不是那樣。」
而是把更多時間花在審查真正推動專案前進的程式碼上。
我不覺得 vibe coding 會消失。
老實說，我希望它不要消失。
它仍然是探索點子、做產品原型、學習新技術最快也最有趣的方法之一。如果我半夜兩點突然有個點子，我還是會先打開 AI 寫程式工具，再打開 IDE。
這點沒變。變的是我的期待。
我不再期待 AI 會從一句話就神奇地理解一切。AI 越強大，清晰思考就越有價值。
我們已經從自己寫每一行程式碼，演進到與 AI 協作。也許下一個演進方向，不是成為更強的提示詞工程師。
也許是成為更好的軟體工程師，知道如何善用 AI 為自己創造優勢。
感謝閱讀！
我很好奇，過去幾個月你的工作流程有改變嗎？你還是完全在 vibe coding，還是已經開始在請 AI 產生程式碼之前先做更多規劃了？
我真的很想知道你最近是怎麼用 AI 開發的。歡迎透過 LinkedIn 與我聯繫。我真的很想知道你最近是怎麼用 AI 開發的。
P.S. 那些 vibe 還會回來的。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
