译：AI 如何改变 Anthropic 的工作方式

原文： https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic
作者： Saffron Huang, Bryan Seethor, Esin Durmus, Kunal Handa, Miles McCain, Michael Stern, Deep Ganguli
译者： Gemini 2.5 Pro

AI 是如何改变我们的工作方式的？我们之前关于 AI 经济影响的研究着眼于整个劳动力市场，涵盖了各种不同的工作。但如果我们更深入地研究 AI 技术的首批使用者——也就是我们自己，会怎么样？

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

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

我们认识到，在一家开发 AI 的公司研究 AI 的影响，意味着我们处在一个特殊的位置——我们的工程师能优先接触到最前沿的工具，在一个相对稳定的领域工作，并且他们自己也在为影响其他行业的 AI 转型做出贡献。尽管如此，我们认为研究并公布这些发现总体上是有益的，因为 Anthropic 工程师们正在经历的变化，可能仍然是更广泛社会变革的一个有启发性的预兆。我们的发现揭示了一些挑战和考量，可能值得各行各业及早关注（不过，请参阅附录中的局限性部分以了解注意事项）。在收集这些数据时，Claude Sonnet 4 和 Claude Opus 4 是当时最强大的模型，而模型的能力还在不断进步。

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

主要发现

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

调研数据

1. Anthropic 的工程师和研究员最常用 Claude 来修复代码错误和学习代码库。调试（Debugging）和代码理解（code understanding）是最常见的用途（图1）。
2. 人们报告 Claude 的使用率和生产力增益都在增加。 员工自述在 60% 的工作中使用 Claude，并获得了 50% 的生产力提升，这比去年同期增长了 2-3 倍。这种生产力表现为每个任务类别花费的时间略有减少，但产出量却大幅增加（图2）。
3. 27% 的 Claude 辅助工作包含了那些若没有 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 修复了大量的“小毛病” (papercuts)。 8.6% 的 Claude Code 任务涉及修复那些能提升工作体验的小问题，比如为了可维护性而重构代码（即“修复 papercuts”），人们说这类任务通常会被排在较低优先级。这些小修复累积起来，可能会带来更大的生产力和效率提升。
3. 每个人都变得更加“全栈” (full-stack)。 不同的团队以不同的方式使用 Claude，通常是为了增强他们的核心专长——安全团队用它来分析不熟悉的代码，对齐与安全团队用它来构建数据的前端可视化等等（图5）。

调研数据

我们调研了来自公司各部门的 132 名 Anthropic 工程师和研究员，了解他们对 Claude 的使用情况，以便更好地理解他们日常究竟是如何使用它的。我们通过内部沟通渠道分发了问卷，并直接联系了代表研究和产品职能的多个不同团队的员工。我们在附录的局限性部分包含了更多方法论的细节，并分享了我们的问卷问题，以便他人可以评估我们的方法并将其用于自己的研究。

人们用 Claude 做哪些编程任务？

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

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

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

使用情况与生产力

员工自述，12 个月前，他们在 28% 的日常工作中使用 Claude，并从中获得了 20% 的生产力提升；而现在，他们在 59% 的工作中使用 Claude，平均生产力提升了 50%。（这与我们在整个工程部门采用 Claude Code 后观察到的每位工程师每日合并的 pull requests——即成功并入代码的变更——增加 67% 的情况大致相符。）年度对比相当显著——这表明在一年内，这两项指标都增长了两倍以上。使用率和生产力也密切相关，在分布的极端情况下，14% 的受访者通过使用 Claude 将生产力提高了 100% 以上——这些是我们的内部“超级用户”。

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

当询问员工，在他们目前使用 Claude 的任务类别中，Claude 如何影响他们在该类别上的总耗时和工作产出量时，一个有趣的生产力模式出现了。在几乎所有任务类别中，我们都观察到耗时的净减少，以及产出量的更大幅度的净增加：

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

然而，当我们深入研究原始数据时，我们发现节省时间的回答聚集在两个极端——有些人在 Claude 辅助的任务上花费的时间反而显著增加了。

为什么会这样？人们普遍解释说，他们需要花更多时间调试和清理 Claude 的代码（例如，“当我自己凭感觉写代码把自己绕进去时”），并且因为代码不是自己写的，理解它需要承担更多的认知负荷。一些人提到，在某些情况下花更多时间是一种赋能——有人说，使用 Claude 帮助他们“坚持完成以前可能立刻就放弃的任务”；另一个人说，它帮助他们进行更彻底的测试，以及在新的代码库中进行更多的学习和探索。总的来说，似乎节省了时间的工程师，可能是那些为 Claude 划定易于快速验证任务范围的人，而花费更多时间的人，可能是在调试 AI 生成的代码，或是在 Claude 需要更多指导的领域工作。

我们的数据也无法清楚地表明，节省下来的时间被重新投入到了哪里——是投入到额外的工程任务、非工程任务、与 Claude 互动或审查其输出，还是工作之外的活动。我们的任务分类框架并未涵盖工程师可能分配时间的所有方式。此外，节省时间的感觉可能反映了自述中的感知偏差。需要进一步的研究来理清这些影响。

产出量的增加则更为直接和显著；所有任务类别的净增长都更大。当我们考虑到人们报告的是任务类别（例如整个“调试”类别）而非单个任务时，这个模式就说得通了——也就是说，人们可以在调试这个类别上花费稍少的时间，但总体上产出更多的调试工作。生产力很难直接衡量，但这些自述数据表明，在 Anthropic，AI 提升生产力主要是通过增加产出量来实现的。

Claude 催生新工作

我们好奇的一点是：Claude 是在催生性质上全新的工作，还是说那些 Claude 辅助的工作，员工最终也会完成（尽管可能速度会慢一些）？

员工们估计，他们通过 Claude 辅助完成的工作中，有 27% 是若没有 Claude 就不会去做的。工程师们举例说，他们使用 AI 来扩展项目、制作“锦上添花”的功能（例如交互式数据看板）、完成有用但繁琐的工作（如文档和测试），以及进行手动操作不划算的探索性工作。正如一个人解释的，他们现在可以修复更多以前影响工作体验的“小毛病”（papercuts），比如重构结构糟糕的代码，或者构建“能帮助更快完成另一项任务的小工具”。我们也在使用数据分析中寻找这一点，并发现 8.6% 的 Claude Code 任务涉及“修复小毛病”。

另一位研究员解释说，他们会同时运行多个版本的 Claude，让它们各自探索解决一个问题的不同方法：

人们倾向于将超强模型看作一个单一实例，就像得到一辆更快的车。但拥有一百万匹马……让你能测试一大堆不同的想法……当你拥有了这种额外的探索广度时，会感到兴奋，也更有创造力。

正如我们将在下文看到的，这种新工作常常涉及工程师们处理其核心专长之外的任务。

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

尽管工程师们频繁使用 Claude，但超过一半的人表示，他们只能将 0-20% 的工作“完全委托”给 Claude。（值得注意的是，受访者对“完全委托”的理解可能有所不同——从完全不需要验证的任务，到足够可靠、只需轻度监督的任务。）在解释原因时，工程师们描述了他们与 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。”

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

一开始我只在不认识的路线上使用（谷歌地图）……这就像我用 Claude 写我不懂的 SQL，但不会让它写我懂的 Python。后来，我开始在基本认识的路线上使用谷歌地图，但可能不确定最后一段路怎么走……今天，我一直都在用谷歌地图，甚至日常通勤也用。如果它让我走另一条路，我就照做，并且相信它已经考虑了所有选项……我今天使用 Claude Code 的方式也与此类似。

对于是在自己专业领域内还是领域外使用 Claude，工程师们的看法不一。一些人将其用于“外围”领域以节省实现时间；另一些人则偏爱在熟悉的领域使用，因为他们可以验证输出（“我使用 Claude 的方式是，我仍然完全理解它在做什么”）。一位安全工程师强调了经验的重要性，他提到 Claude 曾提出一个“以一种危险的方式非常聪明”的解决方案，“就像一个非常有才华的初级工程师可能会提出来的东西”。也就是说，只有具备判断力和经验的用户才能识别出其中的问题。

其他工程师则两种任务都用 Claude 处理，要么是实验性地（“基本上任何编程问题，我都会先让 Claude 试试”），要么是根据自己对任务的专业水平调整方法：

我既在我的核心专业领域使用这些工具（作为加速器，我知道该期待什么，并且能有效地指导它），也在略微超出我专业领域的地方使用，在那里我大致知道该期待什么，但 Claude 能填补我记忆或对特定定义熟悉度的空白。

如果是我特别精通的事情，我会更果断，告诉 Claude 它需要追踪什么。如果是我不确定的事情，我常常会让它扮演专家，给我提供选项和见解，告诉我应该考虑和研究些什么。

人们会把哪些任务留给自己？

人们一致表示，他们不会将 Claude 用于涉及高层级或战略性思考的任务，也不会用于需要组织背景或“品味”的设计决策。一位工程师解释说：“我通常会保留高层级的思考和设计。从新功能开发到调试，只要能委托的我都委托。” 这在我们的调研数据中得到了反映，数据显示设计和规划任务的生产力增益最少（图2）。不过，许多人将委托的界限描述为一个“移动靶”，随着模型的改进会定期重新商讨（下文的 Claude Code 使用数据显示，与六个月前相比，现在用于代码设计/规划的比例相对更高了）。

技能转型

新能力…

调研发现，27% 的 Claude 辅助工作若没有 AI 就不会完成，这反映了一个更广泛的模式：工程师正利用 AI 在其核心专业领域之外工作。许多员工报告称，他们完成了以前超出其专业范围的工作——后端工程师构建用户界面；研究员创建可视化图表。一位后端工程师描述了他通过与 Claude 迭代构建一个复杂用户界面的过程：“它做得比我能做的任何时候都好。我本来是做不到的，肯定无法按时完成……（设计师们）都说‘等等，这是你做的？’我说‘不，是 Claude 做的——我只是给了它提示。’”

工程师们报告说正在“变得更加全栈……我现在可以很胜任地处理前端、事务性数据库或 API 代码，而以前我可能会害怕去碰那些我不太擅长的东西。” 这种能力扩展使得反馈循环更紧密，学习速度更快——一位工程师说，一个原本需要“几周时间”的构建、安排会议和迭代的过程，现在可以变成“几小时的工作坊”，同事们在场提供实时反馈。

总的来说，人们对自己新获得的能力感到兴奋，包括快速制作原型、并行处理工作、减少重复劳动，以及普遍提升了他们的抱负水平。一位资深工程师告诉我们：“这些工具确实让初级工程师的生产力更高，也更有勇气去承担各种类型的项目。” 还有人说，使用 Claude 降低了“启动能量”，使他们更容易克服拖延症，“极大地减少了我想开始解决一个问题所需的能量，因此我愿意去处理更多额外的事情。”

……以及更少的动手实践

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

如果你自己去调试一个难题，你会花时间阅读那些对解决问题并非直接有用的文档和代码——但在这整个过程中，你都在构建一个关于系统如何工作的模型。现在这种情况少了很多，因为 Claude 可以直接带你找到问题所在。

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

使用 Claude 可能会跳过我通过解决一个简单实例来学习如何执行一项任务的环节，导致之后在解决更复杂的实例时遇到困难。

一位资深工程师说，如果他更年轻，他会更担心自己的技能：

我主要在那些我知道答案应该是什么或长什么样的场景下使用 AI。我是通过‘硬核’方式做软件工程才培养出这种能力的……但如果我还处于职业生涯的早期，我认为需要付出很多刻意的努力来继续提升自己的能力，而不是盲目地接受模型的输出。

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

老实说，比起我具体的技能集，我更担心监督和监管问题……我的技能退化或未能发展，主要会在我安全使用 AI 完成我关心的任务的能力方面产生问题，而不是在我独立完成这些任务的能力方面。

为了对抗这一点，一些工程师会刻意不使用 AI 进行练习：“每隔一段时间，即使我知道 Claude 能搞定一个问题，我也不会去问它。这能帮助我保持敏锐。”

我们还需要那些动手编码的技能吗？

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

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

在某个领域持续发展技能可以带来对 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月与2025年2月（x轴）之间 Claude Code 使用情况的变化。平均任务复杂度随时间增加（左图），每份对话记录的平均最大连续工具调用次数随时间增加（中图），人类回合数随时间减少（右图）。误差线显示 95% 置信区间。数据表明，随着时间的推移，人们正越来越多地赋予 Claude 更大的自主权。

这些使用数据证实了调研数据：工程师们将日益复杂的工作委托给 Claude，而 Claude 需要的监督也更少了。这似乎很可能是推动所观察到的生产力提升的原因。

任务分布

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

图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 任务被归类为“修复小毛病”（papercut fixes）。这些任务包括创建性能可视化工具和为可维护性重构代码等较大的任务，也包括创建终端快捷方式等较小的任务。这可能有助于工程师们报告的生产力提升（解决以前被忽略的、能提升工作体验的问题，可能会随时间推移带来更高的效率），并可能减少日常工作中的摩擦和挫败感。

团队间的任务差异

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

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

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

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

1. 预训练 (Pre-training) 团队（他们帮助训练 Claude）经常使用 Claude Code 来构建新功能（54.6%），其中大部分是进行额外的实验。
2. 对齐与安全 (Alignment & Safety) 和 后训练 (Post-training) 团队使用 Claude Code 进行的前端开发最多（分别为 7.5% 和 7.4%），通常是为了创建数据可视化。
3. 安全 (Security) 团队经常使用 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, and Heather Whitney 提供了有益的想法、讨论、反馈和支持。感谢 Casey Yamaguma 绘制了图表。我们也感谢 Anton Korinek, Ioana Marinescu, Silvana Tenreyro, and Neil Thompson 提出的富有成效的评论和讨论。

附录

局限性

我们的调研发现受到一些方法论上的限制。我们通过便利抽样和目的性抽样（以确保广泛的组织代表性）来选择受访者。我们在多个内部 Slack 频道发布了调研，获得了 68 份回复；我们还从组织结构图中选择了 20 个跨研究和产品职能的不同团队，并直接向每个团队的 5-10 人发送了消息（总共联系了 207 人），最终获得了 64 份回复，回复率为 31%。我们访谈了最先回复的 53 人。这里可能存在一些选择性偏差，因为那些特别积极使用 Claude 或持有强烈观点（无论正面或负面）的人可能更倾向于回复，而那些体验较为中性的人可能代表性不足。

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

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

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