Vibe coding 正在改變誰能做軟體

92 名學生。6 週課程。沒有先修程式背景。這組數字很猛，因為它直接碰到一個老問題：做軟體到底要不要先會寫程式？哈佛教育學院的 Karen Brennan 把這件事搬進教室，結果很像一面鏡子，照出 AI 時代誰能做東西，也照出誰會卡住。

她用過 Replit、Figma Make、Claude Code，後來自己又拿 v0 做研究網站。講白了，vibe coding 不是叫你不用腦。它是叫你先講清楚需求，再讓 AI 幫你拼出第一版。

這套玩法很吸引人。也很危險。因為一旦門檻降到自然語言，品質、責任、維護成本，全部都會冒出來。你可能會想問，這到底是軟體開發的捷徑，還是新的混亂來源？

Vibe coding 到底是什麼

「vibe coding」這個詞，是研究者 Andrej Karpathy 在 2025 年 2 月帶紅的。意思很直白。你用 AI 做軟體，但不一定懂每一行程式碼在幹嘛。

這跟一般的 AI coding assistant 不太一樣。一般工具是幫你補 code、修 bug、寫測試。vibe coding 則是把起手式整個改掉。你先說目標，AI 先吐出可跑的東西，再慢慢修。

Harvard 的 Harvard Gazette 這篇採訪裡，Brennan 說她第一次認真碰這種做法，是在 2024 年 12 月。她看到學生用生成式 AI 做自發專案，才開始想：也許教學可以直接把這件事納進來。

• 核心做法：先用自然語言描述需求。
• AI 先產出原型，再由人類修正。
• 重點不是寫得多快，而是判斷得準不準。
• 它最適合做 demo、原型、個人小工具。

這裡有個很重要的差別。會用 AI，不代表會做產品。會做產品，也不代表能把需求講清楚。vibe coding 把這兩件事拆開了，然後逼大家面對現實。

如果你只會下模糊指令，AI 可能回你一坨看起來很像樣的東西。你如果能講得夠精準，AI 就能幫你省掉前面 60% 到 80% 的苦工。差別很大，真的。

哈佛課堂怎麼玩出來的

Brennan 和博士生 Jacob Wolf 設計這門課時，重點不是教某個工具。重點是問：我們怎麼把 AI 當成創作夥伴？每週都有主題，像是做一個會說故事的作品、做一個能改善生活的小工具，或做一個有趣的互動專案。

更有意思的是，他們每週都換工具。學生不是只碰單一平台。這很重要，因為不同工具會塑造不同思考方式。像 Figma Make 偏設計流程，Claude Code 更接近程式實作，Replit 則讓你更快看到可執行結果。

課程也不是純玩具展示。Brennan 要學生每週讀一篇經典電腦科學文本，外加一篇當代批判文章。這設計很聰明。因為如果只看 demo，大家很容易把 AI 當魔術。加上批判閱讀，學生才會開始問：這工具哪裡可靠？哪裡在唬爛？

“The central question motivating the course was: How do we think about AI as a creative partner?” — Karen Brennan

這句話講得很準。課程不是在教學生崇拜工具。它是在訓練學生把 AI 當合作對象，然後保留懷疑。

我覺得這點很台灣。很多團隊上 AI 工具後，第一反應是「哇，省時間了」。但真正麻煩的地方，是你得知道哪裡不能省。教學也是一樣。

為什麼這麼多人會買單

最直接的理由是門檻下降。以前你想做一個網站或 app，至少要懂前端、後端、資料庫、部署。現在先用英文講需求，AI 先幫你生出第一版。這對學生、小團隊、個人創作者都很有吸引力。

這種速度會改變試錯成本。以前你要花兩天做個 prototype，現在可能 20 分鐘就能看到雛形。雖然雛形很粗，但它夠用來測想法。這對教育特別有用，因為「做出來」常常比「想明白」更快讓人學會。

另一個好處是，很多工具不是完全黑箱。像 Claude Code 這類工具可以讓你看見 AI 生成的程式，還能要求它用更白話的方式解釋。也就是說，AI 不一定只是在遮住技術細節，它也可能把細節攤開。

• 原型速度：從幾小時縮到幾分鐘。
• 入門門檻：從語法學習，改成需求描述。
• 適用場景：課堂專案、個人工具、快速驗證想法。
• 學習方式：先做，再回頭理解結構。

但別把這件事想得太浪漫。速度快，不代表品質好。你只是更快看到問題而已。有時候，這反而是好事。

因為你很快就會發現，AI 生成的東西常常很像樣，卻不一定真的能用。外表像產品，內裡可能只是拼貼。這種落差，才是 vibe coding 的真面目。

真正的限制，才是重點

Brennan 沒有把 vibe coding 講成萬靈丹。她提到幾個限制。第一是環境成本。第二是工具費用。第三是自然語言本來就不夠精準。你如果講不清楚，AI 就會亂猜。

更麻煩的是，很多人會誤以為「看起來能跑」就等於「可以上線」。這中間差超多。真正的軟體要面對測試、資安、日誌、版本更新、錯誤處理，還有長期維護。demo 可以很美，產品不行。

課堂裡也出現一個典型問題。學生常常先拿到一個泛用答案，接著又不知道怎麼精準修正。結果瓶頸從「不會寫 code」變成「不會描述問題」。這很真實，也很殘酷。

這裡還有公平性問題。Brennan 指出，擅長口語表達的人，通常更能把 AI 用好。懂設計的人、懂軟體的人，也比較知道怎麼拆解需求。也就是說，門檻是降了，但能力差距沒有消失。

• 快速原型：適合測試想法，不適合直接承載核心業務。
• 生產系統：需要測試、監控、權限、資安審查。
• 自然語言：適合方向，不適合嚴格規格。
• 人類判斷：在高風險場景裡，還是不能外包。

如果拿台灣常見情境來比喻，vibe coding 像是先用試算表做出一個內部工具，再決定要不要請工程師重寫。這樣做很合理。直接拿試算表當正式系統，就很容易出事。

所以問題不是「能不能做」。問題是「做到哪裡就該停」。這句話很土，但很重要。

這件事放到產業裡怎麼看

vibe coding 其實不是孤立現象。它是整個 AI 工具鏈往前推的結果。從 ChatGPT、Claude，到各種 code assistant，大家都在把「寫程式」拆成更小的動作。先問需求，再生草稿，再修正。

這也會影響團隊分工。以前產品、設計、工程之間有明顯界線。現在界線還在，但變得模糊。PM 可以更快做 prototype，設計師可以自己做可互動頁面，工程師則要花更多時間做審查、整合和收尾。

我覺得這對台灣公司很有參考價值。很多新創資源有限，最缺的不是想法，而是驗證速度。如果一個團隊能用 AI 在 1 天內做出 3 個版本，和只能做 1 個版本，決策品質通常會差很多。

但別忘了，真正值錢的還是判斷力。工具會變。流程會變。可是一個團隊能不能看出哪個原型只是表面好看，哪個真的能上線，這才是核心競爭力。

你可以把 vibe coding 想成一種新的前期工作法。它不是終點。它比較像是把「想法」變成「可討論的東西」的加速器。這件事對教育、創業、內部工具開發，都很有用。

接下來會怎麼走

我的判斷很直接。接下來 12 到 24 個月，會有更多人不是先學語法，而是先學怎麼描述需求、怎麼驗證輸出、怎麼抓 bug。也就是說，會寫 code 仍然重要，但「會跟 AI 合作」會變成基本技能。

如果你是開發者，現在就可以做一件事：拿一個小專案試 vibe coding。限制自己只做原型，不碰核心系統。看 AI 哪裡幫得上忙，哪裡開始亂來。這比空談 AI 影響實際多了。

如果你是主管或老師，問題也很簡單：你有沒有教團隊怎麼驗證 AI 產物？如果沒有，那你只是把產能外包給模型，風險還是留在自己身上。

說到底，vibe coding 改變的不是「誰能碰電腦」。它改變的是「誰能把想法變成第一版」。而第一版，常常就是整個專案最難跨過去的一步。

所以我的建議很明白：先用它做原型，再用人腦做審查。別把 AI 當終點，把它當草稿機。這樣最實際，也最不容易翻車。