AI 如何改变 Anthropic 的工作方式

How AI is transforming work at Anthropic

Anthropic · 2025‑12‑02 · 问卷（n=132）· 深度访谈（n=53）· Claude Code 记录（n≈200,000）

本文翻译自 Anthropic Research 发布的文章《How AI is transforming work at Anthropic》。 访问英文原文 →

作者

Saffron Huang、Bryan Seethor、Esin Durmus、Kunal Handa、Miles McCain、Michael Stern、Deep Ganguli

机构：Anthropic

原文发布日期：2025‑12‑02

概览

AI 如何改变 Anthropic 的工作方式（原文插图）
插图：原文插图（Illustration）。

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 的使用频率与生产力收益都在上升。受访者自报：Claude 参与了其约 60% 的工作，并带来约 50% 的生产力提升——相比一年前增长约 2–3 倍。这种生产力提升体现为：每类任务花费时间略有下降，但产出量显著增加（见图 2）。
  3. 有 27% 的“Claude 协助工作”由“否则不会做”的任务构成，例如扩大项目规模、制作锦上添花的工具（如交互式数据看板），以及如果手工完成将不划算的探索性工作。
  4. 多数员工频繁使用 Claude，但自报能“完全委派”给 Claude 的工作仅占 0–20%。Claude 是持续的协作者，但使用通常需要主动监督与验证，尤其是在高风险任务中——而不是把无需任何核验的任务直接交出去。

定性访谈

  1. 员工正在形成一套对 AI 委派的直觉。工程师倾向于把容易验证的任务委派出去——他们“相对容易嗅探式检查正确性”；也会委派低风险任务（例如“一次性的调试或研究代码”）或无聊的任务（“越是我兴奋想做的任务，我越不想用 Claude”）。许多人描述了一种“信任递进”：从简单任务开始，逐渐把更复杂的工作交给 Claude。虽然目前他们仍将大部分设计或“品味”类任务保留在人类手中，但随着模型变强，这条边界正在被重新谈判。
  2. 技能覆盖面更广，但一些能力获得的练习变少。Claude 让人把技能拓展到更多领域（软件工程的更多面向——“我现在可以很胜任地做前端、事务型数据库或 API 代码……而以前我会害怕碰那些我不够擅长的东西”），但也有人担心：更深层的技能会出现悖论式的“萎缩”——这些深层技能既用于写代码，也用于评审代码——“当产出变得如此容易与快速时，就越来越难真正腾出时间去学会某样东西”。
  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 任务属于修复一些能改善体验的小问题（如为可维护性而重构代码），这些通常会被降级处理；这些“小修小补”可能累积成更大的生产力与效率收益。
  3. 每个人都在变得更“全栈”。不同团队以不同方式使用 Claude，往往用于增强其核心专长：安全团队用它分析不熟悉的代码；对齐与安全团队用它构建数据的前端可视化，等等（见图 5）。

调查数据

我们对来自组织各处的 132 名 Anthropic 工程师与研究员进行了问卷调查，了解他们如何使用 Claude，从而更具体地理解他们在日常工作中究竟如何用 AI。我们通过内部沟通渠道与对不同团队员工的定向触达分发问卷，覆盖研究与产品两类职能。我们在附录“局限性”中补充了更多方法细节，并公开了问卷题目，便于他人评估我们的做法或将其改编用于自己的研究。

Claude 用于哪些编程任务？

我们让受访的工程师与研究员评估他们使用 Claude 完成各类编程任务的频率，例如“调试”（让 Claude 帮助修复代码错误）、“代码理解”（让 Claude 解释已有代码，以帮助用户理解代码库）、“重构”（让 Claude 帮助重组已有代码），以及“数据科学”（如让 Claude 分析数据集并制作柱状图）。

下图展示了最常见的每日任务：55% 的员工每天使用 Claude 做调试；42% 每天用 Claude 做代码理解；37% 每天用 Claude 实现新功能。使用频率较低的任务包括高层设计/规划（可能因为这些任务更倾向保留在人类手中），以及数据科学和前端开发（可能因为它们整体上更不常见）。这一分布与“Claude Code 使用趋势”部分报告的 Claude Code 任务分布大致一致。

图 1：不同编程任务的每日用户占比
图 1：不同编程任务的每日用户占比。横轴为每日使用占比，纵轴为任务类型。

使用情况与生产力

受访者自报：12 个月前，Claude 参与其日常工作约 28%，并带来约 +20% 的生产力提升；而现在，Claude 参与其约 59% 的工作，平均生产力提升达到 +50%。（这与我们在工程部门全面采用 Claude Code后观察到的现象大致吻合：每位工程师每天合并的 Pull Request（即成功纳入代码库的变更）数量增长约 67%。）这组同比对比相当剧烈——意味着两项指标在一年内都提升了 2 倍以上。使用频率与生产力提升也高度相关；在分布的极端一端，有 14% 的受访者通过使用 Claude 将生产力提升到了 100% 以上——他们是我们内部的“重度用户（power users）”。

需要说明的是（以及下文其他基于自报的生产力结论），生产力很难被精确衡量（更多限制见附录）。AI 研究非营利机构 METR 的最新研究表明：在高度熟悉的代码库上与 AI 合作的资深开发者，会高估 AI 带来的生产力提升。尽管如此，METR 发现导致“生产力低于预期”的因素（例如：AI 在大型复杂环境中表现更差，或需要大量默会知识/上下文）与我们员工在访谈中提到的“不太会委派给 Claude”的任务类型高度对应（见下文“AI 委派策略”）。我们在跨任务维度上的自报生产力收益，可能反映了员工正在形成更策略性的 AI 委派能力——这在 METR 研究设计中并未被纳入考量。

当我们询问：对于他们目前使用 Claude 的各类任务，Claude 对这些任务类别的总耗时与产出量有何影响时，一个有趣的模式出现了：几乎所有任务类别上，耗时净减少，而产出量净增加且幅度更大：

图 2：按任务类别的耗时与产出变化
图 2：按任务类别的耗时变化（左）与产出量变化（右）。每张图的横轴为受访者自报的耗时/产出变化：减少（负值）、增加（正值）或无变化（竖向虚线），对比基准为“不使用 Claude”。误差线为 95% 置信区间。圆点面积与该评分点的回答数量成正比。仅纳入在该任务类别上报告“使用 Claude”的受访者。

但当我们进一步查看原始数据时会发现：关于“节省时间”的回答在两端聚集——有些人使用 Claude 反而在任务上花了显著更多时间。

为什么会这样？受访者普遍解释说：他们需要对 Claude 生成的代码做更多调试与清理（例如“当我用 vibe coding 把自己写进死胡同时”），而且由于代码不是自己写的，理解 Claude 代码需要承担更多认知负担。有些人提到“花更多时间”也可能是一种“赋能式”的更多：有人说 Claude 帮助他们“坚持在过去会立刻放弃的任务上”；也有人说它让自己能做更彻底的测试，或在新代码库里投入更多学习与探索。总体而言，体验到时间节省的工程师，可能更擅长为 Claude 切分出可快速验证的任务；而花更多时间的人，可能在调试 AI 生成代码，或处在 Claude 需要大量引导的领域中。

此外，我们的数据也无法回答：被节省下来的时间究竟被“再投资”到了哪里——是更多工程任务、非工程任务、与 Claude 的交互/审阅其输出，还是工作之外的活动。我们的任务分类框架并不能覆盖工程师分配时间的全部方式；自报也可能受到感知偏差影响。要拆解这些效应，还需要进一步研究。

相对而言，产出量的提升更直观且更显著：几乎所有任务类别都出现了更大的净增幅。这一模式在任务类别层面也很合理：受访者报告的是“调试”这类总体类别，而非单个具体任务——因此他们完全可能在“调试”总体上花更少时间，却产出更多调试相关结果。生产力很难直接测量，但这些自报数据暗示：在 Anthropic，AI 主要通过显著提高产出量来提升生产力。

Claude 促成的新工作

我们关心的一个问题是：Claude 是否正在促成性质上全新的工作，还是说这些在 Claude 协助下完成的工作即便没有 Claude 也终会被员工完成（只是可能更慢）？

受访者估计：他们在 Claude 协助下完成的工作中，有 27% 若没有 Claude 就不会去做。工程师提到用 AI 来扩大项目规模、做一些锦上添花的功能（如交互式数据看板）、完成“有用但繁琐”的工作（如文档与测试），以及如果手工完成会不划算的探索性工作。正如一位受访者所说，他们现在能够修复更多过去会损害体验却常被搁置的“小痛点（papercuts）”，例如重构结构糟糕的代码，或构建“能让另一项任务更快完成的小工具”。我们也在使用数据分析中寻找这一点，并发现 Claude Code 任务中有 8.6% 属于“修复小痛点（papercut fixes）”。

另一位研究员解释说，他们会同时运行许多 Claude 实例，让它们并行探索同一问题的不同路径：

人们往往把超级强大的模型当作一个单一实例来想象，就像得到一辆更快的车。但如果你有一百万匹马……你就能同时测试一大堆不同的想法……当你拥有额外的探索广度时，会更令人兴奋，也更有创造力。

在下文我们会看到，这种“新增工作”往往意味着工程师在处理那些超出其核心专长的任务。

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

尽管工程师频繁使用 Claude，超过一半的人表示：他们只能把 0–20% 的工作“完全委派”给 Claude。（需要注意的是，“完全委派”的理解可能存在差异：从“完全不需要核验”的任务，到“足够可靠、只需轻度监督”的任务都可能被纳入。）在解释原因时，工程师描述了与 Claude 的主动、迭代式协作以及对其输出的验证——特别是在复杂任务或高风险领域（对代码质量要求严格）时。这表明工程师更倾向与 Claude 紧密协作并检查其工作，而不是把任务在无需核验的情况下直接交出去；同时，他们对“算不算完全委派”设定了很高的门槛。

定性访谈

调查数据揭示了显著的生产力提升与工作模式变化，但也引出一个问题：工程师在日常工作中究竟如何体验这些变化？为了理解指标背后的“人的维度”，我们对 53 位参与问卷的 Anthropic 工程师与研究员开展了深度访谈，以更深入了解他们如何思考并感受工作中的这些变化。

AI 委派策略

工程师与研究员正在形成多样的策略，以更高效地把 Claude 融入工作流。总体而言，人们更愿意把满足以下特征的任务委派给 Claude：

委派标准 访谈摘录 / 描述
超出使用者上下文，且复杂度低

“我会把那些我上下文不多、但总体复杂度也不高的事情交给 Claude。”

“我遇到的大多数 infra[structure]（基础设施）问题并不难，Claude 就能处理……我对 Git 或 Linux 也不算熟……Claude 很擅长弥补我在这些领域经验不足的短板。”
易于验证

“对那些验证成本相比生成成本并不高的事情，它简直太惊艳了。”
定义清晰 / 相对自包含

“如果项目的某个子组件与其他部分足够解耦，我就会让 Claude 先试一把。”
代码质量不是关键约束

“如果只是一次性的 debug[ging]（调试）或研究代码，我会直接交给 Claude。如果是概念上很难、需要非常特定的调试注入，或者属于设计问题，我就自己做。”
重复或无聊

“我越兴奋想做的任务，就越不想用 Claude。相反，如果我感到很抗拒……我往往更容易先和 Claude 就这个任务聊起来。”

在我们的问卷中，受访者平均表示：其 Claude 协助工作的 44% 属于“如果自己做并不会喜欢”的任务。
提示更快，自己做更慢（反之则不值当）

“如果我预计某个任务不到 10 分钟就能搞定……我大概率不会费事用 Claude。”

“冷启动问题可能是现在最大的阻碍。所谓冷启动，是指：关于我们团队代码库如何工作的很多内隐信息，我天然就知道，但 Claude 默认并不知道……我当然可以花时间去迭代出一个完美的提示词，但我往往会选择直接自己去做。”

我们员工在委派决策中提到的这些因素，与 METR 的外部研究中用于解释 AI 相关生产力放缓的因素高度相似（例如：开发者对代码库非常熟悉、仓库规模大且复杂）。这种跨访谈的一致性表明：是否选择“合适的任务”是 AI 生产力收益的重要决定因素（未来的生产力研究应谨慎控制这一变量）。

信任，但要核验

许多用户描述了一条随时间演进的路径：他们会逐渐把越来越复杂的任务交给 Claude——“一开始我用 AI 工具来问一些关于 Rust 的基础问题……最近我已经在所有编码工作上都用 Claude Code 了。”

一位工程师把这种“信任递进”类比为采用 Google Maps 等其他技术的过程：

最开始我只会在不熟悉的路线才用 Google Maps……这就像我会让 Claude 写我不懂的 SQL，但不会让它写我会写的 Python。后来我开始在大体熟悉、但可能最后一公里不熟的路线也用 Google Maps……今天我每天通勤也一直用 Google Maps。它如果建议走另一条路，我就照做，并且信任它已经把所有选项都考虑过了……我现在用 Claude Code 的方式也很类似。

关于“在自身专长之内用 Claude”还是“在专长之外用 Claude”，工程师看法并不一致：有人把它用于“边缘领域”以节省实现时间；也有人更喜欢在熟悉领域使用，从而能够验证输出（“我用 Claude 的方式仍能让我完全理解它在做什么”）。一位安全工程师强调了经验的重要性——当 Claude 提出一种“危险但很聪明”的方案时，他把它比作“一个非常有才华的初级工程师可能会提出的那种建议”。也就是说，问题之所以危险，需要具备判断力与经验的人才能识别出来。

也有人两种任务都用 Claude：要么是更偏实验式的使用（“我基本上会让 Claude 先对任何编码问题打个草稿”），要么会根据自己在某个任务上的熟练程度调整协作方式：

我会把工具用于两类事情：一类是我非常擅长的（作为加速器，我知道预期结果是什么，也能有效引导 agent）；另一类是略超出我专长的（我大致知道应该长什么样，但 Claude 能补上我记忆或对具体定义不够熟悉的空白）。

如果是我特别熟悉的内容，我会更强势一些，直接告诉 Claude 该去查什么；如果是不太确定的内容，我经常会让它当专家，给我一些选项和洞见，告诉我应该考虑和研究哪些点。

人们会留给自己做的任务

受访者一致表示：他们不会让 Claude 去做那些需要高层或战略思考的任务，也不会把需要组织上下文或“品味（taste）”的设计决策交给它。一位工程师解释：“我通常保留高层思考与设计，我会把从新功能开发到调试之间能委派的都委派出去。”这也反映在我们的调查数据中：设计与规划类任务的生产力收益最小（见图 2）。尽管如此，很多人也把委派边界描述为一个“移动靶”——随着模型进步而持续被重新谈判（下文 Claude Code 使用数据也显示：如今用于代码设计/规划的占比相较六个月前更高）。

技能转变

新的能力……

调查中“27% 的 Claude 协助工作若无 Claude 就不会做”的结论，折射出一个更广泛的模式：工程师正在用 AI 走出自己的核心专长。许多员工报告完成了过去超出其专长范围的工作——后端工程师做 UI；研究员做可视化。一位后端工程师描述自己如何与 Claude 迭代构建一个复杂 UI：“它做得比我自己能做的好太多了。我根本做不出来，肯定也不可能按时完成……[设计师] 还说‘等等，你做的？’我说：‘不，是 Claude 做的——我只是写提示词。’”

工程师报告说自己变得更“全栈”——“我现在可以很胜任地做前端、事务型数据库或 API 代码，而以前我会害怕碰那些我不够擅长的东西。”这种能力扩展也带来了更紧密的反馈回路与更快的学习速度：一位工程师表示，一个需要“几周”的流程（构建、排会议、迭代）可能变成“几个小时的工作 session”，同事也能在现场给实时反馈。

总体而言，人们对快速原型、并行推进、减少重复劳动（toil）、以及整体“提高野心上限”的新能力感到兴奋。一位资深工程师告诉我们：“这些工具确实让初级工程师更高效，也更敢接更大胆的项目。”也有人说，使用 Claude 的“启动能量（activation energy）”变低，使他们更容易克服拖延，“显著降低了我愿意开始着手一个问题所需的能量，因此我愿意做更多额外的事情”。

……以及更少的动手练习

与此同时，也有人担心：随着“把更多事情委派出去”，自己的技能会“萎缩”，并且会失去手工解决问题过程中的“附带学习（collateral learning）”——那种并不直接服务于当下问题、但能帮助自己建立系统心智模型的学习：

如果你自己去调一个很难的问题，你会花很多时间读文档、读代码——这些并不一定直接用来解决你的问题——但这段时间里你是在构建对系统如何运作的心智模型。现在这种事情少了很多，因为 Claude 可以把你直接带到问题上。

以前我会把每个配置都摸一遍，去理解这个工具能做什么；但现在我会依赖 AI 告诉我新工具怎么用，于是我就缺少了那种专业掌握。过去跟队友聊天时我能立刻回忆起细节；现在我得去问 AI。

用 Claude 可能会跳过这样一个过程：我先通过解决一个简单例子学会如何做这件事，然后在更复杂的例子上挣扎；被跳过之后，未来我可能会在复杂情况里更难应对。

一位资深工程师表示：如果自己更初级，他会更担心技能问题：

我主要是在那些我知道答案应该是什么、或者应该长什么样的场景里用 AI。我之所以能做到这一点，是因为我曾经用“更艰难的方式”做过软件工程（SWE）……但如果我处在职业生涯更早期，我会认为要继续提升自己的能力，需要非常刻意的努力，而不能盲目接受模型输出。

编码技能萎缩之所以令人担忧，还有一个原因是“监督悖论（paradox of supervision）”：如前所述，高效使用 Claude 需要监督，而监督 Claude 又需要那些可能因为过度使用 AI 而萎缩的编码技能。一位受访者说：

说实话，我更担心“监督与审阅”问题，而不是我的技能本身……技能萎缩或发展不足，主要会影响我是否能安全地用 AI 去做我关心的任务，而不是影响我是否还能独立完成那些任务。

为应对这一点，一些工程师会刻意在某些场景下不使用 AI 来保持手感：“偶尔，即使我知道 Claude 能把问题完美搞定，我也不会问它。这能让我保持锋利。”

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

也许软件工程正在走向更高层次的抽象——这在历史上一直发生。早期程序员离机器更近：手动管理内存、写汇编，甚至拨动物理开关来输入指令。随着时间推移，更高级、更易读的语言出现，自动处理复杂的底层操作。或许，特别是在“vibe coding（凭感觉写代码）”兴起后，我们正走向“用英语作为编程语言”。一位同事建议，想成为工程师的人应当“擅长让 AI [写代码]，并把重心放在学习更高层的概念与模式上”。

有些员工表示，这种变化让他们能够在更高层次思考——“关注最终产品与最终用户”，而不只是代码本身。有人把当前变化类比为：计算机科学课上曾经必须学习链表（linked lists）这类基础结构，但如今许多高级语言已经自动处理。“我很庆幸自己知道怎么做……[但] 做这些底层操作在情感上并不重要。我更在意的是代码让我能做到什么。”另一位工程师也做了类似类比，但补充说：抽象带来代价——随着语言层级提高，大多数工程师失去了对内存处理的深刻理解。

持续在某个领域打磨技能，确实能带来更好的 Claude 监督与更高效的工作（“我发现当任务是我熟悉的，往往我自己做更快”）。但工程师们对这是否重要存在分歧。一些人相对乐观：

我不太担心技能被侵蚀。AI 仍然会让我认真思考问题，也能帮助我学习新方法。如果有什么变化，那就是能更快地探索和测试想法，让我在一些领域的学习反而加速了。

另一些人更务实：“我的软件工程技能确实在萎缩……但如果未来真的需要，这些技能也能捡回来；只是我现在不再需要它们了！”还有人指出，他们失去的主要是一些不那么重要的技能，比如做图表，而“关键的那类代码我依然写得很好”。

也许最有意思的是，有工程师挑战了“变生疏（getting rusty）”这个前提：“‘变生疏’的说法隐含了一个假设：编码方式有一天会回到 Claude 3.5 之前的样子。但我认为不会。”

软件工程的技艺与意义

工程师对是否“怀念动手写代码”分歧很大。有些人感到真正的失落——“对我来说，这是一个时代的结束。我已经编程 25 年了，感觉自己在这项技能上很胜任，是我职业满足感的核心来源。”也有人担心新的工作形态不会让人享受：“整天写提示词让 Claude 干活并不有趣，也不充实。真正有趣且充实的是放点音乐、进入心流，自己把东西实现出来。”

也有人直面这种取舍并接受它：“写代码确实有一些部分我会想念——比如重构时进入一种禅意的心流，但总体上我现在生产力高太多了，我很愿意放弃这些。”

还有人说，与 Claude 迭代反而更有趣，因为他可以比对人类更“挑剔”地提出反馈。也有人更看重结果。一位工程师说：

我原以为到了现在我会感到害怕或无聊……但我其实并没有。相反，我很兴奋，因为我能做得多得多。我以为我真的很喜欢写代码，后来发现我其实只是喜欢“写代码给我带来的东西”。

人们是拥抱 AI 协作还是为动手编码的减少而惋惜，往往取决于他们认为软件工程中最有意义的部分是什么。

职场社交关系的变化

一个突出的主题是：Claude 成了许多问题的第一站——这些问题过去会问同事。“我现在总体上问的问题更多了，但其中 80–90% 都问 Claude，”一位员工指出。这形成了一种“过滤机制”：Claude 处理例行咨询，而同事更多处理那些更复杂、更战略、或更依赖上下文、超出 AI 能力的问题（“它让我们对团队的依赖减少了 80%，但最后那 20% 非常关键，我还是得去找他们聊”）。人们也会像和人类合作者那样，把想法“拿去和 Claude 过一遍”。

大约一半的受访者表示团队协作模式没有变化。一位工程师说他仍在和同事开会、共享上下文、做方向选择；他认为在不久的将来仍会有大量协作，只是“你不再做传统意义上的专注工作，而是和很多个 Claude 对话”。

但也有人描述与同事的互动变少了（“我和 Claude 的互动比和任何同事都多得多”）。一些人喜欢社交摩擦降低（“我不会因为占用同事时间而感到内疚”）。也有人抗拒这种变化（“我其实不太喜欢大家的默认回应变成了‘你问过 Claude 了吗？’我真的很喜欢和人面对面一起工作，并且很看重这一点”），或怀念过去的工作方式：“我喜欢和人一起工作，感觉现在我‘需要’他们更少了，这让人难过。”还有人提到这会影响传统的导师机制，因为“Claude 可以给初级员工提供大量辅导”，而不是由资深工程师来做。一位资深工程师说：

更难过的是，初级同事不再那么常来问我问题了；但他们的问题确实被更有效地解决了，学习也更快了。

职业不确定性与适应

许多工程师形容自己的角色正从“写代码”转向“管理 AI”。工程师越来越把自己看作“AI 代理的管理者（manager of AI agents）”——有人已经“几乎一直开着至少几个 Claude 实例”。有人估计自己的工作已经有“70% 以上变成了代码审阅/修订，而不是从零写新代码”；也有人把“对 1、5 或 100 个 Claude 的工作负责”视为未来角色的一部分。

从更长期看，职业不确定性非常普遍。工程师把这些变化视为行业更广泛转型的先兆，许多人认为很“难说”几年后自己的职业会是什么样。有些人在短期乐观与长期不确定之间感到冲突：“短期我很乐观，但长期我觉得 AI 会做一切，让我和很多人都变得无关紧要。”也有人说得更直白：“有时候感觉我每天来上班是在把自己做失业。”

也有更乐观的声音。一位员工说：“我替初级开发者担心，但我也觉得初级开发者可能最渴望新技术。我总体上对这个职业的走向非常乐观。”他们认为：即便经验不足的工程师可能会交付有问题的代码，随着更好的 AI 护栏、更内置的教育资源，以及在错误中自然学习的机制，行业会逐步适应。

我们询问了人们如何想象自己的未来角色、以及是否有适应策略。有人计划进一步专业化（“要能有意义地评审 AI 的工作，会更难，也需要更深的专精”）；有人预计未来会更多做人与人之间的协调与战略工作（“我们会花更多时间达成共识，让 AI 花更多时间去实现”）。还有人把 Claude 用于职业发展，让它给自己的工作与领导力技能反馈（“我学习东西的速度，甚至在不完全学会的情况下也能变得有效的速度，都彻底变了。我几乎感觉上限被打碎了”）。

总体而言，许多人承认存在深层不确定性：“我对未来哪些具体技能会有用几乎没有信心。”一位团队负责人说：“没人知道会发生什么……重要的是尽可能保持适应力。”

展望未来

过去一年里，Anthropic 员工显著增加了对 Claude 的使用：不仅加速既有工作，也用于学习新的代码库、减少重复劳动、扩展到新的领域，并处理过去被搁置的改进项。随着 Claude 更加自主与强大，工程师正在探索新的委派方式，同时也在摸索未来需要哪些技能。这些变化带来清晰的生产力与学习收益，但也伴随着对软件工程工作长期走向的真实不确定性。AI 会像过去的软件工程转型那样——从低层到高层语言，或从个人贡献者到管理者（正如一些工程师所类比）——还是会走得更远？

现在仍处早期：Anthropic 内部有许多早期采用者，外部环境也在快速变化，因此我们的发现很可能暂时无法推广到其他组织或语境（更多限制见附录）。这项研究也反映了这种不确定性：结论细腻而多元，未出现单一共识或明确指令。但它确实提出了一个问题：我们应如何更审慎、更有效地应对这些变化？

为了跟进这项初步工作，我们正在采取若干举措：与 Anthropic 工程师、研究员与管理层展开讨论，回应其中的机会与挑战。这包括：反思我们如何把团队凝聚在一起、如何彼此协作；如何支持职业发展；以及如何建立 AI 增强工作的最佳实践（例如参考我们的AI fluency framework）。我们也在把研究范围扩展到工程师之外，理解 AI 转型如何影响组织内其他角色；并支持诸如 CodePath 等外部组织，帮助其在 AI 协助的未来调整计算机科学课程。展望未来，我们也在考虑一些随着 AI 能力提升可能越来越重要的结构性方案，例如角色演进或再技能化（reskilling）的新路径。

随着我们思考的成熟，我们预计会在 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 位个体（总触达 n=207），最终在这部分获得 31% 的回复率，形成 64 份最终回复。我们对最先回复的 53 人进行了访谈。这里可能存在一定选择偏差：对 Claude 特别投入或对其影响有强烈观点（正面或负面）的人可能更愿意参与，而体验更中性的个体可能被低估了。

此外，回应也可能受到社会期许偏差影响（由于回应并非匿名，且参与者均为 Anthropic 员工，受访者可能夸大 Claude 的正面影响），以及近因偏差影响（要求参与者回忆 12 个月前的生产力与使用模式，容易产生记忆失真）。并且，如前所述，生产力本就极难估计，因此这些自报数据应当谨慎解读。应将这些主观感受与我们更客观的 Claude Code 使用数据结合起来理解；未来研究也应考虑匿名数据收集与更严格验证的测量工具。

我们的 Claude Code 分析在时间段之间采用了按比例抽样，这意味着我们只能衡量任务分布的相对变化，而无法衡量绝对工作量变化。例如，当我们报告“新功能实现”在 Claude Code 使用中的占比从 14% 上升到 37% 时，这并不必然意味着总体的新功能工作量在增加。

最后，这项研究开展于 2025 年 8 月，当时 Claude Sonnet 4 与 Claude Opus 4 是我们的最先进模型。考虑到 AI 发展速度极快，我们观察到的模式可能已随着更新模型的出现而发生变化。

出处声明

本文翻译自 Anthropic Research 发布的文章：

《How AI is transforming work at Anthropic》

访问英文原文

翻译：GPT‑5.2 + @nake13

开发：GPT‑5.2 + @nake13

翻译仅供学习交流使用