AI 会替代程序员吗？Anthropic 内部使用 Claude Code 的使用调查

随着大模型的升级更新，编程功能越来越强，甚至可以一句话让大模型自行编写一个微型版操作系统：打破思考大模型“不可能三角”，蚂蚁集团更新了百灵万亿模型 Ling-2.5-1T、Ring-2.5-1T。

那么一直摆在我们面前的问题：“AI大模型会取代程序员”吗？

看到一篇 Anthropic 公司调查的博客，基于 20 万条 Claude Code 内部使用记录，给我们展示了：在一家业内顶级的公司，当每人有一个“AI 助手”之后，程序员会被替代吗？开发工作会变成什么样？

核心发现

(1) AI 如何改变了工作本质

AI（Claude）正在彻底改变软件开发者的工作方式，带来了显著的生产力提升，但也伴随着不确定感。

• 工作量爆炸：工程师们完成的任务量（输出量）大幅增加，即使有时每个任务花费的时间不一定减少，但能完成更多的工作。
• 全栈能力：AI 让工程师们变得更‍“全栈”‍（Full-stack）。他们不再局限于自己擅长的技术领域，而是可以涉及 UI、后端、数据库等多个领域。
• 深度与广度的张力：虽然可以触及更多领域，但也有工程师担心自己的核心技术深度会随之衰退。

(2) AI 促进了“全栈”能力的拓展

AI 正在让人们走出舒适区，触及“非核心”领域。

• 能力扩张：AI 的辅助下，工程师们开始承担以前不愿触碰的任务。例如，后端工程师开始参与前端 UI 的构建。
• 学习曲线加速：AI 降低了学习新领域的门槛，让原本需要数周或数月的学习过程在几小时甚至几分钟内完成。

(3) 技能退化的悖论

AI 的便利性带来了技能退化的担忧。

• 过度依赖：虽然 AI 能快速给出答案，但工程师们可能错过了学习过程中的“旁枝末节”，这些往往是建立深层次知识模型的重要环节。
• 监督难题：使用 AI 的前提是需要对其输出进行监督检查。如果核心技能退化，反而会导致监督 AI 的能力下降，从而陷入“监督难题”。

(4) 工作关系的转变

Claude 正成为‍“第一个询问对象”‍。

• 沟通方式变化：过去工程师会向同事寻求帮助，现在更多人会直接询问 Claude。这减少了日常的同事互动，但也可能导致 ‍“协作机会”‍ 的减少。
• 指导方式改变：对于初级工程师而言，Claude 也在承担“导师”的角色，提供即时的代码解释和调试建议。

以下为博客全文：

人工智能正在如何改变我们的工作方式？ 我们之前关于人工智能对经济影响的研究考察了整个劳动力市场，涵盖了各种不同的工作。但如果我们更详细地研究一些最早采用人工智能技术的群体——也就是我们自己呢？

回过头来看，我们在 2025 年 8 月调查了 132 名 Anthropic 的工程师和研究人员，进行了 53 场深入的定性访谈，并研究了内部的 Claude Code 使用数据，以了解人工智能的使用正在如何改变 Anthropic 的工作方式。我们发现，人工智能的使用正在从根本上改变软件开发人员的工作性质，带来了希望和担忧。

我们的研究揭示了一个面临重大转型的工作场所：工程师们完成的工作量大幅增加，变得更加“全栈”（能够胜任超出其正常专业领域的任务），加速了学习和迭代速度，并开始处理以前被忽视的任务。这种广度的扩张也让人们开始思考权衡——有些人担心这可能意味着失去更深入的技术能力，或者变得不太能有效监督 Claude 的输出，而另一些人则拥抱这种机会，去更广阔地思考并提升到更高的层次。有些人发现更多的人工智能协作意味着他们与同事的合作更少；还有些人担心他们最终可能会自动化地失去工作。

我们认识到，研究 AI 在一家构建 AI 的公司中的影响意味着代表了一种特权地位——我们的工程师可以提前接触到前沿工具，工作在一个相对稳定的领域，并且他们本身也在推动影响其他行业的 AI 转型。尽管如此，我们仍然觉得平衡上研究并发布这些发现是有用的，因为 Anthropic 内部工程师正在发生的事情可能仍然是更广泛社会转型的一个有启发性的预兆。我们的发现暗示了一些可能需要跨行业提前关注的挑战和考虑（尽管请参见附录中的“局限性”部分以了解警告）。在收集这些数据时，Claude Sonnet 4 和 Claude Opus 4 是当时最强大的模型，且其能力仍在持续进步。

更强大的 AI 带来了生产力收益，但它也引发了关于维护技术专长、保留有意义的协作以及为一个可能需要在 AI 增强的工作场所中学习、指导和职业发展采取新方法的不确定未来的准备问题。我们在下面的“展望未来”部分讨论了一些我们正在内部探索的初步措施。我们也在最近的博客文章中探讨了潜在的政策回应，讨论了 AI 相关经济政策的想法。

关键发现

在本节中，我们简要总结了来自我们的调查、访谈和 Claude Code 数据的发现。我们在以下章节中提供了详细的发现、方法和警告。

调查数据

• 工程师和研究人员最常用 Claude 来修复代码错误和了解代码库。调试和代码理解是最常见的用途（见图 1）。
• 人们报告称 Claude 使用率和生产力收益都在增加。员工自报使用 Claude 的比例从去年的 28% 增加到现在的 59%，并实现了 50% 的生产力提升，这是去年此时的 2-3 倍增长。这种生产力表现为每个任务类别的时间略有减少，但产出量显著增加（见图 2）。
• 27% 的 Claude 辅助工作属于原本不会完成的任务，如扩大项目规模、制作可有可无的工具（例如交互式数据仪表板）以及如果手工完成成本高昂的探索性工作。
• 大多数员工频繁使用 Claude，但报告称他们只能“完全委托” 0-20% 的工作给它。Claude 是一个持续的合作者，但使用它通常涉及主动的监督和验证，特别是在高风险工作中——而不是完全将不需要验证的任务交给它。

定性访谈

• 员工正在形成 AI 委托的直觉。工程师倾向于委托那些容易验证、他们“相对容易嗅探正确性”的、低风险的（例如“临时调试或研究代码”）或乏味的任务（“我越想做这个任务，我越不使用 Claude”）。许多人描述了一种信任进程，从简单任务开始，逐渐委托更复杂的工作——虽然他们目前仍保留大多数设计或“品味”任务，但随着模型的改进，这个边界正在重新协商。
• 技能集正在拓展，但有些人练习得更少。Claude 使人们能够拓展技能（例如“我现在可以非常有能力地处理前端或事务性数据库...以前我会害怕触碰这些东西”），但一些员工也矛盾地担心更深层次的技能会萎缩——“当产生输出变得如此容易和快速时，实际上很难抽出时间去学习东西。”
• 编码工艺的关系正在改变。一些工程师拥抱 AI 协助并专注于结果（“我认为我真的喜欢写代码，但我现在其实只享受写代码带来的结果”）；另一些人则说：“当然，我错过了[写代码]的某些部分。”
• 工作场所的社会动态可能正在改变。Claude 现在是原本去同事那里提问的第一站——有些人报告说因此而减少了指导和协作机会（“我喜欢和人一起工作，但现在我‘需要’他们的程度更少了……更初级的人不再像以前那样经常向我提问了。”）
• 职业发展和不确定性。工程师报告说他们正在转向管理 AI 系统的更高级别工作，并报告了显著的生产力收益。然而，这些变化也引发了关于软件工程作为职业长期轨迹的问题。一些人表达了对未来的矛盾情感：“我短期内感到乐观，但长期来看，我认为 AI 最终会做所有事情，使我和许多其他人变得无关紧要。”另一些人强调真正的不确定性，只说这“很难说”他们的角色在几年后会是什么样子。

Claude Code 使用趋势

• Claude 正在处理日益复杂的任务并且更具自主性。六个月前，Claude Code 大约完成 10 次操作后需要人类输入。现在，它通常处理约 20 次，需要更少的人类引导来完成更复杂的工作流程（见图 3）。工程师越来越多地使用 Claude 处理复杂任务，如代码设计/规划（使用率从 1% 增加到 10%）和实现新功能（从 14% 增加到 37%）（见图 4）。
• Claude 修复了很多“碎片问题”。8.6% 的 Claude Code 任务涉及修复细小的问题，以改善生活质量，如为了可维护性重构代码（即“修复碎片问题”），人们说这通常会被忽视。这些小修复可能会累积成更大的生产力和效率收益。
• 每个人都变得更加“全栈”。不同团队以不同方式使用 Claude，通常是为了增强他们的核心专长——安全团队使用它来分析不熟悉的代码，对齐与安全团队使用它来构建他们数据的前端可视化，等等（见图 5）。

详细调查结果

我们对 132 名 Anthropic 工程师和研究人员进行了调查，了解他们对 Claude 的使用情况，以更好地了解他们日常是如何使用它的。我们通过内部沟通渠道和对代表研究与产品功能的不同团队的员工进行直接联系来分发我们的调查。我们在附录中包含了一个局限性部分，其中包含了更多的方法细节，并且我们分享了我们的调查问题，以便他人评估我们的方法并适应他们自己的研究。

人们在使用 Claude 做哪些编码任务？

我们要求受访的工程师和研究人员评估他们在各种编码任务上使用 Claude 的频率，如“调试”（使用 Claude 帮助修复代码中的错误）、“代码理解”（让 Claude 解释现有代码以帮助人类用户了解代码库）以及“重构”（使用 Claude 帮助重构现有代码）和“数据科学”（例如让 Claude 分析数据集并绘制条形图）。

以下是最常见的每日任务。大多数员工（55%）每天都使用 Claude 进行调试。42% 每天使用 Claude 进行代码理解，37% 每天使用 Claude 实现新功能。使用频率较低的任务是高层次的设计/规划（可能是因为这些任务人们倾向于保留在人类手中），以及数据科学和前端开发（可能是因为总体上这些任务较少）。这大致与我们在“Claude Code 使用趋势”部分报告的 Claude Code 使用数据分布相符。

图 1：各类编码任务的每日用户比例（x 轴）

图 1：各类编码任务的每日用户比例（x 轴）

使用率和生产力

员工自报称 12 个月前，他们在 28% 的日常工作中使用 Claude，并从中获得了 20% 的生产力提升，而现在他们在 59% 的工作中使用 Claude，并平均实现了 50% 的生产力收益（图 2）。这大致与我们在全公司采用 Claude Code 时看到的每个工程师每天合并的拉取请求（成功纳入代码的更改）增加 67% 的数据相吻合。年度比较非常戏剧性——这表明这两个指标在一年内增长了超过 2 倍。使用率和生产力也高度相关，在分布的极端端点，14% 的受访者报告说他们通过使用 Claude 将生产力提高了超过 100%——这些是我们内部的“强力用户”。

需要对这一发现（以及下面的其他自报告生产力发现）进行警告，因为生产力很难精确衡量（请参见附录了解更多局限性）。有一项来自 AI 研究非营利组织 METR 的近期工作表明，在高度熟悉的代码库上使用 AI 的经验丰富的开发人员往往高估了他们从 AI 那里获得的生产力提升。话虽如此，METR 确定的导致实际生产力低于预期的因素（例如 AI 在大型、复杂环境中的表现较差，或者需要大量隐性知识/上下文的地方）与我们的员工说他们不委托给 Claude 的任务类型（见下文 AI 委托方法）密切对应。我们在各任务上的生产力收益，可能反映了员工开发的战略 AI 委托技能——这是 METR 研究中未考虑的。

当询问员工在他们当前使用 Claude 的任务类别中，它如何影响他们在该任务类别上的整体时间花费和工作产出量时，出现了一个有趣的生产力模式：几乎所有任务类别，我们都看到了时间花费的净减少，但产出量的净增加更大（图 2）。

图 2：各任务的时间花费（左侧）和产出量（右侧）的影响（y 轴）。每个图的 x 轴对应于时间花费或产出量的自报告减少（负值）、增加（正值）或无变化（垂直虚线），相对于不使用 Claude 的情况。误差条显示 95% 的置信区间。圆形面积与每个评级点的响应数量成比例。仅包括报告在每个任务类别中使用 Claude 的受访者。

图 2：各任务的时间花费（左侧）和产出量（右侧）的影响（y 轴）。每个图的 x 轴对应于时间花费或产出量的自报告减少（负值）、增加（正值）或无变化（垂直虚线），相对于不使用 Claude 的情况。误差条显示 95% 的置信区间。圆形面积与每个评级点的响应数量成比例。仅包括报告在每个任务类别中使用 Claude 的受访者。

然而，当我们深入挖掘原始数据时，我们看到时间节省的响应聚集在相反的两端——有些人在 Claude 辅助的任务上花费了显著更多的时间。

为什么会这样？人们通常解释说，他们不得不花更多时间调试和清理 Claude 的代码（例如“当我把代码逼到死胡同时”），并承担更多的认知负担来理解 Claude 的代码，因为他们没有自己编写它。有些人提到花更多时间是为了启用——有人说使用 Claude 帮助他们“坚持做那些我以前会立即放弃的任务”；另一个人说它帮助他们进行更彻底的测试，并在新代码库中进行更多学习和探索。看起来通常，经历时间节省的工程师可能是那些快速为 Claude 指定可快速验证的任务的人，而花费更多时间的工程师可能是在调试 AI 生成的代码或在 Claude 需要更多指导的领域工作。

我们目前的数据也不清楚报告的时间节省是被重新投资到哪里——是额外的工程任务、非工程任务、与 Claude 互动或审查其输出，还是工作之外的活动。我们的任务分类框架并未捕捉工程师可能分配时间的所有方式。此外，时间节省可能反映了自我报告中的感知偏差。需要进一步研究来厘清这些影响。

产出量的增加更直接且更显著；所有任务类别都有更大的净增加。当我们考虑人们报告的是任务类别（如“调试”）而不是具体任务时，这种模式是有意义的——即人们可以在调试作为一个类别上花费稍少的时间，同时整体产生更多的调试产出。生产力很难直接衡量，但这些自报告的数据表明，AI 在 Anthropic 的生产力提升主要是通过更大的产出量实现的。

Claude 使新工作成为可能

我们感到好奇的一件事是：Claude 是否使定性的新工作类型成为可能，或者 Claude 辅助的工作最终是否会由员工完成（虽然可能速度更慢）？

员工估计，27% 的 Claude 辅助工作如果没有它就不会完成。工程师提到使用 AI 扩大项目规模、制作可有可无的工具（如交互式数据仪表板）以及有用但乏味的工作，如文档编写和测试，以及手动进行成本高昂的探索性工作。正如一个人解释的那样，他们现在可以修复更多以前破坏生活质量的“小碎片”问题，例如为了可维护性重构代码，或者构建“帮助更快完成另一项任务的小工具”。我们在使用数据分析中也找到了这一点，发现 8.6% 的 Claude Code 任务涉及“碎片修复”。

另一位研究人员解释说，他们同时运行了许多版本的 Claude，所有这些版本都在探索问题的不同方法：

人们倾向于将超级强大的模型视为一个单一的实例，就像获得一辆更快的汽车。但拥有一百万匹马……可以让你测试一堆不同的想法……当你有那种额外的广度去探索时，这很令人兴奋，也更具创造性。

正如我们将在以下章节看到的，这种新工作通常涉及工程师处理超出其核心专长的任务。

有多少工作可以完全委托给 Claude？

虽然工程师频繁使用 Claude，但超过一半的人说他们只能“完全委托” 0-20% 的工作给 Claude。（值得注意的是，受访者可能对“完全委托”的解释会有差异——从根本不需要验证的任务到只需要轻微监督的任务都有）。当解释原因时，工程师描述了与 Claude 主动、迭代地合作，并验证其输出——特别是对于复杂任务或高风险领域，代码质量标准至关重要。这表明工程师倾向于与 Claude 紧密合作并检查其工作，而不是在没有验证的情况下将任务交给它，并且他们对什么算作“完全委托”设置了很高的门槛。

定性访谈结果

虽然这些调查发现揭示了显著的生产力收益和工作模式变化，但它们也提出了关于工程师日常体验这些变化的问题。为了了解这些指标背后的人性维度，我们对 53 位响应调查的 Anthropic 工程师和研究人员进行了深入访谈，以深入了解他们对这些工作场所变化的思考和感受。

AI 委托方法

工程师和研究人员正在开发各种策略，以在工作流程中富有成效地利用 Claude。人们通常委托以下任务：

这些员工在决定委托时提到的因素与 METR 的一项外部研究中解释 AI 生产力放缓的因素（如对代码库的高度熟悉，或者大型复杂仓库）非常相似。我们访谈中出现的这些委托标准的共识表明，任务选择是 AI 生产力收益的重要因素（这在未来的生产力研究中应该被仔细控制）。

信任但要验证

许多用户描述了他们的 Claude 使用进程，涉及随着时间推移委托越来越复杂的任务：“一开始，我只用 AI 询问 Rust 编程语言的基础问题……最近，我用 Claude Code 完成了所有编码工作。”

一位工程师将信任进程比作采用其他技术，如谷歌地图：

最初，我只会在不熟悉的路线使用[谷歌地图]……这就像我使用 Claude 编写我不知道的 SQL，但不要求它编写我熟悉的 Python。然后，我开始在大多数我熟悉的路线使用谷歌地图，可能只是不知道最后一英里……今天，我一直在使用谷歌地图，即使是我的日常通勤。如果它说走不同的路线，我会相信它考虑了所有选项……我今天以类似的方式使用 Claude Code。

工程师们在是否在自己专长范围内使用 Claude 上存在分歧。有些人将其用于“外围”领域以节省实现时间；另一些人则更喜欢熟悉的领域，在那里他们可以验证输出（“我在使用 Claude 时，仍然完全了解它在做什么”）。一位安全工程师强调了经验的重要性，当 Claude 提出一个“非常聪明却危险的解决方案”时：

这是一个非常有才华的初级工程师可能会提出的东西。这意味着，只有具有判断力和经验的用户才能识别出问题。

另一些工程师在两种任务上都使用 Claude，要么以实验的方式（“我基本上总是使用 Claude 来解决任何编码问题的第一步”），要么根据他们在任务中的专长水平调整他们的方法：

我在核心专长（作为加速器）上使用工具，我知道该期望什么，并且可以有效地指导代理；在我稍微超出专长领域的事情上，我大致知道该期望什么，但 Claude 能够填补我记忆或特定定义方面的空白。 如果是我特别熟悉的东西，我会更有主见，告诉 Claude 需要追踪的内容。如果是不确定的，我经常要求它成为专家，给我提供选项和见解，告诉我应该考虑的事情。

人们保留哪些任务？

人们一致表示他们不使用 Claude 进行涉及高层次或战略性思考的任务，或者需要组织上下文或“品味”的设计决策。一位工程师解释道：“我通常保留高层次的思考和设计。我将新功能开发中的任何可以委托的事情委托出去。”这反映在我们的调查数据中，显示设计和规划任务的生产力收益最少。许多人描述委托边界是一个“移动的目标”，但随着模型改进而定期重新协商（见下文 Claude Code 使用趋势显示现在使用编码设计/规划的比例比六个月前更多）。

技能转变

新能力……

调查发现 27% 的 Claude 辅助工作如果没有它就不会完成，这反映了一个更广泛的模式：工程师使用 AI 从事超出其核心专长的工作。许多员工报告完成了以前超出其专长范围的工作——后端工程师构建 UI；研究人员创建可视化。一个后端工程师描述了通过 Claude 迭代构建复杂 UI 的过程：

它做得比我想象的好得多。我根本无法完成……[设计师] 说“等等，你是怎么做到的？”我说“不，是 Claude 做的——我只是提示它。”

工程师报告说：“变得更加全栈……我可以非常有能力地处理前端，或者事务性数据库，或者 API 代码，而以前我会害怕接触我不太擅长的东西。”这种能力扩展使得反馈循环更紧密，学习更快——一位工程师说，构建、安排会议和迭代的“几周过程”可以变成“有同事在场进行实时反馈的几个小时”。

总体而言，人们对自己能够快速原型、并行工作、减少繁琐工作感到兴奋，这提升了他们的雄心。一位资深工程师告诉我们：“这些工具肯定让初级工程师更有生产力，也更大胆地承担他们会承担的项目类型。”还有些人说，减少的“激活能量”使他们更容易克服拖延，“极大地降低了我想要开始解决问题的能量，因此我愿意处理更多的额外工作。”

……但少了动手练习

与此同时，一些人担心“随着他们更多地委托，技能会萎缩”，失去在手动解决问题时发生的偶然（或“附带”）学习：

如果你自己去调试一个困难的问题，你会花时间阅读与解决你的问题直接无关的文档和代码，但在这段时间里，你正在构建一个系统如何运作的模型。现在发生的事情更少，因为 Claude 可以直接把你带到问题上。

我过去会探索每个配置，以了解工具能做什么，但现在我依赖 AI 告诉我如何使用新工具，所以我缺乏专业知识。在与其他队友的对话中，我可以立刻回忆起事情，而现在我必须问 AI。

使用 Claude 有可能跳过这样一个过程：我通过解决一个简单的实例来学习如何执行一项任务，然后再努力解决更复杂的实例。

一位资深工程师说，如果他们是初级工程师，他们会更担心自己的技能：

我主要在我知道答案应该是什么或应该是什么样子的情况下使用 AI。我通过艰难的方式做 SWE 开发来培养这种能力……但如果我处于职业生涯的早期，我会认为需要大量的刻意努力来继续发展自己的能力，而不是盲目接受模型的输出。

导致编码技能萎缩令人担忧的一个原因是“监督悖论”——如上所述，有效使用 Claude 需要监督，而监督 Claude 需要可能因 AI 过度使用而萎缩的编码技能。一位人士说：

老实说，我更担心监督和监督问题，而不是我的技能集……我的技能萎缩或未发展主要在于我能否安全地使用 AI 完成我关心的任务，而不是我能否独立完成这些任务。

为了解决这个问题，一些工程师有意在没有 AI 的情况下练习：“偶尔，即使我知道 Claude 能解决问题，我也不会请它帮忙。这有助于我保持敏锐。”

我们仍然需要这些动手编码技能吗？

也许软件工程正转向更高层次的抽象，这在过去已经发生过。早期的程序员离机器更近——手动管理内存、用汇编语言编写代码，甚至切换物理开关输入指令。随着时间推移，出现了更高层次、更易读的语言，自动处理复杂的低层操作。也许，特别是随着“共振编码”（vibe coding）的兴起，我们现在正在转向使用英语作为编程语言。我们的一名员工建议有志成为工程师的人“擅长让 AI 写代码，并专注于学习更高层次的概念和模式”。

少数员工说他们觉得这种转变赋予了他们思考更高层次的能力——“关于最终产品和最终用户”，而不仅仅是代码。一位人士通过将当前的转变与以前必须学习计算机科学中的链表进行比较来描述当前的转变——这是大多数高级编程语言现在自动处理的基本结构。“我很高兴我知道如何做到这一点……但手动执行这些低层操作在情感上并不重要。我宁愿关心代码让我能做什么。”另一位工程师做了类似的比较，但指出抽象是有代价的——随着向更高层语言的转变，大多数工程师失去了对内存处理的深刻理解。

在一个领域继续发展技能可以导致更好地监督 Claude 并更有效地工作（“我注意到，当这是我熟悉的事情时，我通常更快”），但工程师在这是否重要上存在分歧。有些人保持乐观：

我并不太担心技能萎缩。AI 仍然让我仔细思考问题，并帮助我学习新方法。如果有什么的话，能够更快地探索和测试想法实际上加速了我在某些领域的学习。

另一位更务实：“我肯定在软件工程技能上萎缩了……但那些技能如果有需要的话可以恢复，而且我根本不再需要它们了！”一位指出他们只失去了一些不太重要的技能，比如制作图表，“最关键的代码我仍然写得很好。”

也许最有趣的是，一位工程师挑战了这种前提：“‘变得生锈’的说法依赖于编码将来会回到 Claude 3.5 之前的方式。我认为不会。”

软件工程的工艺和意义

工程师对他们是否想念动手编码的看法截然不同。有些人感到真正的失落——“这是我时代的终结——我已经编程 25 年了，感到胜任这个技能集是我的职业满足感的核心部分。”另一些人担心不喜欢新工作性质：“整天提示 Claude 并不是非常有趣或有成就感。自己实现东西时更有乐趣。”

一些人直接面对权衡并接受它：“确实有一些我想念的部分——重构代码时进入的禅定状态，但总体而言，我现在的生产力更高，我愿意放弃这一点。”

一位人士说，与 Claude 迭代更有趣，因为他们可以比人类更挑剔地反馈。另一些人对结果更感兴趣。一位工程师说：

我预计到这个时候我会感到害怕或无聊……然而我并没有真的感到这两种情况。相反，我感到非常兴奋，因为我能做得多得多。我认为我真的很喜欢写代码，而我实际上只享受写代码所带来的结果。

是否拥抱 AI 协助或哀叹失去动手编码似乎取决于他们认为软件工程最有意义的是什么方面。

工作场所的社会动态正在改变

其中一个更突出的主题是 Claude 已经成为了曾经去同事那里提问的第一站。一位员工指出：“我现在提的问题更多，但 80-90% 去 Claude 了。”这创造了一种过滤机制，Claude 处理日常询问，让同事专注于更复杂、战略性或超出 AI 能力的上下文繁重的问题（“它减少了我对团队的依赖 80%，但最后 20% 是关键，我去找他们”）。人们也“与 Claude 抛出想法”，类似于与人类合作者的互动。

约一半人报告说团队协作模式没有改变。一位工程师说他仍然与人会面、分享上下文并选择方向，他认为在不久的将来仍然会有很多协作，但“不是做标准的专注工作，而是与许多 Claude 对话。”

然而，其他人描述了与同事互动减少的经历（“我与 Claude 的合作比与任何同事都多。”）。有些人欣赏减少的社交摩擦（“我不觉得浪费同事的时间不好”）。另一些人抵制这种变化（“我实际上不喜欢常见的回应是‘你问过 Claude 吗？’我真的喜欢亲自与人合作并高度重视它”），或者想念过去的工作方式：“我喜欢与人合作，我觉得可悲的是我现在‘需要’他们更少了。”

有几位指出了对传统指导动态的影响，因为“Claude 可以为初级员工提供大量辅导”，而不是高级工程师。一位资深工程师说：

对于初级员工来说，这是悲哀，因为更多的初级员工不再经常向我提问，虽然他们肯定更有效地得到答案并学得更快。

职业不确定性与适应

许多工程师描述他们的角色正在从写代码转向管理 AI。工程师越来越看到自己是“AI 代理的经理”——有些人已经“始终有几个人 Claude 实例在运行”。一位人士估计他们的工作已经转向“70%+ 变成了代码审查/修订者，而不是新代码编写者”，另一位则看到“承担 1、5 或 100 个 Claude 的工作”作为未来角色的一部分。

从长期来看，职业不确定性是普遍存在的。工程师认为这些变化是更广泛行业转型的预兆，许多人说很“难说”几年后他们的职业生涯会是什么样子。一些人表达了短期乐观与长期不确定之间的冲突：“我短期内感到乐观，但长期来看，我认为 AI 最终会做所有事情，使我和许多人变得无关紧要”，一位人士陈述。

一些工程师更乐观。一位说：“我担心初级开发者，但我也欣赏初级开发者可能是最渴求新技术的。我对这个行业的轨迹总体上非常乐观。”他们认为，虽然有不成熟的工程师发布有问题的代码的潜在风险，但更好的 AI 防护栏、更多内置的教育资源以及从错误中自然学习将帮助该领域随着时间的推移进行适应。

我们询问人们如何设想他们未来的角色以及是否有任何适应策略。一些人提到了进一步专门化的计划（“发展有意义审查 AI 工作的技能将需要更长时间并需要更多专门化”），一些人预计未来会专注于更人际和战略性的工作（“我们会花更多时间寻找共识，让 AI 花更多时间在实现上”）。一位人士说他们专门用 Claude 来进行职业发展，获取关于工作和领导技能的反馈（“我学习东西或甚至仅仅是有效的速率完全改变了。我几乎觉得天花板被打碎了”）。

总体而言，许多人承认深度不确定性：“我对未来几年哪些具体技能会有用的信心非常低。”一位团队负责人说：“没有人知道会发生什么……重要的是要非常适应性强。”

Claude Code 使用趋势

调查和访谈数据表明，Claude 使用的增加正在帮助人们工作更快并承担新类型的工作，尽管这伴随着关于 AI 委托和技能发展的紧张。尽管如此，自我报告的数据只讲了部分故事。为此，我们也分析了 Anthropic 团队的实际 Claude 使用数据。因为调查受访者报告 Claude Code 是他们使用的主要方式，我们使用了我们的隐私保护分析工具来分析 2025 年 2 月和 8 月的 20 万份 Claude Code 内部记录。

以更少监督处理更难的问题

Claude Code 使用已经转向了更困难、更自主的编码任务（图 3）：

• Claude Code 正在处理越来越复杂的任务并且更具自主性。我们对每个记录的任务复杂度进行了 1-5 评分，其中 1 对应“基本编辑”，5 对应“需要数周/月人类专家工作的专家级任务”。任务复杂度从平均 3.2 增加到 3.8。为了说明分数之间的差异：平均 3.2 的任务包括“排查 Python 模块导入错误”，而平均 3.8 的任务包括“实现和优化缓存系统”。
• Claude Code 完成任务所需的最大连续工具调用次数增加了 116%。工具调用对应 Claude 使用外部工具（如编辑文件或运行命令）执行的操作次数。Claude 现在可以在无需人类干预的情况下串联 21.2 次独立工具调用，而六个月前为 9.8 次。
• 人类回合次数减少了 33%。平均人类回合次数从 6.2 减少到 4.1，表明完成给定任务现在需要更少的人类输入。

图 3. 2025 年 8 月和 2 月的 Claude Code 使用变化（x 轴）。平均任务复杂度随时间增加（左图），每个记录的最大连续工具调用次数随时间增加（中图），人类回合次数随时间减少（右图）。误差条显示 95% 的置信区间。数据表明人们随着时间推移正在越来越多地委派自主权给 Claude。

图 3. 2025 年 8 月和 2 月的 Claude Code 使用变化（x 轴）。平均任务复杂度随时间增加（左图），每个记录的最大连续工具调用次数随时间增加（中图），人类回合次数随时间减少（右图）。误差条显示 95% 的置信区间。数据表明人们随着时间推移正在越来越多地委派自主权给 Claude。

这些使用数据证实了调查数据：工程师正将更复杂的工作委派给 Claude，Claude 需要的监督也更少。这似乎是推动观察到的生产力收益的原因。

任务分布

我们将 Claude Code 记录分类为一种或多种编码任务类型，研究了过去六个月中不同任务的使用情况（图 4）：

图 4. 各类编码任务（y 轴）作为整体记录数量的百分比（x 轴）。我们比较了 6 个月前（粉色）与现在（紫色）的分布。y 轴按 2025 年 2 月的频率排序。

图 4. 各类编码任务（y 轴）作为整体记录数量的百分比（x 轴）。我们比较了 6 个月前（粉色）与现在（紫色）的分布。y 轴按 2025 年 2 月的频率排序。

从使用数据估计的整体任务频率分布大致与自报告的任务频率分布一致。最显著的变化是，从 2025 年 2 月到 8 月，使用 Claude 实现新功能（14.3% → 36.9%）和进行代码设计或规划（1.0% → 9.9%）的记录比例显著增加。这种相对分布的变化可能表明 Claude 在处理这些更复杂任务方面变得更好，尽管它也可能反映了团队采用 Claude Code 的工作流程变化，而不是绝对工作量的增加（见附录了解更多局限性）。

修复碎片问题

我们发现从调查中得知，工程师现在花更多时间进行小的质量生活改进；与此一致的是，当前 Claude Code 任务中有 8.6% 被分类为“碎片修复”。这些包括创建性能可视化工具和重构代码以便维护的较大任务，以及创建终端快捷键等较小任务。这可能有助于工程师报告的生产力收益（解决之前被忽视的质量生活改进可能会导致长期更高的效率），并可能降低日常工作的摩擦和挫败感。

团队间任务差异

为了研究不同团队之间的任务差异，我们细化了分类方法，将每个 8 月的记录分配给单一主要编码任务，并按内部团队拆分数据（水平轴）。堆叠条形图显示了每个团队的 Claude Code 使用中不同任务的比例（水平轴）：

图 5. 每个水平条形代表一个团队（y 轴），其中的细分显示该团队 Claude Code 使用中不同编码任务（x 轴）的比例，按颜色区分任务（图例）。顶部条形（“All Teams”）代表整体分布。

图5. 每个水平条形代表一个团队（y 轴），其中的细分显示该团队 Claude Code 使用中不同编码任务（x 轴）的比例，按颜色区分任务（图例）。顶部条形（“All Teams”）代表整体分布。

“All Teams”条形显示了整体分布，最常见的任务是构建新功能、调试和代码理解。这为团队特定的比较提供了基准。

值得注意的团队特定模式：

• 预训练团队（Pre-training team）‍（帮助训练 Claude）经常使用 Claude Code 来构建新功能（54.6%），其中很大一部分是运行额外的实验。
• 对齐与安全（Alignment & Safety）和后训练（Post-training）团队在前端开发方面使用 Claude Code 最多（分别为 7.5% 和 7.4%），通常是为了创建数据可视化。
• 安全团队（Security team）‍ 经常使用 Claude Code 进行代码理解（48.9%），具体是分析和理解代码库不同部分的安全影响。
• 非技术员工（Non-technical staff）‍ 通常使用 Claude Code 进行调试（51.5%），如排除网络问题或 Git 操作，以及数据科学（12.7%）；Claude 似乎对弥补技术知识的差距非常有价值。

这些团队特定模式展示了我们在调查和访谈中观察到的能力扩展：使团队成员能够从事他们原本没有时间或技能去做的工作。例如，预训练团队运行了许多额外的实验，非技术员工能够修复代码中的错误。虽然数据表明团队确实使用 Claude 完成他们的核心任务（例如，基础设施团队最常使用 Claude Code 进行基础设施和 DevOps 工作），但 Claude 通常也增强了他们的核心任务（例如，研究人员使用 Claude 进行前端开发，以更好地可视化他们的数据）。这表明 Claude 正在使每个人在工作中变得更加全栈。

展望未来

Anthropic 员工在过去一年中大幅增加了 Claude 的使用量，不仅加速了现有工作，还学习了新的代码库，减少了繁琐工作，拓展到新领域，并处理以前被忽视的改进。随着 Claude 变得更加自主和强大，工程师正在发现新的 AI 委托方式，同时也在思考未来他们需要哪些技能。虽然这些转变带来了明显的生产力和学习收益，但也伴随着关于软件工程长期轨迹的真正不确定性。AI 会像过去的软件工程转变——从低级到高级编程语言，或者从个人贡献者转变为管理者一样吗？或者它会走得更远？

这仍然是早期阶段——Anthropic 有许多早期采用者，格局正在快速变化，我们的发现目前可能并不适用于其他组织或背景（见附录了解更多局限性）。这项研究反映了这种不确定性：发现是细微的，没有单一的共识或明确的指令出现。但它确实提出了关于我们如何在这些变化中思考的问题。

为了跟进这项初步工作，我们正在采取几项措施。我们正在与 Anthropic 的工程师、研究人员和领导层交谈，解决提出的机会和挑战。这包括审视我们如何将团队聚集在一起并相互协作，如何支持职业发展，以及如何建立 AI 增强工作（例如通过我们的 AI 流利度框架）的最佳实践。我们还在将这项研究扩展到工程师之外，以了解 AI 转型如何影响组织内各角色，并支持外部组织（如 CodePath），帮助他们适应 AI 辅助的未来计算机科学课程。展望未来，我们也在考虑结构化的方法，随着 AI 能力的提升，可能变得越来越相关，例如角色演变的新路径或组织内部的再技能培训。

我们预计在 2026 年分享更具体的计划，随着我们的思考成熟。Anthropic 是负责任的工作场所转型实验室；我们不仅想研究 AI 如何改变工作，还想尝试如何深思熟虑地、有效地导航这种转型，从我们自己做起。

@online{huang2025aiwork,
author = {Saffron Huang and Bryan Seethor and Esin Durmus and Kunal Handa and Miles McCain and Michael Stern and Deep Ganguli},
title = {How AI Is Transforming Work at Anthropic},
date = {2025-12-02},
year = {2025},
url = {https://anthropic.com/research/how-ai-is-transforming-work-at-anthropic/},
}

原文地址：https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic

推荐阅读：

• 打破思考大模型“不可能三角”，蚂蚁集团更新了百灵万亿模型 Ling-2.5-1T、Ring-2.5-1T
• 2026年做 Agents 应该看这篇全面的技术综述
• Skill设计白皮书：Anthropic官方推荐的构建方法与避坑指南
• 春节前这波“偷袭”！DeepSeek 没官宣，但偷偷点了什么技能？
• 我在云端搭了个“贾维斯”：Moltbot（Clawdbot）云端部署与初体验