为何大多数开发者仍然无法从编程智能体中获得太多收益

两项2026年的研究——一项来自JetBrains，另一项来自Anthropic——给出了工程师实际如何与编码智能体协作的具体数据。他们共同认为，从智能体那里获得有用成果与得到无用信息之间的差异在于工作的分配方式，而非所选模型的不同。

其核心观点是，AI编码已不再是实验阶段，如今重要的区别在于是让模型负责编写代码，还是真正将工程任务委托给它。

AI coding is no longer an experiment.

90% of professional developers now use coding agents at least weekly.

But there is a big difference between asking AI to write code
and actually delegating engineering work to an agent.

为何交易应用是良好的测试对象

以某证券公司开发的iOS交易应用为例。该应用同时使用了UIKit和SwiftUI框架，其架构之上还采用了MVVM模式与Clean Architecture设计。在这样的代码体系中，订单确认界面上的数字错误不会被视为一条缺陷报告，而是会引发合规部门的介入。

对于处于这种境地的团队而言，将实际工作交给编程助手并非为了追求速度。真正需要关注的是助手在无人察觉的情况下悄悄出错的情形。研究这类情况比任何课程都能让人更深入地了解助手的工作流程，2026年的数据也解释了其中的原因。

JetBrains调查的结果

在2026年5月至7月期间，JetBrains对超过15,000名在职开发者进行了调查。其中十分之九的受访者表示至少每周会在工作中使用AI编程助手，而68%的人则表示每天都会使用。

Claude Code的全球使用率为39%，在美国则为47%，大约是GitHub Copilot 21%的两倍，而后者相比上一年已从29%下降。Codex的使用率则从3%上升至16%。

另一份相关报告揭示了更有趣的数字：开发者们估计，目前约有47%的代码是由智能工具完全生成的，超过一半的开发者自己编写的代码占比低于20%，还有五分之一的开发者完全不借助AI编写代码。

实际使用经验并未阻碍这些工具的普及，反而推动了其发展。大约四分之一的资深开发者会让智能工具生成他们80%以上的代码，这一比例高于倾向于逐行获取帮助的初级开发者。这打破了“AI会让初级开发者变得多余”这一观点。那些判断力最强的人才会将更多工作交给智能工具，这绝非偶然。

40万次使用记录揭示了什么

Anthropic自身的研究涵盖了2025年10月至2026年4月期间约235,000名用户进行的大约400,000次Claude Code交互会话。实际数据比营销宣传所展示的更为简单：

• 与编码相关的工作占会话总数的56%，其中25%用于编写代码，26%用于修复错误，5%用于测试或协调操作。
• 运行软件占17%。
• 规划与探索占14%。
• 分析及文本撰写占13%。

最值得关注的是关于决策权的分配：大约70%的规划决策由人类做出，而大约80%的执行决策由Claude完成。人类决定“做什么”，而智能体则负责“如何做”。

并没有人刻意设计出那种划分方式。它是数十万工程师通过独立探索达成的平衡状态，因为这种方式确实有效。许多对编程智能体的抱怨都来自那些本末倒置的人——他们先确定了“要做什么”，却又在“如何做”上与智能体争执。

专业能力决定结果

对于那些认为“现在任何人都能编程”的人来说，这些数据无疑是个打击。评估时会通过三个指标来判断用户在相应领域的专业程度：指令的精确度、用户让Claude检查的内容以及修正方式。随后会将不同评估结果进行对比。

从前两行开始即可。专家不会输入更多内容。专家的一条指令所产生的工作量是无人指导情况下的两倍多，新手则需要执行12次操作，而专家仅需5次，即便模型、工具和价格完全相同。专家的指令包含了足够的上下文，因此智能体无需停下来猜测。

最后一行同样重要。当会话偏离方向时，约19%的新手会放弃且不会生成任何代码，而专家的比例仅为5%到7%。决定成败的关键并非提示语的表述方式，而是能否将偏离轨道的会话拉回正轨。

论文中的一句话总结了这一点：对于新手，Claude倾向于纠正用户；而对于专家，则是用户纠正Claude。这就是使用智能体与被智能体掌控之间的区别。

会出问题的三步循环

常见的流程如下：

Bad:
Prompt → AI writes code → Accept

这三个步骤中有两个属于代理部分。没有要求、没有上下文、没有计划，也没有验证机制。这并非在分配工程任务，而是在更粗粒度的层面进行自动补全，期望最终结果能够符合预期。

经得起考验的七阶段循环

经过实际交易应用测试后依然有效的流程包含七个阶段：

Better:
Requirement
↓
Context
↓
Plan
↓
Agent implementation
↓
Build
↓
Tests
↓
Human review

工程师负责前三个阶段和最后两个阶段，而代理人则负责中间的部分。这一比例与研究结果一致，即规划阶段为70/30，执行阶段为80/20，并以流程图的形式呈现。每个阶段都有其相应的成本。

需求

像“在订单流程中添加确认单”这样的表述即算作一项任务。代理人可能会做出技术上正确但功能上有缺陷的成果。真正有价值的需求则包含更多内容：

Order confirmation sheet, SwiftUI, presented from OrderEntryViewController.

Must show: instrument code, side (BUY/SELL), quantity in lots,
limit price, estimated total including fee, and account buying power
AFTER the order.

Buying power must be recomputed, never passed in from the entry screen.
If recompute fails, disable confirm and show the retry state.
Never show a stale number next to a confirm button.

该规范的最后一条要求就是领域知识，而没有任何模型具备这一点。这正是能区分正常工作的界面与会被监管机构指出问题的界面的关键。这与研究中的“方向精度”指标相对应，也是最容易解决的环节。

背景

在Clean Architecture架构下，当UIKit和SwiftUI共存时，如果没有任何既定模式可供使用，代理组件就会自行创建模式，而每一种自创的模式日后都会变成审查时的评论。因此，应首先让代理组件参考真实示例：当前的用例协议、某个存储库的实现方式、承担最相近功能的ViewModel，以及包含分层规则的模块级CLAUDE.md文件。相比三段解释文字，这三个文件加上一份规范文档的效果要好得多。尽管几乎所有人都跳过了这一步，但它带来的回报却是最大的。

计划

在编写任何代码之前，先请求一份计划书，其中需列出哪些文件会发生变化、每个变化由哪一层负责处理、ViewModel提供了什么接口以及哪些内容会接受测试。阅读这份计划书时可以将其视作PR描述。拒绝一份计划书大约需要90秒，而拒绝一项实现方案则需要20分钟，而且还会留下必须在心中忽略的差异对比内容。

大约三分之一的计划书会被修改，几乎总是由于分层方面的问题，比如将本应放在用例中的计算逻辑放到了ViewModel中。用文字修正这类问题成本很低，但用Swift语言修正则不然。

实现

计划确定后，请退到一旁。80%的执行决策都集中在这里：命名、控制流、如何构建差异对比、该提取哪个小型辅助工具。如果为了挑剔变量名而打断流程，原本需要12个步骤的任务就会变成5个步骤。此外，还要让高级工程师花费精力来处理初级工程师的输出工作。

验证

最佳实践指出，只有当代码能够成功编译且测试通过时，任务才算完成，而且代理需要独立执行这两项操作。相关研究将此视为用户要求Claude进行的验证内容，也是人们最容易忽视的环节。能够运行xcodebuild并执行测试目标的代理可以完成整个流程；而缺乏此能力的代理则只会返回草稿，并将其标记为功能特性。

对于确认表而言，测试通过意味着实现了事先列出的具体行为。在提交该表格时必须重新计算购买力，重新计算期间确认按钮必须保持禁用状态，且费用计算结果必须与仓库中已有的设定一致。

审查

每一行代码都会被仔细检查。这并非因为代码通常很糟糕，实际上往往并非如此。审查环节仍是需要人类专业知识介入的步骤。检查的重点是绿色构建无法发现的方面：更改是否遵守了层边界规则，四舍五入规则是否符合财务部门的实际使用要求，以及状态机能否在确认过程中处理套接字断开的情况。

这一阶段也是处理效率的真正上限。一个智能体生成的工作量可能超过任何人能够合理审查的范围，而草率处理的倾向正是整个工作流程中真正的隐患。其风险并非幻觉，而是疲劳。

工作的发展趋势

40万次会话中七个月来的变化值得关注：

• 用于调试的会话比例下降，从三分之一（33%）降至19%。
• 运行中的软件操作比例从14%上升至21%。
• 编写代码与数据分析所占比例几乎翻倍，从约十分之一上升至约五分之一。

查找漏洞所需时间较短，而操作及分析运行中的系统则耗时更多。在同一时期，预计任务价值上升了约25%，而构建类任务的增幅则达到43%左右。工作并没有消失，只是从编写实现代码转向了对其进行规范、协调与验证，这正是拥有团队的资深工程师一贯的工作方式。

瓶颈在于循环流程

十分之九的开发者每周都会使用这些工具，但仅有15%到33%的操作能以验证成功的结果告终。因此，模型从来都不是限制因素。大多数人只是用为七步流程设计的工具来执行三步循环操作而已。

仅仅优化提示语并不能解决问题。正确的做法是在问题产生的环节就进行判断，也就是事先定义什么是“正确”的，并在最后确认这一标准是否得到满足。智能体负责处理中间环节，其表现好坏取决于边界条件设定的清晰程度。

2026年，最能从编程智能体中获益的人并非那些写出最巧妙提示语的人，而是那些能够决定什么才算“完成”的人。