Vibe Coding 是什麼？2026 為什麼人人都在談
Vibe Coding 是什麼？簡單說，Vibe Coding 是一種以自然語言驅動、讓 AI 代寫大部分程式碼的開發新典範。本文從 Andrej Karpathy 的倡議切入，帶你徹底搞懂 Vibe Coding 是什麼、它與傳統開發的差異，並完整比較 5 大主流 Vibe Coding 工具。
如果你最近在科技圈滑 X、刷 YouTube、聽 podcast，應該已經被「vibe coding」這個詞洗過好幾輪。有人說它是革命、有人說它是泡沫、有人說工程師要失業了、有人說這只是另一個 hype cycle。老實說，這些說法都對，也都不完全對。
這篇文章想把 vibe coding 講清楚：它從哪來、跟傳統 coding 差在哪、5 個主流工具怎麼選、工程師到底會不會被取代、新手該怎麼學。不販賣焦慮，也不誇張說「徹底改變世界」，給你一個能拿來做決策的版本。
一、Vibe Coding 是什麼？1 段話搞懂
Vibe Coding 是什麼？老實說，就是「用嘴巴寫 code」。
這個詞是 Andrej Karpathy（OpenAI 前研究員、特斯拉 AI 前主管、現為獨立教育者）在 2025 年 2 月於 X 上提出的。他的原話大致是：
“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It’s possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good.”
翻譯成人話就是：「有一種新的寫 code 方式，我叫它 vibe coding。你就完全交給感覺、擁抱指數成長、忘記 code 本身的存在。這之所以可能，是因為 LLM（像 Cursor Composer 配 Sonnet）已經強到一個程度了。」
Karpathy 在那則貼文裡還補了一句很經典：他想要做一個「能用 voice 加 todo」的 app，就直接跟 Cursor 講「給我寫一個 voice 控制的 todo app」，然後就 ship 了。整個過程他幾乎沒看幾行 code，但東西就 work 了。
重點來了：vibe coding 不是「不寫 code」。Code 還是被寫出來、還是被 compile、還是被 ship，只是「寫」這個動作從工程師的手指轉到了 AI。工程師的角色從「coder」變成「指揮官」——你用自然語言描述要什麼，AI 把它翻譯成 code，你 review、修改、繼續迭代。
跟「no code」差在哪？no code 是用拖拉式 UI 在預設好的元件裡組裝，受限於工具支援的功能；vibe coding 是用 LLM 生成「真實的 code」，理論上 LLM 能做的事 vibe coding 都能做。差別在抽象層級：no code 是樂高，vibe coding 是請一個會講話的工人幫你蓋房子。
這個典範轉變比 GitHub Copilot 還大。Copilot 是「補全」，你還在主導；vibe coding 是「交付」，AI 在主導，你在 review。換句話說，工程師的注意力從「下一行 code 要怎麼寫」轉移到「整個系統下一步該怎麼走」。
還有一個容易被誤解的點：vibe coding 不等於「亂寫」。它是「用更高的抽象層級寫」。你還是要有需求、有架構、有品味，只是不用親手把每個分號打出來。這跟「不思考」是兩回事，反而對「思考品質」的要求變高了，因為你下的每個指令都會被 AI 放大成幾百行 code。
二、Vibe Coding 的歷史脈絡：從 Copilot 到 Devin
這個轉變不是一夜之間發生的。它有一條清楚的演化線。
2021 年：GitHub Copilot 推出。 這是 AI coding 的第一波浪潮。Copilot 用 OpenAI Codex 模型做「程式碼自動補全」，你寫一半，它幫你接完。工程師的工作流程基本沒變，只是打字速度變快。當時 GitHub 的研究指出，使用 Copilot 的開發者完成任務速度快 55%。
2022 年：ChatGPT 爆紅。 工程師開始把 code 貼進 ChatGPT 問問題、debug、生成 snippet。這個階段「prompt engineering」這個詞紅起來，大家在比誰會寫 prompt。但 ChatGPT 還不能直接動你的 codebase，是「對話式工具」。
2023 年：Cursor、Continue 等 AI IDE 出現。 AI 開始進到 IDE 裡，能讀取整個 codebase 上下文、能跨檔案編輯、能執行命令。這時候開發者已經能說「幫我把這個 component 拆成兩個檔案」，AI 真的會去動檔案。
2024 年：Cursor Composer、Claude Code、Devin、Replit Agent 登場。 這是「Agent 時代」的開始。AI 不只是被動補全，而是能主動規劃多步驟任務、寫測試、跑測試、看錯誤、修錯誤。Devin 號稱「第一個 AI 軟體工程師」（雖然爭議很大）。這時候 prompt engineering 開始過時，因為你不需要寫很長的 prompt，AI 自己會問 clarifying questions。
2025 年：Karpathy 提出 vibe coding。 不是因為技術突然變了，而是因為這時候工具好到一個程度——Cursor Composer 配 Claude Sonnet 已經能讓你「完全不看 code 也能 ship」。Karpathy 用一個詞把這個體驗命名了。
2026 年（現在）：vibe coding 普及化。 Bolt.new、v0、Lovable 把這個體驗推到瀏覽器，連 IDE 都不用裝。同時，「review AI 輸出」變成工程師的核心技能。
每個階段「人 vs AI」的分工都在轉移：
| 階段 | 人做什麼 | AI 做什麼 |
|---|---|---|
| 2021 Copilot | 主導、設計、寫架構 | 補全幾行 code |
| 2023 Cursor | 指示、review、修細節 | 跨檔案編輯、refactor |
| 2024 Agent | 定義任務、check 結果 | 規劃、執行、自我修正 |
| 2025 Vibe Coding | 描述「感覺」、給方向 | 規劃 + 執行 + 寫測試 + ship |
「prompt engineering」這個技能在 2024 年還是熱詞，2025 年就被「context engineering」取代。重點不再是「怎麼寫 prompt 哄 AI」，而是「怎麼給 AI 對的 context（codebase 結構、設計文檔、API 規格）讓它自己搞定」。一個寫得好的 CLAUDE.md または .cursorrules 檔案，比一段超精細的 prompt 還重要。
另一個值得注意的趨勢是「模型差異開始被工具抹平」。2024 年大家還在比 Claude 和 GPT 誰寫 code 強，2025 年開始 Cursor、Windsurf、Aider 這類工具能讓你自由切換模型，差異從「模型本身」轉移到「工具的調度與 context 管理」。所以選工具有時候比選模型更重要。
三、Vibe Coding vs 傳統 Coding 對比
不是「取代」而是「補充」。但兩者的工作模式差別大到必須拆開來看。
對比表 1：開發體驗
| 次元 | 傳統 Coding | Vibe Coding |
|---|---|---|
| 学習曲線 | 數年（語法、工具、框架） | 數天（學會描述需求 + review） |
| 初次 ship MVP 時間 | 數週至數月 | 數小時至數天 |
| Debug 方式 | 自己讀錯誤、查文件、stack overflow | 把錯誤丟給 AI、AI 修 |
| 主要技能 | 寫 code、讀文件、系統設計 | 描述需求、review diff、系統設計 |
| 適合的人 | CS 背景、想做 production system | 創業者、產品經理、學習者 |
對比表 2：產品品質
| 次元 | 傳統 Coding | Vibe Coding |
|---|---|---|
| 保守性 | 高（自己寫的自己懂） | 中（不一定看得懂 AI 寫的） |
| 效能 | 可調優 | 取決於 AI 選擇 |
| 安全性 | 看工程師功力 | 風險高（AI 會留漏洞） |
| 團隊協作 | 成熟工具鏈（PR、code review） | 還在演化中 |
| 長期 cost | 前期高、後期穩定 | 前期低、後期維護成本高 |
對比表 3：什麼專案適合
| 專案類型 | 傳統 Coding | Vibe Coding |
|---|---|---|
| MVP / Prototype | 慢 | 適合 |
| Landing Page | 過度設計 | 適合 |
| 個人工具 / 自動化 | 沒必要 | 適合 |
| 醫療、金融、合規 | 必要 | 不適合 |
| 大型 codebase 維護 | 必要 | 補充用 |
| 教學、學習 | 慢但扎實 | 快但容易卡 |
關鍵觀念：兩者不是對立的。一個健康的工程師工作流程是「vibe coding 做 prototype、傳統 coding 做 production」。Karpathy 自己也說，他用 vibe coding 做「週末玩具」，但他不會用 vibe coding 寫 production system。
真實案例：2025 年下半年，X 上有個叫 Pieter Levels 的獨立開發者（他自己已經是老 founder 了）用 Cursor + Claude Sonnet 在一個週末 ship 了一個飛行模擬遊戲 fly.pieter.com，賺了超過 100 萬美金的廣告收入。整個專案他幾乎是「vibe」出來的，但他本人是有 10 年以上經驗的工程師，知道什麼東西不能讓 AI 亂搞。這個案例同時證明了 vibe coding 的威力，也提醒了「review 能力」才是關鍵。
新手用 vibe coding 也有成功案例。X 上有不少「我從來沒寫過 code、用 Bolt.new 一個週末 ship 了一個 SaaS」的故事。這些 MVP 通常能驗證想法、能拿到第一批用戶，但要規模化、要可維護，多半得重寫。
老實說，這個現象有一個很微妙的反差：vibe coding 讓「ship 第一版」變超快，但「養大第二版」沒變快，甚至更慢——因為你前期累積的技術債、模糊的架構決策，都會在後期反噬。所以判斷該不該 vibe，第一個問題不是「這個能不能 vibe 寫出來」，而是「這個東西如果成功了、半年後我能不能維護它」。
四、5 大 Vibe Coding 工具完整解析
市場上 vibe coding 工具一堆，這 5 個是 2026 年的主流。每個定位不同，選錯了會浪費時間。
1. Cursor（IDE-based）
定位：給「會 review code」的工程師用的 vibe coding 工具。 核心功能：Cursor Composer 能跨檔案 edit、有 codebase index、支援 Claude Sonnet / GPT / Gemini 多模型切換。 強項：精準 edit 既有 codebase、能讀懂大型 repo 結構、Tab 補全極快。 適合：已經有 codebase 想加速開發的工程師、做 production 系統。 價格：Pro 方案約 USD 20/月，Business 方案 USD 40/月（2026 年初）。 限制：學習曲線比 Bolt 高，要會用 IDE。新手會覺得介面太工程師。
典型用例：你有一個 Next.js 專案，想加一個 dashboard 頁面。你開 Composer，描述「加一個 /dashboard 頁面，顯示用戶的訂閱狀態，從 Stripe API 拉資料」，Cursor 會列出要動哪幾個檔案、寫 code、跑 lint，你 review 後 accept。
內鏈建議：https://hogantechs.com/cursor-ai-editor-200b-valuation-analysis/
2. Replit Agent
定位：browser-based、教學友好的全端 vibe coding 工具。 核心功能：Replit 把 IDE、deploy、資料庫、auth 全部塞進瀏覽器，Agent 能幫你從零生 app 並一鍵 deploy。 強項：不用裝任何東西、適合教學、適合學生、適合 hackathon。 適合：完全沒寫過 code 的人、教學情境、快速 demo。 價格：Core 方案約 USD 20/月，學生有優惠。 限制：複雜專案會卡、效能不如本地 IDE。
典型用例：你是設計師，想做一個能讓客戶上傳檔案、自動發 email 通知的工具。打開 Replit、跟 Agent 講需求、它幫你生 code + 接資料庫 + deploy，10 分鐘後就有一個能用的網址。
3. Bolt.new
定位：純 prompt 變 app、最低門檻的 vibe coding 工具。 核心功能：StackBlitz 出的，在瀏覽器裡跑 WebContainer，純 prompt 就能生 full-stack app。 強項：上手最快、生成速度快、出 landing page 特別猛。 適合：landing page、小工具、demo、產品 mockup。 價格：免費額度有限，Pro 方案約 USD 20/月起。 限制：複雜邏輯容易迷路、不適合需要長期維護的專案。
典型用例：你週六晚上突然想驗證一個「AI 算命網站」的想法。打開 Bolt，輸入「做一個輸入生日就用 OpenAI 算命的網站，深色風格、有訂閱表單」，2 分鐘後就有一個能用的 prototype 可以丟給朋友測。
4. v0（by Vercel）
定位：UI 生成的專家。 核心功能：Vercel 出品，用自然語言 + 截圖生成 React + shadcn/ui 元件，跟 Vercel 部署生態整合。 強項：UI 品質高、生成的 code 乾淨、能直接複製到 Next.js 專案。 適合：需要快速做 UI 元件、產品 designer、Vercel 用戶。 價格：Premium 約 USD 20/月，Team 方案更高。 限制：focus 在 UI / 前端，後端邏輯弱。
典型用例：你要做一個 SaaS 的 pricing page。打開 v0，描述「三欄式 pricing，深色背景、漸層 CTA、support FAQ accordion」，它生出 React 元件，你複製進 Next.js 專案就能用。比起自己刻 Tailwind 快 10 倍。
5. Lovable
定位：全端 SaaS prototype 生成器。 核心功能：歐洲團隊（Anton Osika 創立）做的，主打「描述一個 SaaS、它幫你 ship 一個 SaaS」，Supabase 整合做後端。 強項：full-stack、含 auth + database、UI 品質中上。 適合：想驗證 SaaS 點子、不會寫 code 的創業者、early-stage MVP。 價格：免費有限額度，Pro 從 USD 25/月起。 限制：客製化深度有限、複雜邏輯仍需手動介入、AI 改錯時可能整個 break。
典型用例：你是 PM、想驗證一個「健身房 booking」SaaS 概念。在 Lovable 描述需求，它生出登入註冊、預約日曆、付費、管理後台，半天內可以拿給目標用戶測試。
工具選擇速查
- 已經會寫 code、想加速：カーソル
- 完全新手、要教學或一鍵 deploy：Replit Agent
- 想最快做出 landing page 或 demo：Bolt.new
- 要做 React UI 元件：v0
- 想做 full-stack SaaS prototype：愛らしい
也別忘了 Claude Code 這條路線——終端機原生的 agent，https://hogantechs.com/claude-code-engineer-tutorial-2026/——它走的是另一條路（CLI + 自家模型），但精神跟 vibe coding 一致。
五、適合 / 不適合 Vibe Coding 的場景
不是所有專案都該 vibe coding。先看你的專案落在哪裡。
適合 Vibe Coding 的場景
MVP / Prototype。 目的是驗證想法、不是長期維護。code 醜沒關係，能跑、能展示就好。Vibe coding 在這裡威力最大，原本要 2 週的東西 1 天搞定。
單檔 script、自動化任務。 你要寫一個「每天爬某網站價格、變動就發 email」的小工具，根本不用搞 production-grade 架構。讓 AI 寫一個 Python script、跑起來就好。
Landing Page、行銷頁。 視覺重於功能、需求清楚、生命週期短。Bolt 或 v0 都能 10 分鐘搞定。
個人工具。 只有你自己用、沒有安全顧慮、爛了重做就好。例如你想要一個「把 Notion 筆記自動轉成 markdown」的 CLI，vibe coding 半小時。
學習特定概念。 想看 useEffect 怎麼用？讓 AI 寫個範例你看。但前提是你要看得懂、能問問題。
不適合 Vibe Coding 的場景
高效能要求。 比如低延遲交易系統、大規模分散式系統。AI 寫的 code 通常不會做底層調優、會用「能跑就好」的方案。
安全敏感系統。 認證授權、加密、支付。AI 會用看起來合理但有漏洞的 pattern（例如把 secret 寫死、SQL injection 沒擋）。即使是資深工程師都得謹慎 review，更何況新手 vibe coder。
合規行業：醫療、金融、法律。 你要符合 HIPAA、PCI-DSS、SOC 2，每一行 code 都可能被審計。AI 生出來的 code 沒有 trace、沒有 review record，不能上。
跨團隊大型 codebase。 10 個工程師共同維護的 500k LOC 系統，你 vibe 一個 feature 進去，其他人看不懂、規範對不上、CI/CD 過不了。
需要長期維護 5 年以上的系統。 你今天 vibe 的 code 半年後 AI 模型升級了、原作者離職了，沒人看得懂。
決策樹
問自己 3 個問題：
- 這個專案會跑超過 1 年嗎？
- 出錯會死人、會被告、會被罰款嗎？
- 會有其他工程師需要維護嗎？
如果答案都是「否」，vibe coding 起飛。如果有任何一個「是」，傳統 coding 為主、vibe coding 輔助。
六、工程師會被取代嗎？三個層面拆解
這是大家最關心的問題。先說結論：短期沒事、中期重新洗牌、長期角色重新定義。然後拆開講。
短期（6-18 個月）
工具的 user 變多了，但工程師需求沒減少，反而某些位置更搶手。
GitHub 在 2022 年的研究（”Quantifying GitHub Copilot’s Impact on Developer Productivity”）指出，使用 Copilot 的開發者完成同樣任務速度快 55%。這個數字到 2025-2026 年用上 Cursor + Claude Sonnet 的工程師體感更高，有些任務快 3-5 倍。
但「快」不等於「不需要」。當每個工程師產能變 3 倍，公司的選擇是：(a) 砍人省錢 (b) 同樣人力做更多。Stack Overflow 2024 Developer Survey 顯示，大部分公司選 (b)。原因簡單——軟體需求一直被供給壓抑，能做更多功能、誰會嫌多。
短期內最危險的不是「工程師被 AI 取代」，是「不會用 AI 的工程師被會用 AI 的工程師取代」。這個分水嶺在 2025 年特別明顯。
中期（2-5 年）
Junior 需求下降、senior 變得更值錢。
Vibe coding 工具最擅長的是「重複性 CRUD」「樣板 code」「常見 pattern」。這正好是 junior 工程師主要的工作。當一個 senior 配 Cursor 就能做完 3 個 junior 的工作，公司很自然會減少 junior 招募。
這已經在發生。2025 年下半年起，矽谷大廠的 new grad 職缺數量明顯下降（雖然部分是經濟因素）、實習轉正比例緊縮。Y Combinator 在 2025 年也公開講過：「我們投的早期公司現在 2-3 人就能做以前 10 人的事」。
但 senior 工程師反而更搶手。原因是：vibe coding 出來的 code 還是要 review、架構還是要設計、效能還是要調、bug 還是要 debug。這些都是 senior 工作。AI 把「打字」這部分解放了，但「判斷」這部分還是人的。
長期（5 年以上）
軟體工程師職位重新定義。
未來的工程師不是「寫 code 的人」，是「定義系統 + review AI 輸出 + 負責結果的人」。職稱可能還叫 software engineer，但日常工作會接近現在的 architect / tech lead。
類比：1980 年代會「打字」是辦公室技能，現在沒人把「打字」寫進履歷。Coding 的命運可能類似——還是會有，但不再是核心區別。核心區別變成「系統思維」「debug 能力」「對用戶體驗的判斷」「能不能跟非工程師溝通」。
也別恐慌。「軟體工程師會消失」這個預測從 1960 年代 COBOL、1990 年代 4GL、2010 年代 low-code 都有人講過，每次都沒成真。AI 這次力道更大，但歷史教訓是：抽象層級會上升、總需求會上升、新的職位會出現。
平衡觀點：你會失業的可能性遠低於你「不適應」的可能性。
七、新手 vs 資深工程師的不同建議
vibe coding 對不同階段的人意義不一樣。給錯建議會害人。
給新手的建議
不要跳過基礎。 如果你連「變數、迴圈、function、陣列、什麼是 JSON」都還沒搞懂，就一頭栽進 vibe coding，會發生一件事：app 跑不動，你不知道為什麼，你問 AI、AI 改了、還是不動、你不知道為什麼。卡 1 週、放棄、覺得自己沒天分。
正確順序：先學基礎（資料結構、控制流、debug 邏輯、Git）、再用 vibe coding 加速。基礎不用學到精，但要能看懂 AI 寫的 code 在做什麼。
AI 工具用來「加速學習」而不是「跳過學習」。 寫 code 卡住問 AI、看不懂的概念請 AI 解釋、寫完讓 AI review 你的 code 給建議。這樣 AI 是你的家教。但「請 AI 幫你寫完所有作業」會讓你變成「能描述需求但不會寫」，這在求職和實作上都吃虧。
重點學「閱讀 code」。 你的職涯前期可能會花更多時間在「讀別人的 / AI 的 code」而不是「自己寫」。練習打開 GitHub 上的開源專案，挑一個小函式，逐行讀懂在做什麼。
給資深工程師的建議
Vibe coding 用來做 mock / prototype / 一次性任務。 你要驗證一個 idea、要做 client 的 demo、要寫一個只用一次的 migration script——這些用 vibe coding，可以省幾倍時間。
正式產品還是 traditional 為主、vibe coding 輔助。 你的核心 codebase、你要長期維護的系統，還是要自己掌握架構、自己 design、用 AI 加速「打字」這部分，但每一個 diff 都要 review 到位。
把 vibe coding 當成「資深 junior」。 它能做事、但不能不 review。你不會把一個 junior 寫的 PR 不看就 merge，AI 寫的也一樣。
分水嶺：你會 review code 嗎？
這是新手和資深的真正分界。會 review，vibe coding 就是你的超能力。不會 review，vibe coding 就是你的地雷。
學什麼是 AI 拿不走的？
- 系統思維：拆解問題、權衡取捨、決定不做什麼。
- Debug 能力：當 AI 也卡住的時候，你能不能下去看 stack trace、用 binary search 找問題。
- 用戶體驗判斷：「這個按鈕該放哪」「這個流程合不合理」AI 還做不好。
- 跨領域溝通：跟 PM、設計師、客戶聊出真正的需求。
- 負責結果：當系統爛了，最後拍板的還是人。
這些都不是「寫 code」，這些是「工程師」。
補充一個觀察：那些把職涯從「寫 code 的人」轉成「定義系統的人」的工程師，在這波 AI 浪潮裡反而最受益。因為他們本來就在做 AI 還做不好的事——抽象、權衡、溝通、判斷。他們現在多了一個生產力加速器，等於原本的判斷品質乘上 3-5 倍輸出速度。這也是為什麼 staff/principal 層級的工程師在 2025-2026 年薪水反而往上跳。
八、Vibe Coding 的 3 個常見坑
每個 vibe coder 都會踩到的坑，先看過會少痛一次。
坑 1：不 review 就 ship → 安全漏洞。 AI 很愛把 API key、database 連線字串寫死在 code 裡、很愛用 eval() 之類的危險函式、很愛跳過輸入驗證。你不 review 直接 ship，第一個 user 就可能把你的資料庫 dump 走。建議：每次 AI 改動，特別注意 .env、權限檢查、SQL 查詢、外部 API 呼叫。
坑 2：不寫測試 → 改一個地方壞 10 個。 Vibe coding 前期很爽，每個 prompt 都 work。但專案大到一定程度，AI 改 A 檔案壞 B 檔案、改 B 檔案壞 C 檔案。沒測試的話你根本不知道哪裡壞了。建議：早期就讓 AI 寫測試（”請把這個 function 補 unit test”），然後每次改動跑一次測試。
坑 3：不懂底層 → debug 卡 1 週。 AI 會的 pattern 是有限的。當你碰到它沒見過的 bug、它會開始亂改、把 working 的 code 也改壞。你不懂底層的話，會跟 AI 一起在錯誤裡打轉。建議：碰到 AI 第 3 次還沒修好的 bug，停下來、自己讀 stack trace、自己 google、自己想。AI 不是萬能。
九、6 個 Vibe Coding 實戰建議
如果你決定要認真用 vibe coding，這 6 個建議能讓你少走彎路。
1. 給 AI 明確的 context。 在 repo 根目錄寫一個 README.md または CLAUDE.md，列出技術棧、檔案結構、coding 規範、不能改的地方。Cursor、Claude Code 都會自動讀。這是現在最重要的「context engineering」技能。
2. 分段 prompt，不要一次塞太多。 不要說「做一個完整的 SaaS、有 auth、有 dashboard、有 billing」。改成「先做 auth、用 Supabase」→ review → 「再加 dashboard」→ review → 「再加 billing」。每段都小、每段都驗證。
3. 學會看 diff 是核心能力。 每次 AI 改完，認真看 diff。不只看「有沒有錯」，看「為什麼這樣寫」。Cursor、Claude Code、GitHub 的 PR 介面都能看 diff。看不懂的部分問 AI 解釋。
4. 用 git worktree 隔離 AI 改動。 進階技巧：用 git worktree add ../experiment 開一個並行分支讓 AI 亂搞，搞砸了就刪掉、main 分支不受影響。或者最低限度也要在 feature branch 上工作，不要直接動 main。
5. 寫測試讓 AI 自己 verify。 一個被低估的招式：讓 AI 在改 code 前先寫測試、改完跑測試、測試過了才算完成。Claude Code 在這方面特別擅長。
6. 不懂的部分要追問，不要直接 accept。 AI 寫出來的 code 你看不懂，不要按 accept。問它「為什麼用這個 library？」「這個 function 在做什麼？」「有沒有更簡單的寫法？」。這同時是學習、也是品質把關。
關於 Agent 工作流程的細節（包括 MCP 等協議），可以參考 https://hogantechs.com/what-is-mcp-model-context-protocol-engineer-guide/。
十、總結：vibe coding 不是答案，是選項
回到開頭那個問題：vibe coding 是什麼？它是 2025 年由 Karpathy 命名的一種新開發典範，把「寫 code」交給 AI、把「定義 + review」留給人。
它不會取代工程師，但會重新分配工作。會用的人變超人、不會用的人會被市場淘汰。它也不會讓「不會 code 的人變成軟體開發者」這麼簡單——你還是得會 review、會 debug、會判斷。
對新手：把基礎打好、用 AI 加速學習、不要跳過理解。對資深工程師：用 vibe coding 做 prototype、用傳統 coding 做 production、把節省的時間用來做更有價值的判斷。對所有人：擁抱這個工具，但保持懷疑。
工具是中性的。會不會把它變成超能力，看你。
よくある質問
Q1：Vibe Coding 跟 No Code 一樣嗎？
不一樣。No code 是用拖拉式 UI 在預設好的元件裡組裝（如 Bubble、Webflow），受限於工具支援的功能。Vibe coding 是用 LLM 生成真實的 code，理論上 LLM 能做的事 vibe coding 都能做，更彈性、更接近傳統開發。差別在抽象層級：no code 是樂高，vibe coding 是請一個會講話的工人幫你蓋房子。
Q2：新手該從 Vibe Coding 開始學嗎？
不建議直接從 vibe coding 開始。先學基礎（變數、迴圈、function、debug 邏輯、Git），再用 vibe coding 加速。不然你會卡在 AI 改不好的時候不知道怎麼辦。建議順序：先用 freeCodeCamp 或 CS50 把基礎打 1-3 個月、然後開始用 Cursor 或 Replit Agent 配 vibe coding 練習。
Q3：Vibe Coding 寫出來的 code 能上 production 嗎？
短答：能，但要 review。長答：MVP 和早期產品可以直接 ship，因為 user 不多、出錯成本低。但隨著規模長大、user 變多、營收進來，要逐步把核心模組「rewrite 成 production-grade」。資深工程師 review 過、補上測試、補上監控的 vibe coding code 完全可以上 production。新手沒 review 就 ship 的，會出事。
Q4：Karpathy 為什麼提出 Vibe Coding 這個詞？
Andrej Karpathy 在 2025 年 2 月於 X 上提出這個詞，當時他用 Cursor Composer 配 Claude Sonnet 寫了個 voice-controlled todo app，發現自己「完全沒看 code」就 ship 了。他想用一個詞描述「LLM 強到一個程度、你可以完全交給感覺寫 code」這種新體驗。這個詞迅速被矽谷採用、被引用、被誤用，現在已經是業界通用術語。
Q5：Vibe Coding 工具該選哪個？
看你是誰、要做什麼。已經會寫 code、想加速既有專案：Cursor。完全新手、要在瀏覽器一鍵 deploy：Replit Agent。想最快做出 landing page 或 demo：Bolt.new。要做 React UI 元件：v0。想做 full-stack SaaS prototype：Lovable。預算有限可以從免費額度試，每個工具都有 free tier。建議 1-2 週試 2-3 個工具、找最順手的。
参考資料
- Andrej Karpathy on X (vibe coding 原始貼文與後續討論)：https://x.com/karpathy
- Cursor 官方網站：https://cursor.com
- Replit 官方網站（含 Replit Agent）：https://replit.com
- Bolt.new 官方網站：https://bolt.new
- v0 by Vercel 官方網站：https://v0.dev
- Lovable 官方網站：https://lovable.dev
- GitHub Copilot Productivity Research (2022)：https://github.blog/2022-09-07-research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/
- Stack Overflow Developer Survey 2024：https://survey.stackoverflow.co/2024/
- Anthropic Claude Code 文件：https://docs.claude.com/en/docs/claude-code
- Y Combinator 對早期公司 AI 使用情況的公開分享：https://www.ycombinator.com
FAQPageスキーマ（JSON-LD草案）
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Vibe Coding 跟 No Code 一樣嗎？",
"acceptedAnswer": {
"@type": "Answer",
"text": "不一樣。No code 是用拖拉式 UI 在預設好的元件裡組裝（如 Bubble、Webflow），受限於工具支援的功能。Vibe coding 是用 LLM 生成真實的 code，理論上 LLM 能做的事 vibe coding 都能做，更彈性、更接近傳統開發。差別在抽象層級：no code 是樂高，vibe coding 是請一個會講話的工人幫你蓋房子。"
}
},
{
"@type": "Question",
"name": "新手該從 Vibe Coding 開始學嗎？",
"acceptedAnswer": {
"@type": "Answer",
"text": "不建議直接從 vibe coding 開始。先學基礎（變數、迴圈、function、debug 邏輯、Git），再用 vibe coding 加速。不然你會卡在 AI 改不好的時候不知道怎麼辦。建議順序：先用 freeCodeCamp 或 CS50 把基礎打 1-3 個月、然後開始用 Cursor 或 Replit Agent 配 vibe coding 練習。"
}
},
{
"@type": "Question",
"name": "Vibe Coding 寫出來的 code 能上 production 嗎？",
"acceptedAnswer": {
"@type": "Answer",
"text": "短答：能，但要 review。長答：MVP 和早期產品可以直接 ship，因為 user 不多、出錯成本低。但隨著規模長大、user 變多、營收進來，要逐步把核心模組 rewrite 成 production-grade。資深工程師 review 過、補上測試、補上監控的 vibe coding code 完全可以上 production。新手沒 review 就 ship 的，會出事。"
}
},
{
"@type": "Question",
"name": "Karpathy 為什麼提出 Vibe Coding 這個詞？",
"acceptedAnswer": {
"@type": "Answer",
"text": "Andrej Karpathy 在 2025 年 2 月於 X 上提出這個詞，當時他用 Cursor Composer 配 Claude Sonnet 寫了個 voice-controlled todo app，發現自己完全沒看 code 就 ship 了。他想用一個詞描述 LLM 強到一個程度、你可以完全交給感覺寫 code 這種新體驗。這個詞迅速被矽谷採用、被引用、被誤用，現在已經是業界通用術語。"
}
},
{
"@type": "Question",
"name": "Vibe Coding 工具該選哪個？",
"acceptedAnswer": {
"@type": "Answer",
"text": "看你是誰、要做什麼。已經會寫 code、想加速既有專案：Cursor。完全新手、要在瀏覽器一鍵 deploy：Replit Agent。想最快做出 landing page 或 demo：Bolt.new。要做 React UI 元件：v0。想做 full-stack SaaS prototype：Lovable。預算有限可以從免費額度試，每個工具都有 free tier。建議 1-2 週試 2-3 個工具、找最順手的。"
}
}
]
}
