翻译自：https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic
人工智能正在如何改变我们的工作方式？我们之前关于人工智能经济影响的研究着眼于整个劳动力市场，涵盖了各种不同的工作。但如果我们更详细地研究一些最早采用人工智能技术的人——也就是我们自己——又会如何呢？
2025年8月，我们反观Anthropic公司内部，对132名工程师和研究人员进行了问卷调查，开展了53次深度定性访谈，并研究了公司内部Claude Code的使用数据，以了解人工智能的应用如何改变Anthropic公司。我们发现，人工智能的应用正在从根本上改变软件开发人员的工作性质，这既带来了希望，也带来了担忧。
我们的研究揭示了一个正在经历重大变革的工作场所：工程师的工作效率大幅提升，他们变得更加“全栈”（能够胜任超出自身专业领域的任务），学习和迭代速度也显著加快，并开始处理以前被忽视的任务。这种能力的拓展也引发了人们对利弊的思考——有些人担心这可能意味着他们会失去更深层次的技术能力，或者难以有效地监督人工智能的输出结果；而另一些人则欣然接受这种能够让他们以更广阔的视角和更高的层次思考问题的机会。一些人发现，人工智能协作的增加意味着他们与同事的合作减少了；还有一些人则在思考，他们最终是否会被自动化取代。
我们意识到，在一家人工智能公司研究人工智能的影响意味着我们拥有得天独厚的优势——我们的工程师能够率先使用尖端工具，在相对稳定的领域工作，并且他们自身也在为影响其他行业的人工智能转型做出贡献。尽管如此，我们仍然认为研究并发表这些发现总体上是有意义的，因为Anthropic公司内部工程师的经历或许能够为更广泛的社会转型提供有益的启示。我们的发现揭示了一些挑战和需要考虑的问题，这些问题可能需要各行各业尽早关注（但请参阅附录中的“局限性”部分了解相关注意事项）。在收集这些数据时，Claude Sonnet 4和Claude Opus 4是当时功能最强大的模型，而如今人工智能的功能仍在不断提升。
更强大的人工智能带来了生产力提升，但也引发了诸多问题，例如如何保持技术专长、维系有效的协作，以及如何应对充满不确定性的未来——在人工智能增强的工作场所中，学习、指导和职业发展可能需要新的方法。在下文“展望未来”部分，我们将探讨公司内部为解决这些问题而采取的一些初步措施。此外，我们还在近期发布的关于人工智能相关经济政策的博文中探讨了潜在的政策应对措施。
主要发现
本节简要概述了我们的调查、访谈和克劳德代码数据的研究结果。详细的研究结果、方法和注意事项将在下文中阐述。
调查数据
- 人类工程师和研究人员最常使用 Claude 来修复代码错误和了解代码库。调试和代码理解是最常见的用途（图 1）。
- 用户反馈显示，Claude 的使用率和工作效率均有所提高。员工自述在 60% 的工作中使用 Claude，工作效率提高了 50%，比去年同期提高了 2-3 倍。这种效率提升体现在每项任务所需时间略有减少，但产出量却显著增加（图 2）。
- 克劳德协助完成的工作中有 27% 是原本不会完成的任务，例如扩展项目、制作锦上添花的工具（例如交互式数据仪表板）以及如果手动完成则不划算的探索性工作。
- 大多数员工经常使用 Claude，但他们表示可以“完全委托”Claude 处理 0-20% 的工作。Claude是一个持续的协作工具，但使用它通常需要积极的监督和验证，尤其是在高风险工作中——而不是像完全委托那样，无需任何验证。
定性访谈
- 员工们正在逐渐形成人工智能任务委派的直觉。工程师们倾向于委派那些易于验证的任务，例如“可以相对轻松地检查正确性”的任务、风险较低的任务（例如“一次性调试或研究代码”），或者枯燥乏味的任务（“我对这项任务越感兴趣，就越有可能不用Claude”）。许多人描述了一种信任的逐步提升过程，从简单的任务开始，逐步委派更复杂的工作——虽然他们目前仍然保留着大部分设计或“品味”类任务，但随着模型的改进，这一界限正在被重新界定。
- 技能范围正在不断扩大，但有些技能的练习机会却减少了。Claude帮助人们拓展技能，涉猎更多领域（例如软件工程领域（“我现在可以非常胜任前端开发或事务数据库方面的工作……以前我根本不敢碰这些东西”），但矛盾的是，一些员工也担心编写和审查代码所需的更深层次技能会逐渐退化——“当产出如此轻松快捷时，真正抽出时间学习新知识就变得越来越难了。”
- 人们与编程技艺的关系正在发生变化。一些工程师接受人工智能的辅助，并专注于结果（“我以前以为我真的很享受编写代码的过程，但现在我觉得我真正享受的只是编写代码带来的成果”）；另一些工程师则表示“我当然怀念编写代码的某些环节”。
- 职场社交动态可能正在发生变化。现在，人们遇到以前会问同事的问题时，首先会去找克劳德——一些人反映，这导致他们获得指导和合作的机会减少了。（“我喜欢和人一起工作，但现在我‘需要’他们的次数减少了，这真令人难过……资历较浅的人不再像以前那样经常来问我问题了。”）
- 职业发展与不确定性。工程师们表示，他们的工作重心正在转向管理人工智能系统等更高层次的工作，并且工作效率显著提高。然而，这些变化也引发了人们对软件工程这一职业长期发展轨迹的担忧。一些人对未来表达了矛盾的感受：“短期来看我很乐观，但从长远来看，我认为人工智能最终会包揽一切，让我和其他许多人变得无关紧要。”另一些人则强调了真正的不确定性，他们只表示“很难说”几年后自己的角色会是什么样子。
克劳德代码使用趋势
- Claude 能够更自主地处理日益复杂的任务。六个月前，Claude Code 在需要人工干预之前可以独立完成大约 10 个操作。现在，它通常可以处理大约 20 个操作，并且完成更复杂的工作流程所需的人工干预频率更低（图 3）。工程师们越来越多地使用 Claude 来执行代码设计/规划（占使用量的 1% 到 10%）和新功能实现（占 14% 到 37%）等复杂任务（图 4）。
- 克劳德修复了很多“小问题”。克劳德代码任务中有 8.6% 是修复一些能提升用户体验的小问题，例如为了便于维护而重构代码（也就是“修复小问题”），而这些问题通常会被人们忽略。这些小小的修复累积起来，却能带来更大的生产力和效率提升。
- 每个人都变得越来越“全栈”。不同的团队以不同的方式使用 Claude，通常是为了增强他们的核心专业知识——安全团队用它来分析不熟悉的代码，对齐与安全团队用它来构建数据的前端可视化，等等（图 5）。
调查数据
我们对来自 Anthropic 公司各部门的 132 位工程师和研究人员进行了关于 Claude 使用情况的调查，以更好地了解他们日常使用 Claude 的具体方式。我们通过内部沟通渠道和直接联系的方式向来自不同团队（涵盖研发和产品职能）的员工发放了调查问卷。我们在附录中加入了“局限性”部分，其中包含更多方法论细节。同时，我们也分享了调查问卷，以便其他人可以评估我们的方法并将其应用于他们自己的研究中。
人们使用 Claude 来完成哪些编程任务？
我们要求受访的工程师和研究人员评价他们使用 Claude 执行各种类型编码任务的频率，例如“调试”（使用 Claude 帮助修复代码中的错误）、“代码理解”（让 Claude 解释现有代码以帮助用户理解代码库）、“重构”（使用 Claude 帮助重构现有代码）和“数据科学”（例如，让 Claude 分析数据集并制作条形图）。
以下是最常见的日常任务。大多数员工（55%）每天都使用 Claude 进行调试。42% 的员工每天使用 Claude 来理解代码，37% 的员工每天使用 Claude 来实现新功能。使用频率较低的任务包括高层设计/规划（可能是因为这些任务通常由人工完成），以及数据科学和前端开发（可能是因为这些任务本身就不太常见）。这与“Claude Code 使用趋势”部分中报告的 Claude Code 使用数据分布大致吻合。
使用率和生产力
员工自述，12 个月前，他们在日常工作中使用 Claude 的比例为 28%，生产力提升了 20%；而现在，他们在日常工作中使用 Claude 的比例高达 59%，平均生产力提升了 50%。（这与我们在整个工程团队中采用 Claude Code 后，每位工程师每天合并的 pull request（即成功合并代码变更）数量增加 67% 的结果大致吻合。）同比数据对比非常显著——这意味着这两项指标在一年内都增长了两倍以上。使用率和生产力也高度相关，在分布的极端情况下，14% 的受访者通过使用 Claude 将生产力提高了 100% 以上——这些是我们内部的“超级用户”。
需要注意的是，生产力难以精确衡量（更多局限性请参见附录）。人工智能研究非营利组织 METR 最近的一项研究表明，经验丰富的开发人员在使用人工智能处理高度熟悉的代码库时，会高估人工智能带来的生产力提升。尽管如此，METR 指出的导致生产力低于预期的因素（例如，人工智能在大型复杂环境中表现不佳，或需要大量隐性知识/上下文的情况下）与我们员工表示不会委托给Claude的任务类型密切相关（参见下文“人工智能委托方法”）。我们员工在各项任务中报告的生产力提升，可能反映了员工正在培养战略性的人工智能委托技能——而这一点在 METR 的研究中并未考虑。
当我们询问员工，在他们目前使用 Claude 的任务类别中，Claude 如何影响他们在该任务类别中的总耗时和工作产出时长时，会发现一种有趣的生产力模式。在几乎所有任务类别中，我们都看到耗时净减少，而产出量净增加幅度更大：
然而，当我们深入研究原始数据时，我们发现节省时间的响应集中在相反的两端——有些人花费更多的时间在 Claude 辅助的任务上。
这是为什么呢？人们普遍解释说，他们需要对 Claude 生成的代码进行更多调试和清理工作（例如“当我自己把代码搞得焦头烂额时”），而且由于代码并非他们自己编写，理解 Claude 生成的代码需要付出更多认知成本。有些人提到，使用 Claude 能让他们以更高效的方式完成任务——一位用户表示，使用 Claude 能帮助他们“坚持完成以前会立即放弃的任务”；另一位用户则表示，Claude 能帮助他们进行更彻底的测试，并在新的代码库中进行更多学习和探索。总的来说，节省时间的工程师可能是那些为 Claude 设定易于快速验证的任务的工程师，而花费更多时间的工程师可能是在调试 AI 生成的代码，或者在 Claude 需要更多指导的领域工作。
我们的数据也无法明确显示节省的时间被重新投入到哪些方面——是用于额外的工程任务、非工程任务、与Claude互动或审查其输出，还是用于工作以外的活动。我们的任务分类框架无法涵盖工程师分配时间的所有方式。此外，节省的时间可能反映了自我报告中的感知偏差。需要进一步研究来厘清这些影响因素。
产出量的增长更为直接和显著；所有任务类别的净增长幅度都更大。考虑到人们报告的是任务类别（例如“调试”整体情况），而不是单个任务，这种模式就很容易理解了——也就是说，人们在调试这一类别上花费的时间可能略少，但总体产出量却大幅增加。生产力很难直接衡量，但这些自我报告的数据表明，人工智能主要通过提高产出量来提升 Anthropic 的生产力。
克劳德促成了新的工作
我们好奇的一点是：Claude 是否能带来质的全新工作类型，或者 Claude 辅助的工作最终是否会由员工完成（尽管速度可能会慢一些）？
员工估计，如果没有 Claude，他们 27% 的工作将无法完成。工程师们列举了使用 AI 来扩展项目、添加一些锦上添花的功能（例如交互式数据仪表板）、完成一些实用但繁琐的工作（例如文档编写和测试），以及一些手动操作成本过高的探索性工作。正如一位员工解释的那样，他们现在可以修复更多以前影响工作效率的“小问题”，例如重构结构不良的代码，或者构建“能够更快完成其他任务的小工具”。我们在使用数据分析中也发现了这一点，发现8.6% 的 Claude Code 任务都涉及“小问题修复”。
另一位研究人员解释说，他们同时运行了多个版本的 Claude，每个版本都探索了解决问题的不同方法：
人们往往把超级车型看作是单一的用途，比如拥有一辆更快的车。但拥有百万匹马力……就能让你测试各种不同的想法……当你拥有如此广阔的探索空间时，会更加令人兴奋，也更具创造力。
正如我们将在以下章节中看到的，这项新工作通常涉及工程师处理超出其核心专业知识范围的任务。
有多少工作可以完全委托给克劳德？
尽管工程师们经常使用 Claude，但超过半数的工程师表示，他们只能将 0% 到 20% 的工作“完全委托”给 Claude。（值得注意的是，受访者对“完全委托”的理解可能有所不同——从完全无需验证的任务到只需少量监督即可完成的任务。）在解释原因时，工程师们描述了他们如何积极地与 Claude 进行迭代协作，并验证其输出——尤其是在代码质量标准至关重要的复杂任务或高风险领域。这表明，工程师们倾向于与 Claude 密切合作并检查其工作，而不是在未经验证的情况下将任务交给 Claude，并且他们对“完全委托”的标准很高。
定性访谈
尽管这些调查结果显示生产力显著提高，工作模式也发生了变化，但它们也引发了人们对工程师们日常工作中实际体验到这些变化的疑问。为了了解这些指标背后的人性因素，我们对参与调查的53位Anthropic工程师和研究人员进行了深度访谈，以更深入地了解他们对工作场所这些变化的看法和感受。
人工智能委托方法
工程师和研究人员正在开发各种策略，以便在工作流程中高效利用 Claude。人们通常会委派以下任务：
| 在用户上下文之外且复杂度较低的情况下： “我使用 Claude 处理一些我不太了解的情况，但我认为整体复杂度也很低。” “我遇到的大多数基础设施问题都不难，Claude 都能处理……我对 Git 和 Linux 都不太熟悉……Claude 很好地弥补了我在这些领域的经验不足。” |
| 很容易验证： “对于验证工作量与创建工作量相比并不大的所有情况来说，这绝对令人惊叹。” |
| 定义明确或自包含： “如果项目的某个子组件与其他部分充分解耦，我就让克劳德尝试一下。” |
| 代码质量并不关键： “如果是随意调试或研究代码，就直接交给克劳德。如果是概念上比较难懂、需要某种非常特殊的调试注入，或者存在设计问题，我就自己处理。” |
| 重复或枯燥： “我越是兴奋地去做某项任务，就越有可能不想用Claude。而如果我感到很抗拒……我通常会发现更容易和Claude讨论这项任务。” 在我们的调查中，人们平均表示，44%由Claude辅助完成的工作是他们自己并不喜欢做的。 |
| 提示比执行更快： “对于我预计耗时不到 10 分钟的任务……我可能不会费心使用 Claude。” “冷启动问题可能是目前最大的障碍。所谓冷启动，是指我掌握了很多关于团队代码库运作方式的内在信息，而 Claude 默认情况下并不具备这些信息……我可以花时间尝试迭代出完美的提示，但我还是决定自己动手。” |
员工在决定任务委派时提到的这些因素，与METR一项外部研究中发现的导致人工智能相关生产力下降的因素（例如开发人员对代码库的高度熟悉程度、庞大而复杂的代码库）类似。我们在访谈中对这些委派标准的认同表明，选择合适的任务是提高人工智能生产力的重要因素（未来的生产力研究应仔细控制这一因素）。
信任，但要核实
许多用户描述了他们在使用 Claude 的过程中不断进步，随着时间的推移，他们委托的任务也变得越来越复杂：“一开始我使用 AI 工具来询问有关 Rust 编程语言的基本问题……最近，我所有的编码工作都使用 Claude Code。”
一位工程师将信任的逐步建立比作采用其他技术，例如谷歌地图：
一开始，我只会在不熟悉的路线上使用[谷歌地图]……这就像我用Claude来编写我不熟悉的SQL代码，而不是让它编写我熟悉的Python代码一样。后来，我开始在大部分熟悉的路线上使用谷歌地图，即使最后一段路可能不太清楚……现在，我几乎每天都用谷歌地图，甚至连通勤都用。如果它建议走其他路线，我就照做，并且相信它已经考虑了所有选项……我现在使用Claude Code的方式也类似。
工程师们对于是否应该在自身专业领域内或领域外使用 Claude 意见不一。有些人将其用于“边缘”领域以节省实现时间；而另一些人则更倾向于在熟悉的领域内使用，以便验证输出结果（“我使用 Claude 的方式让我完全理解它的工作原理”）。一位安全工程师强调了经验的重要性，因为 Claude 提出了一个“非常巧妙但危险”的解决方案，这种方案“只有非常有才华的初级工程师才会提出”。也就是说，只有具备判断力和经验的用户才能意识到其中的问题。
其他工程师也会使用 Claude 来完成这两种类型的任务，要么是出于实验目的（“我基本上总是用 Claude 来初步尝试解决任何编码问题”），要么是根据自己对任务的专业知识水平来调整方法：
我使用这些工具既可以用于我擅长的核心领域（作为加速器，我知道会发生什么，可以有效地指导代理人），也可以用于我不太擅长的领域，我大致知道会发生什么，但克劳德能够填补我记忆或熟悉特定定义的空白。
如果我特别熟悉某个领域，我会更主动地告诉克劳德它需要追踪什么。如果我不确定，我通常会请它扮演专家的角色，为我提供一些选择和见解，让我考虑和研究相关事项。
人们会把哪些任务留给自己去做？
人们普遍表示，他们不会将 Claude 用于涉及高层次或战略性思考的任务，也不会用于需要组织背景或“品味”的设计决策。一位工程师解释说：“我通常负责高层次的思考和设计。我会尽可能地将新功能开发和调试等工作委派出去。”我们的调查数据也反映了这一点，数据显示设计和规划任务的生产力提升幅度最小（图 2）。不过，许多人认为委派的界限是一个“不断变化的目标”，会随着模型的改进而定期重新调整（如下 Claude Code 使用数据显示，现在编码设计/规划的使用量比六个月前相对更多）。
技能转型
新增功能……
调查发现，27% 的 Claude 辅助工作原本是无法完成的，这反映了一种更广泛的趋势：工程师们利用人工智能来完成他们核心专业领域之外的工作。许多员工表示，他们完成了以前超出自身专业范围的工作——后端工程师构建用户界面；研究人员创建可视化图表。一位后端工程师描述了他如何通过与 Claude 迭代构建一个复杂的用户界面：“它做得比我好得多。我根本不可能完成，肯定无法按时完成……（设计师们）都惊呆了，‘等等，这是你做的？’我说，‘不，这是 Claude 做的——我只是提示了一下。’”
工程师们表示，“他们正在变得更加全栈化……我现在能够非常胜任前端、事务数据库或 API 代码的开发工作，而以前我根本不敢碰那些我不太熟悉的东西。”这种能力的提升使得反馈循环更加紧密，学习速度也更快——一位工程师表示，以前需要“几周时间”才能完成的构建、安排会议和迭代，现在可以缩短到“几个小时的工作会议”，同事们可以在会上提供实时反馈。
总的来说，人们对快速原型制作、并行工作、减少繁琐工作以及整体上提升工作热情的新能力感到兴奋。一位资深工程师告诉我们：“这些工具确实提高了初级工程师的工作效率，也让他们在承担项目类型方面更加大胆。”一些人还表示，使用 Claude 降低了“启动能量”，使他们更容易克服拖延症，“大大降低了我开始解决问题所需的能量，因此我更愿意承担更多的事情。”
……以及较少的实践操作
与此同时，一些人担心“随着[他们]更多地委派任务，技能会退化”，并且会失去在手动解决问题过程中发生的偶然（或“附带”）学习：
如果你自己去调试一个棘手的问题，你会花很多时间阅读文档和代码，这些内容虽然对解决问题没有直接帮助——但你一直在构建系统工作原理的模型。而使用 Claude 则能让你直接找到问题所在，所以这种情况就少得多。
我以前会仔细研究每个配置，了解工具的功能，但现在我依赖人工智能来告诉我如何使用新工具，因此我缺乏专业知识。以前和队友交流时，我可以立即回忆起相关内容，而现在我必须问人工智能。
使用 Claude 有可能跳过我通过解决一个简单的实例来学习如何执行任务，然后再努力解决更复杂的实例的阶段。
一位资深工程师表示，如果资历较浅，他们会更担心自己的技能：
我主要在知道答案应该是什么或应该是什么样子的情况下才使用人工智能。我是通过“吃苦耐劳”地做软件工程才培养出这种能力的……但如果我回到职业生涯早期，我会觉得需要付出很多努力来不断提升自己的能力，而不是盲目地接受模型的输出。
编程技能退化令人担忧的原因之一是“监督悖论”——如上所述，有效使用 Claude 需要监督，而监督 Claude 本身又需要编程技能，而这些技能恰恰可能因人工智能的过度使用而退化。有人说：
说实话，我更担心的是监督和管理问题，而不是我自身的技能……我的技能退化或无法发展，主要问题在于我能否安全地使用人工智能来完成我关心的任务，而不是我能否独立完成这些任务。
为了应对这种情况，一些工程师会刻意在不使用人工智能的情况下进行练习：“有时候，即使我知道克劳德能解决某个问题，我也不会让它来做。这有助于我保持敏锐。”
我们还需要那些实际操作的编程技能吗？
或许软件工程正朝着更高层次的抽象发展，就像它过去那样。早期的程序员与机器的交互更为直接——手动管理内存、编写汇编语言，甚至通过拨动物理开关来输入指令。随着时间的推移，更高级、更易于人类阅读的语言应运而生，它们能够自动处理复杂的底层操作。或许，尤其是在“感觉编码”（vibe coding）兴起之后，我们现在正朝着以英语作为编程语言的方向发展。我们的一位同事建议，有志成为工程师的人应该“努力让AI编写代码，并专注于学习更高层次的概念和模式”。
一些员工表示，他们觉得这种转变让他们能够从更高的层面思考——“关注最终产品和最终用户”，而不仅仅是代码本身。一位员工将当前的转变比作以前在计算机科学中学习链表——这种基础结构现在被更高级的编程语言自动处理了。“我很庆幸自己以前会做链表……[但是]从情感上来说，做这些底层操作并不特别重要。我更关心代码能让我做什么。”另一位工程师也做了类似的比较，但他指出，抽象是有代价的——随着向更高级语言的转变，大多数工程师对内存处理的深入理解有所下降。
持续提升某一领域的技能有助于更好地指导克劳德的工作，并提高工作效率（“我发现，做自己熟悉的事情时，速度通常会更快”）。但工程师们对此看法不一。有些人仍然乐观：
我并不太担心技能退化。人工智能仍然能促使我认真思考问题，并帮助我学习新的方法。如果说有什么变化的话，那就是能够更快地探索和测试想法反而加快了我在某些领域的学习。
另一位则更为务实：“我的软件工程师技能肯定在退化……但如果需要的话，这些技能还能重新掌握，只是我现在不再需要它们了！”还有一位指出，他们只失去了一些不太重要的技能，比如制作图表，“而那些至关重要的代码，我仍然能写得很好。”
或许最有趣的是，一位工程师对这一前提提出了质疑：“‘技术生疏’的说法依赖于一个假设，即编码总有一天会回到 Claude 3.5 之前的状态。但我认为不会。”
软件工程的技艺与意义
工程师们对于是否怀念亲自动手编写代码的看法截然不同。有些人感到真切的失落——“对我来说，这是一个时代的终结——我从事编程工作25年了，能够熟练掌握这些技能是我职业满足感的核心所在。”另一些人则担心自己无法享受新的工作方式：“整天给Claude提建议既无趣又无成就感。放点音乐，进入状态，自己动手实现一些东西，这要有趣得多，也更有成就感。”
有些人直接谈到了这种权衡，并接受了它：“当然，我怀念编写代码的某些部分——比如重构代码时进入禅定状态，但总的来说，我现在的工作效率高得多，所以我很乐意放弃那些。”
有人说，与 Claude 合作更有趣，因为 Claude 的反馈比人类更挑剔。其他人则更关注结果。一位工程师说：
我原以为到了这个时候我会感到害怕或无聊……然而，我并没有这种感觉。相反，我感到非常兴奋，因为我能做的事情远不止这些。我原以为我真正享受的是编写代码的过程，但实际上，我只是享受编写代码带给我的成就感。
人们是欣然接受人工智能辅助，还是为失去亲自动手编写代码而感到惋惜，似乎取决于他们认为软件工程的哪些方面最有意义。
职场中不断变化的社会动态
其中一个比较突出的主题是，Claude 已经成为人们提出问题的第一选择，而这些问题以前都需要咨询同事。“我现在问的问题比以前多得多，但其中 80% 到 90% 的问题都会先咨询 Claude，”一位员工指出。这形成了一种过滤机制，Claude 处理日常咨询，而同事们则可以专注于处理更复杂、更具战略性或涉及大量背景信息的问题，这些问题超出了人工智能的能力范围（“它让我对团队的依赖减少了 80%，但剩下的 20% 至关重要，我还是会去和他们沟通”）。人们也会像与人类同事交流一样，与 Claude 碰撞出“灵感火花”。
大约一半的人表示团队协作模式没有改变。一位工程师说，他仍然会与人开会、分享背景信息、确定方向，他认为在不久的将来仍然会有很多协作，但是“你不再是做你通常专注的工作，而是要和很多像克劳德一样的人交流。”
然而，也有人表示与同事的互动减少了（“我和克劳德的互动比和任何其他同事都多。”）。有些人很欣赏这种减少的社交摩擦（“我不再觉得占用同事的时间有什么不好意思了”）。另一些人则抵制这种改变（“我其实不太喜欢大家常说的‘你问过克劳德了吗？’我真的很喜欢和人面对面交流，也很重视这一点”），或者怀念以前的工作方式：“我喜欢和人一起工作，现在我‘需要’他们的次数减少了，这让我感到难过。”一些人指出，这种改变对传统的导师制关系产生了影响，因为“克劳德可以指导初级员工”，而不是资深工程师。一位资深工程师说：
令人遗憾的是，资历较浅的员工不太常来问我问题，尽管他们的问题确实能得到更有效的解答，学习速度也更快。
职业生涯的不确定性与适应
许多工程师表示，他们的角色正在从编写代码转向管理人工智能。工程师们越来越把自己视为“人工智能代理的管理者”——有些人甚至“始终运行着至少几个[Claude]实例”。一位工程师估计，他们的工作已经“70%以上变成了代码审查/修改者，而不是全新的代码编写者”，而另一位工程师则认为，“对1个、5个甚至100个Claude的运行负责”是他们未来工作的一部分。
从长远来看，职业前景的不确定性十分普遍。工程师们将这些变化视为整个行业转型的先兆，许多人表示，几年后自己的职业生涯会是什么样子“很难说”。一些人表达了短期乐观与长期不确定性之间的矛盾。“短期内我感到乐观，但从长远来看，我认为人工智能最终会包揽一切，让我和其他许多人变得无关紧要，”一位工程师说道。其他人则更直白地表达了这种感受：“感觉我每天来上班就像是为了让自己失业一样。”
一些工程师则更为乐观。一位工程师表示：“我为初级开发人员感到担忧，但我也意识到，他们或许是对新技术最渴望的。总的来说，我对这个行业的未来发展趋势非常乐观。”他们认为，虽然经验不足的工程师可能会交付有问题的代码，但更完善的人工智能防护措施、更丰富的内置教育资源以及从错误中自然学习的能力，将有助于该领域随着时间的推移而不断改进。
我们询问了人们如何设想自己未来的角色，以及他们是否有任何适应策略。一些人提到计划进一步专攻某个领域（“培养有效审查人工智能工作的能力需要更长时间，也需要更专业化”），一些人则预计未来会专注于更多人际交往和战略性工作（“我们将花更多时间达成共识，让人工智能花更多时间进行实施”）。一位受访者表示，他们专门使用 Claude 来进行职业发展，并从中获得关于工作和领导技能的反馈（“我学习新事物的速度，甚至无需完全掌握就能高效工作的速度都发生了彻底的改变。我感觉自己仿佛突破了瓶颈”）。
总体而言，许多人承认存在深深的不确定性：“我对未来哪些具体技能会有用非常没有信心。”一位团队负责人说：“没人知道会发生什么……重要的是要有很强的适应能力。”
克劳德代码使用趋势
调查和访谈数据显示，Claude 使用量的增加有助于人们更快地完成工作并承担新的工作类型，但这同时也带来了关于人工智能任务委派和技能发展方面的一些问题。然而，自我报告的数据只能反映部分情况。为了补充这些信息，我们还分析了 Anthropic 各团队的实际 Claude 使用数据。由于调查受访者表示 Claude Code 是他们使用的主要工具，我们使用隐私保护分析工具分析了 2025 年 2 月至 8 月期间来自 Claude Code 的 20 万份内部记录。
在监管较少的情况下解决更棘手的问题
过去六个月，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 Code 的转录文本分为一种或多种编码任务类型，并研究了过去六个月中不同任务的用途是如何演变的：
根据使用数据估算的总体任务频率分布与用户自述的任务频率分布大致吻合。2025 年 2 月至 8 月间最显著的变化是，使用 Claude 实现新功能（14.3% → 36.9%）和进行代码设计或规划（1.0% → 9.9%）的文本记录比例大幅增加。Claude Code 任务相对分布的这种变化可能表明 Claude 在这些更复杂的任务上表现更佳，但也可能反映出团队在不同工作流程中采用 Claude Code 的方式发生了变化，而非绝对工作量增加（更多局限性请参见附录）。
处理纸割伤
调查发现，工程师们现在花费更多时间进行一些细微的、提升工作效率的改进；与此相符的是，目前 Claude Code 任务中有 8.6% 被归类为“小修小补”。这些任务既包括创建性能可视化工具和重构代码以提高可维护性等大型任务，也包括创建终端快捷键等小型任务。这可能有助于提高工程师们报告的工作效率（解决之前被忽视的工作效率问题可能会随着时间的推移而提高效率），并有可能减少日常工作中的摩擦和挫败感。
不同团队的任务差异
为了研究当前各团队的任务差异，我们改进了分类方法，将每份八月份的记录分配到一个主要编码任务，并按内部团队（y轴）拆分数据。堆叠条形图显示了每个团队的编码任务构成：
“所有团队”柱状图显示了总体分布情况，其中最常见的任务是构建新功能、调试和代码理解。这为团队间的比较提供了基准。
值得注意的团队特定模式：
- 预训练团队（帮助训练 Claude）经常使用 Claude 代码来构建新功能（54.6%），其中很多是运行额外的实验。
- Alignment & Safety和Post training团队使用 Claude Code 进行前端开发最多（分别为 7.5% 和 7.4%），通常用于创建数据可视化。
- 安全团队经常使用 Claude Code 进行代码理解（48.9%），特别是分析和理解代码库不同部分的安全隐患。
- 非技术员工经常使用 Claude Code 进行调试（51.5%），例如排除网络问题或 Git 操作故障，以及进行数据科学研究（12.7%）；Claude 似乎对弥合技术知识差距很有价值。
许多团队特有的模式都体现了我们在调查和访谈中观察到的能力扩展：Claude 使团队成员能够从事原本没有时间或技能完成的新型工作。例如，预培训团队开展了大量额外的实验，非技术人员也能够修复代码错误。虽然数据显示团队确实会将 Claude 用于核心任务（例如，基础设施团队最常使用 Claude Code 进行基础设施和 DevOps 工作），但 Claude 也经常增强他们的核心任务（例如，研究人员使用 Claude 进行前端开发，以便更好地可视化数据）。这表明 Claude 正在帮助每个人在工作中变得更加全栈化。
期待
过去一年，Anthropic 的员工大幅增加了对 Claude 的使用，不仅用它来加速现有工作，还用于学习新的代码库、减少重复劳动、拓展新领域以及解决之前被忽视的改进问题。随着 Claude 变得更加自主和强大，工程师们正在探索使用 AI 委托的新方法，同时也在思考未来需要哪些技能。这些转变带来了显著的生产力和学习效益，但也带来了软件工程工作长期发展方向的不确定性。AI 的发展会像以往的软件工程转型那样吗？例如，从底层编程语言到高级编程语言，或者像一些工程师所建议的那样，从个人贡献者到管理者？还是会走得更远？
目前仍处于早期阶段——Anthropic 内部有很多早期采用者，行业格局瞬息万变，我们的研究结果可能暂时无法推广到其他组织或环境中（更多局限性请参见附录）。这项研究也反映了这种不确定性：研究结果较为细致，尚未形成统一的共识或明确的指导原则。但它确实引发了关于我们如何深思熟虑且有效地应对这些变化的思考。
为了跟进这项初步工作，我们正在采取多项措施。我们正与 Anthropic 的工程师、研究人员和领导层进行沟通，以应对提出的机遇和挑战。这包括审视我们如何组建团队并促进团队协作，如何支持职业发展，以及如何建立人工智能增强型工作的最佳实践（例如，以我们的人工智能素养框架为指导）。我们还将研究范围扩大到工程师之外，以了解人工智能转型如何影响组织内各个角色，并支持 CodePath 等外部组织调整计算机科学课程，使其适应人工智能辅助的未来。展望未来，我们也在考虑随着人工智能能力的提升，一些结构性方法可能会变得越来越重要，例如在组织内部探索新的角色发展路径或技能提升途径。
随着我们思路的日趋成熟，我们预计将在2026年分享更具体的计划。Anthropic是一个致力于推动工作场所负责任转型的实验室；我们不仅希望研究人工智能如何改变工作，还希望探索如何以深思熟虑的方式应对这种转型，首先从我们自身做起。
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 代码分析采用按时间段比例抽样，这意味着我们只能衡量任务分布的相对变化，而无法衡量工作量的绝对变化。例如，当我们报告功能实现占 Claude 代码使用量的比例从 14% 增加到 37% 时，这并不一定意味着功能实现的总工作量增加了。
最后，这项研究于2025年8月进行，当时Claude Sonnet 4和Claude Opus 4是我们最先进的模型。鉴于人工智能发展的日新月异，随着更新模型的出现，我们观察到的模式可能已经发生了变化。