編輯 | 伊風
這應該是我聽過最扎實、最客觀的一場 AI 編程演講。
它不講「奇蹟」，也不兜售「焦慮」。而是拋出一個很實在的問題：
「今天我們能不能做一次現實核查：
那些極度樂觀的 AI 編程預言，靠譜嗎？還是現實中根本沒那麼神？」
微軟 CEO 說：「30% 的程式碼都是由 AI 編寫的」；
Authoropic 的 CEO 幾個月前聲稱，「一年之內所有程式碼都會由 AI 生成」；
但為何這和工程師跑起來的感覺不一樣？
怎麼有新創公司的人用了 Devin，不僅沒提升效率，還出了 bug 倒賠了 700 美元的事故成本？
這場演講來自 Gergely Orosz —— 曾任 Uber 技術主管、後來轉型為全職技術作者。
他寫的《The Tech Resume Inside Out》一度被稱為「程式設計師履歷聖經」，如今則靠著 The Pragmatic Engineer 這一全球最火工程類 Newsletter，持續影響著數十萬技術人。
為了回答上面的問題，他花了兩個月，採訪了 AI DevTools 新創團隊、大廠內部工程師、AI 生物新創公司和一群「熱愛程式碼本身」的獨立開發者。最終拼出了一份關於 AI 編程真實狀態 的多維圖像。
先來說個初步結論給大家：
- AI DevTools 新創公司：重度使用（不意外）；
- 大廠：投入巨大，使用率持續上升；
- AI 新創公司：使用情況不穩定，有的有效、有的無感；
- 獨立開發者：比以前更興奮、更願意用。
最令人意外的是一位真正的「資深程式設計師」—— Kent Beck（是的，就是《Extreme Programming》作者），他是第四類人的一個代表：
「我現在寫程式碼，比過去 52 年任何時候都開心。」 ——Kent Beck 今年是第 52 年寫程式碼了。
AI 讓他終於能動手做自己一直想做但覺得「太複雜、太貴」的專案，比如用 Smalltalk 寫一個平行運算伺服器。他說：
「技術棧中『什麼便宜、什麼昂貴』的格局正在被重寫，很多過去被我們放棄的事情，現在其實便宜得令人發笑。」
小編將這篇內容豐富的演講，梳理成了好讀、有料的文章，接下來你將讀到：
- AI DevTools 新創公司：9成程式碼 AI 生成，成千上萬個 MCP 請求一起跑！
- Google 和 Amazon：怎麼將 LLM 整合進開發工具？
- AI 新創公司：Claude Code、Cursor、Windsurf 等開發者怎麼用？
- 獨立開發者：誰在「徹底轉變」、誰在「理智觀察」？
- 最後是他留下的 4 個反思性問題，每一個都戳中真實工程場景。
Claude Code、Windsurf 9成已是 AI 程式碼，Cursor 僅為前者一半
首先是 AI DevTools 新創公司。
我上週剛和 Anthropic 團隊聊過，問他們最近在內部觀察到什麼趨勢。雖然這些公司難免會有些「自帶濾鏡」，但他們的回答還挺值得一聽的。
他們說，當第一次在內部開放 Claude Code 給工程師使用時，幾乎所有人都立即開始每天使用，而且熱情持續到現在。這種「自然啟動」讓他們自己也有點意外。
要知道，當時這還只是內部版本。Claude Code 直到一個月前才對外發布，它其實不是 IDE，而是一個命令列工具（CLI），運行在終端裡。
他們還告訴我，目前 Claude Code 這個產品本身，有 90% 的程式碼就是用 Claude Code 寫的。這個數字聽起來非常誇張，甚至像廣告詞。但我也專門和工程師確認過——他們不像市場部門那樣會「演」，所以這個說法還是挺可信的。
他們還提到一個很有趣的數據：Claude Code 正式上線後第一天，使用量就暴漲了 40%；三週不到，漲幅已經達到 160%。不論原因是什麼，這說明這個工具的確有吸引力。
此外，Anthropic 還啟動了一個叫 MCP（Model Context Protocol） 的專案。他們的目標是用一個協定，把 IDE 或 Agent 接入到開發者已有的上下文環境中，比如資料庫、GitHub、Google Drive、Puppet 等。
我自己也動手試了一下，連上了自己的一個 API 資料源，然後直接問它：「有多少人領取了某個優惠碼？」它自動生成 SQL 查詢，結果也挺靠譜。這種「自然語言連資料」的體驗，確實讓人眼前一亮。
據他們說，MCP 是在去年 11 月開源的。到今年年初，有幾家中型公司開始採用。然後在 3 月、4 月，連 OpenAI、Google、Microsoft 這些「大玩家」也加入了對 MCP 的支持。
現在，每天都有成千上萬條 MCP 請求在運行，後面演講中還會提到它為何重要。
除了 Claude，我還和另外兩個 AI IDE 團隊聊了聊：
- Windsurf：他們說目前團隊中 95% 的程式碼都是用 Windsurf 的 Agent 或自動補全生成的；
- Cursor：給出的估算是 40% 到 50% 的程式碼使用了 AI。雖然比不上前面兩個，但他們也坦言：有些地方確實有用，有些還不太行。
我很欣賞 Cursor 的坦誠。畢竟這些公司做的就是 AI 編程工具，誰都想把「AI 使用率」盡量做到 100%，那可是賣點。但 Cursor 沒藏著掖著，這就已經很難得了。
Google：「謹慎而長期主義」，所有 AI 工具都是自主研發
我和 Google 的幾位工程師匿名聊了聊，大概五個人。首先要知道的是：Google 的所有工程系統幾乎都是自主研發的。
- 不用 Kubernetes，而是內部自主研發的 Borg；
- 不用 GitHub，用的是自己的程式碼儲存庫系統；
- 不用公開的程式碼審查工具，而是用內部工具 Critique；
- 他們的 IDE 是自主研發系統 Cider（全稱：Integrated Development Environment and Repository）。
Cider 最初是網頁工具，現在已經演變為一個基於 VS Code 的客製化分支，與 Google 的內部基礎設施高度整合，開發體驗非常順滑， 打通程度很高。
工程師告訴我，現在 AI 工具幾乎無處不在。
在 Google 內部，他們已經將大型語言模型整合進自己的 IDE「Cider」中。Cider 是基於 VS Code 的一個客製化分支，還有一個網頁版叫 Cider V，裡面整合了自動補全、基於對話的 IDE。他們說使用體驗還不錯，雖然可能比不上 Cursor，但整體表現已經相當可以。在程式碼審查工具 Critique 中，AI 也能給出審查回饋，評價是「很合理，能用」。
再比如程式碼搜尋，這是 Google 內部非常強大的工具，現在也已經整合了 LLM 支持。你可以問它一些問題，它會幫你定位相關程式碼部分。而就在一年前，這些功能在 Google 內部幾乎沒人用。但半年內一切都變了。
一位現任 Google 工程師告訴我，Google 內部推行 AI 工具的方式是非常「謹慎而長期主義」的。他們希望這些工具能真正被工程師信任、持續使用。
此外，還有不少只面向 Google 內部的工具，比如：
- Notebook LM：你可以上傳文件、和它對話；
- Prompt Playground：有點像 OpenAI 的 Playground，但其實 Google 在 OpenAI 發布之前就已經做出來了；
- Moma：一個基於 LLM 的知識檢索系統，在 Google 工程師中廣泛使用。
我聽一位 Googler（不便透露姓名）說，現在每個組織（org）都在搞屬於自己的生成式 AI 工具，原因很簡單：領導層希望看到這種創新，而且這麼做更容易拿到內部資源和預算支持。像 Notebook LM 這樣的工具，就是靠「某個團隊拉到預算就自己搞起來」的。
不過讓我印象最深的，是一位前 SRE 告訴我——他和很多 Google 的 SRE 還保持聯繫——現在 Google 的基礎設施團隊正在為「10 倍程式碼量」的增長做準備。他們在升級部署流程、程式碼審查工具、功能開關機制等等。
這讓我非常好奇：Google 是不是已經看到了某些我們還沒意識到的趨勢？
Amazon：採用 AI 比 Google 激進，但相當低調
談起 AI 工具，大多數人第一反應不會想到 Amazon。
雖然外界對 Amazon 的 AI 能力印象不深，但我跟內部工程師聊下來發現，幾乎所有開發者都在用一個叫 Amazon Q Developer Pro 的工具。它對 AWS 相關任務非常好用。
讓我驚訝的是，Amazon 內部的人很疑惑，為什麼外界對這個工具幾乎一無所知？他們表示，「只要你是做 AWS 的，這個工具的上下文理解能力就特別棒。」
大概半年前，我聽他們說這個工具「不太行」；但現在，很多人都說：「真的很好用了。」
他們還告訴我，現在寫 Amazon 的 PR FAQ（六頁文案、模擬新聞稿的那種），也會用 AI 工具。年中績效季，很多寫作任務也用它來加速。
Amazon 和 Anthropic 有合作關係，他們有一個內部版本的 Claude。
關於 Amazon，我覺得最有趣的是 MCP（Model Context Protocol）在內部的推進。
Anthropic 最早提出 MCP，現在 Amazon 似乎在全面接入。
稍微講講背景：Amazon 是個「API 驅動」的公司，早在 2002 年，Jeff Bezos 發出著名命令：
「所有團隊必須通過服務接口（API）暴露功能和資料，不得使用內部通信，違者將被開除。」
這也是 AWS 能誕生的底層原因。他們的所有服務都可以通過 API 公開，因此現在只需要在 API 上「外掛」一個 MCP server，AI Agent 就能直接對接調用，非常輕鬆。
我從某位 Amazon 員工那裡得知，目前 Amazon 內部的大多數工具和網站已經支持 MCP，這應該是第一次被公開提到。
自動化在 Amazon 內部隨處可見。我聽說很多人正在用 AI 工具自動處理工單系統、郵件、內部流程等等，有些工程師甚至已經自動化了大部分工作流。
雖然外界沒人討論這些，但它確實正在發生。Amazon 作為「API First」公司，現在可能也正悄悄成為「MCP First」的引領者，時間點就在 2025。
新創公司的兩極分化：有人愛瘋了，有人說「不如手寫」
我還和一些小型新創公司聊了聊。它們並不是做 AI 工具起家的，但在日常流程中逐步開始整合 AI —— 有的甚至已經轉向「AI 優先」的方向。
1. 支持者 Incident IO：整個團隊都在用，形成濃厚的「知識共創」氛圍
Incident IO，本來是一家做 on-call 報警平台的公司。它本來是做 on-call 平台的，但 AI 明顯是很適合用來做報警、排查和解決方案推論的。所以他們逐步變成了 AI 優先的公司。
我採訪了聯合創始人 Lawrence Jones（他也是這次大會的講者），他告訴我：
整個團隊都在大規模使用 AI 來提升效率，還會在 Slack 中分享使用技巧、最佳實踐，一種「知識共創」的氛圍已經形成。
一些具體例子很有代表性：
- 有人嘗試用另一台 MCP server 來處理一張複雜的工單，結果 AI 給出的初稿非常靠譜；
- 他把這個經驗發到群裡，其他人紛紛試用，討論 prompt 設計和生成邏輯；
- 還有人發現了一個「提示詞新玩法」：讓 AI 給出 3~5 個不同程式碼方案，再追問「為什麼這樣寫、換個思路會怎樣」。
Lawrence 表示最關鍵的轉折點是 Claude Code 上線後的三週。
他查了一下數據（當時是週日），發現整個團隊都已經在日常使用它了。沒有任何品牌贊助，只是純粹覺得 Claude 太好用了。
2. 棄用者 某 AI 生物新創公司：最新的模型也滿足不了需求，領域太小眾了？
這家公司大概成立三年了，團隊規模在 50 到 100 人之間，整個系統架構很現代：基於 Kubernetes 的自動化數值管道、Python、Hugging Face 等技術。
他們的工程師對我說： 「我們試過很多 LLMs，但沒有一個能真正用起來。因為我們手動寫出正確程式碼，其實比修改 AI 寫的程式碼還要快得多 —— 即便是用最新模型，比如 Claude 3.7、甚至 Claude 4，還是這樣。」
他們覺得自己的領域可能太小眾，不適合讓 LLMs 發揮作用。
這位工程師也坦言，不願意公開名字，是因為他們不想被貼上「AI 懷疑者」的標籤——但這是實話。
他們是一家節奏很快的新創公司，嘗試過各種 AI 工具（包括程式碼審查助手），但最終發現這些工具不適用於他們開發的新型複雜軟體。他們不是不試，而是試了發現不行，就迅速換方向了。
「從未如此興奮！」——獨立開發者與資深程式設計師如何評價 AI 編碼？
聊完新創公司，我也採訪了幾位獨立軟體工程師，他們在 AI 時代之前就已經非常厲害了，對「寫程式碼」這件事有深深的熱愛。
1、Flask 作者 Armin：我現在更想當 AI 智能體工程師
Armin Ronacher，Python Web 框架 Flask 的作者，十幾年來一直是个「純寫程式碼」的技術人。他最近離開了 Sentry，準備自己創業。
最近他發布了一篇文章，標題是：《AI 改變了一切》。他說了一句非常顛覆性的話：
「如果你在六個月前告訴我，我會更願意做一名『AI 智能體工程師』而不是親自編碼，我肯定不會相信。」
他的轉變有三個原因：
- Claude Code 用起來真的很順；
- 自己在密集使用 LLMs 之後，終於「突破了心理障礙」，開始接受 AI 合作模式；
- 最關鍵：智能體能自動執行、觀察回饋，這種機制可以極大地降低「幻覺錯誤」的影響。
2、iOS 工具作者 Peter：我又找回了「寫程式碼的熱情」
Peter Steinberger 是 PSPDFKit 的作者，iOS 最流行的 PDF SDK 創辦人。他把公司賣掉後一直在探索新技術，最近發了一篇文章，標題就叫：
「The Spark Returns（熱情回來了）」
他說他感受到一個轉折點到來了：語言和框架不再重要，AI 工具讓他輕鬆從 Objective-C 轉到 TypeScript，寫什麼都行。工具層的解耦能力太強了，生產效率暴漲。
他還跟我分享了一個他發在社群平台的段子： 「很多技術人都因為玩 AI 工具興奮到睡不著。」
有趣的是，我們是在凌晨 5 點互發消息的，我因為別的事早醒，他因為寫程式碼根本沒睡。
3、ThoughtWorks 的 Brigita：LLM 是技術棧的「橫向力量」
Brigita 是 ThoughtWorks 的 Distinguished Engineer，她這樣總結 LLM 的意義：LLMs 是極少數可以在任意抽象層使用的工具。
你可以把它當作組合語言級別的 low code 工具，也可以用來操控高階語言，甚至用自然語言編程。 這不是簡單地「加一層 AI」，而是在整個技術棧中橫向滲透的東西。
正是這種「跨層抽象使用能力」，讓 LLMs 真正令人興奮。說這話的人，本身也是在 AI 出現之前就已功成名就的資深工程師。
4、Django 聯合創始人 Simon：真正的突破剛剛開始
Simon Willison 是 Django 框架的聯合創始人，靠寫部落格和開源維生，被 Andrej Karpathy 稱為「LLM 部落格必讀作者」。
他說：
「程式碼智能體確實可以跑得通，可以反覆循環、調試編譯器、幹實事。 過去 6 個月，大型語言模型的迭代明顯突破了一道門檻，現在開始真的『有用』了。」
5、Kent Beck：52 年程式設計師生涯，現在寫得最開心！
最後是重量級嘉賓：Kent Beck，極限編程（XP）之父，JUnit 作者，軟體工程界的活傳奇。
他說：
「我現在編程比過去 52 年任何時候都開心。」
他正在用 Smalltalk 寫一個平行虛擬伺服器的專案 —— 是他多年來的夢想。
他說 LLM 的出現讓他終於可以專注做自己真正想做的事，不用被工具框架牽著走。
在他眼中，LLM 是繼微處理器、網際網路、智能手機之後，又一次徹底改變成本結構的技術浪潮：
「過去我們因為貴、不現實而不做的事，現在突然變得便宜又容易。」
延伸：值得思考的四個問題
這些趨勢很有意思，但我認為現在仍然談不上「AI 已徹底改變軟體開發」。它遠不是那種「板上釘釘、未來已來」的故事。
所以我自己也留了 4 個問題：
❓問題一：為什麼創始人和 CEO 遠比工程師更興奮？
雖然有一些工程師確實很激動，比如 Armin 和 Peter，他們本身就可能是創業型人才。但比如 Warp 的創始人 Zack Lloyd 就問得很到位：
「有沒有人注意到，最資深的工程師往往不怎麼用 AI，最熱情的反而是創始人和產品經理？」
這可是一個做 AI 工具終端的創始人在反思。
再看那些 CEO 公開發言，幾乎都在極力宣傳 AI 的潛力。這值得我們思考。
❓問題二：AI 工具的使用在開發者中到底有多主流？
我讓現場舉手：「每週至少用一次 AI 工具寫程式碼的有多少人？」
現場大約有 60–70% 的人舉手。
這和 DX 的調查數據相符。他們最近調查了 3.8 萬名開發者，結果是：
- 一個典型組織中，大約 一半人每週使用 AI 工具；
- 最頂尖的公司能達到 六成。
但請注意，我演講裡講的大多數例子，其實都 高於這個中位數（除了那個 AI 生物新創公司）。
也可能有樣本偏差—— 願意分享經驗的人，本來就更願意使用 AI。
❓問題三：我們到底節省了多少時間？
比如 Pete 告訴我，他感覺自己產出效率提升了 10–20 倍。
但 DX 的調查顯示，AI 工具一週大約能幫開發者節省 3–5 小時，平均大概 4 小時。
4 小時也不賴，但要說「10 倍提升效率」就顯得有點誇張了。問題是： 我們真的把省下來的時間用來創造更多價值了嗎？
我也不知道。
❓問題四：為什麼 AI 對個人開發者特別有效，而對團隊卻效果不佳？
這個現象非常普遍。DX 的 Laura Tacho 也告訴我，AI 工具在「個體層面」表現不錯，但在「組織層面」尚未發揮價值。
CEO 和創始人如此熱情，不難理解，畢竟他們公司押寶 AI，也有財務壓力在身上。
大廠積極投資、探索 AI 工具，也說得通。
但最讓我在意的是那些「有年頭」的資深開發者，他們是真的用出了成果、感受到了變化、願意投入更多。
我覺得我們可能正處在一個軟體開發方式的「台階式變革」時刻。
我聯繫了軟體工程思想領袖 Martin Fowler，請他為我審閱的一篇文章給點看法。他的回答是：
「LLMs 將對軟體開發產生的影响，堪比當年從組合語言轉向高階語言的變革。
後來各種高階語言的更新，雖然改進了生產力，但沒有那種『質變』了。
但 LLM 是不同的：它是電腦歷史上第一次引入「非確定性」的工具，這非常關鍵。」
結語
我的結論是：變化正在發生，我們需要更大膽地去實驗。
我們應該像新創公司那樣多試錯，弄清楚：
- 什麼是有效的？
- 什麼是沒用的？
- 什麼是真的便宜了？
- 什麼才是真正值得投資的？
這場演講到這裡也告一段落，內容之扎實、視角之多元，令人回味。
你對演講中的這些觀察有沒有共鳴？
AI 寫程式碼對你來說，是賦能，還是添亂？歡迎在評論區聊聊你的真實感受