wsl-docs

AI 如何重塑 Anthropic 的日常工作

原文链接：https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic60分钟阅读

摘要

1) 一句话总结 Anthropic 的内部研究表明，AI 工具（如 Claude）正显著提升员工生产力并促使工程师向“全栈”发展，但同时也引发了关于深层技术技能退化、人际协作减少以及长期职业发展不确定性的担忧。

2) 核心要点

  • 使用率与生产力飙升：员工自述在 60% 的工作中使用了 Claude，并实现了 50% 的生产力提升（这两项指标同比均增长了两倍多），主要表现为单项任务耗时略减而整体产出量大幅增加。
  • 主要应用场景：最常见的日常用途是代码调试（55% 的员工每天使用）和代码理解（42%）。
  • 促成增量工作：27% 的 Claude 辅助工作属于原本不会去做的任务，例如修复改善生活质量的“小痛点”（占 Claude Code 任务的 8.6%）、探索性工作或开发额外的可视化工具。
  • 有限的“完全委托”：尽管使用频繁，大多数员工表示只能将 0-20% 的工作“完全委托”给 AI；高风险或复杂任务仍需人类主动监督、验证和直觉检验。
  • AI 自主性与复杂性提升：过去六个月内，Claude Code 连续进行的工具调用量增加了一倍多（从约 10 次增至 21 次），人类交互轮次减少了 33%；用于代码设计/规划（1% 升至 10%）和新功能实现（14% 升至 37%）的比例显著上升。
  • 能力边界扩展：员工正变得更加“全栈”，利用 AI 跨越核心专业领域工作（例如后端工程师处理前端 UI，非技术员工进行代码调试）。
  • 角色定位转变：工程师的工作重心正逐渐从“全新代码编写者”向“代码审查员”或“AI 智能体管理者”转变。

3) 风险与局限性（基于原文明确提及）

  • 技能退化与“监督悖论”：员工担忧过度依赖 AI 会导致编写和批判代码的深层技能退化，而这些技能恰恰是有效监督和验证 AI 输出所必需的。
  • 职场社交与指导减少：Claude 成为解答常规问题的首选，导致同事间的日常协作减少，同时也削弱了高级工程师对初级员工的传统指导动态。
  • 职业前景不确定性：尽管短期内对生产力感到乐观，但员工对软件工程作为一种职业的长期发展轨迹存在深深的不确定性，部分人担忧最终会被自动化取代。
  • 数据与测量偏差：自述的生产力数据难以精确衡量，且可能受到社会期望偏差、近因偏差以及样本选择偏差（回复率 31%）的影响。
  • 分析指标局限：Claude Code 的使用数据仅反映任务分布的相对比例变化，无法衡量绝对工作量的增减。
  • 普适性限制：作为一家前沿 AI 公司的内部研究，其员工享有早期接触尖端工具的特权，当前发现可能无法直接推广到其他组织或环境。

正文

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 数据的发现。我们在下文的后续部分提供了详细的发现、方法和注意事项。

调查数据

  • Anthropic 的工程师和研究人员最常使用 Claude 来修复代码错误和了解代码库。调试和代码理解是最常见的用途（图 1）。

  • 员工报告 Claude 的使用量和生产力收益不断增加。员工自述在 60% 的工作中使用了 Claude，并实现了 50% 的生产力提升，比去年同期增长了 2-3 倍。这种生产力的提升表现为每个任务类别所花费的时间略有减少，但产出量大幅增加（图 2）。

  • 27% 的 Claude 辅助工作包含原本不会去做的任务，例如扩展项目、制作“锦上添花”的工具（如交互式数据仪表板），以及如果手动完成则不具备成本效益的探索性工作。

  • 大多数员工频繁使用 Claude，但报告称他们只能将 0-20% 的工作“完全委托”给它。Claude 是一个持续的协作者，但使用它通常需要主动的监督和验证，特别是在高风险工作中——而不是将任务交接出去后完全不需要验证。

定性访谈

  • 员工正在培养对 AI 委托的直觉。工程师倾向于委托那些易于验证、他们“可以相对容易地进行直觉检验 (sniff-check) 以确认正确性”、低风险（例如“用完即弃的调试或研究代码”）或枯燥的任务（“我对任务越兴奋，我就越不可能使用 Claude”）。许多人描述了一种信任的递进过程，从简单的任务开始，逐渐委托更复杂的工作——虽然他们目前仍保留着大多数设计或涉及“品味”的任务，但随着模型的改进，这种边界正在被重新协商。

  • 技能组合正在扩展到更多领域，但某些技能的练习变少了。Claude 使人们能够将技能扩展到软件工程的更多领域（“我可以非常胜任前端或事务性数据库的工作……而以前我会害怕接触这些东西”），但矛盾的是，一些员工也担心编写和批判代码所需的深层技能会退化——“当产生输出变得如此容易和快速时，花时间去真正学习一些东西就变得越来越难。”

  • 与编程技艺的关系正在发生变化。一些工程师拥抱 AI 辅助并专注于结果（“我原以为我真的很享受写代码，但我想实际上我只是享受写代码带来的结果”）；另一些人则表示“我确实很怀念（写代码的）某些部分。”

  • 职场社交动态可能正在发生变化。Claude 现在是解答那些过去通常向同事请教的问题的第一站——一些人报告说，这导致指导和协作的机会减少了。（“我喜欢与人合作，现在我不再那么‘需要’他们了，这让人有些失落……资历较浅的人不再像以前那样经常带着问题来找我了。”）

  • 职业发展与不确定性。工程师报告称，他们正在转向管理 AI 系统的更高层次工作，并报告了显著的生产力提升。然而，这些变化也引发了关于软件工程作为一种职业的长期发展轨迹的疑问。一些人对未来表达了矛盾的感受：“短期内我感到乐观，但从长远来看，我认为 AI 最终会做所有事情，让我和许多其他人变得无关紧要。”其他人则强调了真正的不确定性，只是说“很难说”几年后他们的角色会是什么样子。

Claude Code 使用趋势

  • Claude 正在更自主地处理越来越复杂的任务。六个月前，Claude Code 在需要人类输入之前大约能自行完成 10 个操作。现在，它通常能处理 20 个左右的操作，需要较少的人类引导就能完成更复杂的工作流（图 3）。工程师越来越多地使用 Claude 执行复杂的任务，如代码设计/规划（使用率从 1% 升至 10%）和实现新功能（从 14% 升至 37%）（图 4）。

  • Claude 修复了大量“小痛点 (papercuts)”。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 使用数据分布大致吻合。

使用量与生产力

员工自述在 12 个月前，他们在 28% 的日常工作中使用了 Claude，并从中获得了 +20% 的生产力提升；而现在，他们在 59% 的工作中使用了 Claude，并平均从中获得了 +50% 的生产力提升。（这大致印证了我们在整个工程部门采用 Claude Code 时看到的，每位工程师每天合并的拉取请求——即成功合并到代码中的更改——增加了 67% 的情况）。同比比较非常引人注目——这表明这两项指标在一年内增长了两倍多。使用量和生产力也密切相关，在分布的极端一端，14% 的受访者通过使用 Claude 将生产力提高了 100% 以上——这些是我们内部的“超级用户”。

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

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

然而，当我们深入挖掘原始数据时，我们发现节省时间的回答聚集在两端——有些人在 Claude 辅助的任务上花费了明显更多的时间。

为什么会这样？人们通常解释说，他们必须做更多的调试和清理 Claude 的代码（例如，“当我随性编程 (vibe code) 把自己逼进死胡同时”），并承担更多理解 Claude 代码的认知负担，因为这些代码不是他们自己写的。一些人提到在赋能意义上在任务上花费了更多时间——一位员工说使用 Claude 帮助他们“坚持完成我以前会立刻放弃的任务”；另一位员工说它帮助他们进行更彻底的测试，并在新的代码库中进行更多的学习和探索。似乎通常情况下，体验到时间节省的工程师可能是那些为 Claude 划定可快速验证任务范围的人，而那些花费更多时间的人可能是在调试 AI 生成的代码，或者在 Claude 需要更多指导的领域工作。

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

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

Claude 促成新的工作

我们很好奇的一件事是：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 的问题上，工程师们存在分歧。一些人将其用于“外围”领域以节省实施时间；另一些人则更喜欢在熟悉的领域使用，因为他们可以验证输出（“我以这样一种方式使用 Claude，即我仍然完全理解它在做什么”）。一位安全工程师强调了经验的重要性，当时 Claude 提出了一个解决方案，该方案“以一种危险的方式显得非常聪明，是一个非常有才华的初级工程师可能会提出的那种东西”。也就是说，只有具备判断力和经验的用户才能识别出这是有问题的。

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

人们一致表示，他们不会将 Claude 用于涉及高层或战略思维的任务，或者需要组织背景或“品味”的设计决策。一位工程师解释说：“我通常保留高层思维和设计。我委托从新功能开发到调试的任何我能委托的事情。”这反映在我们的调查数据中，数据显示设计和规划任务的生产力提升最小（图 2）。不过，许多人将委托边界描述为一个“移动的目标”，随着模型的改进而定期重新协商（在下文中，Claude Code 使用数据显示，现在的代码设计/规划使用率相对六个月前有所增加）。

技能转变

调查发现 27% 的 Claude 辅助工作原本不会完成，这反映了一个更广泛的模式：工程师使用 AI 在其核心专长之外工作。许多员工报告完成了以前超出其专业范围的工作——后端工程师构建 UI；研究人员创建可视化。一位后端工程师描述了通过与 Claude 迭代来构建复杂的 UI：“它做得比我能做的要好得多。我不可能做到，绝对不可能按时完成……（设计师们）说‘等等，这是你做的？’我说‘不，是 Claude 做的——我只是提示了它。’”

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

总的来说，人们对他们快速制作原型、并行工作、减少苦工以及总体上提高雄心水平的新能力感到兴奋。一位高级工程师告诉我们：“这些工具绝对让初级工程师变得更有生产力，并且在他们愿意承担的项目类型上更加大胆。”一些人还表示，使用 Claude 降低了“启动阻力 (activation energy)”，使他们能够更容易地战胜拖延症，“极大地降低了我想要开始解决问题所需的能量，因此我愿意解决更多额外的事情。”

与此同时，一些人担心“随着委托的增加，技能会退化”，并失去在手动解决问题过程中发生的偶然（或“附带”）学习：

一位高级工程师表示，如果他们资历较浅，他们会更担心自己的技能：

编程技能退化令人担忧的一个原因是“监督悖论”——如上所述，有效使用 Claude 需要监督，而监督 Claude 需要的正是可能因过度使用 AI 而退化的编程技能。一个人说：

为了应对这种情况，一些工程师刻意在不使用 AI 的情况下进行练习：“每隔一段时间，即使我知道 Claude 能完美解决一个问题，我也不会让它做。这有助于我保持敏锐。”

也许软件工程正在向更高层次的抽象发展，就像过去发生过的那样。早期的程序员在更接近机器的层面工作——手动管理内存，用汇编语言编写，甚至拨动物理开关来输入指令。随着时间的推移，出现了更高级、更易于人类阅读的语言，自动处理复杂的底层操作。也许，特别是随着“随性编程 (vibe coding)”的兴起，我们现在正在转向将英语作为一种编程语言。我们的一位员工建议有抱负的工程师“擅长让 AI（写代码），并专注于学习更高层次的概念和模式。”

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

继续在某个领域发展技能可以带来对 Claude 更好的监督和更高效的工作（“我注意到，当它是我熟悉的东西时，我自己做通常更快”）。但工程师们对于这是否重要存在分歧。一些人保持乐观：

另一个人则更务实：“作为一名软件工程师，我的技能肯定在退化……但如果需要的话，这些技能可以恢复，我只是不再需要它们了！”一个人指出，他们只失去了像制作图表这样不太重要的技能，而“那种关键的代码我仍然写得很好。”

也许最有趣的是，一位工程师对这个前提提出了挑战：“‘变得生疏’的框架依赖于这样一个假设：编程有一天会回到前 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 月来自 Claude Code 的 200,000 份内部记录。

以更少的监督解决更难的问题

在过去的六个月里，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，这表明与六个月前相比，现在完成给定任务所需的人类输入更少了。

这些使用数据印证了调查数据：工程师将越来越复杂的工作委托给 Claude，而 Claude 需要的监督更少。这似乎合理地推动了观察到的生产力提升。

任务分布

我们将 Claude Code 记录分类为一种或多种类型的编程任务，研究了过去六个月中不同任务用途的演变：

从使用数据估计的总体任务频率分布与自述的任务频率分布大致吻合。2025 年 2 月和 8 月之间最显著的变化是，现在有比例多得多的记录使用 Claude 来实现新功能（14.3% → 36.9%）和进行代码设计或规划（1.0% → 9.9%）。Claude Code 任务相对分布的这种转变可能表明 Claude 在这些更复杂的任务上变得更好了，尽管这也可能反映了团队在不同工作流中采用 Claude Code 方式的变化，而不是绝对工作量的增加（更多局限性请参见附录）。

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

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

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

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

  • 预训练 (Pre-training) 团队（帮助训练 Claude）经常使用 Claude Code 构建新功能（54.6%），其中大部分是运行额外的实验。

  • 对齐与安全 (Alignment & Safety) 团队和后训练 (Post-training) 团队使用 Claude Code 进行最多的前端开发（7.5% 和 7.4%），通常用于创建数据可视化。

  • 安全 (Security) 团队经常使用 Claude Code 进行代码理解（48.9%），特别是分析和理解代码库不同部分的安全影响。

  • 非技术员工经常使用 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 键：

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 发展的快速步伐，随着新模型的推出，我们观察到的模式可能已经发生了变化。

相关文档

关联主题

关系图谱

反向链接