正確的 Vibe Coding：AI 工具的好壞取決於使用它的人

「Vibe Coding」是 Collins 字典的 2025 年度詞彙。「AI Slop」也是。這兩者的差別，取決於鍵盤後面的那個人。

AI 改變寫程式方式的一年

2025 年初，Andrej Karpathy 描述了一種新的程式開發方式：「完全沉浸在氛圍中，擁抱指數級成長，忘記程式碼的存在。」

他稱之為 Vibe Coding。

幾個月內，這個詞爆紅了。Collins 字典把它選為 2025 年度詞彙。Y Combinator 報告說，2025 年冬季批次中有 25% 的專案，程式碼有 95% 是 AI 生成的。各大科技公司宣布，30-50% 的新程式碼來自 AI 助手。

但這裡有個常被埋沒在炒作中的不便真相：Merriam-Webster 和 Macquarie 字典為 2025 年選的是另一個詞——AI Slop，定義是「由生成式 AI 創造的低品質內容，常常包含錯誤」。

這兩個年度詞彙並不矛盾。它們是同一枚硬幣的兩面。

插圖顯示 AI 程式開發的兩條路：一條通向高品質產品，另一條通向 AI Slop — 相同的工具，截然不同的結果。差別在於操作的人。

問題不在 AI，在於我們怎麼用它

2025 年 Veracode 的研究發現，45% 的 AI 生成程式碼包含安全漏洞。AI 模型有 5-21% 的機率會幻覺出不存在的套件——攻擊者現在利用這點進行「slopsquatting」攻擊。

同時，METR 的嚴謹研究追蹤了經驗豐富的開發者，發現了一個反直覺的結果：使用 AI 工具的開發者，生產力比不用 AI 時下降了 19%。但這些開發者自己估計 AI 讓他們的生產力提升了 20%。

認知和現實之間差了 39 個百分點。

這不是在否定 AI 程式工具。這是對我們使用方式的警鐘。

產出 AI Slop 的團隊和交付生產級軟體的團隊，常常用的是同樣的工具。差別不在技術——在方法論。

AI 程式工具就只是工具

不管你叫它 Vibe Coding、AI Coding，還是 AI 輔助開發，根本的真理不變：這些是工具，工具需要稱職的操作員。

鏈鋸在木工大師手裡能做出傢俱。在外行手裡只會製造災難。

AI 程式工具會放大你帶進來的任何方法：

清晰的問題定義 → 聚焦、有用的程式碼
模糊的提示 → 通用、常常壞掉的實作
強烈的架構願景 → 連貫的系統
沒有技術判斷 → 剛好能編譯的義大利麵

重要的特質沒有改變：

你正在解決的明確痛點
知道「好」長什麼樣的產品開發專業
你拒絕妥協的品質標準
審查、測試、迭代的紀律

沒有這些，你不是在做產品。你只是在產生垃圾。

我們在生產環境使用 AI 程式開發學到的事

JidouAI 團隊大量使用 AI 程式工具。我們比較過不同的工具，實驗過各種工作流程，也踩過不少雷。

以下是我們的發現。

Code Review 變成瓶頸

當開發者用 AI 輔助更快地產出程式碼時，新問題浮現了：Code Review 變成了瓶頸。

要審查的程式碼量爆增。Reviewer 跟不上。而且 AI 生成的程式碼有個特殊挑戰——它常常看起來正確，但包含需要仔細檢查才能發現的微妙問題。

我們的演進

我們經歷了幾個階段：

第一階段：興奮期 每個人各自使用 AI 工具。產出很快。技術債不斷累積。

第二階段：問題浮現 Code Review 積壓。模式不一致。在 Review 時看起來對的 Bug 跑到了生產環境。

第三階段：流程改善 我們引入 AI 輔助的 Code Review 工具。建立 Spec 驅動開發實踐。標準化適合我們工作流程的工具。

第四階段：可持續的速度 AI 程式開發成為流程中不可或缺的一環——但是在維持品質的結構化框架內。

關鍵洞察

突破點不是找到「最好的」AI 工具。而是建立 Spec 驅動開發作為基礎。

在任何 AI 寫下一行程式碼之前，我們已經有：

完整的規格文件
清楚的驗收標準
定義好的架構限制
測試需求

人類控制什麼和為什麼。AI 負責更多的怎麼做——實作、單元測試、樣板程式碼。但人類審查一切。

結果：我們從概念到內部 POC 只用了 2 天，到上線只用了 30 天——而且沒有犧牲程式碼品質。

Spec 驅動開發流程圖：Spec → 計畫 → 實作 → Review → 部署 — Spec 驅動開發：人類定義意圖，AI 加速實作

AI 程式工具比較：真正重要的是什麼

市場很擁擠：Cursor、Claude Code、GitHub Copilot、Windsurf、Google 的 Antigravity、OpenAI Codex。每週都有新的比較和評測出現。

經過廣泛評估後，以下是我們對真正重要的事的看法。

主要玩家

工具	方法	最適合
Cursor	深度 AI 整合的 VS Code 分支	想要 GUI + 多檔案編輯的開發者
Claude Code	Terminal、VS Code、網頁版皆支援	彈性開發者、複雜程式碼庫
GitHub Copilot	擴充套件式、廣泛 IDE 支援	已在 GitHub 生態系的團隊
Windsurf	VS Code 分支、代理導向	初學者、偏好乾淨 UI
Antigravity	VS Code 分支、支援 Gemini + Anthropic 模型、代理導向	Google 生態系使用者、需要多模型彈性
Codex	API 導向、企業級	大規模自動化

我們的選擇：Claude Code + 客製 Plugin

比較這些工具後，我們團隊一致發現，Claude Code 搭配專門的 Plugin，在我們的工作流程中提供了速度和品質的最佳平衡。

關鍵的 Plugin：

feature-dev：結構化的功能開發工作流程
frontend-design：具設計系統意識的 UI/元件生成
code-refactor（我們自己開發的 Plugin）：帶品質檢查的系統性重構

為什麼特別是 Claude Code？

Terminal 優先的方法強迫你有意識地行動。你不能無腦地接受自動完成建議——你是在對話，討論你想要建造什麼。搭配編碼了團隊最佳實踐的 Plugin，它變成真正的戰力倍增器，而不是技術債的來源。

話說回來，「最好的」工具完全取決於你團隊的工作流程、程式碼庫和偏好。工具本身遠不如你包裹在它周圍的方法論重要。

Spec 驅動開發的興起

如果說 Vibe Coding 是 2024 年的興奮，Spec 驅動開發就是 2025 年的修正。

GitHub 發布了 Spec Kit。AWS 推出帶有明確「Spec Mode」的 Kiro。JetBrains、Anthropic 和其他公司都在強調同樣的洞察：規格幫助 AI 就像幫助人類一樣。

業界正在浮現的模式：

Vibe Coding 用於快速原型和探索
Spec 驅動開發用於生產程式碼

如同 OpenAI 的 Sean Grove 所說：「最會溝通的人將成為未來最有價值的程式設計師。新的稀缺技能是撰寫完整捕捉你意圖的規格。」

諷刺的是，這不是新東西。這是回歸軟體工程基本功——實作前先設計——只是適應了代理式 AI 時代。

Vibe Coding（提示→程式碼→祈禱）與 Spec 驅動開發（規格→計畫→實作→驗證）的比較圖 — Vibe Coding vs Spec 驅動開發：結構讓速度成為可能

閉環：用 Heimin 建造 Heimin

這裡開始有趣了。

Heimin 是一個任務管理工具。我們用 AI 程式工作流程建造 Heimin。而我們管理 Heimin 開發任務的地方是... Heimin。

這創造了我們所謂的閉環開發循環：

規格存在於 Heimin 作為詳細的任務描述——人類撰寫 Spec 草稿
Claude（聊天）透過 MCP 整合讀取任務 來理解上下文，透過 AI 協作優化 Spec
Claude Code 透過 MCP 讀取任務並執行 基於精煉後規格的實作
進度更新自動流回 Heimin，完整的文件留存
審查和迭代在同一個系統內進行

我們正在建造的工具，就是我們用來建造它的工具。

這不只是吃自己的狗糧（dogfooding）。這是產品管理和開發之間根本不同的關係。當你的 AI 程式助手可以直接存取你的任務管理系統，「該建什麼」和「建了什麼」之間的摩擦趨近於零。

MCP：缺失的環節

Model Context Protocol（MCP）讓這成為可能。它讓 Claude 和 Claude Code 可以：

直接拉取任務詳情和規格
不用手動複製就能理解專案上下文
隨著工作進展更新任務狀態
在開發 session 之間維持連續性

結果是 AI 不只寫程式碼——它參與完整的開發工作流程。

Heimin 閉環開發的圓形圖：Heimin 中的 Spec → Claude 透過 MCP 讀取 → Claude Code 實作 → 更新 Heimin — 閉環開發：透過 MCP 整合，Heimin 建造 Heimin

實用重點

如果你正在採用 AI 程式工具，以下是真正有效的做法：

該做的事

✅ 在提示之前建立規格。 你的意圖越清楚，產出越好。

✅ 投資 Code Review。 AI 生成的程式碼需要更多 Review，不是更少。考慮用 AI 輔助的 Review 工具來跟上節奏。

✅ 選擇適合工作流程的工具。「最好的」工具是你的團隊會正確使用的那個。

✅ 把 AI 當成 Junior 開發者。 快速、有能力，但需要清楚的方向和監督。

✅ 建立回饋迴路。 追蹤什麼有效。根據結果調整你的提示和流程。

該避免的事

❌ 不要接受你不理解的程式碼。 你解釋不了的東西，你也維護不了。

❌ 不要因為「AI 寫的」就跳過測試。 AI 生成的程式碼漏洞率比人寫的更高。

❌ 不要把速度和生產力搞混。 快速出貨然後修好幾個月不叫效率。

❌ 不要讓工具決定架構。 你的技術判斷應該引導 AI，而不是相反。

結論

Vibe Coding 不會消失。AI 輔助開發正在成為標準做法——76% 的開發者正在使用或計畫使用 AI 程式助手。

但產出 AI Slop 的團隊和交付高品質軟體的團隊之間的差距正在擴大。

差別不在工具。在於操作的人。

清晰的規格。強健的審查流程。不打折的品質標準。 這些基本功在 AI 時代更重要，不是更不重要。

會成功的團隊不是產生最多程式碼的團隊。而是維持紀律確保那些程式碼值得被產生的團隊。

Heimin 是我們用這些原則建造的任務管理工具——也是我們用來建造它的工具。Spec 驅動開發遇上閉環執行。如果你的團隊重視簡單和品質，免費試用 Heimin。

免費開始使用 →

參考資料

Collins 字典 2025 年度詞彙：「Vibe Coding」— The Conversation
Macquarie 字典 2025 年度詞彙：「AI Slop」— Phys.org
Veracode 研究：45% 的 AI 生成程式碼包含安全漏洞 — Medium: The Rise of Vibe Coding
METR 研究：使用 AI 工具生產力下降 19% — FinalRound AI
Y Combinator 2025 冬季批次：25% 專案有 95% AI 生成程式碼 — Medium: The Rise of Vibe Coding
Stack Overflow 2024 開發者調查：76% 正在使用或計畫使用 AI 程式助手 — SoftwareSeni
Sean Grove（OpenAI）談規格成為新的程式技能 — The New Stack
GitHub Spec Kit 與 Spec 驅動開發 — GitHub Blog
AWS Kiro 與 Spec Mode — Kiro Blog
AI 程式工具比較 — Appwrite Blog、HumAI Blog