Vibe Coding的風潮正席捲全球，但是近期國內傳出，有非工程師背景的人士靠AI寫程式完成專案後，竟然收到萬元帳單！原來是對程式碼不夠理解帶來問題。當人人都能靠直覺寫程式，專業工程師是否還有價值？撞上牆的素人開發者又該如何精進自我？《遠見》彙整多位開發者的分享，探討在AI寫程式與AI Coding普及後，不同能力層級的開發者，該如何重新定位自己的核心價值。
若要回顧AI進展帶給人們的實質影響，除了ChatGPT、Claude等對話式AI服務滲透至不少人的生活以外，利用AI寫程式（AI Coding）解決日常與工作問題已成顯學。
從面向專業開發者的GitHub Copilot、OpenAI Codex、Claude Code，到程式小白也能用的Cursor、Windsurf，還有科技巨頭Google與AWS各自推出的Antigravity以及Kiro，AI寫程式的戰場興旺無比。
然而，隨著熱潮消退，許多人發現單靠直覺並不足以應付複雜系統。
AI寫程式盛況空前，但Vibe Coding也遇到規模化瓶頸
什麼是直覺開發（Vibe Coding）？
由曾任特斯拉AI總監的卡帕西（Andrej Karpathy）發明的術語「直覺開發」（Vibe Coding），很快深入人心。
直覺開發強調使用者不再需要深究艱澀的語法或底層邏輯，只要透過自然語言輸入提示詞，憑藉著對產品的直覺，AI就能替使用者開發出應用程式。
一時之間，社群網路上充斥著非技術背景創業者利用AI在數小時內打造出原型的成功故事，彷彿已經抵達軟體開發的民主化終點。
AI Coding有代價，資安風險、維護泥沼
只是，在這些光鮮亮麗的演示影片背後，陰影正在蔓延。
隨著Vibe Coding普及，愈來愈多災難性的案例浮上檯面。
有使用者因為沒有深究AI生成的程式碼運行邏輯，開發出的應用程式邏輯錯誤，結果收到破萬元的意外帳單；也有使用者利用AI打造出能夠即時運算的網頁服務，但經專家提醒後才發現，倘若遭遇惡意攻擊恐將面臨鉅額虧損。
更普遍的挫折在於，AI能夠快速做出可以運行的原型，但要將其轉化為穩定且安全的產品卻難如登天。
就連卡帕西本人，也表示在打造個人專案時，基本上是自行寫好程式，「因為Claude和Codex的表現不夠好。」
雖然產出程式碼的邊際成本不斷下降，但利用AI伴隨而來的挑戰才剛開始。
面對這些因直覺而生的代價，開發者們試圖在享受AI帶來的迷幻體驗的同時，尋找解方。
近來盛行的「規格驅動開發」，就是在此背景底下產生，試圖在AI的創造力與工程的嚴謹性之間尋找平衡。
若要駕馭AI這匹野馬，人們需要的不再是隨機的對話，而是精確的定義，希望停止依賴運氣，轉而尋求一種能讓AI產出穩定、可維護程式碼的系統化方法。
從Vibe Coding轉向規格驅動開發Spec-Driven Development
AI寫程式有極限，為何對話式AI難以應付複雜需求？
在探討規格驅動開發的具體細節之前，不妨先跟著開發者們回頭審視開發模式的改變。
在AWS雲端年會的一場閃電演講裡，TeamWork Management資深雲端顧問吉羅（Anda-Catalina Giraud）向台下的聽眾分享開發思維如何演進。
她指出，過去的開發者使用的是打孔卡（punched card），極度依賴手動、需要精密規劃，且抓錯非常痛苦；現在只要會說話，就能寫出程式碼。
只是，吉羅觀察到，Vibe Coding雖能大幅加速打造原型所花的時間，但卻難以持續。
若使用者只想快速嘗試新想法時，輸入指令、按下提交，接著等待結果，這種模式非常有效。
然而，當專案開始迭代，想要修改功能或擴展架構時，聊天視窗就不太令人滿意。
「一旦你想改變事物、向前推進、實作新功能，它就會變得非常耗時。」
隨著對話變長，AI的上下文視窗（context window）不堪重負，很容易遺忘先前的設定，導致專案陷入無法維護的泥沼。
AWS資深首席工程師李郭里（Clare Liguori）也遇上類似困境。
作為一名經驗豐富的開發者，李郭里發現，花在與AI溝通上的時間，竟然比自己寫程式還要多。
「AI生成的程式碼很好，但最終產出的軟體並沒有做我想要它做的事。我經常試著用一個新的提示重新開始，從頭再來、再試一次。」
為了修正這些誤差，她被迫撰寫愈來愈長、詳細的提示詞，試圖修正AI的行為。
「我基本上是在創建一份規格說明書（Specification），」李郭里回憶道。
Spec-Driven Development核心：先定義規格，再寫程式
像這樣的反思，促成規格驅動開發（Spec-Driven Development，簡稱 SDD）」，一種強調在AI寫程式前，先明確定義需求、設計與限制的開發方法興起。
包含GitHub輔助SDD的工具包spec-kit、AWS格外強調SDD的AI整合開發環境Kiro、阿里巴巴支援SDD（Quest模式）的AI整合開發環境Qoder、推出SDD框架的新創Tessl，都在推廣規格驅動開發。
SDD的核心邏輯在於承認自然語言的模糊性。
舉例來說，使用者的指令可能是「幫我開發一個天氣應用程式」，這句話背後，可能隱含上百萬種不同的設計組合，如果沒有明確的邊界與定義，AI產出的程式碼就像抽卡，無法確定成品的邊界。
為了將開發的主導權拿回來，新一代的開發工具開始導入SDD流程。
這意味著在AI寫下任何程式碼之前，必須先經歷一段思考與確認的過程。
李郭里以AWS的Kiro IDE為例，其工作流程被嚴謹地拆解為三個階段。
首先是生成「需求（Requirements）」，釐清使用者的目標與限制；接著是產出「設計（Design）」，規劃系統架構與元件互動；最後才是將設計拆解為具體的寫程式「任務（Tasks）」。
為何要先確定規格以後，才能開始寫程式？難道先產出原型、再行修改的模式不可行嗎？
李郭里以自己團隊所遇上的案例，試圖解釋SDD的價值。
曾經，她的團隊試圖在Kiro中的Agent增加通知功能，結果，採用Vibe Coding模式產出的程式碼，卻是在Kiro的Agent系統中，打造出一套全新的通知系統，導致疊床架屋。
改採SDD流程以後，團隊在設計階段就發現錯誤並及時介入，引導AI改用底層IDE既有的原生通知API。
「我們可以通過規格，與AI溝通，進而迭代軟體設計。」李郭里說道。
上下文工程比指令工程更加重要
透過SDD，開發者不用再跟AI猜謎，改為討論專案結構、準則與邊界等完整背景資訊。
吉羅補充，這就是「上下文工程（context engineering）」與「指令／提示工程（prompt engineering）」的決定性差異。
「我們需要告訴AI該使用哪些語言、不該使用哪些。我們需要告訴它們該使用哪些工具、不該使用哪些。將所有這些提供給AI，基於這些上下文推進我們的系統。」
一如其他AI生成內容領域，AI寫程式的重點也從實現點子的速度，轉向控制的精確度。
給非工程師的建議：學會描述「意圖」與「規格」
雖然包含Claude Code在內的開發工具，正努力打造出更友善的介面，藉此降低使用門檻，消除非技術人員對終端機的恐懼，但工具易用性並不能解決所有問題。
Anthropic市場進入團隊的工程師萊恩（Christian Ryan）向《遠見》指出，市場上有許多整合了AI對話功能的IDE，讓大眾能輕易上手。
只是，對於想要在AI Coding領域進階的人來說，他建議可以花點時間閱讀最佳實踐（best practices），從中學習設計模式。
當工具使用起來不再困難，真正考驗的，反而是使用者能否清楚表達想法與思考脈絡。
下指令以外，還要培養產品經理思維
以非工程師來說，無論是培養設計思考能力，還是鍛鍊自己的商業思維，都能讓原型更有機會落地。
然而，只擅長勾勒成果，卻無法清楚描述意圖與過程，讓開發過程很容易撞牆甚至崩潰，使得不少非開發者打退堂鼓。
《遠見》記者向吉羅詢問，利用AI開發出應用程式以後，除了根據結果請AI修改以外，還能多做哪些事情？
吉羅認爲重點不是跳下去學語法，而在學習與AI對話。
「要求系統向你解釋事情、以及它為什麼要這樣做。」藉著AI的自剖，累積對軟體架構的直覺，進而培養出判斷程式碼優劣的能力。
不管是吉羅還是李郭里，都提到掌握規格的重要性。
即便不懂程式碼，也可以學習像產品經理一樣思考，從過往可能想盡辦法調整指令，進一步往清晰描述功能邊界、觸發條件以及與其他模組的關係等邁進。
給開發者的挑戰：成為AI時代的文藝復興工程師
如果非技術人員開始學習寫規格、做產品，那麼專業工程師的地位是否岌岌可危？
亞馬遜CTO：工程師不會被取代，但必須進化
亞馬遜CTO沃格（Werner Vogels）就在演講中，主動向開發者們點出房間裡的大象：「AI會搶走工程師的工作嗎？」
雖然沃格持否定答案，但他同時警告，AI不會讓開發者過時，但會淘汰那些拒絕進化的人。
真正的問題不是AI能不能寫程式，而是工程師是否能承擔起更高層次的責任，因為工具會改變、流程會翻新，但「工作始終是你的，而不是工具的」。
沃格認為，工程師的核心價值劇烈翻轉，從寫程式的人（writer）轉變成系統架構師（architect）以及驗證品質的人（verifier）。
因為AI雖然能迅速生成程式碼，但它會產生幻覺，而且無法承擔法律與道德責任。如果醫療軟體出錯影響病患安全，或是金融系統違反監管法規，工程師不能兩手一攤說「那是AI寫的」。
沃格拋出一個新時代開發者的理想樣貌「文藝復興開發者（Renaissance Developer）」，並明確點出幾項關鍵特質。
保持好奇心、系統思考並且注重溝通
首先，是好奇心。
他認為，好奇心是開發者最古老、也最重要的本能。拆解系統、理解原理、持續學習。在快速變動的技術環境中，唯有保持好奇，才能不斷進化。
第二，是系統思考（systems thinking）。
Vogels指出，軟體系統具有自己的動態行為。調整重試機制，會影響系統負載；加入快取，會改變流量走向；改變團隊權責分工，也會影響交付節奏。
AI往往只能看到局部程式碼，唯有人類工程師能理解這些變動在整體系統中引發的連鎖反應，因此需要能夠掌握架構。
第三，是溝通與規格能力。
在生成式AI時代，工程師不再只用精確的程式語言與機器互動，而是大量依賴模稜兩可的自然語言。正如規格驅動開發的重點，規格正是降低歧義的關鍵工具，能把人類意圖轉化為AI執行的可靠指引。
第四，是當責（ownership）與品質責任。
沃格指出，AI生成程式碼的速度，遠快於人類理解與驗證的速度，形成他所謂的「驗證差距」（verification gap）。
他批評，許多開發者習慣接受AI產出，這宛若賭博，「你不能把IDE當成拉霸機，拉一下就指望出現好程式，那已經不是在做軟體工程，而是在賭運氣。」
他強調工程師必須建立機制，如規格驅動開發、自動化測試與驗證流程，避免在理解程式碼以前，就放任其進入生產環境，
最後，是成為博學的T型人才（polymath/T-shaped developer）。
沃格強調，他並不是要求工程師成為達文西，而是要在技術深度之外，理解業務邏輯、使用者體驗與法規限制。唯有兼具深度與廣度，工程師才能寫出足以引導AI、又符合現實世界複雜性的規格與系統。
寫程式的門檻正在消失，但軟體開發的挑戰才剛開始
從Vibe Coding轉往規格驅動，標誌著AI開發走過看熱鬧階段，進入了更加重視產出穩定性的成熟期。
如同沃格所說，工具躍進並沒有讓人類變得多餘，反而推高了人類價值的層次。
他解釋，古騰堡印刷機的發明沒有讓作家消失，反而讓思想傳播得更遠；AutoCAD的出現沒有取代建築師，反而讓建築設計變得更宏偉。
如今，AI也在做同樣的事。
它消除繁瑣的寫程式勞動，將人類從語法的細節中解放，但同時也賦予人們更艱鉅的任務：設計意圖。
未來的軟體開發，將是人類設計精確意圖、機器高效執行的協作。
如同沃格所說，工作依然是你的，不是工具的；也如同吉羅所說，使用者必須清楚自己想要達成什麼、進而引導機器前進。
在這個新時代，Python或者JavaScript的知識仍然不可或缺，但擁有清晰的邏輯與對系統的深刻理解也變得更加重要。
掌握規格與意圖，將成為AI Coding時代最重要的能力之一，無論是工程師、產品經理，或是希望透過AI寫程式打造產品的非技術創作者，都更有機會加入這場數位文藝復興。
