Claude含AI量超Cursor一倍!資深工程主管揭秘AI編碼真相!谷歌謹慎全搞自研 原創
編輯 | 伊風
出品 | 51CTO技術棧(微信號:blog51cto)
這應該是我聽過最扎實、最客觀的一場 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,用的是自己的代碼倉庫系統;
- 不用公開的 Code Review 工具,而是用內部工具 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(組織)都在搞屬于自己的 GenAI 工具,原因很簡單:領導層希望看到這種創新,而且這么做更容易拿到內部資源和預算支持。像 Notebook LM 這樣的工具,就是靠“某個團隊拉到預算就自己搞起來”的。
不過讓我印象最深的,是一位前 SRE 告訴我——他和很多 Google 的 SRE 還保持聯系——現在 Google 的基礎設施團隊正在為“10 倍代碼量”的增長做準備。他們在升級部署流水線、代碼審查工具、功能開關機制等等。
這讓我非常好奇:Google 是不是已經看到了某些我們還沒意識到的趨勢?
三、Amazon:采用AI比谷歌激進,但相當低調
談起 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 合作模式;?
- 最關鍵:agent 能自動執行、觀察反饋,這種機制可以極大地降低‘幻覺錯誤’的影響。
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 博客必讀作者”。
他說:
“代碼agent確實可以跑得通,可以反復循環、調試編譯器、干實事。 過去 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 寫代碼對你來說,是賦能,還是添亂?歡迎在評論區聊聊你的真實感受
本文轉載自??51CTO技術棧??,作者:伊風
