作者丨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，期待与你同行。
