最近 Anthropic 发了一份很值得看的研究报告，题目叫《Agentic coding and persistent returns to expertise》，发布时间是 2026 年 6 月 16 日。报告分析了大约 40 万次 Claude Code 交互会话，时间跨度从 2025 年 10 月到 2026 年 4 月，涉及约 23.5 万名用户。
很多人都拿Claude Code来生成代码，而这份报告讨论的不是“AI 会不会写代码”这么简单的问题。
这篇研究报告主要聚焦在以下问题：当 AI 已经可以自己读文件、改代码、跑命令、修 Bug、写文档之后，人和 AI 之间到底怎么分工？什么样的人更容易把 AI Coding 用好？未来开发者的价值会转移到哪里？
相信你也对此比较感兴趣，为此，我们本文就来详细解读下这篇报告。
看完这篇研究报告之后，我觉得它最重要的结论可以压缩成一句话：AI Coding 正在降低写代码的门槛，但没有降低理解问题的门槛。
甚至可以说，当代码生成变得越来越低成本，真正值钱的东西会往上游移动，比如业务判断、问题拆解、边界定义、验证能力、风险意识。
一、这份报告研究了什么
Anthropic 把 Claude Code 的会话分成了九类工作模式，包括新建代码、修复问题、测试代码、编排自动化流程、部署和运行软件、理解已有系统、规划变更、分析数据、写文档等。报告显示，大约 56% 的会话仍然和直接写代码、修代码、测试代码有关；17% 和运行、部署、配置软件有关；14% 属于规划和理解系统；还有 13% 用在数据分析和文字文档上。
分类占比如上。
由此可以看出 Claude Code 已经不是一个单纯的“代码补全工具”了。很多人不仅仅是让它补一段函数，而是让它进入一个真实项目里，理解上下文、修改文件、执行命令、跑测试，甚至完成一些和代码相关但最终产物不是代码的工作。
现在的 Claude Code 更像是一个可以参与完整工作流的执行者。
报告里还有一个变化值得注意：从 2025 年 10 月到 2026 年 4 月，修 Bug 类型的会话占比从 33% 降到 19%；与此同时，部署运行软件、分析数据、写文档这类更端到端的任务占比上升。Anthropic 还用自由职业平台的任务价格做了一个粗略估算，认为典型任务的估计价值在这七个月里上升了 27%。
这说明 AI Coding 的使用正在从“帮我修一下这里”变成“帮我把这件事做完”。这个变化很关键。
早期 AI 写代码，很多人把它当搜索引擎、代码片段生成器、Bug 辅助工具。现在它开始进入更复杂的任务链条。人给一个目标，AI 自己拆步骤、找文件、写实现、跑验证。它在改变软件生产的组织方式。
二、人和 AI 到底怎么分工
报告里有一组数据非常关键。
在一次典型的 Claude Code 会话中，人做了大约 70% 的规划决策，但只做了大约 20% 的执行决策。换句话说，人主要决定“做什么”，Claude 主要决定“怎么做”。
这里的规划决策指的是什么呢？比如要实现什么功能，采用什么方向，做到什么程度算完成，哪些边界不能碰。
而执行决策是什么呢？比如改哪个文件，写哪段代码，跑哪个命令，选择什么具体实现方式。
这组数据也阐释了当前 AI Coding 的本质：人并没有从开发中完全退出，而是被推到了更加靠前的位置。具体来说，以前开发者的大量时间花在执行层：查文档、写样板代码、调接口、跑命令、修语法错误。现在这部分工作正在被 AI 承接。
但更上游的东西没有消失，还是需要人去做，比如：
- 你还是要知道目标是什么。
- 你还是要知道业务边界在哪里。
- 你还是要判断结果是不是对的。
- 你还要在 AI 理解偏了的时候，把它拉回来。
如果谁想着有了 AI Coding 自己就不用再动脑思考了，那就不对了。相反，它对人的判断力要求更高了。
以前你写错一段代码，可能编译就报错。现在 AI 可能给你生成一整套看起来很完整的方案，文件自动写完了了，测试也跑通过了了，页面也出来了。但它是不是真的符合业务？有没有破坏历史逻辑？有没有漏掉异常路径？这就不是 AI 自己能保证的。
三、为什么专家能让 AI 做更多事
在这篇报告中，我还发现一个挺有价值的结论：用户越懂任务本身，Claude 每次收到指令后做的事情越多。
在典型的新手会话中，用户每发出一次指令，Claude 大约执行 5 个动作，输出约 600 个词。而在专家会话中，一次指令可以触发约 12 个动作，输出约 3200 个词。
这个差距的来源可能是专家给出的上下文更有效。
比如一个新手可能会说：“帮我做一个导出功能。”
但一个熟悉业务的人会说：“在现有导出逻辑上增加按班级维度汇总，保持原有字段顺序不变，缺失数据补 0，不影响旧模板兼容。完成后跑一下现有导出用例，再补一个学生为空的边界测试。”
这两种指令，表面都是让 AI 写代码，本质完全不一样。
前者给的是一个模糊愿望。 后者给的是目标、边界、约束、验证方式。
AI 很强，但它不能凭空知道你公司的历史包袱，也不能天然理解业务为什么这么设计。谁能把这些信息讲清楚，谁就能让 AI 少猜一点，多做一点。
这也是为什么报告强调“domain expertise”，也就是领域专业能力。
这里的“专家”不一定是写代码最强的人，而是最懂这个任务的人。报告举了一个例子：一个资深工程师第一次问 Rust 问题，在 Rust 这件事上也可能是初学者；一个从没写过 Python 的会计，如果能清楚描述对账规则，并且能发现月末结账的边界问题，在这个任务上反而是专家。
AI Coding 把“会不会写代码”和“懂不懂问题”拆开了，真正放大的，不只是编程能力，而是一个人对问题的掌控力。
四、成功率差异说明了什么
在这份报告把成功分成几种口径，其中比较严格的一种叫 verified success，也就是不只看会话里说“完成了”，还要有一些可验证信号，比如测试通过、提交代码、创建 PR、用户明确确认等。
数据上看，新手会话达到严格成功标准的比例大约是 15%，而中级及以上用户可以达到 28% 到 33%；如果看“至少部分成功”，新手是 77%，中级及以上用户是 91% 到 92%。
还有一个细节更真实。
当会话遇到麻烦时，新手更容易放弃。报告里提到，在遇到困难的会话中，新手达到严格成功的比例大约是 4%，专家是 15%；新手会话里有 19% 会在没有写入代码的情况下被放弃，而其他水平用户是 5% 到 7%。
这很像真实开发现场。高手不是不会遇到问题，而是遇到问题后知道怎么去攻克问题。比如日志看哪里，测试怎么补，风险怎么隔离，能不能先做最小变更，什么时候应该回滚重来，等等。
AI 肯定是会犯错的，也会绕远路，也会误解需求。区别在于，新手可能看不出 AI 哪里错了，只能继续追问，越改越乱。专家能更快定位问题，把 AI 拉回正确路径。
所以，AI 并没有让专业能力变得不重要。它只是把专业能力的表现方式换了。
以前专业能力体现在“我能亲手写出这段代码”，以后会更多体现在“我知道这段代码应该长什么样，以及怎样验证它是对的”。
五、职业身份可能没那么重要了
这份报告还有一个容易引发讨论的结论：在产出代码的会话中，软件相关职业和其他职业的成功率差距并不大。
软件相关职业的严格成功率大约是 34%，非软件职业大约是 29%；如果看“至少部分成功”，两者分别是 89% 和 88%。报告还提到，在样本里最大的十类职业中，每一类和软件工程师的成功率差距都在 7 个百分点以内。
这说明什么？说明写代码这件事，正在从“专业程序员的专属技能”，变成很多岗位都能借助 AI 使用的基础能力。
比如：
- 财务可以让 AI 写对账脚本。
- 运营可以让 AI 做数据清洗。
- 老师可以让 AI 生成题库工具。
- 律师可以让 AI 批量检查合同条款。
- 产品经理可以让 AI 做一个可跑的原型。
这些事情以前也能做，但门槛高。你要么自己会开发，要么找工程师排期。现在只要你足够懂问题，很多小工具、小流程、小自动化，就可以很快实现起来了。
但这里不能误读成“程序员不重要了”。
更准确的说法是：只会执行需求的程序员，会变得没那么稀缺；能理解复杂系统并做出可靠判断的开发者，会更重要。
非软件岗位可以借助 AI 写出代码，不代表他们都能维护复杂系统。AI 可以生成一个功能，不代表它能自动处理长期演进。一个 Demo 能跑，不代表它能稳定承载真实业务。
真正的软件工程，仍然有大量看不见的工作，比如：架构边界、数据一致性、异常恢复、权限模型、性能瓶颈、灰度发布、回滚策略、可观测性、长期维护成本等等…
这些事情不是靠“生成代码”四个字就能解决的。
六、对开发者的启发
这份报告对开发者最大的提醒，不是“赶紧学某个 AI 工具”，而是要重新审视自己的能力结构。
如果一个开发者的价值主要来自执行层，比如按需求写接口、照着原型搭页面、把字段搬来搬去、写重复 CRUD，那确实会越来越危险。
因为 AI 最擅长吞噬掉的的，就是这类上下文清晰、模式固定、验证标准明确的执行工作。
那么，什么样的开发在不会被AI取代，反而会因为AI放大他的能力呢，我想，主要有以下这些：
理解业务为什么这么设计。
知道哪些地方不能随便改。
能把模糊需求拆成清楚的技术方案。
能识别 AI 方案里的隐性风险。
能设计验证路径，而不是只看代码能不能跑。
能在系统复杂度上升时，做取舍和收敛。这点是最难的。AI会把什么活儿都揽下来，最终堆成一座（）。留给大家自己填空
以后怎么区分开发者水平呢？可能不再是“谁写代码更快”，更看重的是这些能力：
- 谁能更快定义问题。
- 谁能更准描述边界。
- 谁能更早发现坑。
- 谁能让 AI 少走弯路。
- 谁能把 AI 生成的东西变成可上线、可维护、可负责的系统。
这才是 AI Coding 时代更稀缺的能力。
七、对企业的启发
对企业来说，这份报告也有启发。
很多公司引入 AI Coding 工具时，很容易只盯着“代码生成效率提升了多少”。但从这份报告看，AI Coding 的价值不只在于个人写代码更快，而是在改变任务分工。
企业应该思考的不是“能不能少招几个程序员”，而是这些：
哪些重复实现可以交给 AI？
哪些业务人员可以通过 AI 自助完成小工具？
哪些开发者应该从执行工作中释放出来，去做更高价值的设计和验证？
如何建立 AI 生成代码的审查、测试和上线规范？
哪些场景绝不能让 AI 直接越过人的判断？
AI Coding 一旦进入真实业务，就不能只看生成速度。
速度越快，越需要边界。
产出越多，越需要验证。
自动化越强，越需要责任链路。
否则，AI 不是帮你提效，而是帮你更快制造技术债。
八、我的判断
从这份报告中，我们可以明显的看出来一个趋势：AI 正在接管越来越多执行工作，但人仍然掌握目标和判断。
这会让很多岗位发生变化。
不会写代码的人，可以借助 AI 做出过去做不了的技术工具。
普通开发者，可以用 AI 更快完成实现。
高级开发者，会把更多精力放到系统设计、业务理解和风险控制上。
真正懂业务的人，会拥有更强的技术表达能力。
只会机械执行的人，会被越来越便宜的 AI 产出挤压。
所以，AI Coding 不是简单地淘汰程序员。
它更像是在重新定价开发者的能力。
过去，代码能力很值钱。
以后，代码能力肯定依然很重要，但会同时需要兼顾更多的业务理解、问题定义、系统判断的能力。
一个人越懂自己要解决的问题，AI 就越能帮他把事情做成。
一个人越不知道自己要什么，AI 生成得越快，反而可能错得越远。
这可能就是 AI Coding 时代最现实的一点：写代码会变得越来越容易。但把事情做对，还是很难。
