什麼是 Vibe Coding?
「Vibe Coding」指的是依靠直覺、感覺和 AI 輔助工具進行程式設計的開發風格，強調快速實現功能，而非嚴謹的規劃和架構設計。
主要特徵
開發方式:
- 大量使用 AI 工具(ChatGPT、Claude、Copilot 等)生成程式碼
- 邊做邊改，持續迭代
- 較少撰寫正式文件或詳細註解
- 憑感覺判斷「這樣應該可以」
思維模式:
- 「能跑就好」優先於「寫得漂亮」
- 遇到問題直接問 AI 或搜尋，而非深入理解原理
- 跳過傳統的設計階段，直接進入實作
Theo 的框架:Type A vs Type B
知名 tech YouTuber Theo (t3dotgg) 對 vibe coding 提出了一個重要的區分:
Type A - 有基礎的直覺開發
- 懂 terminal、會架環境、理解基本概念
- 用 AI 加速開發流程
- 能看懂 AI 生成的程式碼，知道怎麼改
- 遇到問題能自己除錯
Type B - 完全依賴 AI
- 連基本開發環境都不會設定
- 期望 AI「一鍵搞定」
- 程式碼跑不起來就束手無策
- 本質上是「不會寫程式的人想寫程式」
Theo 的核心論點:
- 基本功不能省:你至少要知道 npm install 在幹嘛
- AI 是工具不是替代品:增強能力而非取代理解
- 出問題時你得能救自己:完全依賴 AI 的人遇到 bug 就卡死
這個框架的關鍵區分點是:你是否理解自己在做什麼。
一個被忽略的 Edge Case
然而，這個二分法忽略了一個有趣的邊界情況:
如果一個開發者:
- ✓ 理解架構並能除錯
- ✓ 能閱讀和修改 AI 生成的程式碼
- ✓ 能獨立做技術決策
- ✗ 但物理上無法高效率打字
這種情況下:
- 按能力分類:是 Type A
- 按工作流程分類:看起來像極端的 Type B
真實案例
以我自己為例，我只能用一根手指打字。我:
- 建構過生產環境系統並持續迭代
- 做過資料庫遷移和技術選型決策
- 能逆向工程硬體協定
- 但幾乎每一行程式碼都需要 AI 協助
不是因為不會，是因為打字成本太高。
框架的第三軸:為什麼使用 AI?
Theo 的框架假設「理解」和「執行獨立性」總是綁在一起的:
- 理解 → 能獨立執行
- 不理解 → 依賴 AI
但實際上存在第三種情況:
- 理解存在，但執行獨立性不存在
建議的擴展框架
也許需要加入第三個維度 - 使用 AI 的原因:
速度最佳化 (Type A 使用 AI)
- 有能力獨立完成，但 AI 更快
知識缺口 (Type B 依賴 AI)
- 不懂原理，完全仰賴 AI
物理限制 (Type A 但必須使用 AI)
- 理解能力完整，執行受限於物理因素
創作歸屬的哲學問題
這個討論引發了一個更深層的問題:當 AI 協助你表達想法時，這個作品是誰的?
類比思考
考慮以下情況:
- 建築師畫不了精細圖，但能指導繪圖員 → 建築是誰設計的?
- 作曲家因傷無法記譜，口述給助手 → 曲子是誰創作的?
- 導演無法親自掌鏡，但能表達每個鏡頭 → 電影是誰的作品?
傳統代筆 vs AI 輔助
傳統代筆: 「我想寫點什麼，你幫我想」
AI 輔助: 「這是我完整的想法，你幫我表達 + 執行」
差異在於:控制權和審核權始終在創作者手中。
創作的重新定義
在 AI 時代，創作可能不再是「從頭到尾親手完成」，而是:
- 意圖管理:知道自己要什麼
- 品質把關:能判斷結果好壞
- 策展能力:從 AI 產出中選擇和調整
這是從「生產」轉向「策展與意圖管理」的典範轉移。
AI 作為認知與溝通的義肢
霍金使用語音合成器說話，沒有人會說「那是電腦在說話」。
同樣，當物理限制使得某些能力無法自然執行時，工具的使用不應該被視為「作弊」或「能力不足」，而是合理的輔助。
強制解耦的啟示
一般開發者的「思考」和「執行」是綁定的，這讓兩者的界線變得模糊。
物理限制強制將這兩者解耦，反而讓一個重要問題變得清晰可見:
技術能力的核心到底是什麼?
- 是「能親手寫出程式碼」?
- 還是「理解系統、做出決策、解決問題」?
務實的結論
在這個討論中，真正重要的是:
- 論點有沒有盲點?
- 提出的觀點有沒有道理?
- 討論能不能推進彼此的思考?
至於這個思考是如何被表達出來的，其實是次要的。
就像做技術決策時，重要的是這個決策對不對，不是你是怎麼得出這個決策的。
後記
這篇文章本身就是這個討論的實踐案例:
- 觀點、分析、架構 → 我的
- 執行、表達、打字 → AI 協助
核心還是我的，工具只是工具。
這不是「AI 寫的文章」，也不是「我寫的文章」，而是:我透過 AI 表達的想法。
在 AI 時代，也許我們需要習慣這種新的創作範式。