當 Andrej Karpathy 在社群提出「Vibe Coding」時，全球開發者見證了一場生產力革命：不需要背誦語法，只要抱持著氛圍，對著 Cursor 或 Claude 自然語言描述，幾分鐘內就能長出一個功能完整的全端應用。
隨之而來的，是軟體工程界的大規模懷疑論：如果個人開發者可以在週末「氛圍編程」拼出一個日活用戶破兩萬的 Photoshop 替代品，甚至幾天內獨立做出多人在線遊戲，那麼過去二十年企業視為金科玉律的敏捷開發（Agile Development）——那些兩週一次的 Sprint 規劃、每日站立會議、Story Points 估算與燃盡圖——是不是徹底過時了？
答案既是殘酷的否定，也是深刻的肯定。在過去一個月的社群討論中，Hacker News 與 Reddit 的技術看板上掀起了一場高密度的集體反思：傳統 Scrum 的形式主義儀式正在不可逆地瓦解，但敏捷宣言最初的核心靈魂——短反饋迴圈、快速驗證、擁抱變化——卻比以往任何時候都更加致命。
- 無規格盲目生成：依賴 LLM 自行揣測邊界
- 第 50 天維護懸崖：牽一髮動全身的難以除錯代碼
- 軟體垃圾掩埋：加速打造完全沒人要的無效功能
- 兩週 Sprint 固化：無法跟上小時級原型迭代
- 點數估算通膨：把生成代碼量當作真實價值
- 儀式化注意力消耗：沉溺會議而忽略使用者真實體感
- User Story 即邊界：以防禦型 Context 約束 Agent
- 不變量自動驗收：失敗測試先行，保障架構不腐
- 小時級極速反饋：讓真實使用者檢驗垂直切片
產能狂歡後的幻滅：為什麼「極速編程」正撞上第 50 天懸崖？
在 r/vibecoding 社群中，每天都有無數充滿成就感的 Showcase 貼文：個人開發者靠 AI 在幾天內獨立寫出點對點傳輸工具、3D 遊戲引擎原型，甚至加密貨幣錢包。
然而，狂歡過後往往伴隨著痛苦的技術償還期。一位初學者在社群分享自己無經驗靠 AI 寫出溫馨遊戲的第 5 天心得時，獲得 221 票高讚的熱門回覆一語道破了所有資深工程師的共鳴：
「概念看起來很棒。不用擔心缺乏開發經驗，到了第 50 天當你試圖修復 Bug 或更換核心機制時，經驗就會自己找上門了。」
這種現象在社群中被稱為「Vibe Hangover（氛圍宿醉）」。AI 讓寫程式（Writing Code）變得極其廉價，卻讓理解、除錯與演進程式（Reading & Maintaining Code）變得無比昂貴。純粹的 Vibe Coding 往往呈現以下三種崩潰路徑：
缺少架構約束的偽解法膨脹
- 現象：AI 為了讓目前的提示詞跑通，不惜在底層塞入難以維護的補丁。當功能需求疊加到幾十個小時後，任何微小的改動都會引發全域狀態崩塌。
- 代價：開發者對代碼的內部狀態失去掌控，陷入「改 A 壞 B，改 B 壞 C」的無盡 Prompt 重試地獄。
光速打造「完全沒人要」的軟體垃圾
- 現象：在 AI 出現前，團隊需要花費數個月才能手刻出一個無人問津的產品；現在個人可以在六天內拼湊出來。
- 代價：社群評論尖銳指出，產能暴增如果沒有市場校準，只會變成快速生產數位廢棄物。垃圾就算換成 AI 寫的，本質上依然是垃圾。
點數估算通膨（Story Point Inflation）
- 現象：在團隊環境中，管理層往往將 AI 生成程式碼的高通量（Throughput）誤當成真實的商業交付價值。
- 代價：工程師用 Agent 在兩小時內把 8 個點數的任務「做完」，但代碼審查者需要花費四倍的時間去抓出隱蔽的邊界安全漏洞。
形式主義的死刑：該被埋葬的敏捷儀式（Scrum Ceremonies）
如果 Vibe Coding 暴露了軟體工程的真實痛點，那麼首先應該被淘汰的，正是那些早已僵化的敏捷繁文縟節。
在傳統軟體團隊中，敏捷往往退化成了「Scrum 儀式箱」：
僵化的兩週 Sprint 週期
在 Agent 時代，從一個產品假說到可運作的互動原型，迭代週期已經被壓縮到以小時為單位。硬性把工作切碎並鎖定在兩週的排程框架中，要求工程師在 Sprint Planning 預測下下週二要交什麼代碼，已經完全違背了現代開發工具的節奏。
虛幻的複雜度估算（Story Points & Poker）
點數估算本意是衡量人類工程師的思考複雜度與實現工時。當 AI 能夠在十秒內實作好一個複雜表單與資料庫 Migration 時，討論「這個任務算 3 點還是 5 點」不僅浪費注意力，更助長了刷產出的虛榮指標。
走形式的每日站立會議（Standup Theater）
「昨天做了什麼、今天要做什麼、有沒有遇到 Block」在 GitHub PR 與 Agent 執行日誌完全透明的今天，已經不需要每天集合全組人員口頭背誦。這種同步會議只會打斷深度的架構思考與上下文調度。
靈魂的復興：敏捷工程如何成為 Vibe Coding 的導航儀？
當我們把形式主義的 Scrum 外殼剝離後，留下來的才是敏捷最純粹的內核。敏捷不是管理工程師的工廠打卡制度，而是在高度不確定性下，以最小代價持續逼近正確答案的工程哲學。
Vibe Coding 解決了「輪子轉動的速度」，但唯有敏捷能確保車子不是筆直開向懸崖。在 AI 時代，敏捷的核心實踐正在演化為不可或缺的工程護欄：
核心原則一：以「可驗證的垂直切片（Vertical Slices）」取代端到端盲猜
傳統 Vibe Coding 最容易犯的錯誤是一口氣讓 Agent 生成全套資料庫、後端與前端，最終得到一個看似華麗卻充滿假資料的玩具。
敏捷工程強調「縱向貫穿（Tracer Bullets）」：哪怕第一天只有一個輸入框和一個按鈕，也必須真實打到後端、寫入資料庫並觸發事件。只有當真實的數據管道跑通，Agent 的下一步擴展才具備堅實的基底。
核心原則二：User Story 轉化為 Agent 的防禦型上下文（Spec-driven Development）
在現代 AI 工程實踐（如社群提倡的 BMAD 方法論）中，User Story 不再是寫在 Jira 裡給主管看的驗收項目，而是直接編譯給 Agent 的嚴格邊界約束：
# 敏捷 User Story 作為 Agent 的執行邊界
feature_slice:
epic: 身份認證與雙因素驗證
story_id: AUTH-204
intent: 使用者可在個人安全頁面綁定 TOTP Authenticator
non_goals:
- 不支援 SMS 簡訊驗證碼
- 不變更既有 OAuth 第三方登入介面
acceptance_invariants:
- 斷言 1: 輸入錯誤驗證碼超過 5 次，該 Session 必須強制冷卻 15 分鐘
- 斷言 2: Secret 金鑰在資料庫中必須以 AES-GCM 加密存放，嚴禁明文落盤
- 斷言 3: 生成之 QR Code 僅以暫態 SVG 於記憶體渲染，嚴禁寫入公開靜態目錄透過明確定義「非目標（Non-goals）」與「不變量斷言（Acceptance Invariants）」，人類工程師扮演的是產品負責人與架構裁決者，把模糊的商業語義收斂成具備防腐效果的規格，防止 Agent 自作主張引入不必要的架構污染。
核心原則三：TDD 與測試先行是避免「第 50 天懸崖」的唯一保險
很多人以為有了 AI 就不需要寫測試，事實恰恰相反：在 Vibe Coding 時代，測試是人類向 Agent 傳達意圖成本最低的介面。
當你先讓 Agent 寫出或自己定義好失敗的紅燈測試（Red Test），AI 生成程式碼的目標就不再是發散的「隨便寫能動就好」，而是精準收斂至「讓測試綠燈（Green）」。這構建了一套自動化的防退化安全網，即使第 50 天團隊需要重構整個核心邏輯，只要既有的不變量測試依然全綠，系統就能安全前行。
工程判斷：從「碼農工廠」轉向「架構與產品裁決」
回到最初的問題：Vibe Coding 下，敏捷開發還有必要嗎？
如果你的敏捷指的是兩週排期、Jira 點數賽跑和無休止的儀式會議，那麼它不僅沒有必要，而且正在被技術浪潮加速淘汰。
但如果你的敏捷指的是：
- 短反饋迴圈（Short Feedback Loops）：不盲信任何未經真實使用者檢驗的原型。
- 小步迭代與架構防腐（Iterative Refactoring）：用狹窄介面、深模組（Deep Modules）與自動化測試防禦代碼熵增。
- 以人為本的商業校準（Customer Collaboration）：將工程師從繁瑣的語法實現中解放出來，全力專注於真實業務價值的辨別與交付。
那麼，敏捷非但沒有死去，反而在 Vibe Coding 的催化下迎來了它真正的黃金時代。
在未來的軟體團隊中，AI 是無限算力的施工隊，而敏捷思維則是工程師手中唯一的水平儀與羅盤。 唯有懂得用架構邊界約束生成、用高頻真實反饋校準方向的人，才能在程式碼滿天飛的世界裡，構建出真正長青的生產級系統。