42%的代碼是AI寫的，可96%的開發者不信它：誰敢拍板說“上線”？這成了2026年最大挑戰

作者丨SEDaily

譯者丨明知山

策劃丨Tina

“我批準將這段代碼投入生產環境，并承擔隨之而來的所有風險。”2026 年最大的挑戰，就是找到愿意說出這句話的人。

AI 編碼已經不是嘗鮮工具，而是進入了生產環境。Sonar 每天分析 7500 億行代碼，他們在最新《開發者代碼現狀調查報告》中看到一個很刺眼的矛盾：72% 的開發者每天使用 AI 編碼工具，42% 的代碼已經由 AI 生成或輔助完成，但 96% 的開發者仍然無法完全信任 AI 生成的代碼。

這意味著，軟件工程正在從“怎么寫出更多代碼”，轉向另一個更棘手的問題：代碼可以由 AI 批量生成，但誰來確認它足夠安全、可靠、可維護？誰敢簽字讓它上線？這也成了 2026 年工程團隊繞不開的挑戰。

Sonar 是一家專注代碼質量與安全分析的公司，核心產品 SonarQube 已被全球超過 700 萬開發者使用。在本期節目中，Sonar 企業營銷高級副總裁 Chris Grams、產品營銷與開發者關系副總裁 Manish Kapur，與擁有二十余年工程管理經驗的 Matt Merrill 討論了這份報告背后的真實信號：AI 為什么讓代碼生成更快，卻讓審核、測試、治理變得更重？為什么 35% 的開發者會繞過企業授權工具使用“影子 AI”？為什么 AI 生成代碼不一定需要重造審核流程，反而更需要確定性校驗、質量門禁和人工責任制？

當 AI 從實驗工具變成開發基礎設施，真正的瓶頸不再是代碼產出，而是信任、質量和責任。

1 AI 代碼的信任鴻溝：42% 生成率與 96% 不信任”

Matt Merrill：今天我和來自 Sonar 的兩位嘉賓一起聊聊《開發者代碼現狀調查報告》。開始之前，Manish、Chris，二位能否先簡單介紹一下自己，聊聊個人背景以及各自在 Sonar 負責的工作？

Chris Grams：我是 Chris Grams，在 Sonar 擔任企業營銷副總裁——這個頭銜聽起來或許會讓人失去收聽興趣，但我想說的是，我同時也是公司內部的數據與調研負責人，所以我對這份調查報告的熟悉程度可能超過大多數人。我在企業技術領域工作了很久。職業生涯早期我在 Red Hat 待了大約十年，之后在多家軟件公司擔任顧問，后來又成為 Tidelift 的早期員工之一——這家公司為開源維護者提供贊助，大約一年前被 Sonar 收購。我也正是在一年多前正式加入 Sonar 任職。

Manish Kapur：我是 Manish，目前在奧斯汀工作。我加入 Sonar 已有兩年半左右，馬上就要滿三年了。和 Chris 一樣，我也擁有多年企業軟件行業從業背景。我最初在 Sun Microsystems，之后加入 Oracle，現在來到了 Sonar。我職業生涯中扮演過多種角色。目前我是 Sonar 的產品營銷與開發者關系副總裁，但也曾擔任過產品經理、開發者關系負責人和其他售前等技術崗位。我算是比較偏技術、愛動手的類型。很期待今天與你交流。

Matt Merrill：那 Sonar 呢？如果有聽眾不太熟悉 Sonar，二位能簡單介紹一下這家公司是做什么的、都提供哪些產品嗎？

Chris Grams：我們的核心產品是 SonarQube，已經存在很長時間了，全球有超過 700 萬開發者在使用。簡單來說，你可以把 Sonar 理解為代碼的必備驗證層——無論是 AI 生成的代碼，還是開發者手寫的代碼，我們都能幫助確保代碼的質量和安全。現在，隨著 AI 智能體越來越多地參與編碼，我們的作用也延伸到了這個領域。

為了讓大家直觀了解 Sonar 的業務規模：我們每天分析 7500 億行代碼。我們的使命是幫助各類企業確保部署到生產環境的代碼具備高質量、高安全性且易于維護。

Matt Merrill：我認真閱讀了這份調查報告，非常有意思。作為一個有工程領導背景、之前主要從事后端工程等工作的人，我的第一反應是：怎么又來了一份調查報告？它和的 Stack Overflow 調查報告有什么不同？但深入閱讀后，我發現這份報告真的很獨特。如果可以的話，你們認為從這份調查中能收獲哪些 Stack Overflow 調查無法提供的內容？

Chris Grams：首先，能與 Stack Overflow 調查報告被一同提及，我們感到很榮幸。我們的目標是躋身 Stack Overflow 調查報告、GitHub Octoverse 報告等優質開發者調研行列。在我們看來，這類行業調研能夠引領行業方向， 幫助開發者與技術管理者掌握有效信息，做出合理決策。如果我們的調查報告能取得成功，就能成為這些優質的開發者調查報告行列中的一員。我們希望能夠提供增量的價值——Sonar 能夠輸出哪些獨一無二的行業視角？

我認為究其根本原因在于：我們非常了解代碼——正如我剛才所說，我們每天分析 7500 億行代碼。今年早些時候，我們啟動了“代碼現狀”系列研究工作，做了大量的分析。希望稍后有機會聊聊我們在探究主流大語言模型編碼特性方面所做的研究。我們還從可維護性、安全性等角度分析了代碼，并發布了一系列相關報告。對于這份報告，我們的想法是：我們已經從可維護性、安全性、可靠性等角度審視了代碼；我們也研究了大語言模型生成的代碼。現在我們想關注的是：每天使用這些新編碼工具的開發者們是怎么看的？他們對當前的技術發展現狀有什么看法？

這可以說是 Sonar 版本的“代碼現狀”人文視角——深入了解開發者對這個正飛速變化的世界有何看法，認清我們當下所處的階段。最后我想要強調的是：這份調查是在去年 10 月左右進行的，而在那之后行業環境又發生了巨大變化。在討論過程中，我們會花一點時間談談那些我們認為仍然具有參考價值的數據，以及我和 Manish 認為自調查以來已經發生了哪些變化。

Matt Merrill：我很喜歡你提到的“人文視角”，這也正是我的感受——你們用這些數據講述了一個很好的故事。我很好奇，能否介紹一下這份數據的收集與分析方式？不得不說，這份報告做得十分出色。

Chris Grams：我做這類調查已經有很長時間了。實際上，我大概 20 多年前在 Red Hat 就開始做開發者調查了，還參與了 Red Hat 最早的一些研究數據工作。我一直認為，好的研究不只是堆砌數據。我始終秉持這樣的理念：不要只羅列數據，而是要輸出有效結論。核心要點是什么，或是有哪些關鍵的發現？我們在設計調查報告時也會帶著一些強烈的假設和觀點，認為部分現象是大概率真實存在的。我們想驗證人們是否同意我們的看法，這是否也是他們的視角，或者有哪些地方我們可能錯了。本次調研中，就有幾處案例印證我們原先的假設并不成立。

我們會帶著預設的調研視角開展項目，但有時也會發掘出新的內容。這次調研便是兩者兼而有之：部分數據印證了我們的判斷，也有不少結果出乎我們的意料。

Matt Merrill：我們已經聊了很多關于調查的背景內容，接下來就正式進入調研結果部分。我們先從重磅的發現開始。這個問題想請二位都聊聊。Chris，你可以先來講講。你最直觀、最深刻的收獲是什么？哪些內容最能引發你們的共鳴？

Chris Grams：我認為從整體層面來看，有幾項數據在我們初次看到時十分令人震驚。例如，有 72% 使用過 AI 工具的開發者如今已經做到每日高頻使用。如果現在這個數字比 72% 更高，我不會感到驚訝。但在去年秋天我們初次拿到這份數據時，72% 這個數字已經相當驚人，也大致印證驗證了我們預判的趨勢。此外，我們還讓開發者如實說明，日常編寫的代碼當中，由 AI 生成的占比有多少——我們還詢問了他們當前的現狀和對未來的預期，比如幾年后他們認為這個比例會是多少。

我們得到的結果是：目前開發者編寫的代碼中已有 42% 是 AI 生成或 AI 輔助完成的。42%，這個比例很瘋狂。到 2027 年，開發者預計這個數字將攀升至約 65%。回想一下，去年 1 月我剛加入 Sonar 時，絕大多數開發者還對 AI 工具產出的代碼心存疑慮。而截至去年秋天，已有 42% 的代碼由 AI 生成，這非常有趣。我還要補充另一個數據：當我們詢問開發者他們對 AI 生成代碼的準確性抱有多大信任時，96% 的開發者表示他們并不完全信任 AI 生成的代碼。

這就形成了一種鮮明反差：42% 的代碼由 AI 編寫，未來幾年還將攀升至 65%，但開發者卻并不真正信任這些代碼。由此便產生了一道亟待解決的驗證鴻溝，也可以說是信任鴻溝。這或許就是本次調研最重要的發現。

2 代碼快了，工程慢了

Matt Merrill：結合我的經驗與日常工作來看，這個結論完全合理。我越來越多地聽到關于智能體代碼審查的事，甚至出現了讓智能體互相校驗、交叉驗證的做法。這是一項非常有意思的發現。Manish，你最大的收獲是什么？

Manish Kapur：我認同 Chris 的觀點。整體而言，我對此倍感意外。最讓我吃驚的是，AI 編碼場景的落地與普及速度極快。回首來看，初代 GPT 模型問世不過兩年半左右，而現如今，超 72% 的開發者每天都在使用 AI 編碼工具，這已然成為他們的日常工作常態。這個數據來源于上個季度，我確信目前這一占比仍在持續攀升，未來甚至會達到 80%、90%，開發者的日常工作早已離不開這類工具。

AI 編碼應用場景的爆發速度以及在全行業的普及程度都超乎想象。我還發現，AI 雖然大幅加快了代碼生成效率，卻拖慢了代碼生成之后的全流程工作，而這部分恰恰是軟件工程中占比極高、不可或缺的環節。代碼生成只是第一步，后續還有代碼審核、校驗、調試、集成測試以及長期維護等一系列工作。目前，這些配套環節的效率提升速度完全跟不上 AI 代碼的產出速度。

智能體還會進一步放大這種影響。正如 Matt 剛才所說的，隨著各類編碼工具持續迭代，智能體技術也隨之快速發展，未來會出現大批協同運轉、相互交互的智能體集群。整個行業的技術演進節奏都會因此大幅提速。最終的發展走向仍有待觀察，我十分期待后續的變化。對我而言，手寫編碼早已不再是難題，真正的挑戰在于代碼寫完之后的各項工作；以及在智能體互聯互通、開發者逐步脫離日常編碼與完整開發流程的大環境下行業會迎來怎樣的變革。

Matt Merrill：我同樣滿懷期待，迫切想要見證后續的發展。談及 AI 工具的快速普及，我在日常工作中發現一個現象：開發者們普遍主動想要使用這類工具。一方面，行業環境帶來了無形的推動壓力；另一方面，大家自身的探索意愿也在不斷增強。不少開發者會使用個人賬號處理工作事務、訪問 AI 工具，只為提升工作效率、嘗試新興技術。你們的報告中也提到了不少有意思的調研結論，方便和我們分享一下嗎？

Manish Kapur：這一調研結果同樣出乎我們的意料。目前企業內普遍存在大量影子 AI 的使用行為。這里所說的影子 AI，具體是指近 35% 的開發者會繞過企業官方授權工具使用個人賬號登錄第三方 AI 平臺開展工作。其實這一點不難理解，Matt，你本身就是技術從業者，我也擁有技術背景，雖算不上專職開發者，但也長期編寫代碼。開發者天生樂于創造、熱衷探索與嘗試，所有人都想體驗前沿頂尖的技術與工具，緊跟行業的前沿發展趨勢。

行業變革日新月異，這正是開發者不愿局限于企業指定工具的核心原因。隨著智能體逐步落地，這類現象愈發普遍：開發者開始借助智能體掃描代碼倉庫、編寫遷移腳本、重構老舊代碼模塊，這類操作早已成為日常。但這也暗藏風險，開發者向第三方非合規工具、影子 IT 平臺傳輸代碼、提示詞、業務數據及上下文信息時，會直接導致企業知識產權與數據隱私面臨泄露隱患。

遺憾的是，現階段企業針對這類行為的管理制度與管控體系尚不完善。未來隨著大量智能體實現協同工作，整體管控難度還會大幅增加，短期內行業必將面臨一系列管理難題，但我相信，和過往各類技術難題一樣，我們最終都能找到解決方案。

在管控治理層面，有一條核心原則始終不變：無論使用企業合規工具還是個人第三方工具，所有 AI 生成的代碼都必須經過嚴格核驗，后續的全流程管控環節缺一不可。企業需要進一步強化審核力度，全面校驗代碼可靠性，確保代碼能夠直接投入生產環境使用。

Matt Merrill：就在今天，公司隱私合規部門的同事還專門強調，若團隊使用 AI 工具，務必將相關合規要求納入合作協議，與軟件開發行業的規范標準保持一致。當下明顯呈現出本末倒置的現狀：全員都在被迫擁抱 AI 工具，但對應的合規管控、風險約束機制卻嚴重滯后。這個問題確實值得重視。Chris，針對這份調研結論，你還有其他內容想要補充嗎？

Chris Grams：我再補充一點，主要圍繞企業內部工具的使用數量展開。目前各大企業普遍在試水各類不同的 AI 工具，調研數據顯示，人均會同時使用四款不同的 AI 工具。

Matt Merrill：這個數量超出了我的預期。

Chris Grams：不同從業者的工具使用數量存在明顯差異，有人使用得多，有人使用得少。結合去年秋季的調研數據來看，當下 AI 工具賽道尚未決出絕對頭部產品。不過近一兩個月，Claude 的市場競爭力大幅提升，表現十分亮眼。整體來看，行業依舊處于多方工具測試、百花齊放的階段。

Matt Merrill：確實如此。直到去年 11 月，我還無法判定哪款工具更具優勢，但體驗過 Claude 之后，不得不承認它的表現極為出色。除此之外，企業的流程迭代速度遠遠跟不上技術變革節奏，開發者自行注冊試用新興工具也就成了必然，這種現象的出現并不難理解。

Chris Grams：如果企業采購的官方工具已經淪為市場中下游產品，想要更換新工具，還要走完繁瑣的企業采購審批流程，而使用第三方工具能夠數倍提升工作效率。即便從企業風控角度來看存在隱患，也不難理解開發者做出這類冒險選擇的原因。

3 AI 消滅了重復勞動，但新的低效工作正在生成

Matt Merrill：確實是這樣。我們換個話題。這份報告里有兩個內容讓我格外關注，其中一個是“低效工作轉移”這一概念。能否為我們解讀一下這個概念，以及相關的調研發現？

Chris Grams：這也是我們調研中意外發現的結論之一。我們原本預設 AI 會大幅削減開發者的重復性低效工作，比如編寫文檔、撰寫測試用例這類耗時繁瑣、流程化的基礎工作。當我們直接詢問受訪者 AI 是否減少了日常低效工作時，超七成受訪者給出了肯定答案。75% 的人表示，AI 確實降低了重復性工作負擔。

但實際情況遠比表面上看的更為復雜。結合工具使用頻率展開進一步調研后發現：低頻使用 AI 的開發者依舊被傳統低效工作束縛；而高頻使用 AI 的開發者雖然擺脫了舊有的繁瑣工作，卻面臨新的低效任務。值得注意的是，兩類開發者花費在低效工作上的總時長基本持平，只是工作內容發生了變化。以往編寫文檔這類基礎工作如今都可以交由 AI 高效完成，徹底解放了人力。

隨之而來的新的工作難題：AI 極速批量生成代碼后，開發者需要投入大量精力逐一核驗代碼質量、排查安全漏洞，代碼審核校驗成為了新的低效工作。究其根本，AI 無需為生成代碼的質量承擔責任，所有風險與責任最終都會落到人類開發者身上。這也是當下低效工作轉型背后最大的挑戰。既然責任無法轉嫁，人工逐行核驗 AI 生成代碼就成了硬性要求，這類工作往往枯燥繁瑣，卻又必不可少，畢竟在責任認定層面，AI 產出的代碼等同于開發者親自編寫。

Matt Merrill：我經常用一個類比和身邊人探討這類問題，或許不算完全貼切，但很貼合當下的現狀：電子表格問世之后，會計行業并沒有消失，只是工作內容發生了變化。AI 之于開發行業，也是同樣的道理。“低效工作轉移”這個定義十分貼切，我之后也會沿用這個說法。

Manish Kapur：38% 的開發者認為，審核 AI 生成代碼的難度遠高于人工編寫的代碼。這一點在代碼審核環節體現得尤為明顯，也是讓我感觸很深的一個細節。

Matt Merrill：理解 AI 生成代碼的邏輯脈絡、梳理完整業務鏈路確實要困難得多，這個結論完全合理。

Chris Grams：我們還發現，審核 AI 生成代碼如同大海撈針。隨著大模型持續迭代，AI 產出代碼的性能、安全性與整體質量不斷優化，潛藏的漏洞與問題也變得更加隱蔽。人工審核他人編寫的代碼尚且存在難度，更何況是無人工參與、由 AI 獨立生成的代碼。這類代碼的整體問題數量或許有所減少，但殘留的隱患往往更具隱蔽性與危害性，排查難度大幅增加。

Matt Merrill：完全認同。Sonar 的核心產品之一是靜態代碼分析工具。能否分享一下目前客戶在借助靜態分析技術時都通過哪些創新方式應對 AI 編碼帶來的各類隱患與挑戰？

Manish Kapur：過去 17 年里，很多企業一直選擇并將我們視作業界公認的代碼質量標桿。事實上，我們的能力遠不止代碼質量管控。我們的分析引擎不僅會從代碼質量、安全、可靠性、可維護性和復雜度等維度審核代碼，還新增架構檢測能力，可對代碼庫整體架構進行研判，監測系統從合規架構逐步劣化為不良架構的演變速度。

我們的客戶正以多種不同方式使用我們的產品。在智能體技術蓬勃發展的時代，我們已全面適配各類主流 AI 原生開發環境，包括 Windsor、Cursor、GitHub Copilot 等主流集成開發環境，以及各類命令行工具。Matt，你也清楚，如今命令行工具的使用熱度正持續攀升，無論是 Gemini 命令行工具、代碼編解碼工具、云開發命令行工具等，我們均已完成適配。簡單來說，市面上主流的相關工具我們都已支持。我們為這些工具提供了一套獨立、結果可確定的通知底層能力。

AI 可以編寫代碼、審核代碼，但往往存在固有的局限：AI 會默認自己生成的代碼完全合規無誤，且難以排查出全部的潛在問題。究其原因，AI 訓練所依賴的數據集同時服務于代碼生成與代碼審核這兩個場景。而我們擁有一套結果精準可控的代碼審核機制，并深度嵌入現代軟件開發生命周期。無論是 AI 在開發環境、命令行工具中編寫代碼，還是智能體提交合并請求等待審核的場景，我們都能介入檢測，深度融入完整的研發流程。

我們還推出了 MCP 服務器，目前不少大型企業客戶都在使用 SonarQube 的 MCP 服務器。該服務器相當于智能體對接 SonarQube 代碼分析能力的網關，采用了智能體通用通信協議，可為智能體開發環境、命令行工具等各類平臺提供服務。除常規代碼分析外，我們也在持續優化檢測引擎，專門針對 AI 引發的漏洞添加識別能力。我們的產品支持自定義規則配置，已有部分客戶通過添加自定義規則專門識別 AI 編碼帶來的風險模式。同時，我們也內置了多條專屬檢測規則，用于防范 AI 衍生風險，例如提示詞注入攻擊、規則文件后門攻擊。這類風險完全由 AI 的編碼行為產生，傳統人工開發模式下基本不會出現。

4 不需要重造流程，老的審核體系依然有效

Matt Merrill：你剛剛最后提到的那個風險是什么？

Manish Kapur：規則文件后門攻擊是一類特定攻擊途徑，具體是指編碼智能體和開發環境所依賴的配置文件、規則文件，例如 MDC 格式的文件、MD 格式的文件等。攻擊者可以在這類文件中植入隱藏的特殊 Unicode 字符，這類隱蔽字符很難被 AI 識別檢測到。我們專門開發了對應規則，能夠精準排查配置文件、規則文件中暗藏的此類隱患。除此之外，針對大語言模型提示詞注入攻擊，我們也配置了專門的檢測規則，可有效識別相關安全問題。這些都是在原有基礎能力之上新增的、專門針對大語言模型的安全檢測能力。

Matt Merrill：我大概明白了這類后門攻擊的原理。比如從 Claude 平臺或其他地方復制了一份配置文件，無意間帶入大量隱蔽的 Unicode 字符，進而篡改指令提示詞，大致是這個邏輯吧？

Manish Kapur：就是這樣。不法攻擊者正是通過在這類文件中植入隱藏 Unicode 字符實施惡意操作。

Matt Merrill：這確實值得關注。結合實際場景來看，如果我自主編寫功能配置、設計持續集成與持續交付流程，就可以接入你們的 MCP 服務器及其他集成工具，將靜態代碼分析納入自動化校驗環節，同步輸出檢測結果。一旦檢測出指定問題，即可終止構建流程，這類操作是否能夠實現？

Manish Kapur：完全可行。我們提供了質量門禁機制，企業可自主制定判定策略，自定義構建任務通過或攔截的觸發條件。

不同應用場景的管控標準可以靈活區分。面向企業內部使用、無對外暴露風險、非敏感業務、無需投產的小型項目無需設置嚴苛的強制校驗規則。但如果是銀行系統、醫療系統這類核心應用，一旦系統故障或數據泄露將會造成極高損失，就需要啟用更高標準的管控策略，升級質量門禁門檻。這類高風險項目，哪怕是一處安全漏洞也會直接攔截，無法通過校驗。

反之，對于非核心、不影響業務運轉的內部輕量化應用，即便存在低優先級漏洞，企業也可靈活放行。團隊能夠根據自身業務需求自定義質量門禁與管控策略，這也是我們客戶高頻使用的核心場景之一。

Chris Grams：確實如此。有一點我感觸很深，數月前，我們和一位業內知名的科技行業分析師交流，探討 AI 時代的代碼審核流程。對方提出了一個建議：作為權威分析機構，我們應該建議企業沿用傳統的人工代碼審核流程來校驗 AI 生成的代碼。如果企業原本就搭建了成熟的人工代碼審核體系，再加入質量門禁等全套管控機制，這套成熟的流程完全可以高效復用在 AI 生成代碼的審核工作中。因為歸根結底，AI 產出的內容本質上依舊是代碼。

這個觀點我十分認同。現在市面上涌現出各類 AI 專屬代碼審核工具，這一點也讓我心存疑惑。當下很多人陷入了誤區，單純因為代碼由 AI 生成就認為必須搭建全新的審核流程。誠然，部分場景下專屬流程會更具優勢，但大量經過長期驗證、成熟穩定的標準化靜態分析流程同樣適用于 AI 代碼審核，并且能夠穩定輸出可復現、高一致的檢測結果。

Manish Kapur：我十分認同。其中關鍵問題在于誤報率。我體驗過多款第三方 AI 代碼審核工具，同時也長期使用我們自研的產品。我發現，在部分場景中，純 AI 審核的誤報率比較高。在我看來，最優解是融合兩類技術的優勢，結合不同場景的適配性，按需選用合適的技術方案。Chris 說得完全正確，當下客戶的核心訴求是引入一套結果穩定一致、低誤報率的確定性檢測體系，并將其作為最終的核驗防線。

在部分特定場景中，正如你和 Chris 剛才所說，大語言模型會是更優選擇。例如文檔編寫、合并請求描述文案撰寫等工作，大語言模型的處理效果遠超傳統工具，我們也會充分發揮大語言模型在這類場景中的優勢。

5 大模型寫代碼各有脾氣，怎么選比“誰更強”更重要

Matt Merrill：沒錯。你們在《開發者代碼現狀調查報告》中還提及并引用了一份關于大語言模型編碼特征的專項報告，內容十分有價值。希望你能簡單介紹這份報告，以及目前的調研得出的相關結論。

Manish Kapur：一年前，我們便啟動了大語言模型的專項測評工作，重點評估代碼編寫質量、安全性能與代碼復雜度。行業內目前存在各類通用的測評基準，幾乎所有大語言模型廠商都會依賴通用基準開展測試。例如，人工評估數據集等行業通用標準主要用于檢驗模型的基礎編碼能力。這類基準測評具備參考價值，是基礎的評估手段，但我們認為，它們只能覆蓋一半的評估維度。原因在于，通用基準僅考核代碼最終結果的正確性，檢驗模型能否完成指定算法的編寫、解決特定的編程問題，以及答案是否準確。

但它們忽略了一個核心的點：不同大語言模型在解決同類算法問題、應對編程挑戰時編碼的實現方式與邏輯差異。為此，我們搭建了一套專門的評估體系，選取了 4400 道編程測試題，對主流大語言模型進行全維度測評。這些題目不屬于任何一個通用基準題庫，都是全新的未知考題，各大模型此前均未接觸過，因此能夠客觀檢驗模型的真實編碼能力。

我們會參照所有基準測試的統一標準進行評分，考核維度包括生成頻次、通過率是否達標、代碼功能是否合規無誤等。我們的評估還不止于此，我們還會進一步統計每千行、每萬行乃至每百萬行代碼中出現的漏洞數量、安全問題數量，以及代碼整體的復雜度水平，包括認知復雜度與圈復雜度兩大核心指標，全面衡量大語言模型生成代碼的綜合質量。

基準測試固然也是不錯的參考，但我們實現了評估體系的全面升級，因為我們的核心業務始終是代碼健康度審查與代碼評審。我們為六七款大語言模型劃分了專門的特質風格，發現不同的模型具有截然不同的特質表現，我們將其定義為模型特質原型。部分模型產出的代碼功能表現極為出色，但認知復雜度與圈復雜度嚴重超標；還有一類模型生成的代碼復雜度極低、代碼行數精簡，同時還能保障功能準確性。我們以此為依據，完成了這批大語言模型的特質劃分。

不同大語言模型的代碼生成風格差異顯著，體現在抽象設計程度、表述泛化方式、錯誤處理邏輯、冗余代碼占比、代碼壞味道以及安全漏洞類型等多個維度。我們針對模型生成的各類代碼缺陷開展了全面且細致的深度分析。項目最初以模型特質報告為核心載體，如今已迭代升級為大語言模型排行榜，大家可前往 sonar.com/leaderboard 頁面查看。截至目前，榜單已收錄約 35 款主流大模型，從安全性、可靠性、可維護性、圈復雜度、認知復雜度、問題密度等多個維度完成全面測評，各項關鍵指標均會詳細標注。

不僅如此，我們還會清晰標注模型產生的安全漏洞數量，并細分漏洞類型，包括路徑遍歷風險、機密信息泄露問題等，所有問題都會形成完整的詳細報告。礙于時間限制，我們無法逐一展開講解，但非常推薦大家自行前往 sonar.com/leaderboard 頁面查閱，深入了解這 35 款大語言模型的各項特質與綜合表現。

Matt Merrill：你剛才提到了模型特質，能否詳細聊聊這部分內容？有沒有比較特別、有意思的案例？

Chris Grams：去年夏天我們啟動這項研究時，核心重點就是挖掘每款模型獨有的特質風格。但后來我們逐漸意識到，大模型迭代速度極快，全新模型持續不斷推出。這也是我們放棄特質劃分、轉而推出綜合排行榜的核心原因——模型特質更新迭代過于頻繁，根本無法為 Claude 代碼模型固定標簽。我甚至已經記不清去年夏天為 Claude 代碼定義的特質，如今這個模型已成長為全球頂尖的編碼專家。所有模型的共性變化十分明顯：隨著綜合性能不斷提升，代碼輸出愈發冗長，行數持續增加，進而導致認知復雜度同步走高。這一趨勢一直延續至去年十一月左右。

而近期大家查閱排行榜數據就能發現，部分模型實現了雙向優化，在保證出色性能的同時，有效控制了代碼復雜度，漏洞問題也大幅減少。去年很長一段時間里，行業呈現出線性規律：模型性能越強，代碼行數越多，整體復雜度越高。但如今行業發展愈發精細化，不少頂尖模型的綜合能力實現了質的飛躍。頭部模型的特質逐漸趨同，全都成長為專業級編碼高手。Manish，你還有什么內容想要補充嗎？

Manish Kapur：你說得很對。早期我們僅測評了六款模型，并完成了特質定義，其中就包含 GPT-5、Claude Sonnet 4、Claude Sonnet 3.7 等版本。測評樣本兼顧不同的規格，既有 80 億參數的開源編碼小模型，也有 GPT-5 這種超大模型。結合兩端模型的表現差異，我們制定了首批特質標簽。例如，開源編碼小模型被我們稱作快速原型搭建者，原因在于這類模型能夠高效解決基礎問題、精簡代碼行數，但代碼嚴謹性不足，容易遺留各類隱性問題。

它采用了原型方案，原型方案難免存在漏洞，但卻能快速高效地驗證核心構想。我們稱之為“快速原型構建者”。而 Claude Sonnet 系列模型更像是資深架構師，它們在編寫代碼時會綜合考量應用可擴展性、用戶承載量、運行性能等多諸多因素。我們稱之為"資深架構師"。我們曾為最初的六個模型起過一些名字，但現在我們已經有超過 35 個模型了，很難為所有這些模型都命名。隨著模型不斷迭代，我們正在逐漸放棄為它們賦予個性化名字的做法。

Chris Grams：不過不得不說，給大語言模型賦予擬人化特質是一件十分有趣的事。

Matt Merrill：確實很有意思，這種方式也更容易讓人記住各個模型的特點。現如今行業早已告別小眾定制化，進入規模標準化階段。我發現 Opus 4.5 的邏輯思考能力小幅領先 Opus 4.6，這個細節十分耐人尋味。從安全維度，也就是每百萬行代碼的安全漏洞數量來看，高配版 GPT 5.2 位居榜首；從可靠性維度，即漏洞嚴重程度與百萬行代碼問題密度方面，高配版 Gemini 3 Pro 表現最優，不同模型的優勢領域差異十分鮮明。另外我還注意到，本次測評全部基于 Java 語言。

這一點至關重要，不同模型針對不同編程語言的訓練側重點存在明顯差異。

即便如此，這份測評結果依舊極具參考價值。在結束這個話題之前，兩位還有沒有關于排行榜或模型特質的內容想要補充？

Manish Kapur：如果有聽眾希望測評特定模型，排行榜頁面內設有專屬提交表單，我們可以按需完成定制測評。

我們一直有收到大量的測評需求。團隊也在盡力跟進，但目前幾乎每兩周就會有新模型發布，更新的壓力巨大。如果某個熱門模型暫未收錄，只要市場關注度足夠高，我們都會優先安排補充測評。

Matt Merrill：單純好奇想問一下，完成一輪完整的基準測試需要多久？原本我以為會耗費很久，實際情況是不是這樣？

Manish Kapur：初期測評周期確實較長，不過現在我們搭建了成熟的自動化測評框架，能夠快速完成各類大模型的性能評估。

上幾輪測評最大的瓶頸出現在 Opus 4.6 發布時，當時針對該模型的接口請求量暴增，服務器出現過載，響應速度大幅下降，還頻繁出現超時問題，我們只能反復重啟測試任務。

Chris Grams：結合過去六個月的研究成果，我想分享一個核心結論：企業與團隊在選擇大語言模型時切勿只關注單一性能指標，需要建立全局評估思維，綜合考量代碼冗余程度、安全隱患數量。編碼測試成績只是參考維度之一，實際評估需要兼顧更多細節。不少性能頂尖的模型，一旦結合認知復雜度、代碼冗余度、調用成本等維度綜合評判，綜合性價比就會大打折扣，這些都是不可忽視的關鍵因素。

成本高低完全取決于調用模型所需的詞元消耗成本。企業需要綜合考量所有因素，而不能只單純關注性能表現，我認為此前業界在評估模型時大多都將重心放在了性能層面。

Manish Kapur：除了成本之外，推理能力也至關重要。每款模型都支持不同的推理模式，一般有兩到四種可選模式。推理等級越高，成本越高，問題求解耗時也越長，但分析推導的詳盡程度會更高。

6 AI 讓新人更快，也讓經驗更值錢

Matt Merrill：我內心同樣抱有顧慮，不禁會想：這類工具的定價會不會大幅暴漲？廠商是不是想先牢牢鎖住用戶，搶占行業龍頭地位？在規劃自身團隊與業務發展時，這也是我一直在思考的問題。

接下來我們聊聊從業年限，以及從業經驗如何影響本次的調研結果。我深耕這個行業已有二十余年，我發現其中有一個現象十分值得深究。能否談談開發者的從業年限會如何影響他們對 AI 工具的認知？

Chris Grams：本次調研中有一項結果讓我們頗為意外：不同從業經驗層級的開發者在 AI 工具的使用方式上存在巨大差異。初級開發者表示，AI 能讓他們的工作效率提升 40%，但其中 66% 的人也坦言，AI 生成的代碼看似無誤，實則暗藏漏洞。他們上手寫代碼的速度更快，卻常常陷入困惑，無法真正信任工具產出的結果。

反觀資深開發者，他們的態度則更為謹慎理性。二者的使用方式截然不同。這份數據來自去年秋季的調研，65% 的資深開發者主要借助 AI 理解老舊復雜代碼、編寫文檔、梳理歷史遺留項目，或是用來校驗內容準確性；而初級開發者往往過度依賴工具，直接讓 AI 包攬全部編碼工作。

另外我想說，如今 AI 代碼生成的質量已有大幅提升。關注相關討論的人應該能發現，去年 12 月中旬左右形成了普遍共識：恰逢年末假期，大批開發者有時間體驗各類全新的大模型，切實感受到這類工具的能力實現了質的飛躍。即便是資深開發者也開始用它們來完成更復雜的工作。二者的核心差異在于，初級開發者愿意貿然嘗試新工具，資深開發者則更為克制，他們更清楚劣質代碼上線的潛在風險，明白遺留問題會在后續帶來巨大隱患。這就是兩類開發者最關鍵的區別，也和我們最初的調研預判有所出入。

Manish Kapur：資深開發者會將 AI 工具當作推理輔助工具，能夠讀懂并校驗工具生成的代碼，具備獨立甄別判斷的能力。而初級開發者恰恰缺少這份審慎，他們會直接照搬生成代碼，這正是從業經驗帶來的本質區別。經驗豐富的開發者習慣多方求證、多角度審視問題，而新生代開發者對新興技術的接納度更高、信任感更強。

Chris Grams：對于初級開發者而言，當下的處境其實充滿焦慮。自己耗費數年苦心鉆研的編碼技能如今 AI 可以輕松實現，而應用架構設計這類高階工程能力恰恰是他們的經驗短板，這也正是人類開發者區別于 AI 的核心競爭力。對于資深開發者來說，當下是機遇滿滿的階段，只要轉型成為 AI 調度統籌者就能把握優勢。就像 Manish 提到的智能體集群概念，如何統籌調度多智能體協同工作也是近期社交平臺的熱門話題，不少人開始搭建專屬智能體團隊，拆分獨立任務、優化多智能體協作與協同調度模式。不難預見，初級開發者不能再局限于基礎編碼能力，必須向上學習高階技能才能保持職場競爭力。

Matt Merrill：報告中還有一點值得關注，調研顯示，借助 AI 編碼工具，初級開發者的工作滿意度顯著提升。結合你們的分享，這個結論也合乎情理。我平時不使用社交平臺，但你們提到的假期體驗大模型這件事我深有同感。當時平臺發放了免費體驗額度，我親自試用后徹底改變了對這類工具效能的認知，即便我從業多年，也深受震撼。看來有相同感受的人并不在少數，這一點十分有意思。

Chris Grams：確實如此，很多人都有同樣的感受。如今幾乎每天都能看到行業資深工程師、技術大牛分享相關體驗，不少業內頂尖開發者都表示，如今已經不再手動編寫代碼，核心工作變成了架構設計、定制化訓練專屬智能體、拆分和分配任務，以及推動智能體之間的協作與代碼互審。行業變革的速度超乎想象。

Matt Merrill：沒錯，發展速度著實令人震驚。你提到初級開發者對這類工具抱有極高的熱情，而我在體驗過后，也對其改觀并充滿期待。我們聊到了去年 10 月至今的變化，我很好奇，資深開發者的態度與認知是否也在同步發生轉變？從 10 月至今，你們是否觀察到了相關變化？

Chris Grams：我們正計劃開展新一輪短期抽樣調研，正是因為行業變化節奏過快，需要持續跟進一線市場動態、補充調研數據，形成對比基準，清晰捕捉行業變化。后續調研完成后，我們會同步分享新增數據，敬請期待。去年秋季開展調研時，我們帶著諸多預設假設，如今隨著行業發展，我也誕生了許多新的猜想。社交平臺上的相關討論熱度居高不下，說實話，我很好奇，這些前沿探討究竟只屬于小眾先鋒群體，還是廣大企業研發團隊都已開始落地智能體技術。

去年秋季的調研數據顯示，已有大量企業開始試水智能體工具，而在過去一個半月里，相關落地規模大概率還在持續擴張。我們需要通過新一輪調研驗證實際情況，拿到精準結論。

7 快而不穩，不如不快

Matt Merrill：結合我服務大型企業客戶的經驗，過去半年里，企業對智能體與 AI 編碼工具的落地使用率大幅攀升，變化十分明顯。還有一個有趣的發現：AI 在全新開發項目與老舊存量項目中的落地效果差異顯著。報告中是否提及 AI 在哪類場景的落地效果更好、認可度更高？

Manish Kapur：數據顯示，AI 最適合從零開始的新項目，90% 的開發者都會在新項目中使用 AI 工具。但在對接現有存量代碼庫時，效能會大幅下降，尤其是那些使用小眾老舊開發語言構建的項目，短板尤為突出。大語言模型對主流編程語言適配性極佳，例如 Python、JavaScript、TypeScript、Java 等，但面對老舊應用系統與冷門技術棧的遺留代碼，表現往往差強人意。僅有 43% 的開發者認為，AI 能夠高效完成老舊框架、冷門語言的代碼迭代與優化工作，這是本次調研得出的觀察結論之一。

核心問題還在于代碼準確性。新項目業務邏輯簡單、代碼體量小，現階段頂尖大語言模型能夠保障極高的輸出準確率；而老舊存量項目存在大量非顯性代碼耦合、無文檔隱性規則、老舊接口邏輯限制等問題，僅依靠代碼文本很難梳理清楚底層邏輯，這也是 AI 難以適配存量改造場景的主要原因。目前，大語言模型在老舊存量項目中的應用普及率整體偏低。

Matt Merrill：這個結論完全符合客觀邏輯。還有一個我很好奇但尚未驗證的問題：自 10 月以來，有沒有團隊嘗試借助智能體 MD 說明文檔或是同類輔助文件為老舊項目提供邏輯參考？你們是否了解這類落地實踐？

Manish Kapur：目前暫未聽說專門針對老舊存量項目的相關方案，但這個思路具備可行性與合理性。云原生代碼工具中已經引入規則、技能、鉤子機制，鉤子可以保障代碼基礎規范，規則能夠劃定開發約束。依靠這類配套機制，AI 未來完全有機會實現老舊項目改造。

Matt Merrill：我十分期待這類方案的落地。我們正在對接的一家合作企業有一套運行二十年、主要基于 C++ 開發的老舊系統，技術負責人長期深陷維護難題。我建議對方進行試點嘗試，將系統沉淀的隱性業務經驗、團隊專屬業務邏輯整理錄入到智能體配套文件中，看看實際落地效果。后續我們會結合本輪抽樣調研結果同步跟進并反饋試點的進展。

Manish Kapur：正如你所說，上下文信息至關重要。為智能體補充完善的項目文檔、業務背景與代碼上下文信息必然能有效提升其在老舊存量項目中的適配能力。

Matt Merrill：簡單再問最后一個小問題。本次調研受訪者覆蓋全球各地，不同地區的開發者之間是否存在明顯的地域化使用差異？

Chris Grams：我們暫未統計并發布相關結論。整體來看，全球開發者面臨的行業環境與技術變革趨勢基本一致。我們專門篩選過具備統計學意義的差異化數據，但并沒有找到足夠顯著的地域特征。無論身處全球哪個地區，所有人都在同步經歷這場 AI 技術變革。

Matt Merrill：可以理解，我只是單純好奇。本次分享接近尾聲，這次調研內容讓我收獲滿滿。我脫離一線開發崗位、轉入管理崗位已有一段時間，雖然仍會編寫代碼，但核心工作以管理為主。換位思考來看，當下很多企業管理者會強制要求團隊落地 AI 工具，部分目標切合實際，也有不少要求脫離了現實。對于廣大從業者而言，如果上級制定了不切實際的 AI 落地目標，你會給出哪些建議？

Chris Grams：企業需要厘清核心訴求：使用 AI 是追求編碼速度的提升還是整體交付上線效率的提升？二者截然不同，后者落地難度要大得多。很多企業沒能兌現 AI 的落地價值，根源就在于只聚焦代碼提速，卻忽略了核心環節。在 AI 時代，代碼交付前的質量校驗、安全風控才是關鍵。對于具備完善傳統代碼審核流程的企業而言，落地 AI 編碼工具會更加順暢，搭配自動化代碼審核工具、代碼質量檢測平臺，就能構建出完整的風控體系。

總而言之，企業必須建立完善的 AI 生成代碼質檢與安全審核流程。如果暫時缺失這套機制，研發人員需要主動向上溝通，讓管理層明白：AI 快速產出的代碼不代表可以直接投產上線。劣質代碼會拉高企業運營風險、產生難以維護的冗余代碼，衍生各類后續問題。

Manish Kapur：核心就是堅守質量底線。提速增效固然重要，但絕不能犧牲代碼質量、軟件穩定性與應用安全性，這一點絕對不能妥協。

Matt Merrill：正所謂凡事過猶不及。這讓我想到一個經典橋段，流水線上的巧克力源源不斷產出，一旦速度過快，就會難以把控品質，AI 編碼工具的使用也是同理。

Chris Grams：確實是這樣。

8 2026 年，管理者必須正視代碼信任危機

Matt Merrill：站在普通開發者的角度，本次調研最重要的啟發是什么？

Manish Kapur：對于開發者而言，核心技能已經不再是單純的編寫代碼，編碼已經成為可被工具替代的基礎能力。未來的核心能力是讀懂、校驗智能體與 AI 工具生成的代碼，完善審核機制、搭建開發約束規則。無論代碼由誰產出，最終的責任歸屬依舊在開發者身上。從業者需要恪守開發規范、做好代碼校驗、把控產出質量，不必再一味執著于學習新的編程語言。

Chris Grams：結合我剛才的觀點再補充一點：想要保持職場競爭力、緊跟行業發展，開發者當下最需要掌握的能力是管理、調度、訓練各類智能體。熟練運用頂尖大模型工具、保持持續學習的好奇心至關重要，行業迭代速度極快，剛掌握的技術可能短時間內就會被新技術淘汰。從業者需要保持敏銳，每周固定留出時間學習、測試、嘗試新工具與新方案。近日我看到一個觀點：今年或將成為所有技術人職業生涯的關鍵轉折點，行業變革空前迅速，一旦停止學習、固步自封，很快就會被行業淘汰，且很難實現追趕。

我也時常以此自省，督促自己堅持學習。每天工作結束之前都會嘗試接觸新工具、新用法，對比每日實操效果，就能切實感受到技術的快速迭代與進步。

我十分認同兩個核心觀點：一個是不能脫離基礎底線，代碼漏洞、質量問題永遠是重中之重；一個是必須緊跟前沿技術趨勢，二者兼顧，才能長久保持競爭力。最后一個問題，對于研發管理者、技術負責人來說，本次調研最大的借鑒意義是什么？

管理者必須正視代碼信任危機。如今 AI 技術持續發展，但調研初期的一組核心數據值得所有人重視：96% 的開發者無法完全信任 AI 生成的代碼。并非工具產出的代碼質量不佳，事實上其水準一直在穩步提升，核心原因在于：代碼故障、安全漏洞產生的后果不會由 AI 承擔，最終責任仍歸屬企業與團隊管理者。作為負責人，必須明確代碼的人工責任制，搭建完善的審核體系，嚴守上線關口，杜絕盲目直接上線 AI 生成的代碼。除非是追求極致創新、能夠承擔試錯風險的初創團隊，普通企業手握大量用戶數據與核心業務信息，必須審慎校驗每一段代碼的可靠性。

過去的難題是如何產出更多代碼，這個問題早已解決。如今我們能夠生成質量相當不錯的優質代碼，且代碼質量還在持續提升。

但關鍵難點在于，必須要有專人審核，愿意簽字確認：“我批準將這段代碼投入生產環境，并承擔隨之而來的所有風險。”這，將會是 2026 年面臨的最大挑戰。

Matt Merrill：說得很有道理。作為管理者，我會想到，既然調研顯示 66% 的開發者并不信任 AI 生成的代碼，那就必須加入人工審核。我覺得以這個引人深思的觀點收尾恰到好處。今晚的交流里，還有沒有什么內容是你們想補充提及的？

Chris Grams：我們之前提到的大模型排行榜項目也在持續推進，我們每天都會關注新上線的模型、實測數據，親眼見證這類技術在不斷進步。當下是變革迅猛的一段時期。我的職業生涯經歷過數次行業轉折，相信你們二位也是，但像如今這樣的變革盛況，前所未有。身處這個行業，既充滿挑戰，又樂趣十足。前路略帶未知與忐忑，但整體充滿意義，非常感謝你的邀約與交流。

Matt Merrill：非常感謝二位的精彩分享。

查看英文原文：

https://softwareengineeringdaily.com/2026/04/23/hype-and-reality-of-the-ai-coding-shift

聲明：本文為 InfoQ 編譯，不代表平臺觀點，未經許可禁止轉載。

會議推薦

世界模型的下一個突破在哪？Agent 從 Demo 到工程化還差什么？安全與可信這道坎怎么過？研發體系不重構，還能撐多久？

AICon 上海站 2026，4 大核心專題等你來：世界模型與多模態智能突破、Agent 架構與工程化實踐、Agent 安全與可信治理、企業級研發體系重構。14 個專題全面開放征稿。

誠摯邀請你登臺分享實戰經驗。AICon 2026，期待與你同行。