AI如何改变Anthropic的工作方式

AI如何改变Anthropic的工作方式 AI如何改变Anthropic的工作方式 Modified December 5, 2025 工程师们表示“变得更像全栈工程师了……我现在能够游刃有余地处理前端、事务性数据库或 API 代码，而在以前，我会害怕去碰那些自己不太擅长的东西”。这种能力的拓展实现了更紧密的反馈循环和更快的学习速度——一位工程师说，以前那种需要花费“几周时间”来进行构建、安排会议和迭代的过程，现在有同事现场提供实时反馈，就可以变成“几个小时的工作会议”。 总体而言，人们对自己新获得的快速制作原型、并行开展工作、减少辛劳并普遍提升抱负水平的能力感到兴奋。一位资深工程师告诉我们：“这些工具无疑让初级工程师更有成效，在接手项目类型上也更大胆。”一些人还表示，使用Claude降低了“启动能量”，使他们更容易克服拖延，“极大地减少了我想要开始解决问题所需的精力，因此我愿意处理更多额外的事情”。 …以及较少的实践操作 与此同时，一些人担心“随着[他们]更多地委派任务，技能会退化”，并失去在手动解决问题过程中产生的附带（或“间接”）学习机会： 如果你亲自去调试一个棘手的问题，你会花时间阅读那些对解决问题并非直接有用的文档和代码——但在这整个过程中，你正在构建一个关于系统如何运作的模型。而有了Claude，这种情况就少多了，因为它能让你立刻找到问题所在。 我过去常常探索每一个配置，以了解工具的功能，但现在我依赖AI来告诉我如何使用新工具，因此我缺乏专业知识。过去与其他队友交谈时，我能立即回忆起相关内容，而现在我不得不向AI询问。 使用Claude有可能跳过这样一个过程：我先通过解决一个简单的实例来学习如何执行一项任务，然后再费力地解决一个更复杂的实例。 一位资深工程师表示，如果他们资历更浅，就会更担心自己的技能： 我主要在知道答案应该是什么或应该是什么样子的情况下使用AI。我通过 “艰难的方式” 从事SWE工作培养了这种能力……但如果我处于[职业生涯早期]，我会认为要继续提升自己的能力，需要付出很多刻意的努力，而不是盲目接受模型的输出。 编码技能萎缩令人担忧的一个原因是“监督悖论”——如上文所述，有效使用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征求意见”。 约一半的人表示团队协作模式没有变化。一位工程师说，他仍在与人会面、分享信息和选择方向，他认为在不久的将来仍会有大量的协作，但“你不会再做常规的专注工作，而是会与很多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的20万份内部记录。 在较少监督的情况下处理更难的问题 在过去六个月里，Claude Code的使用已转向更具挑战性和自主性的编码任务（图3）： 1. 员工们正使用Claude Code处理日益复杂的任务。我们将每个记录的任务复杂度按1 5的等级进行评估，其中1对应“基本编辑”，5对应“需要人类专家数周/数月工作的专家级任务”。任务复杂度平均从3.2上升到3.8。为说明分数之间的差异：平均3.2的任务包括“排查Python模块导入错误”，而平均3.8的任务包括“实施并优化缓存系统”。 2. Claude Code每个对话记录中连续调用工具的最大次数增加了116%。工具调用对应Claude使用外部工具执行的操作，如编辑文件或运行命令。Claude现在可以连续进行21.2次独立的工具调用而无需人工干预，而六个月前这一数字为9.8次。 3. 人工对话轮数减少了33%。每篇记录的平均人工对话轮数从6.2轮降至4.1轮，这表明与六个月前相比，现在完成一项既定任务所需的人工投入更少。 图3. 2025年8月至2025年2月（x轴）期间Claude Code使用情况的变化。平均任务复杂度随时间增加（左图），每个对话记录的平均最大连续工具调用次数随时间增加（中图），人类对话轮次数量随时间减少（右图）。误差线显示95%置信区间。数据表明，随着时间的推移，人们越来越多地将更多自主权委托给Claude。 这些使用数据证实了调查数据：工程师们将越来越复杂的工作委派给Claude，而Claude所需的监督也越来越少。似乎有理由认为，这推动了所观察到的生产力提升。 任务分配 我们将Claude Code的记录分类为一种或多种类型的编码任务，研究不同任务的用途在过去六个月中是如何演变的： 图4. 各项编码任务（y轴）占总记录数（x轴）的百分比分布。我们将6个月前（粉色）的分布与当前（紫色）进行比较。y轴按2025年2月的频率排序。 根据使用数据估算的总体任务频率分布与自我报告的任务频率分布大致相符。2025年2月至8月间最显著的变化是，使用Claude来实现新功能（从14.3%增至36.9%）和进行代码设计或规划（从1.0%增至9.9%）的转录内容在比例上大幅增加。Claude Code任务相对分布的这种变化可能表明Claude在处理这些更复杂的任务方面表现更好，不过这也可能反映出团队在不同工作流程中采用Claude Code的方式发生了变化，而不是绝对工作量的增加（更多限制请见附录）。 修复小问题 我们从调查中发现，工程师现在花更多时间进行小型的生活质量改善；与此相符的是，当前Claude Code任务中有8.6%被归类为“小问题修复”。这些任务既包括创建性能可视化工具和重构代码以提高可维护性等较大的任务，也包括创建终端快捷方式等较小的任务。这可能有助于工程师提高生产力（解决之前被忽视的生活质量改善问题可能会随着时间的推移提高效率），并有可能减少日常工作中的摩擦和挫折感。 各团队之间的任务差异 为研究当前各团队的任务差异，我们优化了分类方法，将每个8月的记录分配给单一的主要编码任务，并按内部团队（y轴）对数据进行拆分。堆叠条形图展示了每个团队编码任务的细分情况： 工程师们表示“变得更像全栈工程师了……我现在能够游刃有余地处理前端、事务性数据库或 API 代码，而在以前，我会害怕去碰那些自己不太擅长的东西”。这种能力的拓展实现了更紧密的反馈循环和更快的学习速度——一位工程师说，以前那种需要花费“几周时间”来进行构建、安排会议和迭代的过程，现在有同事现场提供实时反馈，就可以变成“几个小时的工作会议”。 总体而言，人们对自己新获得的快速制作原型、并行开展工作、减少辛劳并普遍提升抱负水平的能力感到兴奋。一位资深工程师告诉我们：“这些工具无疑让初级工程师更有成效，在接手项目类型上也更大胆。”一些人还表示，使用Claude降低了“启动能量”，使他们更容易克服拖延，“极大地减少了我想要开始解决问题所需的精力，因此我愿意处理更多额外的事情”。 …以及较少的实践操作 与此同时，一些人担心“随着[他们]更多地委派任务，技能会退化”，并失去在手动解决问题过程中产生的附带（或“间接”）学习机会： 如果你亲自去调试一个棘手的问题，你会花时间阅读那些对解决问题并非直接有用的文档和代码——但在这整个过程中，你正在构建一个关于系统如何运作的模型。而有了Claude，这种情况就少多了，因为它能让你立刻找到问题所在。 我过去常常探索每一个配置，以了解工具的功能，但现在我依赖AI来告诉我如何使用新工具，因此我缺乏专业知识。过去与其他队友交谈时，我能立即回忆起相关内容，而现在我不得不向AI询问。 使用Claude有可能跳过这样一个过程：我先通过解决一个简单的实例来学习如何执行一项任务，然后再费力地解决一个更复杂的实例。 如果你亲自去调试一个棘手的问题，你会花时间阅读那些对解决问题并非直接有用的文档和代码——但在这整个过程中，你正在构建一个关于系统如何运作的模型。而有了Claude，这种情况就少多了，因为它能让你立刻找到问题所在。 我过去常常探索每一个配置，以了解工具的功能，但现在我依赖AI来告诉我如何使用新工具，因此我缺乏专业知识。过去与其他队友交谈时，我能立即回忆起相关内容，而现在我不得不向AI询问。 使用Claude有可能跳过这样一个过程：我先通过解决一个简单的实例来学习如何执行一项任务，然后再费力地解决一个更复杂的实例。 一位资深工程师表示，如果他们资历更浅，就会更担心自己的技能： 我主要在知道答案应该是什么或应该是什么样子的情况下使用AI。我通过 “艰难的方式” 从事SWE工作培养了这种能力……但如果我处于[职业生涯早期]，我会认为要继续提升自己的能力，需要付出很多刻意的努力，而不是盲目接受模型的输出。 我主要在知道答案应该是什么或应该是什么样子的情况下使用AI。我通过 “艰难的方式” 从事SWE工作培养了这种能力……但如果我处于[职业生涯早期]，我会认为要继续提升自己的能力，需要付出很多刻意的努力，而不是盲目接受模型的输出。 编码技能萎缩令人担忧的一个原因是“监督悖论”——如上文所述，有效使用Claude需要监督，而监督Claude又恰恰需要那些可能因过度使用AI而萎缩的编码技能。有个人说： 老实说，比起我具体的技能组合，我更担心监督和监管问题……我的技能萎缩或无法发展，主要会对我安全使用AI完成我关心的任务的能力产生问题，而不是对我独立完成这些任务的能力产生问题。 老实说，比起我具体的技能组合，我更担心监督和监管问题……我的技能萎缩或无法发展，主要会对我安全使用AI完成我关心的任务的能力产生问题，而不是对我独立完成这些任务的能力产生问题。 为了应对这一问题，一些工程师会刻意在不借助AI的情况下进行实践：“即便我知道Claude能解决某个问题，我也会时不时地选择不向它求助。这有助于我保持敏锐。” 我们还需要那些实际操作的编码技能吗？ 或许软件工程正朝着更高的抽象层次发展，就像过去那样。早期的程序员与机器的距离更近——手动管理内存、用汇编语言编写代码，甚至通过拨动物理开关来输入指令。随着时间的推移，更高级、更易读的语言应运而生，它们能自动处理复杂的底层操作。或许，特别是随着“氛围编码”的兴起，我们现在正朝着将英语作为编程语言的方向发展。我们的一位员工建议有抱负的工程师“擅长让AI[编写代码]，并专注于学习更高级的概念和模式”。 一些员工表示，他们觉得这种转变使他们能够进行更高层次的思考——“思考最终产品和最终用户”，而不仅仅是代码。有一人将当前的转变比作以前在计算机科学中必须学习链表——这是现在高级编程语言会自动处理的基本结构。“我很高兴我知道如何做这些……[但]从情感上来说，进行那些底层操作并不是特别重要。我更愿意关注代码能让我做什么。”另一位工程师也做了类似的比较，但指出抽象是有代价的——随着向高级语言的转变，大多数工程师失去了对内存处理的深入理解。 持续提升某一领域的技能，有助于更好地监督Claude并提高工作效率（“我注意到，当涉及我熟悉的内容时，往往我自己做会更快”）。但工程师们对于这一点是否重要存在分歧。一些人仍然持乐观态度： 我不太担心技能退化的问题。AI 仍然促使我认真思考问题，并帮助我学习新的方法。如果说有什么不同的话，能够更快地探索和测试想法在某些领域加速了我的学习。 我不太担心技能退化的问题。AI 仍然促使我认真思考问题，并帮助我学习新的方法。如果说有什么不同的话，能够更快地探索和测试想法在某些领域加速了我的学习。 另一位则更为务实：“我作为软件工程师的技能肯定在退化……但如果有需要，这些技能还能恢复，而我只是不再需要它们了！”有一位指出，他们只是失去了一些不太重要的技能，比如制作图表，“而那些关键的代码我仍然能写得很好”。 或许最有意思的是，一位工程师对这一前提提出了质疑：“‘生锈’这一说法的框架依赖于这样一种假设，即编码有朝一日会回到Claude 3.5之前的状态。而我认为不会。” 软件工程的技艺与意义 工程师们在是否怀念亲自动手编码这一问题上存在严重分歧。一些人真切地感到失落——“对我来说，这是一个时代的终结——我已经编程25年了，对自己的技能感到胜任是我职业满足感的核心部分。”另一些人则担心无法享受工作的新性质：“整天给Claude提要求并不有趣或有成就感。放点音乐，进入状态，自己动手实现一些东西要有趣和有成就感得多。” 一些人直接谈到了这种权衡并接受了它：“[编写代码]中肯定有一些我怀念的部分——在重构代码时进入一种心流状态，但总体而言，我现在的工作效率提高了很多，所以我很乐意放弃这些。” 有一人表示，与Claude迭代更有趣，因为他们在反馈时可以比跟人类交流时更挑剔。其他人则对结果更感兴趣。一位工程师说： 我原以为到这个阶段，我会感到害怕或无聊……然而，我并没有真正感受到这两种情绪。相反，我感到非常兴奋，因为我能做的事情多了很多。我原以为自己真的喜欢写代码，实际上我只是喜欢写代码所带来的收获。 我原以为到这个阶段，我会感到害怕或无聊……然而，我并没有真正感受到这两种情绪。相反，我感到非常兴奋，因为我能做的事情多了很多。我原以为自己真的喜欢写代码，实际上我只是喜欢写代码所带来的收获。 人们是欣然接受AI辅助，还是为亲手编码的消逝而惋惜，似乎取决于他们认为软件工程的哪些方面最有意义。 职场中不断变化的社会动态 其中一个比较突出的主题是，Claude已经成为曾经向同事请教的问题的首选去处。“我现在总体上问的问题更多了，但其中大约80 90%都会问Claude，”一名员工指出。这就形成了一种过滤机制，Claude处理日常询问，让同事们去解决那些超出AI能力范围的更复杂、更具战略性或需要更多背景信息的问题（“它让我对[团队]的依赖减少了80%，[但]最后的20%至关重要，我会去找他们交流”）。人们还会像与人类合作者互动一样，“向Claude征求意见”。 约一半的人表示团队协作模式没有变化。一位工程师说，他仍在与人会面、分享信息和选择方向，他认为在不久的将来仍会有大量的协作，但“你不会再做常规的专注工作，而是会与很多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的20万份内部记录。 在较少监督的情况下处理更难的问题 在过去六个月里，Claude Code的使用已转向更具挑战性和自主性的编码任务（图3）： 1. 员工们正使用Claude Code处理日益复杂的任务。我们将每个记录的任务复杂度按1 5的等级进行评估，其中1对应“基本编辑”，5对应“需要人类专家数周/数月工作的专家级任务”。任务复杂度平均从3.2上升到3.8。为说明分数之间的差异：平均3.2的任务包括“排查Python模块导入错误”，而平均3.8的任务包括“实施并优化缓存系统”。 2. Claude Code每个对话记录中连续调用工具的最大次数增加了116%。工具调用对应Claude使用外部工具执行的操作，如编辑文件或运行命令。Claude现在可以连续进行21.2次独立的工具调用而无需人工干预，而六个月前这一数字为9.8次。 3. 人工对话轮数减少了33%。每篇记录的平均人工对话轮数从6.2轮降至4.1轮，这表明与六个月前相比，现在完成一项既定任务所需的人工投入更少。 图3. 2025年8月至2025年2月（x轴）期间Claude Code使用情况的变化。平均任务复杂度随时间增加（左图），每个对话记录的平均最大连续工具调用次数随时间增加（中图），人类对话轮次数量随时间减少（右图）。误差线显示95%置信区间。数据表明，随着时间的推移，人们越来越多地将更多自主权委托给Claude。 这些使用数据证实了调查数据：工程师们将越来越复杂的工作委派给Claude，而Claude所需的监督也越来越少。似乎有理由认为，这推动了所观察到的生产力提升。 任务分配 我们将Claude Code的记录分类为一种或多种类型的编码任务，研究不同任务的用途在过去六个月中是如何演变的： 图4. 各项编码任务（y轴）占总记录数（x轴）的百分比分布。我们将6个月前（粉色）的分布与当前（紫色）进行比较。y轴按2025年2月的频率排序。 根据使用数据估算的总体任务频率分布与自我报告的任务频率分布大致相符。2025年2月至8月间最显著的变化是，使用Claude来实现新功能（从14.3%增至36.9%）和进行代码设计或规划（从1.0%增至9.9%）的转录内容在比例上大幅增加。Claude Code任务相对分布的这种变化可能表明Claude在处理这些更复杂的任务方面表现更好，不过这也可能反映出团队在不同工作流程中采用Claude Code的方式发生了变化，而不是绝对工作量的增加（更多限制请见附录）。 修复小问题 我们从调查中发现，工程师现在花更多时间进行小型的生活质量改善；与此相符的是，当前Claude Code任务中有8.6%被归类为“小问题修复”。这些任务既包括创建性能可视化工具和重构代码以提高可维护性等较大的任务，也包括创建终端快捷方式等较小的任务。这可能有助于工程师提高生产力（解决之前被忽视的生活质量改善问题可能会随着时间的推移提高效率），并有可能减少日常工作中的摩擦和挫折感。 各团队之间的任务差异 为研究当前各团队的任务差异，我们优化了分类方法，将每个8月的记录分配给单一的主要编码任务，并按内部团队（y轴）对数据进行拆分。堆叠条形图展示了每个团队编码任务的细分情况： 图5. 每个水平条形代表一个团队（y轴），各分段显示该团队在不同编码任务（x轴）中使用Claude Code的比例，按编码任务进行颜色编码（图例）。顶部条形（“所有团队”）代表总体分布。 “所有团队”栏展示了整体分布情况，其中最常见的任务是构建新功能、调试和理解代码。这为特定团队的比较提供了基准。 值得注意的特定团队模式： 1. 预训练团队（负责协助训练Claude）经常使用Claude Code来开发新功能（占比54.6%），其中大部分是在进行额外的实验。 2. 对齐与安全团队和训练后团队使用Claude Code进行的前端开发最多（分别为7.5%和7.4%），通常用于创建数据可视化。 3. 安全团队经常使用Claude Code进行代码理解（48.9%），特别是分析和理解代码库不同部分的安全影响。 4. 非技术员工经常使用Claude Code进行调试（51.5%），例如解决网络问题或Git操作问题，以及用于数据科学（12.7%）；Claude似乎在弥补技术知识差距方面很有价值。 许多这些特定团队的模式都展现出了我们在调查和访谈中观察到的同样的能力扩展：能够开展新类型的工作，而团队成员若没有这些模式，要么没有时间，要么没有相应技能来完成