AI如何改变Anthropic的工作

AI 正在如何改变我们的工作方式?我们在之前的研究中探讨了 AI 的经济影响,当时着眼于整体劳动力市场,涵盖了各种不同的工作岗位。但是,如果我们更深入地研究一些 AI 技术最早期的采用者——也就是我们自己,会发现什么呢?

AI如何改变Anthropic的工作

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 的使用率和生产力增益均在增加。 员工自述在 60% 的工作中使用 Claude,并实现了 50% 的生产力提升,这比去年同期增加了 2-3 倍。这种生产力的提升表现为每个任务类别花费的时间略有减少,但产出量却大幅增加(图 2)。
  3. 27% 的 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 任务涉及修复那些能改善工作体验的小问题,比如为了可维护性重构代码(即“修复细微瑕疵”),人们表示这些任务通常会被降低优先级。这些小的修复加起来可以带来更大的生产力和效率提升。
  3. 每个人都变得更加“全栈”。 不同的团队以不同的方式使用 Claude,通常是为了增强他们的核心专长——安全团队用它来分析不熟悉的代码,对齐与安全团队用它来构建数据的可视化前端,等等(图 5)。

调查数据

我们调查了来自整个组织的 132 名 Anthropic 工程师和研究人员,了解他们的 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 互动或审查其输出,还是工作以外的活动。我们的任务分类框架并没有捕捉到工程师分配时间的所有方式。此外,节省的时间可能反映了自述中的感知偏差。需要进一步的研究来理清这些影响。

产出量的增加则更加直接和显著;所有任务类别的净增加量都更大。当我们考虑到人们是针对任务类别(如整体上的“调试”)而不是单个任务进行报告时,这种模式是有道理的——即人们可以在调试作为一个类别上花费稍少的时间,同时总体上产生多得多的调试产出。生产力很难直接衡量,但这些自述数据表明,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。人们通常委托以下类型的任务:

超出用户语境且低复杂度:
“我会在我语境缺失但认为整体复杂度也较低的事情上使用 Claude。”

“我遇到的大多数基础设施问题并不难,Claude 可以处理……我不太懂 Git 或 Linux……Claude 在弥补我在这些领域的经验不足方面做得很好。”

易于验证:
“对于所有验证工作量相对于创作工作量较小的事情,它绝对是太棒了。”

定义明确或自成一体:
“如果项目的某个子组件与其余部分充分解耦,我会让 Claude 试一试。”

代码质量不关键:
“如果是一次性的调试或研究代码,就直接交给 Claude。如果是概念上困难的,或者需要某种非常特定的调试注入,或者是设计问题,我就自己做。”

重复或无聊:
“我对任务越兴奋,我就越不可能使用 Claude。反之,如果我感到很大的阻力……我通常发现就这个任务与 Claude 展开对话会更容易。”

在我们的调查中,平均而言,人们表示 44% 的 Claude 辅助工作包含他们自己不喜欢做的任务。

提示比执行更快:
“[对于]我预计只需不到 10 分钟就能完成的任务……我可能不会费心使用 Claude。”

“冷启动问题可能是目前最大的阻碍。所谓冷启动,是指我有大量关于我的团队代码库如何工作的内在信息,而 Claude 默认是没有的……我可以花时间尝试迭代出完美的提示,[但]我就直接自己去做了。”
图 3:2025 年 8 月至 2025 年 2 月 Claude Code 使用情况的变化(x 轴)。平均任务复杂度随时间增加(左图),每个脚本的平均最大连续工具调用次数随时间增加(中图),人类轮次数量随时间减少(右图)。误差条显示 95% 置信区间。数据表明,随着时间的推移,人们越来越多地将自主权委托给 Claude。

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

任务分布

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

图 4:各种编程任务(y 轴)占总记录数的百分比分布。我们将 6 个月前(粉色)的分布与目前(紫色)进行比较。y 轴按 2025 年 2 月的频率排序。

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

修复细微瑕疵 (Fixing Papercuts)

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

跨团队的任务差异

为了研究当前各团队的任务差异,我们改进了分类方法,将 8 月份的每份对话记录分配给一个主要的编程任务,并按内部团队(y 轴)划分数据。堆叠条形图显示了每个团队的编程任务明细:

图 5:每个水平条代表一个团队(y 轴),其中的区段显示了该团队 Claude Code 用于不同编程任务(x 轴)的比例,按编程任务颜色编码(图例)。顶部的条形(“All Teams”)代表整体分布。

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

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

  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. 非技术 (Non-technical) 员工经常使用 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, 和 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 发展的快速步伐,随着更新的模型变得可用,我们观察到的模式可能已经发生了变化。

原文:https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic