AI 编码智能体的真实收益

在过去的一年里，我一直在与公司的核心开发者团队合作，推动采用 AI 编码助手。作为评估其影响的专门团队的一员，我已将其推广给我们的工程师，同时也在自己的日常工作流程中使用它们。这让我对 AI 在软件开发中的前景（以及陷阱）有了独特的视角。

这种脱节现象日益严重。尽管科技界充斥着“10 倍生产力”的宣传，但我团队的实际经验却并未反映这一点。我们确实看到了收益，但这些收益只是渐进式的，而非指数级的——而且远不及 10 倍的水平。这让我开始质疑一切：我们是不是用错了工具？

因此，我和我的团队决定超越内部指标，深入研究主要的行业研究。我们希望用确凿的数据来取代炒作。我们的发现证实了我们的怀疑，并为在工程领域利用 AI 提供了清晰、切实的路线图。

简而言之：基于数据支撑的 AI 编码工具实际带来的生产力提升约为 20-30%，而不是 1000%（10 倍）。即使是这样的提升也伴随着一些关键的警告。

免责声明：我们公司正在开发一个框架，以便在软件开发生命周期中采用人工智能。此处引用的行业通用数据并不反映我们内部的进展，我们通过这些结构化的努力获得了更高的收益。

1、真实的数字是多少？

人们对人工智能工具最初的兴奋显而易见。但随着新鲜感的消退，数据显示情况更加严峻。

1.1 Stack Overflow 2025：对AI的信任度正在下降

根据 Stack Overflow 2025 年开发者调查，该调查覆盖了来自 177 个国家/地区的 49,000 多名开发者：

• 84% 的开发者目前正在使用或计划使用人工智能工具（高于 2024 年的 76%）。
• 但只有 60% 的人对人工智能持积极态度（低于 2023-2024 年的 70% 以上）。
• 46% 的开发者不信任 AI 的输出（高于去年的 31%）。
• 66% 的开发者对 AI 给出的结果“几乎正确，但不完全正确”感到恼火。
• 45% 的开发者表示，调试 AI 生成的代码比自己编写代码花费的时间更多。

这反映了我们内部观察到的情况。66% 的开发者抱怨 AI 输出“几乎正确，但不完全正确”这一统计数据最准确地反映了我们的经验。这意味着 AI 生成的代码通常看起来正确，但实际上存在细微的错误，导致调试和审查周期比从头编写代码花费的时间更长。

因此，即使使用率上升，信任度却下降了。开发者已经度过了与 AI 的“蜜月期”，现在对其真正的能力和局限性有了更清晰的理解。

1.2 谷歌和微软研究：提升 20-30%，而非 10 倍

一些权威的对照研究证实了这个较为保守的数字：

• 谷歌内部 RCT（2024 年）：在 100 名谷歌工程师中，专业编码任务的速度提升了 21%。有趣的是，与预期相反，高级开发人员的获益甚至比初级开发人员更大。
• 多公司研究（微软、埃森哲、财富 100 强）：在近 5,000 名开发人员中，该研究发现生产力平均提升了 26%。其中，初级开发人员的增幅最为显著（35-39%），而高级开发人员的增幅较小（8-16%）。
• Upwork 自由职业者研究：该研究显示速度提升了 55%，但这些任务比较简单，无法代表现实世界的复杂性。

总体而言，20-30% 的提升是实际数字，我在日常工作中也清晰地看到了这一点。这可不是初创公司创始人或投资者经常吹嘘的 10 倍速度。

1.3 剧情反转：METR 研究——AI 拖慢经验丰富的开发者速度！

这是 METR 最令人震惊的研究：

• 16 位经验丰富的开源开发者在自己的代码库（超过 100 万行代码）上工作。
• 结果：使用 AI 时，他们的速度慢了 19%。
• 讽刺的是？他们感觉自己快了 20%😂

为什么速度会下降？他们把隐藏的时间花在了以下方面：

• 验证和调试 AI 的输出。
• 在自己的想法和 AI 的建议之间切换上下文。
• 让 AI 了解他们庞大代码库的完整上下文。

2、AI 生产力悖论：为何代码量越大，价值却不越高

Faros AI 的一项研究分析了来自 10,000 多名开发者的遥测数据，发现了所谓的“AI 生产力悖论”。

大量使用 AI 的团队完成的任务增加了 21%，合并的拉取请求增加了 98%。但这也带来了高昂的代价：

• PR 审核时间激增 91%。
• PR 大小激增 154%。
• 缺陷密度增加了 9%。

为什么会发生这种情况？

这是一个典型的阿姆达尔定律（Amdahl's Law）：系统的速度受限于其最慢的组件。人工智能加速了流程中“代码编写”的部分，但这在以人为中心的阶段造成了巨大的瓶颈：代码审查、质量保证和架构验证。

简单的事实是，更多的代码并不一定等于更高的价值。开发流程的关键部分：

• 代码审查仍然需要人工。
• 质量保证仍然需要人工。
• 部署流程保持不变。
• 架构决策仍然需要人工。

结果呢？编码流程卡在其他瓶颈上！

因此，一家大量使用人工智能的公司并不一定比一家不使用人工智能的公司交付速度更快或质量更高。

说实话，在我看来，人工智能只是加速了工作中耗时最少的部分：编写初始代码，而这通常只占整个开发生命周期的 10% 到 20%。我们工作中真正耗时的部分是调试、系统设计、测试和优化——这些深度思考促使我们凝视虚空，寻求突破。

当我自己编写所有代码时，我会在脑海中绘制一张地图，标明可能隐藏的错误，这使得调试更加直观。现在，人工智能可以在几分钟内生成数千行代码。代码审查简直是一场噩梦，迫使你理解它的逻辑，寻找隐藏的错误，检查重复代码，并验证其安全性。这怎么能不花更长的时间呢？

3、为什么这种影响在组织层面看不到？

Faros 的研究还指出了个人速度提升未能转化为全公司效益的四个关键原因：

• 采用时间太短：超过 60% 的开发人员在过去几个季度才每周使用一次人工智能。实际上，团队只是在生产环境中对这些工具进行 Beta 测试。
• 使用情况不均衡：软件交付是一项跨团队的工作。如果 A 团队大量使用 AI，而 B 团队仍然采用老派技术，那么整个流程并不会加快。
• AI 更倾向于新工程师：新加入公司的开发人员最常使用 AI 来浏览不熟悉的代码库，而高级工程师（负责制定关键架构决策的人员）则持怀疑态度。
• AI 的使用仍然很浅：大多数开发人员只使用自动完成功能。像 AI 聊天、代码审查和自主代理这样的高级功能仍然很少使用。

4、那么，AI 究竟有何优势，又有何劣势？

理解这一悖论是释放真正价值的关键。我们的研究和亲身经验指向了清晰的用例。

✅ 优势：在何处加倍投入 AI

• 引导新项目和 PoC：我亲眼目睹了 AI 在推动新想法落地方面所发挥的非凡作用。当严格的代码库标准和安全性并非首要考虑因素时，您可以在投入大量资源之前快速构建概念验证 (POC) 来展示愿景。
• 优质文档：说实话，大多数开发者（包括我自己）并不享受编写文档的乐趣。人工智能改变了这种现状。它使编写高质量、上下文感知的文档与编写代码几乎无缝衔接。
• 样板代码和重复代码：这正是人工智能的强项。不妨将其用于单元测试、CRUD 端点、数据转换和 API 粘合代码。
• 学习与入职：人工智能是卓越的苏格拉底式伙伴，通过帮助新工程师理解不熟悉的代码库，显著加快了他们的入职速度。Stack Overflow 的调查显示，44% 的开发者使用人工智能学习新技术。新员工可以使用人工智能更快地理解代码库，而无需不断地向高级开发人员请教。

❌ 墙：人工智能仍在苦苦挣扎的地方

• 大型代码库：人工智能无法理解上下文、领域特定模式或自定义实用程序。它生成的代码基于从训练项目中学习到的模式，因此通常与现有项目的架构不匹配（除非有明确的指导）。
• 代理编码：能够自动编码、测试和修复错误的代理仍然非常脆弱，需要大量的监控。Armin Ronacher 对此进行了测试，并得出结论 — 大多数尝试都失败了。
• “几乎正确”的解决方案：66% 的开发者对 AI 生成的“几乎正确”的结果感到沮丧，这导致他们花费比自己编写代码更多的时间进行调试。
• 创造性解决问题：AI 是一种模式模仿者；它无法发明新颖的解决方案。
• 扩展和代码膨胀：随着项目的发展，AI 的贡献可能会成为一种负担。它经常生成过度设计的解决方案或创建包含重复逻辑的新文件，导致代码库混乱且难以维护。
• 安全噩梦：AI 生成的代码往往存在更多漏洞。这并非小问题，而是一个重大威胁，会大幅增加人工代码审查和安全审计的负担。
• 数据工程盲点：如果您身处数据领域，请勿盲目信任 AI 生成的 SQL。AI 无法理解您的底层架构、元数据、表大小、连接频率等信息。频率或更新模式。它会生成语法正确但通常效率低下或完全错误的查询。

5、聪明的开发人员如何调整他们的工作流程

数据显示了一个明显的趋势：你不能只是“使用人工智能”并期待结果。最高效的工程师正在改变他们的工作方式，以利用人工智能的优势，同时防范其弱点。以下是现实世界中正在出现的工作流程：

• 将人工智能视为“结对编程”的聊天伙伴。精明的开发人员不会仅仅依赖自动完成功能，而是会持续打开人工智能聊天窗口。这是一种对话。在我使用 Claude Code 等工具的工作流程中，我经常打开两个选项卡：一个用于编码，一个用于提问、集思广益解决方案以及获取“第二意见”。
• 构建提示库。开发人员正在创建个人和共享的提示符模式集合，以便为他们的特定任务提供最佳结果。可以将它们视为人工智能的 Shell 脚本。这关乎对输入进行工程化，以获得高质量的输出。
• 实现更小、更频繁的提交 AI 很容易生成大量的 PR，这很危险。我曾经见过一些代理工具，它们会生成堆积如山的代码，需要一整天的时间来审查。解决方案是将任务分解成更小、更易于管理的块，以便更轻松地验证和合并。
• 加倍测试 。由于 AI 生成的代码可能存在隐藏的错误和逻辑缺陷，因此自动化测试不再是“锦上添花”的事情，而是绝对必要的。当我编写自己的代码时，我对它有着根深蒂固的直觉。现在，在没有强大的测试套件的情况下，在任何重要的项目中使用 AI 都注定会失败。我是认真的。

代码验证驱动开发势在必行！💪

6、人机协同，而非单靠 AI

在阅读了所有这些研究并根据我的经验后，我的结论是：

AI 确实有帮助，但效果并不显著，而且效果并不均衡。

• 在受控条件下，生产力提升 20-30%。
• 个人比组织受益更多。
• 初级/新工程师比资深工程师受益更多。
• 绿地项目比棕地项目受益更多。

真正的问题：

• 使用率在增长，但信任度却在下降。
• 开发人员正在学习“信任，但要验证”。
• 仍然需要人工监督质量。

工作流程需要适应：

• 它并非即插即用。
• 它需要培训和流程变革。
• 投资于测试和审查流程。

这是我自己的经验。我一直在尝试使用人工智能优化我的工作流程，但我注意到生产力提升并不显著。一个过去需要 10 天的项目，现在可能只快 2-3 天。我把所有时间都花在了审查和与人工智能争论上，否则事情会立即崩溃。

6、从问题到流程：构建我们的 AI 工程框架

这些挑战并非仅存在于理论层面，而是我们每天都会遇到的现实问题，可以通过工程规范和提示技巧来应对。正因如此，我们公司已不再仅仅提供工具，而是构建一个能够有效利用这些工具的系统。

我们致力于利用 AI 改进软件开发生命周期 (SDLC) 的项目已经构建了一个全面的框架，其中包括：

• 强大的工具和报告：我们拥有仪表板来查看和评估 AI 的使用情况，使我们能够将其与实际生产力指标（而不仅仅是代码行数）关联起来。
• 集中式提示框架：我们开发并在各个项目之间共享提示技术。这确保 AI 遵循我们特定的编码最佳实践和标准，而不是默认遵循通用模式。
• 特定工具的分步指南：我们为工程师使用的工具套件（Cursor、GitHub Copilot、Windsurf、Q Developer、Kiro 以及我个人最喜欢的 Claude Code）提供了清晰的指南。
• “上下文优先”方法：提示不应以“创建功能”开头。我们的流程始于指导代理理解项目背景。对于小型项目来说，这很简单。对于大型遗留系统，这种技术可能成本高昂，因此我们开发了专门的指南，以便高效加载必要的背景信息，避免每次请求都导致模型不堪重负。

因此，要点是：

• 如果您是开发者：不要指望人工智能能在一夜之间将您变成 10 倍效率工程师。但也不要放弃它。利用它来更快地学习并自动化枯燥的任务。
• 如果您是老板或经理：不要轻信“人工智能将开发效率提高 10 倍”的营销宣传，不要再压缩开发团队的时间表或向客户做出空洞的承诺。开发者已经够痛苦的了。
• 如果您是客户：不要轻信所有媒体的炒作。只需了解人工智能的真正能力，并对上述两类群体多一些关爱🫶。

7、关于炒作对人类成本的个人看法

自从人工智能出现以来，这种说法就让开发者处于被动地位。我们面临着被取代的威胁，被逼入倦怠，压力比以往任何时候都大——所有这一切都是因为媒体不断重复“10 倍生产力”的论调，放大了一些非科技公司创始人利用AI编写的代码，打造价值数十亿美元的初创公司的离奇故事。

这让开发者陷入了职业困境：

• 快速利用AI：如果你工作速度不够快，就会被指责“技能问题”或不懂如何使用AI。但如果你操之过急，不仔细审查，就会积累大量的技术债务，引入细微的bug，并构建一个垃圾。
• 如果你谨慎行事，就会被指责速度慢、技能不足或抵制新技术，同时还要眼睁睁地看着截止日期缩短和预算紧缩。

这是一个双输的局面，更快、更便宜地交付的巨大压力与构建可靠安全软件的专业责任相冲突。

这就是为什么我们必须重新构建对话。AI不是工程师的替代品；它是一种杠杆。它是一种工具，可以自动化繁琐的工作，加速学习，并生成样板。它并非、也无法取代人类独有的批判性思维、系统设计和创造性解决问题的能力。

这引出了我最关键的一点：你的价值不在于编写代码，而在于解决问题。

人工智能可以完成简单的工作，但艰难的工作仍然需要人类。随着人工智能接管简单的任务，我们的角色将转向处理更多艰难、高价值的工作。我们必须利用这些工具，不断学习，并让世界记住一位伟大的开发者真正在做什么。让我们重现黄金时代。💪

原文链接：AI Coding Agent Will Not Boost Your Productivity 10x - Here is WHY

汇智网翻译整理，转载请标明出处