AI編程的落地真相調查，30位一線開發者給出了答案

（來源：麻省理工科技評論）

如果你現在去問一個程序員怎么看 AI 編程，可能會得到兩種截然不同的回答。

可能有人認為，AI 編程將把軟件開發者的生產力推到前所未有的高度；也可能有人批評它只會源源不斷地產出設計糟糕的代碼，不僅耗盡開發者的注意力，還會讓軟件項目在長期維護上埋下嚴重隱患。現階段，我們很難說哪種判斷更接近事實。

在科技巨頭向大語言模型（LLM）投入數十億美元之后，編程已成為這項技術最受推崇的殺手級應用。微軟 CEO 薩蒂亞·納德拉和谷歌 CEO 桑達爾·皮查伊都聲稱，他們的公司如今大約四分之一的代碼由 AI 生成。3 月，Anthropic 的 CEO 達里奧·阿莫代伊還預測，六個月內 90% 的代碼都將由 AI 編寫。

這種判斷聽起來似乎既誘人又順理成章：代碼也是一種語言，我們需要大量代碼，而人工編寫的成本很高；并且代碼是否可用也很容易驗證，只要運行程序就能立刻看出它是否能正常工作。

科技公司的高管們看中 AI 突破人類效率瓶頸的潛力，正在推動工程師更積極地擁抱 AI 驅動的未來。《麻省理工科技評論》在與 30 多位開發者、科技公司高管、分析師與研究人員交流后發現，實際上現實遠沒有宣傳中那么簡單。

隨著一次次碰到技術瓶頸，一部分一線開發者的最初熱情正在消退。而隨著越來越多研究顯示，所謂的生產力提升可能只是“幻象”，也有人開始質疑：皇帝是不是根本沒穿衣服。

不過，進步速度本身也讓問題變得更復雜。新模型的發布的節奏緊密不斷，這些工具的能力與脾氣都在不停演化；而它們的實際效果，往往取決于具體任務，以及組織圍繞它們搭建的流程與結構。所有這些因素疊加起來，讓開發者不得不在預期與現實之間的混亂落差中摸索前行。

借用狄更斯的名言來形容 AI 編程：這是最好的時代，還是最壞的時代？

也許兩者都是。

一個高速變化的領域

如今，幾乎沒有開發者能完全繞開 AI 編程工具。相關產品已經多到讓人難以分辨優劣：既有 Anthropic、OpenAI、Google 這樣的模型開發者提供的工具，也有 Cursor、Windsurf 這類公司把模型封裝進打磨精致的代碼編輯軟件里。根據 Stack Overflow 的 2025 年開發者調查，這些工具正被迅速采用：65% 的開發者如今至少每周使用一次。

AI 編程工具大約在 2016 年出現，但隨著 LLM 的到來得到了加速。早期版本幾乎只是給程序員做自動補全，提示下一步該敲什么；而今天，它們已經可以分析整個代碼庫、跨文件編輯、修復 bug，甚至生成解釋代碼如何工作的文檔。所有這些都可以通過聊天界面，用自然語言提示來引導完成。

智能體（agents）是 AI 編程的最新前沿：這類由 LLM 驅動的自主編程工具可以接收一個抽象的目標，然后獨立構建完整程序。實現這一躍遷的關鍵，是最新的推理模型（reasoning models）：它們能把復雜問題拆成步驟逐一解決，更重要的是，還能訪問外部工具來完成任務。Anthropic 編程智能體 Claude Code 的負責人 Boris Cherny 說：“正因為如此，模型才是真正在寫代碼，而不是只會聊編程。”

在軟件工程基準測試（用來衡量模型表現的標準化測試）上，這些智能體取得了令人印象深刻的進展。OpenAI 在 2024 年 8 月推出 SWE-bench Verified 基準，為評估智能體在開源代碼庫中修復真實 bug 的成功率提供了一種方法；當時最強模型只能解決 33% 的問題。一年后，領先模型的得分已穩定超過 70%。

2 月，OpenAI 創始成員、特斯拉前 AI 負責人 Andrej Karpathy 提出了 vibe coding（氛圍編程）一詞，指的是一種做法：人們用自然語言描述軟件需求，讓 AI 編寫、完善并調試代碼。社交媒體上充斥著認同這種愿景的開發者，他們宣稱自己的生產力獲得了巨大提升。

但盡管一些開發者和公司報告了這樣的效率提升，更“硬”的證據卻更為復雜。來自 GitHub、Google 和 Microsoft（它們也都是 AI 工具供應商）的早期研究發現，開發者完成任務速度快了 20% 到 55%。不過，咨詢公司貝恩（Bain & Company）在 9 月的一份報告中形容，真實世界的節省效果“并不顯著”。

開發者分析公司 GitClear 的數據顯示，自 2022 年以來，大多數工程師產出的“更耐久的代碼”（即不會在幾周內被刪除或重寫的代碼）大約增加了 10%，這很可能得益于 AI。但這種提升伴隨著多項代碼質量指標的明顯下滑。Stack Overflow 的調查也發現，人們對 AI 工具的信任和正面情緒首次出現顯著下降。

更具挑釁意味的是，非營利研究機構 Model Evaluation & Threat Research（METR）在 7 月的一項研究顯示：經驗豐富的開發者認為 AI 讓他們快了 20%，但客觀測試表明他們實際上慢了 19%。

日益增長的幻滅感

對軟件咨詢公司 Substantial 的首席開發者 Mike Judge 來說，METR 的研究戳中了他的痛點。他曾是 AI 工具的熱情早期用戶，但隨著時間推移，他越來越受挫于這些工具的局限，以及它們對自己生產力帶來的有限提升。他說：“我會跟人抱怨，因為我覺得，它確實在幫我，但我就是搞不清怎樣才能讓它真正大幅幫到我。”他還說：“我總覺得 AI 很笨，但也許只要我找到正確的‘咒語’，就能把它騙得聰明一點。”

朋友問起時，Judge 曾估計這些工具大概能讓他提速 25%。所以，當他在 METR 研究中看到開發者給出類似估計時，決定親自測試。連續六周，他先估算一項任務需要多久，再拋硬幣決定用 AI 還是手寫代碼，然后計時。令他驚訝的是，AI 讓他的速度中位數下降了 21%，與 METR 的結果如出一轍。

這促使 Judge 自己動手做了一次數據分析。他推理說，如果這些工具真的讓開發者大幅提速，那么應該能看到新應用、網站注冊、電子游戲，以及 GitHub 項目數量出現爆發式增長。他花了幾個小時、又花了幾百美元，分析所有公開可得的數據，結果發現各項曲線幾乎都“橫著走”。

Judge 說：“這難道不應該向右上方飆升嗎？這些圖里所謂的‘冰球桿曲線’在哪里？我以為大家都變得異常高產。”他認為，一個顯而易見的結論是：對大多數開發者而言，AI 工具提供的生產力提升并不大。

接受《麻省理工科技評論》采訪的開發者總體上認可 AI 工具擅長的地方有：生成樣板代碼（boilerplate code）（指幾乎無需修改、在多個地方重復使用的可復用代碼片段）、編寫測試、修復 bug，以及向新開發者解釋陌生代碼。有幾位指出，AI 能通過提供一個并不完美的初版來幫助解決空白頁問題，從而激發開發者的思路。此外，它還可以讓非技術同事快速做出功能原型，減輕本就過載的工程師負擔。

這些任務往往枯燥，開發者通常樂于把它們交給工具。但其只占資深工程師工作量的一小部分。對于那些更復雜、真正體現工程師價值的難題，許多開發者告訴《麻省理工科技評論》，這些工具仍面臨顯著挑戰。

也許最大的問題在于，LLM 只能在上下文窗口（context window）里容納有限的信息，這本質上就是它們的工作記憶。這意味著它們很難解析大型代碼庫，也容易在耗時更長的任務中忘記自己在做什么。Judge 說：“它會變得非常短視，只盯著眼前那一小塊。你讓它做十二件事，它會做完十一件，然后把最后一件給忘了。”

LLM 的這種“近視”，會讓人類程序員非常頭疼。LLM 針對某個問題給出的代碼，也許單獨運行沒問題，但軟件由成百上千個相互連接的模塊組成。如果生成的模塊沒有考慮軟件的其他部分，很快就會導致代碼庫糾纏不清、前后不一致，讓人類難以理解，更重要的是難以維護。

傳統上，開發者會通過遵循既定傳統（conventions）來應對這一點：也就是一些定義并不嚴格、但在不同項目與團隊之間差異很大的編碼準則。

GitClear 的 CEO Bill Harding 說：“AI 有一種壓倒性的傾向，即不理解一個代碼庫里已經存在的既定傳統。于是，它很可能會自己想出一種略有不同的解法版本。”

模型也會直接出錯。和所有 LLM 一樣，編程模型容易產生幻覺，這是它們工作方式內生的問題。但廣告技術公司 Mediaocean 的軟件工程總監 James Liu 說，因為它們輸出的代碼看起來非常像模像樣，錯誤反而更難被發現。把這些缺陷疊加起來，使用這些工具的體驗就很像拉一臺單臂老虎機的把手。Liu 說：“有些項目里，你能在速度或效率上得到 20 倍提升；但在另一些事情上，它會徹底翻車，然后花大量時間試圖讓它實現你想要的愿望，結果它就是做不到。”

Judge 懷疑，這正是工程師經常高估生產力提升的原因。他說：“你會記住中大獎的時候；但是，你不會記得自己坐在那里往老虎機里塞籌碼塞了兩小時。”

如果開發者對任務并不熟悉，問題可能更嚴重。Judge 記得自己曾讓 AI 幫忙配置微軟的云服務 Azure Functions，而他此前從未用過。他以為大概需要兩小時，但九小時后他放棄了。他說：“它不斷把我帶進一個又一個死胡同，而我對這個主題了解不夠，甚至沒法對它抱怨‘嘿，這完全不合邏輯’。”

技術債正在被快速堆高

達特茅斯學院工程創新教授 Geoffrey G. Parker 表示，開發者不斷在開發速度與代碼可維護性之間做權衡，從而產生所謂的“技術債（technical debt）”。每一次走捷徑都會增加復雜度，讓代碼庫更難管理，并累積需要通過重構來償還的“利息”。隨著技術債越堆越高，新增功能與維護軟件都會變得更慢、更難。

Harding 說，在大多數項目里技術債的累積幾乎不可避免，但 AI 工具讓時間緊張的工程師更容易走捷徑。GitClear 的數據表明，這正在以規模化的方式發生。自 2022 年以來，公司觀察到復制粘貼代碼的數量顯著上升，這表明開發者復用更多代碼片段，很可能來自 AI 的建議；與此同時，“代碼從一個地方移動到另一個地方”的數量下降得更厲害，而這種移動往往發生在開發者清理、整理代碼庫時。

代碼質量檢查工具公司 Sonar 的 CEO Tariq Shaukat 說，隨著模型不斷改進，它們生成的代碼變得越來越冗長、越來越復雜。這會減少明顯 bug 和安全漏洞的數量，但代價是代碼異味（code smells）增加，也就是更難精準定位、卻會導致維護問題與技術債的缺陷。

Sonar 的最新研究發現，在領先 AI 模型生成的代碼中，這類問題占其發現問題的 90% 以上。Shaukat 說：“容易發現的問題正在消失，剩下的是更復雜、需要花時間才能找出來的問題。這正是我們目前對這個領域最擔心的地方，你幾乎會被哄進一種虛假的安全感里。”

喬治城大學的安全研究員 Jessica Ji 表示，如果 AI 工具讓代碼越來越難維護，可能會引發嚴重的安全問題。Ji 說：“更新和修復越困難，代碼庫或任何一段代碼隨著時間推移變得不安全的可能性就越大。”

她說，還存在更具體的安全擔憂。研究人員發現了一類令人不安的“幻覺”：模型會在代碼里引用并不存在的軟件包。攻擊者可以利用這一點，創建同名但含有漏洞的軟件包，隨后模型或開發者可能在不知情的情況下把它們引入軟件中。

LLM 也容易遭受數據投毒攻擊（data-poisoning attacks）：黑客向模型訓練所用的公開數據集注入數據，以不良方式改變模型行為，例如在特定短語觸發下生成不安全的代碼。Anthropic 在 10 月的一項研究中發現，無論模型規模多大，只需要 250 份惡意文檔就可能向 LLM 引入這種“后門”。

開始轉向擁抱 AI 的人

不過，盡管存在這些問題，現實可能已難以回頭。微軟旗下代碼托管平臺 GitHub 的首席運營官 Kyle Daigle 說：“很可能，用鍵盤手工敲下每一行代碼的日子，正在迅速成為過去。”GitHub 出品了一款流行的 AI 工具 Copilot（不要與微軟同名產品混淆）。

Stack Overflow 的報告發現，盡管人們對這項技術的不信任在加深，但過去三年里使用率仍快速且持續增長。Stack Overflow 的高級分析師 Erin Yepis 表示，這意味著工程師在利用這些工具時，對風險保持相對清醒的認知。報告還發現，高頻用戶往往更熱情；而超過一半的開發者并未使用最新的編程智能體，這也許解釋了為什么許多人仍對這項技術感到“不過如此”。

但最新工具也可能帶來醍醐灌頂的體驗。軟件開發機構 Twenty20 Ideas 的 CTO Trevor Dilley 說，他曾覺得 AI 編輯器的自動補全有點價值，但一嘗試更復雜的事情就會失敗。后來在 3 月，他和家人度假時，讓剛發布的 Claude Code 去處理他的一個業余項目。它在兩分鐘內完成了一項原本要四小時的任務，而且代碼比他自己寫的還要好。

他說：“我當時就想，對我來說那一刻才是真正的轉折點。從這里開始就回不去了。”此后，Dilley 聯合創辦了名為 DevSwarm 的初創公司，開發能夠調度多個智能體并行開發同一軟件的系統。

知名開源開發者 Armin Ronacher 認為，難點在于這些工具的學習曲線“起步很淺，但路很長”。到 3 月為止他對 AI 工具仍不以為然，但 4 月他離開軟件公司 Sentry 去創業后，開始試驗智能體。“我基本上花了好幾個月什么都不干，就只做這個。”他說，“現在，我寫的代碼里 90% 都是 AI 生成的。”

要達到這種程度需要大量試錯，以弄清楚哪些問題容易把工具絆倒，哪些問題它們能高效處理。Ronacher 說，只要有合適的護欄，當下模型可以應對大多數編程任務，但這些護欄往往與具體任務和項目高度相關。

獸醫人力公司 IndeVets 的 CTO Nico Westerdale 表示，要把這些工具用到極致，開發者必須放棄對每一行代碼的控制，把注意力轉向整體軟件架構。他最近構建了一個數據科學平臺，代碼量達 10 萬行，幾乎完全是通過提示模型來完成，而不是自己逐行編寫。

Westerdale 的流程從與模型進行一段較長對話開始，用來形成“要做什么、怎么做”的詳細計劃；接著，他再引導模型一步步執行。模型很少一次就能做對，需要持續“拽著走”，但 Westerdale 說，只要你強制它遵循明確的設計模式，模型就能生成高質量、易維護的代碼。他會審查每一行，并表示這些代碼不比他過去產出的任何作品差：“我覺得它完全是革命性的。當然，它也很讓人挫敗、很難、是一種不同的思考方式，而我們才剛剛開始適應。”

但當個體開發者逐漸學會有效使用這些工具時，要在大型工程團隊里獲得一致的效果就難得多。Google 產品管理高級總監 Ryan J. Salva 說，AI 工具會放大工程文化中的優點與缺點：如果你有強流程、清晰的編碼模式、定義明確的最佳實踐，它們就能大放異彩。

但如果你的開發流程本來就混亂，它們只會把問題放大。同樣關鍵的是把組織內部的經驗知識制度化、文檔化，讓模型能夠有效調用。Salva 說：“為了建立足夠的上下文、把那些口耳相傳的隱性知識從我們腦子里拿出來，有大量工作要做。”

加密貨幣交易所 Coinbase 一直高調談論自己對 AI 工具的采用。CEO Brian Armstrong 在 8 月披露公司解雇了不愿使用 AI 工具的員工，一度引發關注。但 Coinbase 的平臺負責人 Rob Witoff 告訴《麻省理工科技評論》，盡管他們在某些方面看到了生產力的巨大提升，但整體效果卻并不均衡。對重構代碼庫、編寫測試這類更簡單的任務，AI 驅動的工作流最高能實現 90% 的提速；但對其他任務，提升更有限，而且改造既有流程帶來的擾動往往會抵消編碼速度的增長，Witoff 說。

其中一個因素是，AI 工具讓初級開發者能夠產出更多代碼。像幾乎所有工程團隊一樣，這些代碼必須由其他人（通常是更資深的開發者）進行評審，以發現 bug 并確保符合質量標準。但如今被“卷”出來的代碼量之大，正在迅速壓滿中層人員審查變更的能力。Witoff 說：“我們幾乎每個月都在經歷這樣一個循環：我們在技術棧更底層自動化了一件新事，于是更上層就承受更大壓力。然后我們又開始考慮把自動化應用到更上層的部分。”

貝恩合伙人 Jue Wang 說，開發者真正用于寫代碼的時間只有 20% 到 40%，所以即便編碼本身大幅提速，整體收益也往往更為有限。開發者其余時間要用于分析軟件問題、處理客戶反饋、產品策略以及行政事務。Jue 表示，要獲得顯著的效率提升，公司可能也需要把生成式 AI 應用于這些其他流程，但這仍在推進之中。

飛速迭代

用智能體來編程與以往工作方式差異巨大，所以公司會遇到“長牙期”的問題并不意外。況且這些產品都很新，幾乎每天都在變。Anthropic 的 Cherny 說：“每隔幾個月模型就會變強，編碼能力會出現一次大的階躍式提升，你就必須重新校準自己的使用方式。”

例如，Anthropic 在 6 月為 Claude 引入了內置的規劃模式（planning mode），后來也被其他提供商效仿。10 月，公司又讓 Claude 在需要更多上下文或面對多種可行解法時向用戶提問。Cherny 指出，這有助于它避免“直接自作主張地認為某條路徑最好”的傾向。

最重要的是，Anthropic 增加了一些功能，讓 Claude 更擅長管理自己的上下文。Cherny 說，當它接近工作記憶的上限時，會自動總結關鍵細節，并基于這些總結開啟一個新的上下文窗口，從而在效果上擁有一個“無限”的窗口。Claude 還可以調用子智能體（sub-agents）處理更小的任務，這樣它就不必把項目的所有方面都同時裝在“自己腦子里”。公司聲稱，其最新模型 Claude 4.5 Sonnet 現在可以連續自主編碼超過 30 小時，而不會出現明顯的性能衰減。

軟件開發中的新方法也可能繞開編程智能體的其他缺陷。MIT 教授 Max Tegmark 提出一種他稱為 vericoding 的概念，可能讓智能體從自然語言描述出發生成完全沒有 bug 的代碼。它基于形式化驗證（formal verification）方法：開發者為軟件建立數學模型，從而無可辯駁地證明其功能正確。這種方法用于飛行控制系統、密碼學庫等高風險領域，但由于成本高、耗時長，一直限制了其更廣泛的應用。

Tegmark 說，LLM 數學能力的快速提升帶來一個誘人的可能性：模型不僅能產出軟件，還能給出無 bug 的數學證明。“你只要給出規格說明，AI 就會返回可被證明正確的代碼，”他說，“你不需要碰代碼，甚至都不必看代碼。”

根據 Tegmark 團隊一項未經同行評審的研究，在 Dafny（為形式化驗證設計的語言）中大約 2,000 個 vericoding 題目上測試時，表現最好的 LLM 解決了超過 60%。這一結果是在“開箱即用”的通用 LLM 上實現的，Tegmark 預計，如果針對 vericoding 做專門訓練，得分可能會快速提升。

但出乎意料的是，AI 生成代碼的速度也許反而能緩解可維護性的擔憂。商業軟件巨頭 Intuit 的首席工程師 Alex Worden 指出，維護之所以困難，往往是因為工程師在不同項目間復用組件，形成一團依賴關系：一次改動會在整個代碼庫里引發連鎖反應。過去復用代碼能節省時間，但在一個 AI 幾秒鐘就能生成數百行代碼的世界里，這種必須復用的動力已經消失了。

因此，他主張可棄用代碼（disposable code）：每個組件都由 AI 獨立生成，不必考慮它是否遵循某種設計模式或約定；然后再通過 API（讓組件彼此請求信息或服務的一組規則）把它們連接起來。Worden 說，由于每個組件的內部實現不依賴代碼庫的其他部分，就可以在不產生更大影響的情況下將其替換或移除。

他說：“行業仍在擔心人類如何維護 AI 生成的代碼。但我懷疑人類還會看代碼、或在乎代碼多久。”

程序員的人才梯隊正在變窄

不過在可預見的未來，人類仍需要理解并維護支撐項目運行的代碼。而 AI 工具最隱蔽、也最棘手的副作用之一，可能是能勝任這項工作的人才池在縮小。

一些早期證據表明，人們對 AI 摧毀崗位的擔憂可能并非空穴來風。斯坦福大學最近的一項研究發現，在 2022 年到 2025 年間，22 到 25 歲軟件開發者的就業人數下降了近 20%，這與 AI 編程工具的興起時間相吻合。

資深開發者也可能遇到困難。游戲基礎設施開發公司 Companion Group 的工程師 Luciano Nooijen 在日常工作中大量使用 AI 工具，因為公司免費提供；但當他開始一個無法使用這些工具的副業項目時，他發現自己竟在過去本能完成的任務上頻頻卡殼。“我感覺自己很蠢，因為以前憑直覺就能做的事變成了手工操作，有時甚至很笨重。”Nooijen 說。

與運動員仍要做基礎訓練類似，他認為保持編碼“手感”的唯一方式，就是定期練習那些苦活累活。這也是他基本棄用 AI 工具的原因，盡管他承認背后也還有更深層的動機。

Nooijen 和《麻省理工科技評論》采訪到的其他開發者之所以抵觸 AI 工具，部分原因在于他們認為：這些工具正在掏空工作中他們熱愛的那部分。“我進入軟件工程行業，是因為我喜歡和計算機打交道，我喜歡讓機器按我想要的方式做事。”Nooijen 說，“但如果只是坐在那里，看著原本屬于我的工作被代勞，那一點也不好玩。”

https://www.technologyreview.com/2025/12/15/1128352/rise-of-ai-coding-developers-2026/