Vibe Coding 升級版：當 AI 每天推 22 個 PR，工程師真正的核心價值是什麼？
有一個數字讓我停下來思考了很久。
Anthropic 的 Claude Code 部門主管 Boris Cherny 在今年一月的貼文說：他前天推了 27 個 pull request，昨天推了 22 個。每一個，都是 100% 由 Claude 寫的。他個人超過兩個月沒有手動寫過一行程式碼。
我第一次看到這個數字的時候，腦子裡浮現的不是「哇，好厲害」，而是：「那他在做什麼？」
這個問題，可能比你想的更重要。
Anthropic 在做一件非常奇怪的事
今年二月，Anthropic Labs 的負責人 Mike Krieger 在 Cisco AI 峰會上說了一句話：「目前 Anthropic 大多數產品，基本上 100% 是由 Claude 在寫程式。」
「基本上 100%」——這不是行銷說法，是他們內部真實的工作狀態。
然後他補充：「我們在外圍建立了一套完整的框架，讓我們可以信任它。」
這一句更有意思。不是「AI 很強」，而是「我們建立了讓我們能夠信任 AI 的機制」。這兩件事差距很大。
Anthropic 的 CEO Dario Amodei 在去年三月預測，AI 將在三到六個月內寫下 90% 的程式碼。結果他的預測不但成真，內部數字還衝破了他當初估計的上限。一個內部調查顯示，Anthropic 的工程師和研究員有 60% 的工作時間都用上了 Claude，生產力提升了 50%；27% 由 Claude 協助完成的工作，是「沒有 AI 根本不會做的事」——意思是，不是原本的工作加速了，而是新的工作因此被創造出來。
同期，微軟 CEO Satya Nadella 在四月說，他們公司有 30% 的程式碼是 AI 生成的。同樣是大公司，差距那麼大，不是能力問題，是文化問題。
但最讓我覺得有點超現實的，是 Krieger 說的那句：
「我們在讓 Claude 寫 Claude。」
AI 在開發自己的下一個版本。這不是科幻，是 2026 年二月正在發生的現在式。
「Vibe Coding」這個詞，快要不夠用了
如果你去年有在追科技動態，應該聽過 Andrej Karpathy 創造的「Vibe Coding」這個詞——大意是：你不需要真的懂程式，只要把想法說給 AI 聽，讓它把細節搞定，你盯著結果、接受輸出、遇到錯誤就把錯誤訊息貼回去，整個過程靠感覺（vibe）推進。
但 Karpathy 最近說，Vibe Coding 這個詞已經不夠精確了。他自己現在更喜歡用的詞是： Agentic Engineering 。
他的解釋是：「你 99% 的時間不是在直接寫程式，而是在指揮代理（agent）去做，自己扮演監督的角色——強調『Engineering』是因為這件事有藝術、有科學、有專業門檻，是可以學習和精進的。」
這個命名的轉變，背後其實藏了一個重要訊息：Vibe Coding 原本帶有一點「輕鬆隨意」的意味，好像任何人都可以無腦使用 AI 做出東西。但「Agentic Engineering」強調的是——這件事有技藝，需要系統思考、需要品味、需要你懂得怎麼協調多個代理。
它不是讓人變懶，而是把人的能力層次拉高了。
Steve Yegge 的 8 個層級，你在哪裡？
Steve Yegge 是個寫程式超過 40 年的工程師，待過 Amazon、Google，最近出了一本叫《Vibe Coding》的書。他在澳洲一場演講裡畫了一張圖，把 AI 採用程度分成 8 個層級：
AI 採用的 8 個層級
Yegge 說了一句很刺的話：「如果你今天還在用 IDE，你可能是個落後的工程師。」他說這不是在罵人，而是他看到許多他認識的、很優秀的工程師，還停留在 L2、L3，一行一行審查 AI 產出的程式碼，然後很小心地 commit——他說：「你要被淘汰了，而你是我認識最厲害的工程師之一。」
這句話讓我想到一件事：問題不是能不能用 AI，而是你有沒有在移動。
吸血鬼效應（Dracula Effect）：全速衝刺的代價
這是我在 Yegge 的採訪裡讀到最讓我意外的一段。
他說，在使用 AI 全速工作（Vibe Coding at max speed）的人，包括他自己，以及他認識在新創公司工作的朋友們，都出現了同一個症狀： 白天開始需要小睡。
「有一種吸血鬼效應在這裡面，它讓你很興奮、捕捉了很多價值、你拼命工作——然後你會覺得累、暴躁。」
他建議，一個全速在 Agentic Engineering 模式下工作的工程師，每天大概只能保持 3 小時的高效產出。但在這 3 小時裡，他可能比沒有 AI 的 8 小時做出多 100 倍的東西。
管理層需要理解這件事。如果你期待工程師全天候都在 Vibe Coding，你要的不是高效率，你是在讓他們過勞然後辭職。
這讓我想到一個更根本的問題： 誰在捕捉這個 100 倍的生產力價值？
Yegge 說了一個有趣的觀察：有兩種人。第一種，每天努力工作 8 小時，做出 100 倍的成果，但公司拿走了全部的價值，工程師拿到的還是那份薪水。第二種，每天工作 10 分鐘，做出 100 倍的成果，自己默默把價值留下來，但不告訴任何人。
「這兩種都不理想。每個工程師都需要學會說不，而且要學得很快、很好。」
大公司快死了，但它們還不知道
Steve Yegge 說了另一個大膽的觀點：大公司正在死去，只是它們還不知道。
他的邏輯是這樣的：AI 讓小團隊可以做出過去需要幾百人才能做到的東西。這就像當年雲端計算出現的時候——原本需要龐大 IT 基礎設施的大公司，突然發現一個五人新創可以用 AWS 複製它們 90% 的能力。
大公司的工程師可能每個都超強、超高效，但「公司本身無法吸收這些工作成果」。下游一堆瓶頸，這些超高效的工程師被卡住了，然後辭職。
「我們看著大公司說：你們什麼時候要做點什麼出來？答案是——我們在看一群已經死了只是還沒倒下的公司。」
這個說法可能有點誇張，但他指出的問題是真實的： 創新速度快不快，跟公司大不大無關，跟文化有沒有讓快速試錯成為可能有關。
Amazon 的 Andy Jassy 說，他們未來要用更少的人做同樣的事。這不是因為工程師不好，而是因為組織對「多少人才夠」的計算基準，正在被 AI 從根本改寫。
那工程師的護城河在哪裡？
這才是最核心的問題。
當 Boris Cherny 一天推 22 個 PR、100% 由 AI 寫的時候，他在做什麼？
他在做的是：決定 要推什麼、要做什麼、為什麼這件事值得做 。
這不是說寫程式的技能就毫無意義了。你要能讀懂 AI 寫的程式，要能發現問題、辨識風險，要能決定架構的方向。但核心工作從「執行」移向了「判斷」。
Karpathy 的說法是：「AI 負責『怎麼做』，工程師負責『做什麼』。」
Yegge 把這個叫做「品味」（taste）和「系統思維」（systems thinking）。當程式碼本身不再稀缺，工程師的稀缺性來自於：你有沒有辦法知道什麼值得做，以及你能不能判斷 AI 產出的東西是不是真的對。
這讓我想到一句我自己一直在思考的話：
這句話在 AI 時代有了新的詮釋：不是說你應該忽視新技術，而是說——光是追著工具跑不夠，你需要把某一件事真的做透。AI 幫你快了 100 倍，但如果你用來追更多跑不完的事，產出還是零。品味，是你知道把這 100 倍的力氣放在哪裡。
值得一提的是，Anthropic 自己把 Claude 形容為一個「超嚴格的審查員」。Mike Krieger 說：「我提交一個 PR，Claude 會回來說：『這裡有所有的安全漏洞』，然後還說『這邊可以怎麼重構』。」
有趣的是，Claude 現在可以在開源函式庫裡找到超過 500 個之前未知的高嚴重性安全漏洞，而且每一個都經過人工或外部安全研究員驗證。
AI 不只是在寫程式，它也在做過去需要高階工程師才能做的程式碼審查和安全稽核。
「就算不會寫程式，也能做工程師」——但前提是…
Yegge 說了一個例子：他的妻子，一個不會寫程式的人，現在可能成為他們共同開發的遊戲《Wyvern》裡貢獻最多的人。
這在一年前是不可能的事。
MIT 科技評論也在 2026 年的突破技術清單裡把「生成式程式碼」列進去，描述 Vibe Coding 為：「用提示詞指示 AI、讓 AI 寫程式、遇到問題就把錯誤訊息貼回去繼續迭代」的工作方式。
但這裡有一個陷阱： 非技術人員可以用 AI 做出東西，不代表他們做出來的東西是對的、安全的、可維護的。
Yegge 說得很直接：AI 驅動的工程師把「知道怎麼寫程式」轉化成了「知道寫出來的東西有沒有問題」。這個判斷能力，需要真正的工程背景才能做到。
換句話說，工程師的門檻沒有降低，只是移動了。以前問的是「你會不會寫 Python？」，現在問的是「你知不知道 AI 寫的 Python 哪裡有問題？」
這兩件事需要的底層知識，其實差不多，只是在應用層次上，從「生成」變成了「驗證和判斷」。
大裁員要來了嗎？
Yegge 說，每家大公司都有一個「裁員調節器」，設定值大概是 50%。他的邏輯是：想要讓工程師完全發揮 AI 的潛力，你必須讓一半的人走，這樣剩下的一半才有足夠的資源使用 AI 工具——因為工程師現在每個人每個月都在花大量的 token 費用。
「我們要失去大公司大約一半的工程師，這很可怕。但同時，AI 也讓非工程師可以寫程式、讓小團隊可以比肩大公司的產出——所以在大規模裁員的同時，也在大規模創造新的軟體公司和機會。」
他說的那個未來，讓我想起雲端運算剛出現的時候。那時候大家也很擔心：傳統 IT 部門的人要去哪？結果 10 年後，整個雲端生態系創造的工作機會，遠比它消滅的還多——只是工作的形態完全不同了。
這次大概也差不多。只是，中間的過渡期，可能會很混亂。
🔴 正在消失的工程師工作
- 重複性的功能開發
- 格式化程式碼、寫文件
- 基本的 bug 修復與測試撰寫
- 從零開始建立 CRUD 應用
🟢 正在浮現的工程師工作
- AI 代理的設計與協調
- 系統架構的判斷與決策
- 安全性稽核與程式碼品質把關
- 產品方向的技術可行性評估
工程師是「什麼」的問題
這一切讓我想回到一個更根本的問題：工程師到底是什麼？
長久以來，工程師的自我認同很大程度建立在「我會寫程式」這件事上。這個技能需要努力學習、多年累積，某種程度上是工程師身份的核心。
當 AI 把這件事變成人人都能做的時候，確實需要一段時間重新定位。Steve Yegge 說，他自己經歷了一個「哀悼過程」——哀悼手寫程式碼時代的結束。
「我意識到我花了幾十年學的技能，現在有很多已經過時了。這需要接受。但是……建造軟體，現在比以前更有趣了。以前要花幾週的東西，現在幾天就能做到。」
哀悼是正常的。但停留在哀悼裡不是。
在 AI 時代，試錯的成本大幅降低了。以前一個想法需要幾週來驗證，現在可能幾小時。在這樣的環境裡，知道什麼該試、快速試、從結果中學習——這個能力比「技術夠不夠強」更決定你走多遠。
你下週可以做的三件事
說了這麼多，回到現實。如果你是一個工程師，看完這篇文章之後，有什麼可以具體做的？
第一，確認自己在 Yegge 的哪個層級，然後刻意往前一格。
如果你在 L2（IDE 裡用 AI，但仔細審查每一行），試試 L3——降低審查密度，讓 AI 做更多決定，看看你的信任臨界值在哪裡。
第二，找一個你熟悉的領域，用 AI 做一個你之前「因為太麻煩而沒做」的東西。
Vibe Coding 或 Agentic Engineering 最有價值的地方，不是讓你做同樣的事更快，而是讓你做以前「根本不會開始」的事。Anthropic 的調查裡，27% 由 AI 協助完成的工作是「本來根本不會做的事」——找到你的那 27%。
第三，練習「讓成果說故事」的能力。
AI 時代的工程師，面對的一個挑戰是：「你做了很多，但怎麼讓別人知道哪些是你的判斷，哪些是 AI 的執行？」這個問題的答案，是學會呈現決策過程，而不只是交付結果。你選擇做什麼、為什麼這樣設計、哪裡你故意不讓 AI 做決定——這些才是你的護城河。
結語
「Claude 在寫 Claude。」這句話在我腦子裡停了很久。
這不只是一個技術現象，它代表著某一種邊界的模糊：創造者和被創造者之間的邊界。工程師和工程師製造出來的東西之間的邊界。
工程師的角色並沒有消失，而是爬升了一層。
從「能寫程式的人」到「能判斷應該做什麼程式的人」——這個升格，不是每個人都能自動完成的。它需要你刻意練習判斷力、系統思維、以及對自己工作領域的深度理解。
工具永遠是工具。品味和判斷，是屬於你的。
資料來源
網路資料
Anthropic Claude 現在撰寫近 100% 的內部產品程式碼 — Technobezz
- 提供 Anthropic 內部開發轉型的第一手數據，包括 Mike Krieger 在 Cisco AI 峰會的聲明、Boris Cherny 的 PR 數量、以及工程師生產力調查結果（60% 工作用 Claude、50% 效率提升）
Steve Yegge on AI Agents and the Future of Software Engineering — The Pragmatic Engineer
- 提供 Steve Yegge 的 8 個 AI 採用層級框架、Dracula Effect 的說明，以及大公司與小團隊在 AI 時代競爭格局的深度分析
Andrej Karpathy Says 'Agentic Engineering' Is the Next Big Thing — Business Insider
- 說明 Karpathy 從「Vibe Coding」到「Agentic Engineering」的命名演化，以及他對工程師角色轉型的定義
Vibe Coding is passé — The New Stack
- 補充 Karpathy 對「Agentic Engineering」的完整定義：「你 99% 的時間不是在直接寫程式，而是在監督和指揮代理」，以及 2026 年 agent 層的未來發展
Generative Coding: 10 Breakthrough Technologies 2026 — MIT Technology Review
- MIT 科技評論將生成式程式碼列入 2026 年十大突破技術，提供主流媒體對 Vibe Coding 現象的評估與爭議