AI 如何改变 Anthropic 的工作方式

AI 正在如何改变我们的工作方式？我们之前关于 AI 经济影响的研究从整体上考察了劳动力市场，涵盖了各种不同的工作。但如果我们更详细地研究一些最早采用 AI 技术的群体——也就是我们自身，会发生什么？

向内审视，2025 年 8 月，我们调查了 132 名 Anthropic 工程师和研究人员，进行了 53 次深度定性访谈，并研究了内部 Claude Code 的使用数据，以了解 AI 的使用如何在 Anthropic 内部带来变化。我们发现，AI 的使用正在从根本上改变软件开发人员的工作性质，既带来了希望，也引发了担忧。

我们的研究揭示了一个正在经历重大变革的工作场所：工程师们完成了更多的工作，变得更加“全栈”（能够在超出其正常专业领域的任务中取得成功），加快了学习和迭代速度，并处理以前被忽视的任务。这种广度的扩展也让人们思考其中的权衡——一些人担心这可能意味着失去更深入的技术能力，或者变得不太能够有效地监督 Claude 的输出，而另一些人则拥抱这个机会，进行更宏大、更高层次的思考。一些人发现，更多的 AI 协作意味着与同事的协作减少；一些人想知道他们最终是否会自动化到让自己失业。

我们认识到，研究 AI 对一家构建 AI 的公司所产生的影响意味着代表了一种特权地位——我们的工程师能够率先使用尖端工具，在一个相对稳定的领域工作，并且他们自身正在为影响其他行业的 AI 变革做出贡献。尽管如此，我们仍然觉得研究和发布这些发现总体上是有益的，因为 Anthropic 内部工程师身上发生的事情可能仍然是更广泛社会变革的一个有启发性的预兆。我们的发现意味着一些挑战和考虑，可能需要各个部门及早关注（不过请参阅附录中的局限性部分以了解注意事项）。在收集这些数据时，Claude Sonnet 4 和 Claude Opus 4 是最先进的模型，而能力仍在持续提升。

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

主要发现

在本节中，我们简要总结了从我们的调查、访谈和 Claude Code 数据中得出的发现。我们在下面的章节中提供了详细的发现、方法和注意事项。

调查数据

  1. Anthropic 工程师和研究人员最常使用 Claude 来修复代码错误和了解代码库。调试和理解代码是最常见的用途（图 1）。
  2. 人们报告说 Claude 的使用量和生产力提升都在增加。 员工自我报告在 60% 的工作中使用 Claude，并实现了 50% 的生产力提升，相比去年同期增长了 2-3 倍。这种生产力表现为每个任务类别花费的时间略有减少，但产出量却显著增加（图 2）。
  3. 27% 的 Claude 辅助工作由原本不会完成的任务组成，例如扩展项目、制作锦上添花型工具（如交互式数据仪表板），以及如果手动完成将不具备成本效益的探索性工作。
  4. 大多数员工频繁使用 Claude，同时报告他们可以“完全委托”给它的工作量占 0-20%。 Claude 是一个持续的协作者，但使用它通常需要积极的监督和验证，尤其是在高风险工作中——而不是完全无需验证地移交任务。

定性访谈

  1. 员工正在培养 AI 委托的直觉。工程师倾向于委托那些易于验证的任务，在这些任务中，他们可以“相对容易地嗅出正确性”，低风险（例如“一次性调试或研究代码”），或无聊（“我对这项任务越兴奋，我就越不可能使用 Claude”）。许多人描述了信任的递进，从简单任务开始，逐渐委托更复杂的工作——尽管他们目前仍然保留着大多数设计或“品味”任务，但随着模型的改进，这个边界正在被重新协商。
  2. 技能组合正在扩展到更多领域，但一些人得到的实践机会减少了。 Claude 使人们能够将技能扩展到更多软件工程领域（“我可以非常胜任前端工作，或事务数据库……以前我会害怕接触这些东西”），但一些员工也担心，矛盾的是，这种深度技能组合所需的萎缩——“当产出变得如此简单和快速时，实际花时间学习某些东西变得越来越难。”
  3. 与编程技艺的关系正在改变。 一些工程师拥抱 AI 辅助，并专注于结果（“我原以为我真的很喜欢编写代码，但我认为我实际上只是喜欢通过编写代码所获得的东西”）；另一些人说，“我当然会怀念[编写代码]的某些部分。”
  4. 工作场所社交动态可能正在改变。 Claude 现在成了那些以前会去向同事请教的问题的第一站——一些人报告说，因此指导和协作的机会减少了。（“我喜欢与人一起工作，现在我‘需要’他们的次数减少了，这让我很难过……初级员工不再像以前那样经常带着问题来找我。”）
  5. 职业演变和不确定性。 工程师报告说，他们正转向更高级的工作，管理 AI 系统，并报告了显著的生产力提升。然而，这些变化也引发了关于软件工程作为一门职业的长期发展轨迹的问题。一些人对未来表达了矛盾的感受：“短期内我感到乐观，但长期内我认为 AI 最终会完成所有工作，让我和其他许多人变得无关紧要。”其他人则强调了真正的不确定性，只说“很难说”几年后他们的角色会是什么样子。

Claude Code 使用趋势

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

调查数据

我们对来自整个组织的 132 名 Anthropic 工程师和研究人员进行了调查，以更好地了解他们日常究竟如何使用它。我们通过内部沟通渠道和直接外联的方式向代表研究和产品职能的不同团队员工分发了调查问卷。我们在附录中包含了局限性部分，提供了更多的方法细节，并且我们正在分享我们的调查问题，以便其他人可以评估我们的方法并将其应用于自己的研究。

人们在用 Claude 做什么样的编码任务？

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

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

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

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

使用情况和生产力

员工自我报告说，12 个月前，他们在 28% 的日常工作中使用 Claude，并从中获得了 +20% 的生产力提升，而现在，他们在 59% 的工作中使用 Claude，平均实现 +50% 的生产力提升。（这大致证实了我们在工程组织中采用 Claude Code 时看到的每个工程师每天合并的 PR（即成功合并的代码更改）数量增长 67%。）年度同比比较相当惊人——这表明一年内这两个指标都增长了 2 倍以上。使用量和生产力也高度相关，在分布的极端端，14% 的受访者通过使用 Claude 将生产力提高了 100% 以上——这些是我们内部的“超级用户”。

需要对此发现（以及下面其他自我报告的生产力发现）进行说明的是，生产力很难精确衡量（参见附录以了解更多局限性）。AI 研究非营利组织 METR 的最新工作表明，在高度熟悉的代码库中与 AI 一起工作的经验丰富的开发者高估了 AI 带来的生产力提升。话虽如此，METR 发现导致生产力低于预期的因素（例如，AI 在大型、复杂环境中表现更差，或者需要大量隐性知识/上下文）与我们的员工表示他们不会委托给 Claude 的任务类型密切相关（参见下面的 AI 委托方法）。我们跨任务自我报告的生产力提升可能反映了员工战略性地发展 AI 委托技能——这是 METR 研究中没有考虑到的。

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

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

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

然而，当我们深入研究原始数据时，我们看到时间节省的响应聚集在两个极端——一些人在 Claude 辅助的任务上花费的时间显著更多。

为什么会这样？人们普遍解释说，他们不得不花费更多时间调试和清理 Claude 的代码（例如，“当我自己用 vibe coding 陷入困境时”），并且由于不是他们自己编写的代码，他们在理解 Claude 的代码方面承担了更多的认知开销。一些人提到在一种赋能的意义上在一个任务上花费更多时间——一个人说，使用 Claude 帮助他们“坚持处理那些我以前会立即放弃的任务”；另一个人说它帮助他们在新的代码库中进行更彻底的测试以及更多的学习和探索。似乎通常，体验到时间节省的工程师可能是那些为 Claude 快速确定可验证任务范围的人，而那些花费更多时间的人可能是在调试 AI 生成的代码，或者在 Claude 需要更多指导的领域工作。

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

产出量的增加更直接、更显著；在所有任务类别中都有更大的净增长。当我们考虑到人们报告的是任务类别（如总体上的“调试”）而不是单个任务时，这种模式是有道理的——即，人们可以在一个类别上花费略少的时间，同时产生更多的调试输出总量。生产力很难直接衡量，但这些自我报告的数据表明，AI 主要通过增加产出量来提高 Anthropic 的生产力。

Claude 带来的新工作

我们好奇的一件事是：Claude 是否带来了定性的新工作，或者 Claude 辅助的工作最终是否会由员工完成（尽管可能速度较慢）？

员工估计，他们 27% 的 Claude 辅助工作如果没有 Claude 是不会完成的。工程师提到将 AI 用于扩展项目、锦上添花型工具（例如交互式数据仪表板）、有用的但繁琐的工作，如文档和测试，以及手动完成不具备成本效益的探索性工作。正如一个人解释的那样，他们现在可以修复更多以前会损害生活质量的“小麻烦”，例如重构结构糟糕的代码，或构建“有助于更快完成另一项任务的小工具”。

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

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

正如我们在接下来的章节中将要看到的，这项新工作通常涉及工程师处理超出其核心专业领域的任务。

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

尽管工程师频繁使用 Claude，但超过一半的人表示，他们可以“完全委托”给 Claude 的工作量仅占 0-20%。（值得注意的是，受访者对“完全委托”的解释可能存在差异——从完全不需要验证的任务到足够可靠仅需轻度监督的任务。）在解释原因时，工程师们描述了他们与 Claude 积极且迭代地合作，并验证其输出——尤其是在任务复杂或代码质量标准至关重要的领域。这表明工程师倾向于与 Claude 密切合作并检查其工作，而不是在没有验证的情况下移交任务，并且他们为“完全委托”设定了很高的标准。

定性访谈

虽然这些调查发现了显著的生产力提升和不断变化的工作模式，但它们引发了关于工程师日常如何实际体验这些变化的问题。为了理解这些指标背后的人性维度，我们对调查中做出回应的 53 名 Anthropic 工程师和研究人员进行了深度访谈，以更深入地了解他们对工作场所这些变化的思考和感受。

AI 委托方法

工程师和研究人员正在开发各种策略，以在其工作流程中富有成效地利用 Claude。人们通常会委托以下任务：
超出用户上下文且复杂度低： “我将 Claude 用于那些我上下文了解很少，但认为整体复杂度也很低的事情。” “我遇到的大多数基础设施[结构]问题都不难，可以由 Claude 处理……我不太了解 Git 或 Linux……Claude 很好地弥补了我在这些领域经验不足的缺陷。”
易于验证： “对于那些验证工作量与创建工作量相比不大的所有事情，它绝对是令人惊叹的。”
定义明确或独立的： “如果一个项目的某个子组件与项目的其余部分充分解耦，我会让 Claude 尝试一下。”
代码质量不关键： “如果是一次性调试[或]研究代码，我会直接交给 Claude。如果它在概念上很困难，或者需要某种非常特定类型的调试注入，或者是一个设计问题，我会自己做。”
重复或无聊的： “我对这项任务越兴奋，我就越不可能使用 Claude。而如果我感到很大的阻力……我经常发现与 Claude 开始关于这项任务的对话更容易。” 在我们的调查中，人们平均表示，44% 的 Claude 辅助工作由他们自己不愿意做的任务组成。
提示比执行更快： “[对于]我预计花费不到 10 分钟的任务……我可能不会费心使用 Claude。” “冷启动问题现在可能是最大的障碍。所谓冷启动，是指我拥有关于我的团队代码库如何工作的大量内在信息，而 Claude 默认情况下不会拥有这些信息……我可能会花时间尝试迭代出完美的提示[但]我打算自己去完成它。”

我们的员工在委托决策中提到的这些因素与 METR 的外部研究中发现的解释 AI 相关生产力下降的因素（例如开发者对代码库的高度熟悉、大型且复杂的仓库）相似。我们的访谈中对这些委托标准的趋同表明，适当的任务选择是 AI 生产力提升的一个重要因素（在未来的生产力研究中应仔细控制）。

信任但要验证

许多用户描述了他们的 Claude 使用情况的一个递进过程，涉及随着时间的推移委托日益复杂的任务：“起初，我向 AI 工具询问关于 Rust 编程语言的基本问题……最近，我一直在使用 Claude Code 进行我所有的编码工作。”

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

起初我只在不知道路线时使用 [Google 地图]……这就像我使用 Claude 来编写我不知道的 SQL，但不会要求它编写我知道的 Python。然后我开始在我大致知道的路线上使用 Google 地图，但可能不知道最后一英里……今天，我一直在使用 Google 地图，即使是每天的通勤。如果它说走不同的路，我就走，并且相信它已经考虑了所有选择……我今天以类似的方式使用 Claude Code。

工程师们对于是否在他们的专业领域内或外使用 Claude 存在分歧。一些人将其用于“外围”领域以节省实现时间；另一些人则更喜欢在他们可以验证输出的熟悉领域使用它（“我以这种方式使用 Claude，我仍然完全理解它在做什么”）。一位安全工程师强调了经验的重要性，当 Claude 提出了一个“非常聪明的解决方案，但危险十足，就像一个非常有才华的初级工程师可能会提出的那种东西”。也就是说，这是只有具备判断力和经验的用户才能识别为有问题的东西。

其他工程师以实验方式将 Claude 用于这两种类型的任务（“我基本上总是使用 Claude 来首先尝试任何编码问题”），或者根据他们在任务中的专业水平调整他们的方法：

我将这些工具用于那些属于我的核心专业领域的事情（作为加速器，我知道该期待什么并且可以有效地指导 Agent），以及那些稍微超出我的专业领域的事情，在那里我大致知道该期待什么，但 Claude 能够填补我的记忆空白或我对特定定义不熟悉的地方。

如果这是我对其特别精通的事情，我会更加自信，并告诉 Claude 它需要追踪什么。如果这是我不确定的事情，我通常会要求它成为专家，并给我一些我应该考虑和研究的选项和见解。

人们为自己保留哪些任务？

人们一致表示，他们不会将涉及高级或战略性思维的任务，或需要组织背景或“品味”的设计决策交给 Claude 处理。一位工程师解释说：“我通常会保留高级思维和设计。我会从开发新功能到调试的任何可以委托的事情都委托出去。” 这反映在我们的调查数据中，该数据显示设计和规划任务的生产力提升最小（图 2）。许多人将委托边界描述为一个“移动目标”，尽管随着模型的改进会定期重新协商（下面，Claude Code 使用数据显示，与六个月前相比，现在相对更多的编码设计/规划使用量）。

技能转型

新能力……

调查发现，27% 的 Claude 辅助工作如果没有 Claude 是不会完成的，这一发现反映了一个更广泛的模式：工程师使用 AI 在其核心专业领域之外工作。许多员工报告完成了以前超出其专业领域的工作——后端工程师构建 UI；研究人员创建可视化。一位后端工程师描述了通过与 Claude 迭代构建复杂 UI 的过程：“它做得比我曾经做过的要好得多。我自己做不到，肯定无法按时完成……[设计师们] 就像‘等等，这是你做的？’ 我说‘不，是 Claude 做的——我只是提示了它。’”

工程师们报告“变得更加全栈……我可以非常胜任前端工作，或事务数据库，或 API 代码，以前我会害怕接触我不太精通的东西。” 这种能力的扩展使得反馈循环更紧密，学习速度更快——一位工程师说，一个“几周的过程”包括构建、安排会议和与同事迭代，可以变成“几个小时的工作会议”，同事可以现场提供反馈。

总的来说，人们为他们快速原型化、并行化工作、减少辛劳以及普遍提高抱负水平的新能力感到兴奋。一位高级工程师告诉我们，“这些工具肯定让初级工程师更有生产力，也更有胆量承担各种类型的项目。” 一些人还表示，使用 Claude 降低的“激活能量”使他们能够更轻松地战胜拖延，“显著降低了我想要开始解决问题的意愿所需的能量，因此我愿意处理更多额外的事情。”

……以及更少的实践练习

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

如果你要自己去调试一个难题，你会花时间阅读与你的问题没有直接关系的文档和代码——但整个时间你都在构建系统如何工作的模型。这种情况现在少多了，因为 Claude 可以直接让你找到问题所在。

我曾经探索每个配置以了解该工具可以做什么，但现在我依靠 AI 告诉我如何使用新工具，因此我缺乏专业知识。在与队友的对话中，我可以立即回忆起事情，而现在我必须询问 AI。

使用 Claude 有可能跳过我先通过解决一个简单实例来学习如何执行任务的部分，然后在以后努力解决一个更复杂的实例。

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

我主要在那些我知道答案应该是什么或应该是什么样子的案例中使用 AI。我通过以“困难方式”做软件工程开发了这种能力……但如果我[职业生涯早期]，我会认为需要付出很多刻意的努力才能继续提升自己的能力，而不是盲目接受模型的输出。

编码技能萎缩令人担忧的一个原因是“监督悖论”——如上所述，有效使用 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 可以为初级员工提供大量指导”，而不是高级工程师。一位高级工程师说：

初级员工不再像以前那样经常带着问题来找我，这让人难过，尽管他们的问题 definitely 得到了更有效的解答，学习速度也更快。

职业不确定性与适应

许多工程师描述他们的角色正从编写代码转变为管理 AI。工程师们越来越将自己视为“AI Agent 的经理”——一些人已经“持续运行至少几个 [Claude] 实例”。一个人估计他们的工作已经转变为“70%+ 成为代码审查者/修改者，而不是全新的代码编写者”，另一个人则将“为 1 个、5 个或 100 个 Claude 的工作负责”视为他们未来角色的一部分。

从长期来看，职业不确定性普遍存在。工程师们将这些变化视为更广泛行业变革的先兆，许多人说“很难说”几年后他们的职业会是什么样子。一些人对短期乐观与长期不确定性之间的冲突表达了看法。 “短期内我感到乐观，但长期内我认为 AI 最终会完成所有工作，让我和其他许多人变得无关紧要，” 一个人说。其他人则更尖锐地指出：“感觉就像我每天上班是为了让自己失业。”

一些工程师更加乐观。一个人说：“我为初级开发者感到担忧，但我也很欣赏初级开发者可能是最渴望新技术的群体。我对这个职业的发展轨迹总体感到非常乐观。” 他们认为，虽然缺乏经验的工程师编写有问题代码的潜在风险存在，但更好的 AI 护栏、更多内置教育资源和从错误中自然学习的结合将有助于该领域随着时间的推移而适应。

我们询问人们如何设想他们未来的角色，以及他们是否有任何适应策略。一些人提到计划进一步专业化（“培养有意义地审查 AI 工作的技能将需要更长的时间，并且需要更多的专业化”），一些人预计未来将专注于更多的 interpersonal 和战略性工作（“我们将花费更多时间寻找共识，并让 AI 在实现上花费更多时间”）。一个人说，他们专门将 Claude 用于职业发展，从中获得关于工作和领导技能的反馈（“我学习事物的速度，或者甚至在还没有完全学会的情况下就变得高效的速度，完全改变了。我几乎觉得天花板刚刚为我粉碎”）。

总的来说，许多人承认存在深刻的不确定性：“我对自己认为未来哪些具体技能有用，信心非常低。” 一位团队负责人说：“没有人知道会发生什么……重要的是要真正适应。”

Claude Code 使用趋势

调查和访谈数据显示，Claude 使用量的增加正在帮助人们更快地工作，并承担新类型的工作，尽管这在 AI 委托和技能发展方面存在张力。尽管如此，自我报告的数据只讲述了部分故事。为了补充这一点，我们还分析了 Anthropic 团队之间实际的 Claude 使用情况。由于调查受访者报告说 Claude Code 占他们使用量的大部分，因此我们使用我们的隐私保护分析工具分析了 2025 年 2 月和 8 月的 20 万条内部 Claude Code 转录。

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

在过去六个月中，Claude Code 的使用已转向更困难、更自主的编码任务（图 3）：

图 3. 2025 年 8 月与 2025 年 2 月之间 Claude Code 使用的变化（x 轴）。平均任务复杂度随时间增加（左图），每个转录的平均最大连续工具调用次数随时间增加（中图），人工轮次随时间减少（右图）。误差线显示 95% 置信区间。数据表明，人们越来越将更多的自主权委托给 Claude。

图 3. 2025 年 8 月与 2025 年 2 月之间 Claude Code 使用的变化（x 轴）。平均任务复杂度随时间增加（左图），每个转录的平均最大连续工具调用次数随时间增加（中图），人工轮次随时间减少（右图）。误差线显示 95% 置信区间。数据表明，人们越来越将更多的自主权委托给 Claude。

这些使用数据证实了调查数据：工程师将越来越复杂的工作委托给 Claude，而 Claude 需要的监督更少。似乎这很可能是观察到的生产力提升的驱动因素。

任务分布

我们将 Claude Code 转录分类为一种或多种编码任务，研究了不同任务的用途在过去六个月中是如何演变的：

图 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 Code 任务相对分布的这种转变可能表明，Claude 已经变得更擅长这些更复杂的任务，尽管它也可能反映了团队采用 Claude Code 进行不同工作流程的方式的变化，而不是绝对工作量的增加（更多局限性参见附录）。

修复小麻烦

我们从调查中发现，工程师现在花更多时间进行小的质量改进；与此一致的是，8.6% 的当前 Claude Code 任务被归类为“小麻烦修复”。这些任务包括创建性能可视化工具和重构代码以提高可维护性等较大的任务，以及创建终端快捷方式等较小的任务。这可能有助于工程师报告的生产力提升（解决以前被忽视的生活质量改进可能会随着时间的推移带来更多效率），并可能减少日常工作中遇到的摩擦和挫败感。

跨团队的任务差异

为了研究任务目前在不同团队之间的差异，我们改进了分类方法，将每个 8 月的转录分配给一个主要的编码任务，并按内部团队（y 轴）拆分数据。堆叠条形图显示了每个团队的编码任务分类：

图 5. 每条水平条代表一个团队（y 轴），其中段显示该团队的 Claude Code 用于不同编码任务（x 轴）的比例，按编码任务（图例）进行颜色编码。最上方的条（“所有团队”）代表总体分布。

图 5. 每条水平条代表一个团队（y 轴），其中段显示该团队的 Claude Code 用于不同编码任务（x 轴）的比例，按编码任务（图例）进行颜色编码。最上方的条（“所有团队”）代表总体分布。

“所有团队”条显示了总体分布，最常见的任务是构建新功能、调试和理解代码。这为团队间的比较提供了基线。

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

  1. 预训练 团队（帮助训练 Claude 的团队）经常使用 Claude Code 构建新功能（54.6%），其中很多是运行额外的实验。
  2. 对齐与安全 和 后训练 团队使用 Claude Code 进行前端开发的比例最高（分别为 7.5% 和 7.4%），通常用于创建数据可视化。
  3. 安全 团队经常使用 Claude Code 来理解代码（48.9%），特别是分析和理解代码库不同部分的安全含义。
  4. 非技术 员工经常使用 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 如何改变工作，还希望实验如何深思熟虑地驾驭这种转型，首先从我们自己开始。

Bibtex

如果您想引用这篇文章，可以使用以下 Bibtex 键：

@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/},
}

致谢

Saffron Huang 领导了该项目，设计并执行了调查、访谈和数据分析，绘制了图表并撰写了博客文章。Bryan Seethor 共同设计了调查和访谈，共同领导了调查和访谈数据的收集，分析了访谈主题，为写作做出了贡献，并管理了项目时间表。Esin Durmus 为实验设计做出了贡献，并在整个过程中提供了详细的指导和反馈。Kunal Handa 为面试流程提供了基础设施。Deep Ganguli 提供了关键的指导和组织支持。所有作者都在整个过程中提供了详细的指导和反馈。

此外，我们感谢 Ruth Appel、Sally Aldous、Avital Balwit、Drew Bent、Zoe Blumenfeld、Miriam Chaum、Jack Clark、Jake Eaton、Sarah Heck、Kamya Jagadish、Jen Martinez、Peter McCrory、Jared Mueller、Christopher Nulty、Sasha de Marigny、Sarah Pollack、Hannah Pritchett、Stuart Ritchie、David Saunders、Alex Tamkin、Janel Thamkul、Sar Warner 和 Heather Whitney 提供了有益的想法、讨论、反馈和支持。感谢 Casey Yamaguma 为图表绘制插图。我们也感谢 Anton Korinek、Ioana Marinescu、Silvana Tenreyro 和 Neil Thompson 富有成效的评论和讨论。

附录

局限性

我们的调查结果受到一些方法学上的局限性。我们通过便利抽样和目的抽样（以确保广泛的组织代表性）选择了受访者。我们在多个内部 Slack 频道发布了调查，获得了 68 份回复，我们还从组织结构图中选择了 20 个不同的研究及产品职能团队，并直接联系了每个团队的 5-10 个人（共 207 次外联），获得了最终 64 份回复中的 31% 的回复率。我们采访了前 53 位做出回应的人。这里可能存在一些选择偏差，因为那些特别投入 Claude 或有强烈观点（正面或负面）的人可能更有可能做出回应，而那些体验更中性的人可能代表不足。

此外，回答可能受到社会期望偏差的影响（由于回答不是匿名的，并且所有参与者都是 Anthropic 员工，受访者可能夸大了他们对 Claude 影响的正面评估）和近因偏差（要求参与者回忆 12 个月前的生产力和使用模式会受到记忆扭曲的影响）。此外，正如所讨论的，生产力通常很难估计，因此这些自我报告应该持保留态度。这些自我报告的感知应该与我们对 Claude Code 使用数据的更客观的衡量一并解读，未来的研究将受益于匿名数据收集和更稳健、经过验证的测量工具。

我们的 Claude Code 分析使用了跨时间段的比例抽样，这意味着我们只能衡量任务分布的相对变化，而不能衡量工作量的绝对变化。例如，当我们报告说功能实现从占 Claude Code 使用量的 14% 增加到 37% 时，这并不一定表明正在完成更多的功能工作总量。

最后，这项研究是在 2025 年 8 月进行的，当时 Claude Sonnet 4 和 Claude Opus 4 是我们最先进的模型。鉴于 AI 发展的快速步伐，我们观察到的模式可能已经随着更新模型的出现而发生了变化。