Vibe Coding 革命的陰暗面：當 41% 的程式碼由 AI 撰寫，軟體工程正在失去什麼？

2025 年 2 月 2 日，OpenAI 共同創辦人暨前特斯拉 AI 負責人 Andrej Karpathy 在社群媒體上寫道：「有一種新的程式設計方式，我稱之為 Vibe Coding——你完全沉浸在感覺中、擁抱指數性成長、忘記程式碼的存在。」^[1]這個看似隨性的用語，在十個月後被 Collins 辭典選為 2025 年度詞彙——詞典編纂者在 240 億字的語料庫中觀察到這個詞的使用量出現了戲劇性的爆發。一年之後的 2026 年 2 月，全球已有 41% 的程式碼由 AI 生成、92% 的美國開發者每天使用 AI 編程工具、87% 的 Fortune 500 企業採用了某種形式的 AI 輔助開發平台。^[2]Y Combinator 2025 冬季批次中，25% 的新創公司擁有 95% 由 AI 生成的程式碼庫——它們以不到十人的團隊達到了 1,000 萬美元的營收。^[3]這些數字描繪了一場看似不可阻擋的技術革命。然而，同一時期的另一組數據卻講述了一個截然不同的故事：METR 的隨機對照實驗發現，資深開發者使用 AI 工具後實際速度反而慢了 19%；GitClear 在 2.11 億行程式碼中觀察到複製貼上增加 48%、重構減少 60%；Georgetown 大學的報告指出 40% 的 AI 生成程式碼含有已知安全漏洞；每五家組織中就有一家因 AI 生成的程式碼遭遇嚴重資安事件。在我帶領超智諮詢進行 AI 軟體開發的實踐中，以及過去在劍橋大學從事科技治理研究的經驗裡，我深刻體會到：Vibe Coding 不僅是一種新的程式設計方法——它正在引發軟體工程這個專業的存在性危機。

一、Vibe Coding 的誕生與演化：從年度詞彙到專業方法論

Karpathy 提出 Vibe Coding 時，描述的是一種個人化的、低壓力的 AI 輔助程式設計體驗——他自己用 AI 工具建構一些週末專案，不去逐行檢查生成的程式碼，而是「只看結果有沒有跑起來」。這種態度本身無可厚非——就像一個木工有時候用電動工具快速做個置物架，不追求榫卯工藝的極致。然而，Vibe Coding 迅速從 Karpathy 的個人習慣演變為一場產業運動。到 2025 年底，它已不再是邊緣的次文化，而是矽谷風險投資者評估新創公司的標準敘事。

Y Combinator 的數據是這場運動最有力的佐證。2025 冬季批次（W25）中，25% 的新創公司的程式碼庫有 95% 由 AI 生成。^[3]YC 總裁 Garry Tan 直言：「這不是一時流行，這不會消失，這就是未來的主流程式設計方式。」W25 批次實現了 YC 基金歷史上最快的增速——總體每週 10% 的成長率——這似乎驗證了 Vibe Coding 的商業可行性。然而，一個更精確的問題是：這些新創公司的快速成長，究竟歸因於 AI 程式碼的品質，還是歸因於它們在市場時機、商業模式與創辦人能力上的優勢？相關性不等於因果性——這在任何嚴謹的分析中都是需要謹記的基本原則。

耐人尋味的是，Karpathy 本人在一年後的 2026 年 2 月宣布 Vibe Coding 已經「過時」（passé），提出了「代理式工程」（Agentic Engineering）作為其成熟版本。^[4]他的新論述是：「透過 LLM Agent 進行程式設計，正在成為專業工作者的預設工作流程——但帶有更多的監督與審查。」從 Vibe Coding 到 Agentic Engineering 的概念演化，反映了一個重要的認知修正——業界開始意識到，「忘記程式碼的存在」或許適用於週末專案，但不適用於支撐商業營運的生產系統。

AI 編程工具的市場規模印證了這場轉型的深度。GitHub Copilot 累計用戶已達 2,000 萬，其中 130 萬付費訂閱用戶——活躍用戶中 46% 的程式碼由 Copilot 生成，較 2022 年發布時的 27% 顯著攀升。^[5]更令人矚目的是 Cursor（由 Anysphere 公司開發）——這個 AI 優先的程式碼編輯器在 2025 年 1 月突破 1 億美元年經常性收入（ARR），到 6 月已超過 5 億美元，年底突破 10 億美元，估值達到 293 億美元。^[6]整體 AI 編程工具市場在 2025 年已達 73.7 億美元，預計到 2040 年將成長至 3,250 億美元。^[2]這些數字的規模表明：AI 輔助程式設計不是一個可以忽略的邊緣趨勢——它已是軟體產業的基礎設施。

二、AI 生成程式碼的品質危機：數據說了什麼？

在生產力提升的敘事之下，程式碼品質的實證數據呈現了一幅令人不安的圖景。

GitClear 的大規模分析提供了迄今最全面的 AI 對程式碼品質影響的實證研究。透過分析 2020 至 2024 年間 2.11 億行程式碼的變更歷史，研究發現了三個結構性的品質退化趨勢。^[7]第一，「複製貼上模式」增加了 48%——開發者（或 AI）越來越傾向於複製現有程式碼而非設計可重用的抽象。第二，重構性程式碼減少了 60%——意味著開發者花更少的時間改善既有程式碼的結構與可維護性。第三，程式碼重寫率（code churn，新撰寫的程式碼在兩週內被修改的比率）從 2020 年的 3.1% 上升至 2024 年的 5.7%——表示越來越多的程式碼在提交後不久就被發現有問題而需要修改。更具結構性意義的是，重構佔程式碼變更的比例從 2021 年的 25% 下降至 2024 年的不到 10%。在軟體工程的專業標準中，重構是維持程式碼庫長期健康的關鍵活動——重構的急劇減少，等同於一個城市停止了道路維護，短期內不會出問題，但長期將導致基礎設施的系統性退化。

METR 的隨機對照實驗提供了或許最具顛覆性的發現。^[8]研究團隊招募了 16 位資深開源開發者——他們維護的儲存庫平均擁有 22,000 個以上的 GitHub Stars 和超過 100 萬行程式碼——進行了一項嚴格的隨機對照實驗。開發者被隨機分配使用或不使用 AI 工具（Cursor Pro 搭配 Claude 3.5/3.7 Sonnet）完成任務。結果出人意料：使用 AI 工具的開發者實際完成任務的速度慢了 19%。更引人深思的是認知偏差——在實驗前，開發者預期 AI 工具會讓他們快 24%；在實驗後，他們自我報告認為自己快了 20%。但客觀測量顯示他們其實慢了 19%。這個「感知與現實的 39 個百分點落差」揭示了一個危險的認知陷阱——AI 工具可能讓開發者「感覺」更有生產力，但在涉及深度理解的複雜任務上，實際效果可能相反。

安全漏洞的數據同樣令人擔憂。Georgetown 大學安全與新興技術中心（CSET）的研究報告指出，GitHub Copilot 生成的 1,689 個程式中，約 40% 含有 MITRE CWE Top 25 的已知安全漏洞。^[9]Aikido Security 對美國與歐洲 450 家組織的調查發現，每五家組織中就有一家因 AI 生成的程式碼遭遇嚴重資安事件——美國的比例更高，達到 43%，而歐洲為 20%（差異可能反映了歐盟更嚴格的監管環境的保護效果）。^[10]最常見的漏洞類型包括跨站腳本攻擊（XSS）、SQL 注入、硬編碼憑證與路徑穿越。令人擔憂的是，這些都是軟體安全領域早已熟知的基礎漏洞——AI 不是在產生新型態的安全問題，而是在大規模重現人類工程師過去幾十年已學會避免的錯誤。

開發者自身的態度反映了這種矛盾。調查數據顯示，僅 3% 的開發者高度信任 AI 生成的程式碼；71% 拒絕在未經人工審查的情況下合併 AI 程式碼；63% 表示曾花費比自己從頭撰寫更多的時間來除錯 AI 生成的程式碼；53% 發現了通過初次審查的安全問題。^[2]這些數據共同描繪了一個弔詭的現實：92% 的開發者每天使用 AI 工具，但僅 3% 高度信任它的輸出。這不是一個對工具滿意的使用者群體的特徵——更像是一群在市場壓力下不得不採用尚未成熟技術的專業工作者。

三、技術債海嘯與認知債：軟體工程的雙重危機

AI 輔助開發的品質問題，在時間維度上會被放大為一場技術債（technical debt）的海嘯。Forrester 預測，到 2026 年，75% 的企業將面臨中度至高度嚴重的技術債——直接歸因於 AI 驅動的快速開發。^[11]Stack Overflow 在 2026 年 1 月發表了一篇標題直白的分析：「AI 可以讓開發者的生產力提升 10 倍……在製造技術債方面。」^[12]

技術債的經濟學值得細究。儘管 AI 工具的供應商宣稱開發速度提升 50%，但深入分析第一年的實際成本後，會發現 AI 輔助開發的總成本比傳統開發高出約 12%——原因在於 9% 的額外程式碼審查開銷、1.7 倍的測試負擔、以及 2 倍的程式碼重寫率。^[13]到了第二年，如果不進行積極的技術債管理，維護成本將飆升至傳統開發的 4 倍。這意味著 Vibe Coding 的「快速」不是免費的——它本質上是將未來的維護成本借到現在來消費，就像信用卡消費一樣，延遲付款不等於不用付款。

然而，比技術債更深層、也更難察覺的，是 2026 年 2 月由維多利亞大學 Margaret-Anne Storey 教授提出的全新概念——「認知債」（cognitive debt）。^[14]認知債指的是：當 AI 代替人類撰寫程式碼時，人類對程式碼的理解——設計決策的脈絡、系統元件之間的互動邏輯、錯誤處理的邊界條件——正在系統性地流失。與技術債不同（技術債存在於程式碼中，可以透過重構來償還），認知債存在於人的腦中，一旦團隊失去了對系統的共享理解，償還認知債的唯一方式是重新閱讀、重新理解整個程式碼庫——這往往比從頭撰寫更加耗時。

Storey 引述了一個真實案例：一個使用 AI 工具的學生團隊，在專案的前六週進展迅速——AI 快速生成了大量程式碼，功能快速上線。但到了第七到第八週，團隊遇到了一堵牆——沒有任何成員能夠解釋設計決策是如何做出的，也無法說明系統各部分是如何協同運作的。他們擁有一個「可以執行」的系統，但沒有任何人「理解」這個系統。這不是技術債——程式碼本身可能是乾淨的、可執行的、甚至有完整的測試覆蓋。但團隊已經「失去了線索」（lost the plot）。Simon Willison 與 Martin Fowler 兩位軟體工程界的思想領袖隨後擴大了這個概念的討論，引發了業界的廣泛迴響。

認知債的概念對企業的數位韌性策略有深刻的意涵。當一個企業的核心系統越來越依賴 AI 生成的程式碼，而理解這些程式碼的人類能力卻在同步退化時，企業面臨的不僅是技術風險，更是組織韌性的結構性脆弱——一旦 AI 工具不可用（服務中斷、供應商政策變更、監管限制），企業可能發現自己擁有一個無人能修改的系統。在我過去為世界銀行主持的數位基礎設施研究中，我們反覆強調「系統韌性」不僅取決於技術的穩健性，更取決於維護團隊的能力深度——認知債正在侵蝕後者。

四、初階工程師的消失：AI 如何瓦解軟體人才的培養管道

如果認知債是 AI 輔助開發在組織層面的隱性成本，那麼初階工程師的招聘萎縮則是其在產業層面的結構性後果——而且其影響可能比任何技術問題都更加深遠。

數據是殘酷的。全球十五大科技公司的初階職位招聘在 2023 至 2024 年間下降了 25%。^[15]英國初階技術職位在 2024 年減少了 46%，預計到 2026 年底將減少 53%。美國部分數據集顯示初階開發者職位下降了 67%。全球大型科技公司的應屆畢業生招聘三年內下降了超過 50%。54% 的工程主管計畫減少初階職位招聘。與此同時，資工系畢業生和程式設計訓練營的學員人數卻在增加——形成了一個危險的「人才管道悖論」：供給增加，需求銳減。

表面上，這個趨勢的邏輯很清晰：AI 可以完成初階開發者的大部分工作（撰寫樣板程式碼、修復簡單 bug、執行測試、生成文件），而且速度更快、成本更低。但這個邏輯忽略了一個結構性的問題——初階開發者不僅是「完成初階任務的人」，更是「未來資深開發者的培養管道」。如果企業大幅減少初階招聘，五到十年後，企業將面臨資深工程師的嚴重斷層。這是一個典型的「公地悲劇」（tragedy of the commons）——每家企業個別來看，減少初階招聘是理性的成本優化決策；但整個產業集體這樣做，將摧毀軟體工程的人才再生機制。

Stack Overflow 的分析更直接地指出了代際衝擊：「AI vs. Gen Z」——AI 已經從根本上改變了 Z 世代開發者的職業路徑。^[16]過去，一個新手開發者的成長路徑是：從撰寫簡單的功能開始，逐步參與更複雜的系統設計，在數年的實踐中建立對軟體架構、系統思維與工程權衡的深度理解。但在 AI 代寫大部分程式碼的世界裡，這個「從做中學」的路徑被截斷了——如果你從未從頭撰寫過一個完整的功能模組、從未親手追蹤過一個難以重現的 bug、從未在深夜對著一段晦澀的程式碼反覆思考其設計意圖，那麼你如何培養出判斷 AI 輸出品質的專業直覺？

這個問題的深度在於：它不僅影響個人的職業發展，更影響整個軟體工程專業的知識傳承。軟體工程的許多核心知識——架構判斷、系統思維、錯誤直覺——是「內隱知識」（tacit knowledge），無法透過文件或教科書傳遞，只能透過長期的實踐與師徒制的指導來習得。當初階工程師的實踐機會被 AI 取代時，這些內隱知識的傳承通道就被切斷了。在我過去研究高等教育改革與產學合作的經驗中，我反覆看到一個規律：當一個專業領域的學徒制被打斷時，該領域在一個世代之後往往會經歷品質的系統性下降。軟體工程正在面臨同樣的風險。

五、從程式設計師到系統指揮家：軟體工程專業的重新定義

面對 AI 對軟體工程的全面衝擊，產業界正在嘗試重新定義這個專業。Gartner 預測，80% 的軟體工程師必須在 2027 年前提升 AI 輔助開發的技能。^[17]一個被廣泛討論的框架是「從程式設計師到系統指揮家」（from coder to orchestrator）的角色轉型——開發者不再以撰寫程式碼為主要活動，而是設計系統架構、分配任務給 AI Agent、審查 AI 的輸出品質，並做出 AI 無法做出的工程判斷。

這個轉型在工具層面已經具體化。OpenClaw 讓使用者透過通訊軟體指揮 AI 完成整個開發流程——從 bug 修復到 Pull Request 生成。Claude Code 作為終端機內的 AI 編程代理，直接在開發者的工作環境中提供全程式碼庫的上下文理解。Devin 2.0 定位為「自主軟體工程師」，能獨立管理 Git 儲存庫、撰寫測試並提交 Pull Request。在 SWE-bench 的基準測試中，Devin 自主解決了 13.86% 的真實 GitHub 問題——這個數字看似不高，但考慮到這些都是需要深度理解才能解決的真實工程問題，它標誌著 AI 自主編程能力的重大進步。

然而，「系統指揮家」的角色轉型面臨一個根本性的悖論——你如何在不實際撰寫程式碼的情況下，仍然深刻理解程式碼？這就像一個從未在廚房中操作過的人試圖擔任米其林餐廳的主廚——你或許可以描述你想要的菜色，但你缺乏判斷執行品質的專業直覺。2025 年 DORA 報告的發現印證了這個悖論：59% 的開發者報告 AI 對程式碼品質有正面影響，但實際的 bug 發生率（以每個 Pull Request 的 bug 數量衡量）卻沒有改變——你建構得更快了，但在相同比例上出現 bug。^[18]換言之，AI 放大了生產力，同時等比例地放大了錯誤的產出量。

程式碼審查的自動化市場反映了業界對這個品質缺口的回應。自動化程式碼審查市場在 2025 年從 5.5 億美元暴增至 40 億美元。然而，當前最先進的 AI 程式碼審查工具（如 CodeRabbit）在偵測真實環境中的執行時期 bug 的準確率僅為 46%——這意味著超過一半的問題仍然需要人類審查者來發現。^[19]一個更深層的挑戰是：當 AI 生成程式碼的速度遠超人類審查的速度時，品質保障的瓶頸不再是撰寫程式碼，而是理解程式碼——這正是認知債的具體顯現。預測顯示 2026 年將出現 40% 的品質缺口——進入流水線的程式碼量將超過審查人員的驗證能力。

在我的觀點中，軟體工程面臨的核心挑戰不是「AI 能不能寫程式」——它顯然可以，而且將越來越好。真正的挑戰是：在 AI 承擔了越來越多的「動手做」之後，人類如何維持「判斷力」？這個問題不限於軟體工程——它是AI Agent 經濟中所有知識工作都將面臨的結構性議題。一個外科醫師如果只觀看手術機器人操作而從不親手執刀，他的判斷力會退化；一個飛行員如果只依賴自動駕駛而從不手動操控，他在緊急狀況下的應變能力會下降。軟體工程師如果只審查 AI 的輸出而從不自己撰寫程式碼，他判斷程式碼品質的專業直覺也將逐漸鈍化。

Gartner 的一項預測為這個討論添加了一個令人不安的注腳：到 2026 年，由於生成式 AI 的使用導致批判性思考能力的退化，50% 的全球組織將被迫要求進行「無 AI」的技能評估。^[17]這不是反對 AI 的盧德主義（Luddism），而是一種務實的認知：當工具變得越來越強大時，使用工具的人需要更加、而非更少地理解工具所處理的領域。Vibe Coding 的未來不是「更多 AI」或「更少 AI」的二元選擇，而是如何在 AI 的強大生產力與人類的不可取代判斷力之間，設計出正確的協作架構。這需要的不僅是技術創新，更是制度設計、教育改革與組織再造的系統性工程。