AI中国网 https://www.cnaiplus.com
导读：日前，Anthropic 基于对自己公司的工程师和研究人员的调研，生成了一份 AI 对工程师工作方式影响的报告。报告显示， AI 正在彻底改变程序员的工作方式，让大家效率翻倍，但也带来了新的焦虑和挑战。正向影响是1、效率暴增：Anthropic的工程师使用AI后，生产力平均提升50%，近六成工作都靠AI帮忙2、能力变广：工程师能轻松搞定不擅长的领域（如后端工程师做前端），成了"全能 ......日前，Anthropic 基于对自己公司的工程师和研究人员的调研，生成了一份 AI 对工程师工作方式影响的报告。
报告显示， AI 正在彻底改变程序员的工作方式，让大家效率翻倍，但也带来了新的焦虑和挑战。正向影响是1、效率暴增：Anthropic的工程师使用AI后，生产力平均提升50%，近六成工作都靠AI帮忙2、能力变广：工程师能轻松搞定不擅长的领域（如后端工程师做前端），成了"全能选手"3、质量提高：以前懒得修的小毛病、没时间做的工具，现在都能快速完成。
但也存在一些担忧：1、技能退化：长期依赖AI，自己写代码、Debug的真功夫可能生锈2、人情变淡：有问题先问AI，同事间交流变少， mentorship（师徒指导）也受影响3、前途迷茫：有人担心自己正在"培训替代自己的AI"，长期看工作可能被AI完全接手
报告认为，AI不是简单替代工程师，而是会把他们变成"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数据的主要发现。我们在以下各节中提供了详细的发现、方法和注意事项。
调查数据 Anthropic工程师和研究人员最常使用Claude修复代码错误和学习代码库。 调试和理解代码是最常见的用途（图1）。
人们报告Claude使用量增加和生产力提升。 员工自我报告在60%的工作中使用Claude，并获得50%的生产力提升，比去年这个时候增长了2-3倍。生产力的提升表现为每个任务类别花费的时间略有减少，但产出量显著增加（图2）。
27%的Claude辅助工作属于原本不会完成的任务，例如扩展项目、制作"锦上添花"的工具（如交互式数据仪表板），以及手动完成不具成本效益的探索性工作。
大多数员工频繁使用Claude，同时报告可以"完全委托"0-20%的工作给它。 Claude是一个持续的协作者，但使用它通常需要积极的监督和验证，特别是在高风险工作中而不是完全无需验证地移交任务。
定性访谈 员工正在形成AI委托的直觉。 工程师倾向于委托那些容易验证的任务，"可以相对轻松地快速检查正确性"的任务、低风险的（如"一次性调试或研究代码"）或无聊的任务（"我对任务越感兴趣，就越不可能使用Claude"）。
许多人描述了信任递进的过程，从简单任务开始，逐渐委托更复杂的工作虽然目前他们仍然保留大多数设计或"品味"类任务，但随着模型改进，这个边界正在被重新协商。
技能组合正在向更多领域扩展，但一些人实践减少。 Claude使人们能够将技能扩展到更多软件工程领域（"我可以非常有能力地处理前端、事务数据库……以前我都不敢碰这些东西"），但一些员工也矛盾地担心，编写和审查代码所需的深层技能会萎缩"当产出变得如此容易和快速，越来越难真正花时间去学习一些东西。"
与编程工艺的关系正在改变。 一些工程师拥抱AI辅助并专注于结果（"我曾以为我真的很喜欢写代码，现在发现我其实只是喜欢写代码带来的成果"）；另一些则表示"写代码的某些部分我确实会想念。"
工作场所社交动态可能正在改变。 Claude现在成了过去会去找同事提问时的首选一些人因此报告指导和协作机会减少。（"我喜欢与人一起工作，现在我'不那么需要'他们了，这很令人难过……初级员工不再经常带着问题来找我了。"） 职业演变与不确定性。 工程师报告转向管理AI系统的更高级别工作，并报告生产力显著提升。
然而，这些变化也引发了关于软件工程职业长期轨迹的问题。一些人对未来感到矛盾："短期内我感到乐观，但长期看我认为AI最终会做所有事情，让我和许多其他人变得无关紧要。"其他人强调真正的不确定性，只说"很难预测"几年后他们的角色会是什么样子。
Claude Code使用趋势 Claude正在以更自主的方式处理越来越复杂的任务。
六个月前，Claude Code在需要人工输入前大约能完成10个操作。现在通常能处理约20个操作，需要的人工引导更少，就能完成更复杂的工作流（图3）。工程师越来越多地将Claude用于复杂任务，如代码设计/规划（从1%增加到10%的使用量）和实现新功能（从14%增加到37%）（图4）。
Claude修复了很多"小麻烦"。 8.6%的Claude Code任务涉及修复改善生活质量的小问题，如重构代码以提高可维护性（即"修复小麻烦"），人们说这些通常会被降级处理。这些小改进可能累积成更大的生产力和效率提升。
每个人都变得更"全栈"。 不同团队以不同方式使用Claude，通常是为了增强他们的核心专长安全团队用它分析不熟悉的代码，对齐与安全团队用它构建数据的前端可视化等（图5）。调查数据我们调查了来自全组织的132名Anthropic工程师和研究人员关于他们使用Claude的情况，以更好地了解他们日常究竟如何使用它。我们通过内部沟通渠道和直接联系，向代表研究和产品职能的多元化团队中的员工分发调查。
我们在附录中包含了局限性部分，提供了更多方法论细节，并分享我们的调查问题，以便他人可以评估我们的方法并用于自己的研究。
人们使用Claude进行哪些编码任务？我们要求受访工程师和研究人员评估他们使用Claude进行各类编码任务的频率，例如"调试"（使用Claude帮助修复代码中的错误）、"代码理解"（让Claude解释现有代码以帮助用户理解代码库）、"重构"（使用Claude帮助重构现有代码）和"数据科学"（例如让Claude分析数据集并制作条形图）。
以下是最常见的日常任务。大多数员工（55%）每天使用Claude进行调试。42%每天使用Claude理解代码，37%每天使用Claude实现新功能。频率较低的任务是高层设计/规划（可能是因为这些是人们倾向于保留在人手中的任务），以及数据科学和前端开发（可能是因为总体上传得较少）。这与"Claude Code使用趋势"部分报告的使用数据分布大致相符。
图一（x轴：日常用户比例；y轴：各种编码任务）
使用情况和生产力员工自我报告12个月前，他们在28%的日常工作中使用Claude，并从中获得+20%的生产力提升。而现在，他们在59%的工作中使用Claude，平均实现+50%的生产力提升。（这大致证实了我们在整个工程部门采用Claude Code时看到的每个工程师每天合并拉取请求（即成功合并代码更改）数量增加67%的情况。）
同比比较相当显著这表明两项指标在一年内增长了两倍多。使用量和生产力也高度相关，在分布的极端端，14%的受访者通过使用Claude将生产力提升了100%以上这些是我们内部的"超级用户"。
需要为这一发现（以及下文其他自我报告的生产力发现）补充说明的是，生产力很难精确衡量（更多局限性见附录）。来自AI研究非营利组织METR的近期研究表明，在高度熟悉的代码库上与AI合作的资深开发者高估了AI带来的生产力提升。话虽如此，METR确定的导致生产力低于预期的因素（例如AI在大型复杂环境中表现较差，或需要大量隐性知识/上下文）与我们的员工表示不会委托给Claude的任务类型（见下文AI委托方法）高度吻合。
我们的生产力提升数据（跨任务自我报告）可能反映了员工正在发展战略性AI委托技能这是METR研究中未考虑的因素。
当我们询问员工在目前的Claude使用类别中，它如何影响他们在该任务类别中花费的总时间和工作量时，出现了一个有趣的生产力模式。几乎所有任务类别中，我们看到净耗时减少，而产出量的净增长更大：
按任务（y轴）划分的耗时影响（左图）和产出量影响（右图）。每个图的x轴对应于与不使用Claude相比，在Claude辅助任务类别中自我报告的耗时或产出量的减少（负值）、增加（正值）或无变化（垂直虚线）。误差条显示95%置信区间。圆圈面积与每个评分点的响应数量成正比。仅包括报告在每项任务类别中使用Claude的受访者。
然而，当我们深入原始数据时，我们发现节省时间的响应集中在两端一些人在Claude辅助的任务上花费的时间显著增加。
为什么会这样？人们普遍解释说，他们不得不做更多调试和清理Claude代码的工作（例如"当我自己用氛围编码陷入困境时"），并承担更多理解Claude代码的认知开销，因为他们自己没有编写这些代码。
一些人提到在赋能意义上花费更多时间有人说使用Claude帮助他们"坚持处理以前会立即放弃的任务"；另一个人说，它帮助他们在新代码库中进行更彻底的测试以及更多的学习和探索。
似乎总体而言，体验到时间节省的工程师可能是那些为Claude快速设定可验证任务的人，而花费更多时间的人可能是在调试AI生成的代码或在Claude需要更多指导的领域工作。
从我们的数据中也不清楚，报告的时间节省被重新投资到了哪里是投入到额外的工程任务、非工程任务、与Claude互动或审查其输出，还是工作之外的活动。我们的任务分类框架未能涵盖工程师分配时间的所有方式。此外，节省时间可能反映了自我报告中的感知偏差。需要进一步研究来厘清这些影响。
产出量的增加更直接且更显著；所有任务类别都有更大的净增长。当我们考虑到人们报告的是任务类别（如"调试"整体）而非单个任务时，这种模式是合理的即人们可以在调试这一类别上花费略少的时间，同时总体产生更多的调试产出。生产力很难直接衡量，但这些自我报告的数据表明，AI主要通过更大的产出量提高了Anthropic的生产力。
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默认情况下不会拥有这些信息……我可以花时间迭代完美的提示[但]我还是会自己去做。"
员工在委托决策中提到的这些因素与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降低了"启动能量"，使他们更容易克服拖延，"极大地减少了我想要开始解决问题的能量需求，因此我愿意解决更多额外的事情。"
……以及更少的实践与此同时，一些人担心"随着委托更多，技能会萎缩"，并在手动问题解决过程中失去偶然（或"附带"）的学习：
如果你自己去调试一个难题，你会花时间阅读与你解决问题不直接相关的文档和代码但整个过程中你都在建立系统如何运作的模型。这种情况现在少多了，因为Claude可以直接帮你找到问题。
我以前会探索每个配置以了解工具能做什么，但现在我依赖AI告诉我如何使用新工具，所以我缺乏专业知识。在与队友交谈时，以前我能瞬间回忆事情，现在则必须问AI。
使用Claude可能会跳过通过解决简单实例来学习如何执行任务的部分，然后之后难以解决更复杂的实例。
一位高级工程师表示，如果他们更初级，他们会更担心自己的技能：
我主要在那些我知道答案应该是什么或应该是什么样子的案例中使用AI。我通过以"困难方式"做软件工程开发了这种能力……但如果我[处于职业生涯早期]，我会认为需要付出大量刻意努力才能继续提升自己的能力，而不是盲目接受模型输出。
编码技能萎缩令人担忧的一个原因是上文提到的"监督悖论"有效使用Claude需要监督，而监督Claude需要的可能正是因过度使用AI而萎缩的编码技能。
一个人说：老实说，我比起担心我自己的技能组合，更担心监督和监督问题……我的技能萎缩或未能发展，主要会在我安全使用AI处理我关心的任务的能力方面造成问题，而不是在我独立执行这些任务的能力方面。
为了应对这一点，一些工程师刻意在没有AI的情况下练习："每隔一段时间，即使我知道Claude能完美解决问题，我也不会要求它这样做。这帮助我保持敏锐。"
我们是否仍然需要那些实践编码技能？也许软件工程正在向更高层次的抽象发展，就像过去一样。早期程序员更接近机器手动管理内存、用汇编语言编写，甚至拨动物理开关输入指令。
随着时间的推移，出现了更高级、更易读的语言来自动处理复杂的底层操作。也许，特别是随着"氛围编码"的兴起，我们现在正在将英语作为一种编程语言。
我们的一位员工建议，有抱负的工程师应该"擅长让AI[写代码]，并专注于学习更高层次的概念和模式"。
一些员工表示，这种转变让他们能够更高层次地思考"关注最终产品和最终用户"而不仅仅是代码。一个人通过对比之前学习计算机科学中的链表（现在高级编程语言自动处理的基本结构）来描述当前的转变。
"我很高兴我知道怎么做那个……[但]执行那些底层操作在情感上并不是特别重要。我更关心代码能让我做什么。"另一位工程师做了类似的比较，但指出抽象是有代价的随着转向高级语言，大多数工程师失去了对内存处理的深入理解。
继续在某个领域发展技能可以带来更好的Claude监督和更高效的工作（"我注意到当是我熟悉的事情时，我自己做往往更快"）。但工程师们对此是否重要存在分歧。
一些人保持乐观：我不太担心技能退化。AI仍然让我仔细思考问题，并帮助我学习新方法。如果有的话，能够更快地探索和测试想法在一些领域加速了我的学习。
另一位更务实："我作为软件工程师的技能肯定在萎缩……但如果需要，这些技能可以恢复，而且我不再需要它们了！"一位指出他们只失去了不太重要的技能，如制作图表，"而关键的那种代码我仍然能写得很好。"
也许最有趣的是，一位工程师质疑了这个前提："‘变得生疏’的框架依赖于一个假设，即编码总有一天会回到Claude 3.5之前的方式。而我认为不会。"
软件工程的工艺与意义
工程师们对于是否想念实践编码存在尖锐分歧。一些人感到真正的失落"这对我来说是一个时代的结束我已经编程25年了，在这个技能组合上感到胜任是我职业满意度的核心部分。"
另一些人则担心不喜欢新工作性质："整天提示Claude不是很有趣或充实。戴上音乐，进入状态，自己实现一些东西要有趣和充实得多。"
一些人直接面对这种权衡并接受它："写代码的某些部分我肯定会想念重构代码时进入禅意流状态，但总体上我现在生产力高得多，我很乐意放弃那个。"
一个人说，与Claude迭代更有趣，因为他们可以比对人更挑剔地提出反馈。另一些人更关注结果。
一位工程师说：我曾预计到这个阶段会感到害怕或无聊……然而我实际上没有感到这些。相反，我对能做更多事情感到非常兴奋。我曾以为我真的很喜欢写代码，现在发现我其实只是喜欢写代码带来的成果。
人们是否拥抱AI辅助或悲叹失去实践编码，似乎取决于他们觉得软件工程的哪些方面最有意义。
工作场所社交动态的变化一个更突出的主题是，Claude已成为过去会去找同事提问的首选。"我现在总体上问的问题多得多，但大约80-90%都问Claude了，"一位员工指出。这创造了一种过滤机制，Claude处理常规查询，留下同事处理更复杂、战略性或需要上下文的超出AI能力的问题（"它使我对[我的团队]的依赖减少了80%，[但]最后的20%至关重要，我会去找他们谈"）。人们也会"与Claude讨论想法"，类似于与人工协作者的互动。
约一半的人报告团队协作模式没有变化。一位工程师说他仍然与人会面、分享上下文、选择方向，并认为在不久的将来仍会有很多协作，但"你不会再做标准的专注工作，而是会与很多Claude对话。"
然而，其他人描述与同事互动减少（"我与Claude协作远多于与任何同事协作。"）一些人欣赏减少的社交摩擦（"我不再为占用同事时间感到难过"）。
另一些人抵制这种变化（"我不太喜欢常见的回应是‘你问过Claude了吗？’我真的很喜欢面对面与人合作，非常珍视这一点"）或想念旧的工作方式："我喜欢与人一起工作，现在我‘不那么需要’他们了，这很令人难过。"几个人指出了对传统指导动态的影响，因为"Claude可以为初级员工提供大量辅导"，而不是高级工程师。
一位高级工程师说：更初级的人不再经常带着问题来找我，这很令人难过，尽管他们的问题肯定得到了更有效的解答，学得也更快。
职业不确定性与适应许多工程师描述他们的角色从写代码转变为管理AI。工程师越来越多地将自己视为"AI智能体的管理者"一些人已经" constantly至少有几个[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月Claude Code使用的变化（x轴）。平均任务复杂度随时间增加（左图），每段对话的平均最大连续工具调用次数随时间增加（中图），人工干预次数随时间减少（右图）。误差条显示95%置信区间。数据表明人们正越来越多地将更多自主权委托给Claude。
这些使用数据证实了调查数据：工程师将越来越复杂的工作委托给Claude，而Claude需要的监督更少。这似乎可能推动了观察到的生产力提升。
任务分布我们将Claude Code对话记录分类为一种或多种编码任务类型，研究了不同任务用途在过去六个月中的演变：
图4. 各种编码任务（y轴）占总体记录数量百分比（x轴）的分布。我们比较了6个月前（粉色）和现在的分布（紫色）。y轴按2025年2月的频率排序。
从使用数据估算的总体任务频率分布大致与自我报告的任务频率分布一致。
025年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%），其中很多是运行额外实验。
对齐与安全团队和后训练团队使用Claude Code进行最多的前端开发（分别为7.5%和7.4%），通常用于创建数据可视化。
安全团队最常使用Claude Code理解代码（48.9%），特别是分析代码库不同部分的安全影响。
非技术人员最常使用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如何改变工作，还要实验如何深思熟虑地驾驭这种转型，从我们自己开始。
AI中国网 https://www.cnaiplus.com
本文网址：
