Anthropic 是全球领先的安全导向型通用人工智能公司，以 Claude 系列模型在可靠性、安全性与前沿能力上的突破确立了其在 AI 领域的顶尖地位。
到 2025 年 8 月，Anthropic 的年化收入（run-rate）已达 超过 50 亿美元。公司内部目标是到 2025 年底实现约 90 亿美元 的年化收入，并在 2026 年达到 200-260 亿美元。
当 AI 进入工程师的工位：Anthropic 内部一年观察
过去一年，人工智能在全球职场掀起巨浪，但多数讨论都停留在“宏观层面”。到底 AI 在真实工作场景中会带来什么变化？工程师的日常被怎样改写？未来职业路径会变成什么样？
Anthropic 最近做了一次非常特别的研究：
——研究对象不是外部行业，不是虚构模型，而是他们自己公司的工程师。
2025 年 8 月，Anthropic 对 132 名工程师与研究人员进行了调查、访谈，并分析了内部 Claude Code 使用数据。第一次，从“内部视角”完整呈现了 AI 如何真正改变软件工程的工作方式。
结果非常真实，也非常震撼：
AI 正在重塑工程师的边界、能力、协作方式与职业想象。
下面，我们把这份长文研究浓缩为一篇适合大多数人阅读的深度观察。
01
AI 让工程师“变强”了，但方式与过去完全不同
调查显示，Anthropic 员工如今平均有 60% 的工作依赖 Claude，生产力相比一年前提升约 50%，几乎所有核心任务（调试、理解代码、新功能开发）都明显提速。
更重要的是：
27% 的工作，在没有 AI 的情况下根本不会发生。
包括——
扩展原本做不到的项目
构建以前嫌麻烦的工具
更彻底的测试、更多版本探索
修复被长期忽视的“小麻烦”
这意味着：
工程师不只是“更快完成旧活”，而是在做更多、做新的、做以前不会做的事。
一位后端工程师这样说：
“以前我不可能在 deadline 内做好 UI，但现在 Claude 帮我把前端也搞定了。”
工程师的技能边界正在被重新绘制，每个人都在变得更加“全栈”。
02
但与此同时，大家心里也开始出现隐隐不安
尽管生产力大幅提升，但很多工程师对未来的感觉是复杂的：
● 技能在加速扩展，也在加速萎缩
工程师做的事情变多了，但手写代码、从零调试、深入理解系统的机会变少了。
一些担心也开始出现：
“Claude 帮我跳过了很多‘慢慢摸索’的过程，这意味着我构建系统模型的机会变少。”
“我怕变成不会写代码的人，却又要去监督 AI 写的代码。”
这是工程团队最常提到的“监督悖论”：
你要监督 AI，但监督本身需要的技能正被 AI 稀释。
● 写代码的工艺感在消逝
有人怀念过去写代码的“心流”：
“听着音乐，一行一行敲代码，那种满足感在消失。”
也有人看得更清楚：
“我其实喜欢的不是写代码，而是写完代码后实现的东西。”
很难说哪种情绪更多，但显然：
写代码本身，正在逐渐变成工程师工作中的非核心部分。
图 2：按任务类别（纵轴）展示的时间花费（左图）和产出量（右图）的影响。每个图的横轴表示相比不使用 Claude 时，受访者在 Claude 辅助任务类别上的时间花费或产出量的自我报告变化：负值表示减少，正值表示增加，垂直虚线表示无变化。误差为 95% 置信区间。圆圈面积与该评分点的响应数量成比例。仅包含报告在该任务类别中使用过 Claude 的受访者。
03
人与人之间的关系，也在悄悄变化
Claude 已成为工程师的第一问询对象。
过去问同事的问题，如今有 80%-90% 先问 Claude。
这带来两个结果：
● 协作更高效了，但更“孤独”了
“我和 Claude 合作比和任何同事合作都多。”
“我不再因为问同事小问题而内疚了。”
但也有人说：
“新来的同事不太来问我问题了，这让我有点难过。”
指导、讨论、共同解决问题这些传统工作场景正在减少。
协作仍然存在，但变得更像“大家一起和很多个 Claude 开会”。
● 同事关系正在被重塑
AI 接管了日常询问，人类开始只在真正需要判断的时刻出场——在高风险决策、在具备上下文的讨论、在需要经验的提案里。
04
从“写代码”到“管理 AI”：工程师角色正在上移**
越来越多工程师把自己形容为：
“AI 的管理者”
他们不再从零写代码，而是：
同时管理多个 Claude 实例
审查 AI 的产出
给 AI 下指令、定策略
维护质量标准
做高层设计决定
有人说：
“我的工作有 70% 变成了审查 AI 写的代码。”
有人甚至认为：
“未来工程师是负责一个人、五个人、还是一百个 AI 的区别。”
这或许会成为软件工程职业史上的重大转折点。
“All Teams” 这一条展示了整体任务分布，其中最常见的任务是：构建新功能、调试和代码理解。这为不同团队之间的对比提供了基准。
以下是值得注意的团队差异：
预训练团队（负责训练 Claude）
经常使用 Claude Code 来构建新功能（54.6%），其中很大一部分是用于运行额外实验。对齐与安全团队、后训练团队
使用 Claude Code 进行最多的前端开发（分别为 7.5% 和 7.4%），多用于创建数据可视化工具。安全团队
经常使用 Claude Code 进行代码理解（48.9%），特别是分析代码库不同部分的安全影响。非技术员工
常使用 Claude Code 进行调试（51.5%），例如排查网络问题或处理 Git 操作；也有相当比例用于数据科学任务（12.7%）。这表明 Claude 能有效弥合技术知识差距。
不同编码任务（纵轴）在全部记录中的占比（横轴）。图中对比了 6 个月前（粉色）与当前（紫色）的任务分布情况。纵轴按 2025 年 2 月的任务频率排序。
根据使用数据估计的整体任务频率分布与工程师的自我报告大致一致。
2025 年 2 月到 2025 年 8 月之间最显著的变化是：
使用 Claude 来实现新功能的记录占比大幅上升（从 14.3% → 36.9%）
使用 Claude 进行代码设计或规划的记录占比也明显提高（从 1.0% → 9.9%）
这种 Claude Code 任务相对分布的变化可能说明：
Claude 在处理更复杂任务上的能力明显增强。
不过，这也可能反映团队在不同工作流程中采用 Claude Code 的方式发生了变化，而不一定意味着整体工作量的绝对增长。
05
最大的情绪：短期乐观，长期不确定
几乎所有受访者都有相同的矛盾感觉：
✔ 短期里：
工作效率飙升
能力被放大
可以做更多事
收获更快成就感
✘ 长期里：
角色会不会被 AI 吞噬？
哪些技能还值得继续学？
未来几年职业路径会变成什么？
一句最真实的话来自一位工程师：
“我每天来上班，都觉得自己在加速让自己未来的岗位消失。”
也有人更乐观：
“年轻工程师更愿意学习新工具，AI 可能会让整个行业变得更好。”
但总体来看，真正的回答只有一个：
没有人知道未来会怎样。
06
AI 时代的工程师：正在经历一场“重写职业”的巨大过渡
从内部研究来看，AI 带来的不是简单的“效率提升”，而是职业结构性的重塑：
AI 在放大一切：
放大工程师的能力，也放大工程师的焦虑**
它让工程师：
能做更多
能做更广
迭代更快
学习更多代码库
解决更多“小麻烦”
开拓原本不会做的事
同时也让工程师：
减少深度技能练习
更容易依赖 AI
需要新的监督能力
面临职业方向的不确定
失去一部分手工 craft 的满足感
AI 正在把工程师推向一个更高的抽象层：
从“写代码的人”变成“设计、监督和管理 AI 系统的人”。
这不是坏事，只是转变而已——
就像当年从汇编到高级语言、从手工部署到云平台。
唯一不同的是：
这次转变比以往都快。
尾声：这不仅是 Anthropic 的故事，也是每一位知识工作者的未来预演
虽然研究对象是 Anthropic 的工程师，但它其实为所有行业提供了一个预兆：
AI 不是替代，而是重新定义工作内容。
职业技能将加速演变。
协作关系会重写。
学习路径要更新。
管理方式要改变。
最重要的是：
每个人都必须重新回答一个问题：
当 AI 变成你的“能力延伸”，你要如何重新定义自己？
这篇研究的结尾也提到：
Anthropic 正把自己当成一个“AI 时代的职场实验室”，探索新的学习方式、协作方式与职业发展路径。
所有公司，最终都要面对同样的问题。
==========================
你可以阅读英文原文：
https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic?utm_source=chatgpt.com
下面是翻译后的中文版：
AI 正在如何改变我们的工作方式？我们此前关于 AI 经济影响的研究主要从整体劳动力市场入手，涵盖各种不同的岗位。但如果我们更深入地观察 AI 技术最早的一批使用者——也就是我们自己，会发现什么？
将镜头转向内部，我们在 2025 年 8 月对 132 名 Anthropic 的工程师与研究人员进行了调查，开展了 53 次深度访谈，并分析了内部的 Claude Code 使用数据，以了解 AI 的使用正在如何改变 Anthropic 的工作方式。我们的发现是：AI 的使用正在从根本上改变软件开发人员的工作性质，这既带来了希望，也带来了担忧。
我们的研究揭示了一个面临重大变革的工作场所：工程师完成的工作越来越多，变得更加“全栈”（能够胜任超出其正常专业知识范围的任务），加快了学习和迭代速度，并处理以前被忽视的任务。这种广度的扩展也让人们开始思考权衡——一些人担心这可能意味着失去更深层次的技术能力，或者变得不太能够有效地监督Claude的输出，而另一些人则拥抱更广泛思考和更高层次思考的机会。一些人发现，更多的人工智能协作意味着他们与同事的协作减少；一些人想知道他们最终是否会将自己自动化出工作岗位。
我们认识到，在一家构建人工智能的公司研究人工智能的影响意味着处于一个特权地位——我们的工程师可以早期使用尖端工具，在一个相对稳定的领域工作，并且他们自己也在为影响其他行业的人工智能转型做出贡献。尽管如此，我们认为研究和发表这些发现总体上是有用的，因为Anthropic内部工程师身上发生的事情可能仍然是更广泛社会转型的有益预兆。我们的发现暗示了一些可能需要跨部门早期关注的挑战和考虑因素（尽管请参见附录中的局限性部分了解注意事项）。在收集这些数据时，Claude Sonnet 4和Claude Opus 4是最强大的可用模型，并且能力持续提升。
更强大的人工智能带来了生产力优势，但也引发了关于维持技术专长、保持有意义的协作以及为不确定的未来做准备的问题，这些未来可能需要在人工智能增强的工作场所中采用新的学习、指导和职业发展方法。我们在下面的“展望”部分讨论了我们正在内部采取的一些初步步骤来探索这些问题。我们还在最近关于人工智能相关经济政策想法的博客文章中探讨了潜在的政策应对措施。
主要发现
在本节中，我们简要总结了来自我们的调查、访谈和Claude Code数据的发现。我们在下面的后续部分中提供了详细的发现、方法和注意事项。
调查数据
Anthropic的工程师和研究人员最常使用Claude来修复代码错误和了解代码库，调试和代码理解是最常见的用途。
人们报告Claude的使用量增加和生产力提升。员工自我报告在60%的工作中使用Claude，并实现了50%的生产力提升，比去年同期增长了23倍。这种生产力表现为每个任务类别花费的时间略少，但产出量显著增加（图2）
27%的Claude辅助工作由原本不会完成的任务组成，例如扩展项目、制作实用工具（如交互式数据仪表板）以及手动完成不符合成本效益的探索性工作。
大多数员工经常使用Claude，同时报告他们可以将0—20%的工作“完全委托”给它。Claude是一个持续的协作者，但使用它通常涉及主动监督和验证，特别是在高风险工作中——而不是移交完全不需要验证的任务。
定性访谈
员工正在培养人工智能委托的直觉。工程师倾向于委托易于验证的任务，即他们“可以相对容易地嗅探检查正确性”的任务、低风险任务（例如“一次性调试或研究代码”）或枯燥的任务5.
（“我对完成任务的热情越高，我就越不可能使用Claude”）。许多人描述了一种信任进展，从简单任务开始，逐渐委托更复杂的工作——虽然他们目前保留了大多数设计或“品味”任务，但随着模型的改进，这一界限正在重新谈判。
技能集正在向更多领域扩展，但有些领域的实践越来越少。Claude使人们能够将技能扩展到更多领域（软件工程领域）（“我可以非常熟练地从事前端或事务性数据库工作……以前我会害怕接触这些东西”），但矛盾的是，一些员工也担心编写和批评代码所需的更深层次技能的萎缩——“当产出变得如此容易和快速时，实际上花时间学习东西变得越来越难。”
与编码工艺的关系正在变化。一些工程师接受人工智能辅助并专注于结果（“我以为我真的很喜欢编写代码，但我认为相反，我实际上只是喜欢我从编写代码中得到的东西”）；其他人说“当然有[编写代码的]某些部分我很怀念。”
工作场所的社会动态可能正在发生变化。Claude现在是以前会向同事提出的问题的第一站——一些人报告说，结果是指导和协作机会减少——Claude。（“我喜欢与人合作，现在我’需要’他们的程度降低了，这很令人难过……更多的初级人员不常来找我提问了。”)
职业发展和不确定性。工程师报告转向管理人工智能系统的更高层次工作，并报告显著的生产力提升。然而，这些变化也引发了关于软件工程作为一种职业的长期轨迹的问题。一些人对未来表达了矛盾的感受：“我在短期内感到乐观，但从长远来看，我认为人工智能最终会做所有事情，使我和许多其他人变得无关紧要。”其他人强调真正的不确定性，只说很难说几年后他们的角色会是什么样子。
Claude Code使用趋势
Claude正在更自主地处理越来越复杂的任务。六个月前，Claude Code在需要人类输入之前会自行完成大约10个操作。现在，它通常处理大约20个操作，需要更少的人类指导来完成更复杂的工作流程（图3）。工程师越来越多地使用Claude来完成复杂任务，如代码设计/规划（使用率从1%到10%）和实现新功能（从14%到37%）
Claude修复了很多“小麻烦”。8.6%的Claude Code任务涉及修复解决生活质量的小问题，例如重构代码以提高可维护性（即“修复小麻烦”），人们说这些通常会被优先考虑。这些小修复可能会累积成更大的生产力和效率提升。
每个人都变得更加“全栈”。不同的团队以不同的方式使用Claude，通常是为了增强他们的核心专业知识——安全团队使用它来分析不熟悉的代码，对齐与安全团队使用它来构建数据的前端可视化，等等（图5）。12.
调查数据
我们调查了132名来自整个组织的Anthropic工程师和研究人员关于他们使用Claude的情况，以更好地了解他们日常使用Claude的确切方式。我们通过内部沟通渠道和直接联系代表研究和产品职能的不同团队的员工来分发调查。我们在附录中包含了一个局限性部分，提供了更多方法学细节，并且我们正在分享我们的调查问题，以便其他人可以评估我们的方法并将其调整用于自己的研究。
人们使用Claude完成哪些编码任务？
我们要求接受调查的工程师和研究人员对他们使用Claude完成各种编码任务的频率进行评分，例如“调试”（使用Claude帮助修复代码中的错误）、“代码理解”（让Claude解释现有代码以帮助人类用户理解代码库）、“重构”（使用Claude帮助重组现有代码）和“数据科学”（例如让Claude分析数据集并制作条形图）。
以下是最常见的日常任务。大多数员工（55%）每天使用Claude进行调试。42%的人每天使用Claude进行代码理解，37%的人每天使用Claude实现新功能。频率较低的任务是高级设计/规划（可能因为这些是人们倾向于保留在人类手中的任务），以及数据科学和前端开发（可能因为它们总体上是不太常见的任务）。这与“Claude Code使用趋势”部分报告的Claude Code使用数据分布大致一致。
图1：各种编码任务（y轴）的每日用户比例（x轴）。
使用情况和生产力
员工自我报告称，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如何影响他们在该任务类别的总体时间花费和工作产出量时，出现了一个有趣的生产力模式。在几乎所有任务类别中，我们看到时间花费的净减少和产出量的更大净增加：
图2：按任务（y轴）划分的时间花费（左面板）和产出量（右面板）的影响。每个图的x轴对应于与不使用Claude相比，Claude辅助任务类别的时间花费或产出量的自我报告减少（负值）、增加（正值）或无变化（垂直虚线）。误差棒显示95%置信区间。圆圈面积与每个评分点的响应数量成正比。仅包括报告使用Claude完成每个任务类别的受访者。
然而，当我们深入研究原始数据时，我们发现节省时间的响应集中在相反的两端——有些人在Claude辅助的任务上花费的时间明显更多。
为什么会这样？人们普遍解释说，他们必须对Claude的代码进行更多调试和清理（例如“当我自己把代码搞砸时”），并且由于不是自己编写的，理解Claude代码的认知负担更大。一些人提到在启用意义上花费更多时间在任务上——有人说使用Claude帮助他们“坚持以前会立即放弃的任务”；另一个人说它帮助他们进行更彻底的测试，以及在新代码库中进行更多学习和探索。似乎通常情况下，体验到时间节省的工程师可能是那些为Claude确定可快速验证任务范围的人，而花费更多时间的人可能是在调试AI生成的代码或在Claude需要更多指导的领域工作。
从我们的数据中也不清楚报告的时间节省被再投资到哪里——无论是额外的工程任务、非工程任务、与Claude交互或审查其输出，还是工作之外的活动。我们的任务分类框架并未捕捉工程师分配时间的所有方式。此外，时间节省可能反映了自我报告中的认知偏差。需要进一步研究来理清这些影响。
产出量的增加更为直接和显著；所有任务类别都有较大的净增加。当我们考虑到人们报告的是任务类别（如整体“调试”）而不是单个任务时，这种模式是有意义的——即人们可以在调试类别上花费略少的时间，同时总体上产生更多的调试输出。生产力很难直接衡量，但这种自我报告的数据表明，人工智能使Anthropic的生产力提高主要是通过增加产出量。
Claude促成新工作
我们好奇的一件事是：Claude是促成了质的新工作类型，还是Claude辅助的工作最终会由员工完成（尽管可能速度较慢）？
员工估计，27%的Claude辅助工作如果没有它就不会完成。工程师提到使用AI进行项目扩展、实用但烦琐的工作（如文档和测试）以及手动完成不符合成本效益的探索性工作。正如一个人解释的那样，他们现在可以修复更多以前损害生活质量的“小麻烦”，例如重构结构不良的代码，或构建“帮助更快完成另一项任务的小工具”。我们在使用数据分析中也发现了这一点，发现8.6%的Claude Code任务涉及“小麻烦修复”。
另一位研究人员解释说，他们同时运行了许多版本的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进行所有编码。”
一位工程师将信任的发展比作采用其他技术，如谷歌地图：
一开始我只会在不熟悉的路线上使用[谷歌地图]……这就像我使用Claude编写我不知道的SQL，但不会让它编写我知道的Python。然后我开始在我大致知道但可能不知道最后一公里的路线上使用谷歌地图……今天我一直使用谷歌地图，即使是日常通勤。如果它说要走不同的路，我会照做，只是相信它考虑了所有选择……我今天以类似的方式使用Claude Code。
工程师在是否在其专业知识范围内或之外使用Claude方面存在分歧。一些人将其用于“外围”领域以节省实施时间；另一些人更喜欢熟悉的领域，在那里他们可以验证输出（“我以这样一种方式使用Claude，我仍然完全理解它在做什么”）。一位安全工程师强调了经验的重要性，当时Claude提出了一个“以危险的方式非常聪明的解决方案，那种非常有才华的初级工程师可能会提出的方案”。也就是说，只有具有判断力和经验的用户才能认识到问题。
其他工程师将Claude用于这两种类型的任务，要么以实验方式（“我基本上总是让Claude首先尝试任何编码问题”），要么根据他们在任务中的专业水平调整方法：
我将这些工具用于两件事情：核心专业知识（作为加速器，我知道会发生什么，可以有效地指导代理），以及稍微超出我专业领域的事情，我大致知道会发生什么，但Claude能够填补我记忆或对特定定义熟悉度的空白。
如果是我特别精通的事情，我会更果断，告诉Claude需要追踪什么。如果是我不确定的事情，我经常请它作为专家，给我选择和我应该考虑和研究的事情的见解。
人们保留哪些任务给自己？
人们一致表示，他们不会将涉及高级或战略思维的任务，或需要组织背景或“品味”的设计决策交给Claude。一位工程师解释说：“我通常保留高级思维和设计。我从新功能开发到调试都尽可能委托。”这反映在我们的调查数据中，显示设计和规划任务的生产力提升最少（图2）。然而，许多人将委托边界描述为“移动目标”，随着模型的改进而定期重新谈判（下面的Claude Code使用数据显示，与六个月前相比，现在编码设计/规划的使用率相对更高）。
技能转变
新能力…
27%的Claude辅助工作不会完成的调查结果反映了一个更广泛的模式：工程师使用AI在其核心专业知识之外工作。许多员工报告完成了以前超出其专业知识范围的工作——后端工程师构建UI；研究人员创建可视化。一位后端工程师描述了通过与Claude迭代构建复杂UI：“它做得比我以往任何时候都好。我本来无法做到，绝对无法按时完成……[设计师]说’等等，这是你做的？‘我说’不，是Claude做的，我只是提示它’”
工程师报告“变得更加全栈……我可以非常熟练地从事前端、事务性数据库或API代码的工作，而以前我会害怕接触我不太擅长的东西。”这种能力扩展实现了更紧密的反馈循环和更快的学习——一位工程师说，构建、安排会议和迭代的“几周过程”可以变成同事在场进行实时反馈的“几个小时工作会议”。
总的来说，人们对他们快速原型制作、并行工作、减少辛劳以及总体上提高抱负水平的新能力感到热情。一位高级工程师告诉我们：“这些工具无疑使初级工程师更有生产力，对他们承担的项目类型更大胆。”一些人还表示，使用Claude降低了“启动能量”，使他们更容易克服拖延症，“大大降低了我开始解决问题所需的能量，因此我愿意解决更多的问题。”
…和更少的实践
与此同时，一些人担心“随着[他们]委托更多，技能会萎缩”，并失去手动解决问题过程中发生的附带（或“ collateral”）学习：
如果你自己去调试一个难题，你会花时间阅读与解决问题没有直接关系的文档和代码——但整个过程中你都在构建系统工作方式的模型。现在这种情况少了很多，因为Claude可以直接带你找到问题。
我曾经探索每个配置来了解工具的功能，但现在我依靠AI告诉我如何使用新工具，因此我缺乏专业知识。在与其他队友的对话中，我以前可以立即回忆起事情，而现在我必须问AI。
使用Claude有可能跳过通过解决简单实例来学习如何执行任务的部分，然后在以后难以解决更复杂的实例。
一位高级工程师表示，如果他们更年轻，他们会更担心自己的技能：
我主要在我知道答案应该是什么样子的情况下使用AI。我通过“艰难的方式”做SWE发展了这种能力……但如果我[在职业生涯早期]，我会认为需要很多刻意的努力来继续发展自己的能力，而不是盲目接受模型输出。
编码技能萎缩令人担忧的一个原因是“监督悖论”——如上所述，有效使用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征求意见”，类似于与人类协作者的互动。
大约一半的人报告团队协作模式没有变化。一位工程师说，他仍然与人会面，分享背景，选择方向，他认为在不久的将来仍然会有很多协作，但“ instead of doing your standard focus work, you’ll be talking to a lot of Claudes."
然而，其他人描述与同事的互动减少（“我与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的使用已转向更困难和自主的编码任务：
• 员工正在使用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，表明与六个月前相比，现在完成给定任务所需的人工输入更少。
2025年8月和2025年2月之间Claude Code使用的变化（x轴）。平均任务复杂性随时间增加（左面板），每个记录的平均最大连续工具调用随时间增加（中间面板），人工轮次数量随时间减少（右面板）。误差棒显示95%置信区间。数据表明，人们越来越多地将更多自主权委托给Claude。
这些使用数据证实了调查数据：工程师将越来越复杂的工作委托给Claude，而Claude需要的监督更少。这似乎可能是观察到的生产力提升的驱动因素。
任务分布
我们将Claude Code记录分类为一种或多种编码任务类型，研究过去六个月不同任务的用途如何演变：
各种编码任务（y轴）占总记录数（x轴）的百分比分布。
我们比较了六个月前（粉色）和现在（紫色）的分布。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轴），按编码任务（图例）着色。顶部条（“所有团队”）代表总体分布。
“所有团队”条显示总体分布，最常见的任务是构建新功能、调试和代码理解。这为团队特定比较提供了基线。
值得注意的团队特定模式：
预训练团队（帮助训练Claude的团队）经常使用Claude Code构建新功能（54.6%），其中大部分是运行额外实验。1.
对齐与安全团队和后训练团队使用Claude Code进行最多的前端开发（7.5%和7.4%），通常用于创建数据可视化。2.
安全团队经常使用Claude Code进行代码理解（48.9%），特别是分析和理解代码库不同部分的安全含义。3.
非技术员工经常使用Claude Code进行调试（51.5%），例如排除网络问题或Git操作，以及数据科学（12.7%）；Claude似乎对于弥合技术知识差距很有价值。4.
许多这些团队特定模式展示了我们在调查和访谈中观察到的相同能力扩展：使团队成员能够从事他们要么没有时间要么没有技能集去做的新工作类型。例如，预训练团队运行了许多额外实验，非技术员工能够修复代码中的错误。尽管数据表明团队确实将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次 outreach），最终64份回复的回复率为31%。我们采访了前53名回复者。这里可能存在一些选择偏差，因为特别参与Claude或有强烈意见（正面或负面）的人可能更有可能回复，而那些经验更中性的人可能代表性不足。
此外，回复可能受到社会期望偏差的影响（由于回复不是匿名的，所有参与者都是Anthropic员工，受访者可能夸大了对Claude影响的正面评估）和近因偏差（要求参与者回忆12个月前的生产力和使用模式容易受到记忆扭曲的影响）。此外，如前所述，生产力总体上很难估计，因此这些自我报告应持保留态度。这些自我报告的看法应与我们更客观的Claude Code使用数据一起解释，未来的研究将受益于匿名数据收集和更 robust 验证的测量工具。
我们的Claude Code分析在不同时间段使用比例抽样，这意味着我们只能测量任务分布的相对变化，而不是工作量的绝对变化。例如，当我们报告功能实现从Claude Code使用的14%增加到37%时，这并不一定表明正在完成更多的功能工作。
最后，这项研究是在2025年8月进行的，当时Claude Sonnet 4和Claude Opus 4是我们最先进的模型。鉴于AI发展的快速步伐，我们观察到的模式可能已经随着更新模型的出现而发生变化。