如果有一天你走进公司发现写代码、查 bug、跑实验的大部分体力活都已经由一位看不见的 AI 搭档在后台悄悄完成了——而你更多是在提问题、定方向、做决策而不是一行行敲代码这会是什么感觉是兴奋因为产出翻倍、想法终于可以快速落地还是隐隐不安因为自己赖以安身立命的“手艺”似乎正在慢慢被接管对于正在建设 AI 的公司来说这个问题来得比想象中更早、更猛。Anthropic 在 2025 年做了一次有意思的“自我实验”他们把镜头转向公司内部系统性地调查工程师和研究人员是如何使用 Claude 的以及这些变化正在如何重塑工作的内容、节奏、协作方式甚至职业身份。下面内容翻译自 Anthropic 官方的长文《How AI Is Transforming Work at Anthropic》基于问卷调查、深入访谈以及 Claude Code 使用数据试图回答这样几个问题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 协作下维持有意义的人与人协作如何为一个充满不确定性的未来做准备——那可能需要截然不同的学习方式、指导机制和职业发展路径在文末“展望未来”部分我们讨论了一些 Anthropic 正在内部尝试的初步探索。在另一篇关于经济政策的博客文章中我们也提出了一些围绕 AI 的经济政策设想。关键发现在本节中我们会简要总结问卷、访谈和 Claude Code 数据给出的主要结论。更详细的结果、方法和注意事项会在后面的章节中展开。问卷数据Anthropic 的工程师和研究人员最常用 Claude 来修复代码错误和理解代码库。 调试和代码理解是最常见的使用场景对应图 1。大家报告 Claude 使用频率与生产力提升都在持续上升。 员工自报目前有约 60% 的工作会使用 Claude平均带来约 50% 的生产力提升——相比一年前这是 23 倍的增长。生产力提升的表现形式是各类任务上单个任务花费的时间略有下降但整体产出量明显增加对应图 2。约 27% 的 Claude 辅助工作是本来不会发生的。 比如扩展项目规模、做各种“锦上添花”的工具如交互式数据看板以及一些如果完全人工完成就不划算的探索性工作。多数员工频繁使用 Claude但认为“可以完全交给 Claude 不用自己验证”的工作只占 0–20%。 Claude 更像是一个始终在线的协作者使用它通常仍然需要主动监督和验证尤其是在高风险场景下而不是完全不用检查就把任务直接“甩手”出去。定性访谈员工正在逐渐形成关于“什么任务适合交给 AI”的直觉。 工程师倾向于把那些易于验证、自己“可以比较轻松地嗅一嗅就知道对不对”的任务、低风险任务例如“一次性的调试脚本或研究代码”或者枯燥无聊的事情交给 Claude“我越是对一件事感到兴奋就越不太会用 Claude反之如果对这件事本身有很多心理阻力我往往会先和 Claude 开个头”。许多人会从简单任务开始试探性地交给 Claude然后逐步扩大到更复杂的工作——目前大家仍倾向于把大部分设计或“品味”相关的工作留在自己手中不过随着模型能力提升这条边界也在不断被重新谈判。技能在更多方向上被拓展但动手练习的机会变少了。 Claude 让大家可以在更多领域“伸出触角”比如软件工程的不同层面“我现在可以很熟练地做前端、事务型数据库、API 代码这些东西——这些以前是我不太敢碰的部分”但也有人担忧深层次的技能在写代码和审代码上的积累会因此萎缩——“当产出某个结果变得这么容易、这么快时你就更难逼自己停下来花时间真正去学一个东西。”人与“编程手艺”的关系在改变。 有人拥抱 AI 助手把重点放在结果上“我以前以为自己喜欢的是写代码现在发现我喜欢的其实是写完代码之后得到的那些东西”也有人坦言“对写代码这件事本身有些怀念”。工作场所的社交动态也在变化。 Claude 已经成为很多工程师提问时的“第一站”那些过去会去问同事的问题现在都先问 Claude——结果是部分人感觉到自己获得的指导和协作机会减少了。“我很喜欢和人一起工作现在有点难过的是我‘需要’他们的频率变低了……更初级的同事也不太像以前那样来问我问题。”职业路径在演化未来也充满不确定。 工程师正在转向更高层级的工作——管理 AI 系统同时报告了显著的生产力提升。但这些变化也让人对软件工程这一职业的长期前景产生疑问。有人态度复杂“短期我很乐观但长期我觉得 AI 最终会把所有事情都做掉让我和很多人变得不再重要。”也有人坦承对未来自己的角色会变成什么样“很难说”。Claude Code 使用趋势数据Claude 正在以更高的自主性处理越来越复杂的任务。 六个月前Claude Code 大概可以连续自主完成 10 个动作之后就需要人来介入。现在它通常可以连续完成大约 20 个动作在更复杂的工作流中对人类“指挥”的频率明显降低对应图 3。工程师也越来越多地用 Claude 来做复杂任务比如代码设计/规划在所有使用中的占比从 1% 提升到 10%以及实现新功能从 14% 提升到 37%对应图 4。Claude 修掉了很多“纸割伤papercuts”。 大约 8.6% 的 Claude Code 任务是对那些提升工作体验但容易被忽视的小问题的修复例如为了可维护性而做的重构也就是人们口中的“修纸割伤”这些事情在过去通常会被一直往后排。这些小改动积少成多有望带来更大的效率和体验提升。每个人都在变得更“全栈”。 不同团队以不同方式使用 Claude往往是用来增强各自的核心专长——比如安全团队用它来分析陌生代码Alignment Safety 团队用它来构建数据可视化前端等等对应图 5。问卷数据我们向 Anthropic 各个团队的 132 名工程师和研究人员发放了问卷希望更好地理解他们在日常工作中到底是如何使用 Claude 的。问卷通过内部沟通渠道和直接私信的方式分发覆盖了来自不同研究和产品团队的成员。附录中有更详细的方法说明我们也公开了问卷题目方便其他人评估我们的方法并在自己的研究中借鉴。人们在什么编码任务上使用 Claude我们请受访的工程师和研究人员评估自己在不同类型编码任务中使用 Claude 的频率比如“调试”用 Claude 帮助修复代码错误、“代码理解”让 Claude 解释既有代码帮助自己理解代码库、“重构”用 Claude 帮助重组已有代码、“数据科学”例如让 Claude 分析数据集、画柱状图。下面是最常见的一些日常任务。多数员工55%表示自己每天都会用 Claude 做调试42% 的人每天会用 Claude 做代码理解37% 的人每天会用 Claude 来实现新功能。使用相对较少的是高层设计/规划很可能是因为大家普遍倾向把这类任务保留在“人手里”以及数据科学和前端开发因为这些任务本身在整体工作中的比例就较低。这和 Claude Code 使用数据中不同任务类型的分布大致相符见前文提到的“Claude Code 使用趋势”部分。64a18b1756d8954a93e1356f1330ec11075fbe54-3840x2160.webp图 1不同编码任务纵轴对应的日常使用者比例横轴。使用频率与生产力员工自报的数据显示12 个月前他们在日常工作中约有 28% 的时间会用到 Claude当时平均感受到的生产力提升是 20%而现在他们在约 59% 的工作中使用 Claude平均生产力提升达到了 50%。这一点和工程团队在全面采用 Claude Code 后人均每天合并的 Pull Request 数量增加 67% 的数据大致相互印证。按年对比来看这个变化相当剧烈——一年时间里这两个指标都实现了超过 2 倍的提升。使用频率与生产力提升高度相关在分布的极端一端有 14% 的受访者通过使用 Claude 报告了超过 100% 的生产力提升——可以看作内部的“超级用户”。需要强调的是包括这一条在内的所有“生产力自评”都有不少不确定性生产力本身很难被精确测量。外部研究机构 METR 有一项近期研究指出在一个高度熟悉的代码库上使用 AI 的经验丰富开发者其实高估了 AI 带来的生产力提升。值得注意的是那项研究中导致生产力没有预期那么高的因素例如在大型复杂环境中 AI 表现变差或任务中包含大量隐性知识和上下文与我们员工所描述的“不适合交给 Claude 的任务类型”高度一致。我们的生产力提升数据是跨任务的自报很可能反映了员工在“适合交给 AI 的任务选择”上逐渐形成策略化的判断——而这在 METR 的那项研究中并没有被纳入考量。当我们进一步追问在那些已经使用 Claude 的任务类别中它会如何影响该类别总体花费的时间和产出量时一个有趣的模式出现了几乎在所有任务类别上员工都报告了总体时间投入略有下降而产出数量的增加更加明显。9449bf9393743105a414e17324f30970208ce14b-3840x2160.webp图 2在不同任务类别纵轴中Claude 使用对“时间投入”左图和“产出数量”右图的影响。横轴为自报的时间/产出增减负值代表减少正值代表增加虚线为“无变化”误差条为 95% 置信区间圆点面积与该评价点的回答数量成正比。只统计在该任务类别中使用过 Claude 的受访者。不过进一步观察原始数据会发现时间节省的回答在分布上呈现两极——有些人在 Claude 辅助的任务上反而花了明显更多的时间。为什么会这样人们普遍解释说他们需要花更多时间调试和清理 Claude 写出的代码例如“当我自己随手写着写着把自己写进死胡同时”也要承担理解 Claude 代码的额外认知负担因为那不是自己一行行写出来的。有些人则表示花更多时间是“赋能意义上的多投入”——有人说Claude 让他们能“在以前马上就会放弃的问题上坚持下去”也有人说它让自己能做更全面的测试并在新的代码库中投入更多学习和探索。从整体看那些体验到时间节省的人很可能正是善于把“易验证任务”打包交给 Claude 的人而那些花了更多时间的人则往往要为 AI 生成的代码做更多调试或者在模型需要大量引导的领域中工作。从数据中也看不出这些被节省出来的时间最终流向了哪里——是投入到额外的工程任务、非工程任务、与 Claude 互动或审查其输出还是工作之外的活动我们的任务分类框架无法覆盖工程师时间分配的全部维度。此外时间节省本身也可能受到自报偏差的影响。这些问题都需要进一步研究来拆解。相比之下产出数量的提升要更直接、更显著几乎所有任务类别上净产出增加都更大。这一模式也很合理——受访者报告的是“调试”这一类任务而不是某一条具体的 bug。也就是说即使在“调试”这个类别上花的总时间略有减少人们依然可以完成更多的调试任务。从严格意义上讲生产力很难被直接测量但这些自报数据至少表明在 AnthropicAI 主要是通过增加产出来提升生产力的。Claude 让哪些“新工作”得以发生我们很好奇的一点是Claude 是否真的让一些“以前不会做的事情”得以发生还是说它只是让原本迟早会完成的工作变快了一些员工估算在他们当前使用 Claude 完成的工作中有约 27% 如果没有 Claude 根本不会去做。工程师提到会用 AI 来做项目扩展、各种“锦上添花”的事情比如交互式数据仪表盘、一些本身很有价值但很枯燥的工作如写文档、补测试以及那些如果完全人工来做就不划算的探索性尝试。正如一位受访者所说他们现在可以修掉更多以前影响体验、但一直没有人腾出手去“收拾”的小问题比如重构结构很差的代码或者写一些“小工具”来加速其他任务。我们在 Claude Code 使用数据中也看到了类似现象约有 8.6% 的任务可以归类为“papercut 修复”。另一位研究人员举例说他们会同时开启很多个 Claude 实例让它们并行探索解决同一个问题的不同路径人们往往把“超级强大”的模型想象成一个单一实例就像换了一辆更快的汽车。但如果你有“一百万匹马”……你就可以同时尝试很多不同的想法……当你有这么大的探索广度时这件事会变得非常令人兴奋、也更具创造性。正如我们会在后面的章节里看到的这类“新工作”往往涉及工程师走出自己原有的专业舒适区。到底有多少工作可以完全交给 Claude尽管工程师们非常频繁地使用 Claude但超过一半的人认为真正“可以完全交给 Claude、不需要自己再验证”的工作只占自己总工作量的 0–20%。值得一提的是不同受访者对“完全交给”这一说法的理解并不完全一样——有的人指的是完全无需验证有的人则是指只需很轻量的检查。在解释“为什么不能更多完全交给 Claude”时工程师描述的是一种高度主动、迭代式的工作方式他们会和 Claude 来回对话、一起推进任务并在过程中不断验证 Claude 的输出——尤其是那些复杂任务或代码质量要求极高的高风险领域。这说明工程师们倾向于把 Claude 当作一个紧密协作的伙伴而不是“黑箱外包方”并且他们对“什么算是可以完全交出去”设定了非常高的标准。定性访谈虽然问卷结果显示了显著的生产力提升和工作模式变化但它们并不能回答一个关键问题工程师在日常工作中具体是如何体验这些变化的为此我们对参与问卷的 Anthropic 工程师和研究人员中的 53 人进行了深入访谈以理解他们在这场变革中的真实感受和思考。AI 委托方式工程师和研究人员正在发展出一系列策略以更高效地在工作流中使用 Claude。总体而言人们倾向于把下面几类任务委托给 Claude|| 超出自己的熟悉上下文、但整体复杂度较低的任务例如“我会把那些我自己上下文不太熟但整体难度不高的问题交给 Claude。”又如“我遇到的大多数基础设施问题并不算难Claude 就能搞定……我对 Git 或 Linux 其实不太熟但 Claude 在这些方面很好地帮我补上了经验上的短板。” ||| 容易验证的任务例如“对于那些验证成本相对创建成本不高的事情它简直太好用了。” ||| 边界清晰、相对自洽的子问题例如“如果一个子模块和系统其他部分足够解耦我通常会先让 Claude 试一把。” ||| 代码质量要求不那么高的场景例如“如果是一次性的调试或研究代码我通常会直接让 Claude 写。如果是概念上很难、或者需要非常特殊的调试注入或者是设计问题那我还是会自己来。” ||| 重复、枯燥的事情例如“我越兴奋的一件事就越不太会用 Claude相反如果我对一件事产生很大心理阻力那通常我会先和 Claude 开个头。”在问卷中大家平均认为自己用 Claude 完成的工作有 44% 是本来就不太想亲自做的那种。 ||| 写提示比自己动手更省时间的任务例如“如果我预估某件事我自己十分钟以内能搞定那我通常不会麻烦 Claude。”又比如“现在最大的问题其实是‘冷启动’。所谓冷启动就是我脑子里有很多关于我们团队代码库的隐性信息而 Claude 默认并不知道这些……我可以花很多时间去打磨一个完美的提示词但很多时候不如自己动手来得快。” |这些员工提到的委托考量与一项外部研究中发现的“AI 反而拖慢生产力”的情境高度一致例如开发者对代码库非常熟悉、代码仓库规模巨大且复杂等。这种内外研究在“什么任务适合交给 AI”上的收敛表明任务选择本身很可能是影响 AI 生产力收益的关键因素——未来的生产力研究需要对这一点进行更精细的控制。信任但要验证Trust but verify很多用户描述了自己使用 Claude 的“信任演化过程”一开始只是用它来问一些 Rust 之类语言的基础问题……而最近自己几乎所有编码工作都会用上 Claude Code。有一位工程师把这种信任演化比作自己使用 Google 地图的过程一开始我只会在不熟悉的路线用 Google Maps……这就像一开始我只用 Claude 来写自己不太熟的 SQL但不会让它写我很熟的 Python。后来我会在大致熟悉的路线上也开着地图也许只是最后一段路不太确定……就像逐渐让 Claude 参与我部分熟悉的任务。现在即便是每天通勤的路线我也一直开着 Google Maps。如果它建议我走一条不同的路我通常会直接照做相信它已经综合考虑了各种因素……我今天用 Claude Code 的方式其实很像这样。在“用 Claude 处理自己熟悉领域的任务还是陌生领域的任务”这件事上工程师们也出现了分化。有的人更倾向把 Claude 用在“边缘领域”以节省实现时间有的人则更喜欢在熟悉的领域使用它因为那样自己更有能力验证结果“我用 Claude 的方式是我始终对它在做什么保持完整理解”。一位安全工程师就强调了经验的重要性有一次 Claude 提出一个“非常聪明、但也非常危险”的方案这种方案就像是一个很有才华但缺乏经验的初级工程师会想出来的东西——只有具备判断力和经验的人才能意识到这里潜藏的问题。还有一些工程师则两种情况都会用 Claude要么是以一种“实验”心态“基本上遇到任何编码问题我都会先让 Claude 打个样”要么是根据自己在某个领域的熟悉程度调整与 Claude 的分工方式如果是我非常熟悉的领域我会更强势一点告诉 Claude 具体要去查什么、怎么做。如果是我不太熟的东西我通常会让 Claude 去当专家让它给我提供选项指出我应该考虑和研究的方向。人们会把什么任务留给自己几乎所有人都表示他们不会用 Claude 来做那些涉及高层次或战略性思考的任务也不会把需要组织语境或“品味判断”的设计决策交给 Claude。一位工程师说得很直接“我通常会把高层思考和设计留在自己手里只要能交出去的事情从新功能开发到调试我都会尽量交出去。”这一点也在问卷数据中得到了印证——在设计和规划类任务上生产力提升是最有限的见图 2。许多人也把这种“委托边界”描述为一个“不断移动的目标”会随着模型能力的演进而持续被重新划线Claude Code 使用数据也显示相比六个月前现在用于代码设计/规划的使用占比已经明显提升。技能的变化新的能力……问卷中“有 27% 的 Claude 辅助工作本来不会被完成”这一发现也映射出一个更宏观的模式工程师们正在用 AI 去做原本属于自己核心技能范围之外的事情。许多员工表示他们完成了很多以前自己不太会做的工作——后端工程师开始搭前端界面研究人员自己做可视化。有一位后端工程师回忆说他通过和 Claude 反复迭代搭出了一个复杂的前端界面“效果比我自己做的好太多了。按原来的节奏我根本不可能在要求的时间内做完……设计师看到之后都惊讶地问‘等等这是你做的’我说‘不这是 Claude 做的——我只是负责提需求。’”工程师们普遍觉得自己正在“变得更全栈”“我现在非常有信心能做前端、事务型数据库、API 代码这些活儿而以前我会有点怕碰这些不擅长的部分。”这种能力的扩展让反馈循环变得更紧凑也加快了学习速度——有人形容以前需要“几周时间、不断开会、反复迭代”的过程现在可以在“几个小时的工作会”里完成相关同事也可以在现场实时给反馈。总体而言大家对自己更快原型化、并行推进工作、减少重复劳动、提升目标雄心这一系列新能力都感到振奋。一位高级工程师说“这些工具确实让初级工程师更高效、更敢接大项目。”也有人提到使用 Claude 让自己更容易跨过“启动门槛”战胜拖延症——“它大幅降低了我愿意开始解决一个问题所需要的心理能量因此我愿意多接很多以前会一拖再拖的事情。”……以及更少的“亲手练习”同时也有不少人担心在越来越多事情交给 Claude 之后自己的技能会“慢慢生锈”尤其是那些在手动解决问题过程中积累的“顺带收获”的理解如果你完全自己去排查一个棘手的问题你会花很多时间看文档、看和问题不那么直接相关的代码——虽然这些内容对眼前这一个问题未必有用但在整个过程中你会慢慢构建起对系统的整体心智模型。现在因为 Claude 能直接把你带到问题所在这样的学习过程就少了很多。我以前会自己把一个工具的所有配置项都翻一遍以便真正理解它能做什么现在我更多是问 AI 该怎么用所以很多时候我缺少对工具的那种“肌肉记忆式理解”。以前和同事讨论问题时我可以很快地从记忆里调出很多细节现在则经常需要再去问 AI。使用 Claude 的一个风险是它可能会让你跳过那种通过解决“简单版问题”来练习的阶段然后在遇到“复杂版问题”时反而因为缺乏底层经验而很吃力。一位高级工程师说如果自己处在更初级的阶段他会更担心这一点我现在主要是在自己知道答案是什么、或者大致知道答案长什么样的情况下用 AI。我是通过“按传统方式”做了很多年软件工程积累出这种判断能力的……但如果我还在职业早期我会认为想要在这种环境里持续提升自己的能力需要付出很多刻意练习而不能只是盲目接受模型的输出。技能萎缩之所以让人担心很大一部分原因在于“监督悖论”如前面所说高效使用 Claude 需要监督而要监督 Claude你又需要那些可能因为过度依赖 AI 而萎缩的编码技能。正如一位受访者所说说实话我比起自己的技能更担心的是监督和管控的问题……我的技能如果萎缩或停滞真正的问题在于我对自己使用 AI 完成重要任务是否足够安全、是否有能力发现它的漏洞而不是在于我究竟还能不能自己一个人把这件事从头做到尾。为此有些工程师会刻意“断网练功”——在明知道 Claude 可以很好解决问题的情况下刻意选择不用偶尔我明明知道 Claude 能十拿九稳解决一个问题也会刻意不去问它。这算是给自己的一个“小训练”让自己保持敏锐。这些动手编码能力将来还重要吗也许软件工程正在进入一个新的抽象层级这在历史上已经发生过很多次。最早的程序员工作在非常贴近机器的层面——手动管理内存用汇编语言写程序甚至通过拨动物理开关来输入指令。后来更高级、更易读的编程语言出现它们自动处理了很多底层复杂操作。也许随着所谓“vibe coding”的兴起我们正走向一个“英语就是编程语言”的时代。有人建议未来想做工程师的人应该“先学会如何让 AI 写代码把更多精力放在学习高层概念和模式上”。有些员工觉得这种转变让他们能在更高的层面上思考——“更多去想最终产品和最终用户而不仅仅是代码本身”。有人把当前的变化类比为以前必须在计算机课程里学链表这类底层数据结构——这些结构现在早已被高级语言封装好了。“我很高兴自己曾经学过这些……但从情感上讲一遍遍做这些底层操作对我来说并不重要。我更在意的是代码能让我真正做成什么。”也有人做了类似的比较但同时指出抽象的提升也意味着代价——随着大家对高级语言的依赖绝大多数工程师对内存管理失去了深入理解。在某个领域持续打磨技能确实可以让你更好地监督 Claude也更高效地与之合作“我发现在我熟悉的领域里很多时候自己做反而更快”。但工程师们在“这是否重要”这个问题上并不一致。有的人相对乐观我对技能退化并没那么担心。AI 仍然会迫使我认真思考问题也帮助我学习新的解法。在某些领域能够更快地探索和测试想法反而加速了我的学习。也有人更务实作为一名软件工程师我的技能肯定是在退化的……但如果哪天真的需要我相信这些技能还是能练回来而且现在我也确实不再那么需要它们了还有人提到自己失去的更多是画图之类的次要技能“真正关键的那部分代码我仍然能写得很好”。也许最有意思的是有工程师直接质疑了“会不会变生锈”这一前提把这件事叫做“变生锈”是假定有一天世界会回到 Claude 3.5 之前的那个样子。我并不认为那样的日子会再回来。软件工程的“手艺感”和意义工程师们在“是否怀念亲手写代码”这一点上出现了明显分歧。有的人有真切的失落感——“对我来说这真的是一个时代的结束。我写代码写了 25 年对自己在这方面的熟练掌握一直是我职业满足感的重要来源。”也有人担心自己可能并不会喜欢未来这种新的工作形态“整天在那儿给 Claude 写提示词其实并没有那么有趣或有成就感。相比之下戴上耳机放点音乐自己进入心流状态、从头到尾实现一个东西要好玩得多。”也有人正面承认了这种取舍并表示接受“写代码这件事确实有一些部分是我会怀念的——比如在重构时进入那种‘禅意流’的状态。但总的来说我现在的生产力提升太大了为了这个结果我愿意把那种体验放下。”还有人觉得和 Claude 一起迭代反而更好玩因为“我可以比对人更挑剔”不用顾及对方的情绪。也有人更在意结果而不是过程。有一位工程师说我原本以为到这个阶段我会感到害怕或无聊……但事实上我并没有这些感觉。相反我很兴奋因为我现在能做的事情多太多了。我曾以为自己喜欢的是写代码这件事本身但现在我发现我真正喜欢的是写完代码之后能得到的那些东西。从整体来看人们是否拥抱 AI还是更怀念“亲手写代码”的时代很大程度上取决于他们觉得软件工程这份工作中哪一部分对自己最有意义。工作场所的社交动态在改变访谈中一个很突出的话题是 Claude 已经取代了很多过去会直接问同事的问题成为第一咨询对象。“我现在问问题的频率比以前高多了但差不多 80–90% 的问题我都是先问 Claude。”有员工这样总结。这在一定程度上起到了“信息过滤器”的作用——Claude 会先处理那些日常、重复的问题而同事们则更多被用来讨论复杂的、战略性的或高度依赖组织上下文的问题“它让我的团队对我来说‘不那么必要’了 80%但剩下那 20% 非常关键我仍然会去找他们。”。人们也会把 Claude 当成“头脑风暴搭档”像和人一样用它来对撞想法。大约有一半的受访者表示团队的合作模式并没有发生太大变化。有一位工程师说他仍然会和同事开会、共享上下文、一起做方向选择他认为在可见的未来依然会有大量的人与人协作“只不过平时专注做事的那段时间里你会更多地在和各种 Claude 对话”。但也有人切实感受到和同事的互动变少了“我现在和 Claude 的互动远比和任何一个同事都多。”。有些人对这种变化感到满意因为这样可以减少社交摩擦“我不再需要担心打扰同事占用他们的时间。”。但也有人不太喜欢这个趋势“我其实不太喜欢大家动不动就说‘你问问 Claude’我真的很享受和人面对面一起工作的感觉也非常看重这种体验。”或者怀念过去的工作方式“我很喜欢和人一起工作现在有点难过的是我似乎‘不再那么需要他们’了。”不少人也指出这对传统的“师徒式指导关系”有明显影响——因为许多过去会由高级工程师承担的指导现在可以由 Claude 提供。“Claude 可以给初级同事提供很多指导和教练式帮助。”一位高级工程师说让我有点难过的是初级同事不再像以前那样经常来问我问题了虽然实话实说他们现在确实更快地得到答案也学得更快。职业不确定性与适应许多工程师觉得自己的角色正在从“写代码的人”变成“管理 AI 的人”。越来越多人把自己看作是“AI 代理的管理者”——有人表示自己几乎总是同时开着好几个 Claude 实例。有人估计自己的工作内容中已经有“70% 以上是做代码评审/修改而不是从零写新代码”也有人认为将来“对 1 个、5 个甚至 100 个 Claude 的工作负责”会成为自己角色的一部分。从长期来看职业上的不确定性非常普遍。工程师们普遍认为这些变化是整个行业更大转型的前兆很多人都说“很难判断”几年之后自己的职业会变成什么样。有些人对短期和长期的态度是矛盾的——“短期我很乐观但长期我觉得 AI 最终会把所有事情都做掉让我和很多人变得不再重要。”还有人说得更直接“有时候感觉每天上班都像是在把自己一步步‘做没’。”也有工程师更为乐观。有一位说“我确实替初级开发者有点担心但也知道他们往往是对新技术最有热情的那群人。整体来说我对这个职业的未来还是非常乐观的。”他认为尽管确实存在那些经验不足的人用 AI 写出问题代码的风险但随着 AI 安全措施的完善、教育资源的不断嵌入以及人们在实践中从错误中学习这个行业会逐渐适应并找到新的平衡。当我们问工程师们如何设想自己的未来角色以及是否有应对策略时有人提到会进一步向某些方向深度专精“真正具备对 AI 工作做有意义 review 的能力会需要更长时间的积累和更高程度的专门化”有人预计未来会更多投入到“人与人”的工作和战略性事务上“我们会把更多时间花在达成共识上让 AI 花更多时间在具体实现上”。也有人已经开始有意识地用 Claude 做职业发展——向它寻求关于工作方法、领导力等方面的反馈“我能学习和发挥的速度完全变了感觉就像头顶的天花板一下子碎掉了。”总体来看很多人都坦言自己对“未来哪些技能会有用”几乎没有什么把握。一位团队负责人总结说“其实没人真正知道会发生什么……真正重要的是你是否足够有适应能力。”Claude Code 使用趋势问卷和访谈数据显示越来越多的 Claude 使用正在帮助人们更快推进工作、承担更多以前不会做的任务但同时也带来了围绕“任务委托”和“技能发展”的各种紧张和矛盾。当然自报数据只讲了故事的一部分。为了补全这一点我们还分析了 Anthropic 团队内部真实的 Claude Code 使用记录。因为受访者表示他们的大部分 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这说明现在完成同样复杂的任务所需的人类输入比六个月前更少了。d23e1b8d8af84b45d5cffcc6f0a029d635508153-3840x2160.webp图 32025 年 2 月与 8 月之间 Claude Code 使用情况的变化。左图为平均任务复杂度中图为每条记录中连续工具调用的最大次数右图为人类发言轮次。误差条为 95% 置信区间整体上看人们正在把更多自主性委托给 Claude。这些使用数据与问卷的定性结论相互印证工程师正在持续把更复杂的工作交给 Claude且 Claude 所需的人类监督也在减少。这很可能是我们观察到的生产力提升背后的重要驱动力之一。任务分布我们把 Claude Code 的记录按任务类型进行了分类并对比了过去六个月中不同任务类型在整体使用中的占比变化7da627df8a6be4cb90ecd6e6e41345b8122401ed-3840x2160.webp图 4不同编码任务纵轴在所有记录中所占比例横轴。粉色为 6 个月前的分布紫色为当前分布按 2025 年 2 月的频率排序。整体任务频率分布与自报数据大致一致。最显著的变化是现在用于实现新功能的记录占比明显提高从 14.3% 到 36.9%用于代码设计或规划的占比也有明显提升从 1.0% 到 9.9%。这种相对分布的变化可能说明 Claude 在这些更复杂任务上的表现变好了当然也可能仅仅反映了团队在不同工作流中采用 Claude Code 的方式发生了变化而不一定意味着绝对工作量的增加更多限制与说明见附录。修补“纸割伤”我们从问卷中了解到工程师现在花更多时间做那些“改善日常体验的小修小补”与此相呼应的是大约 8.6% 的 Claude Code 任务被归类为“papercut 修复”。这些任务既包括构建性能可视化工具、为可维护性而做的大规模重构等较大工作也包括创建终端快捷方式这样的小改动。这些工作可能一方面提升了自报的生产力长期来看修复那些一直积累的“小摩擦点”会让整体效率提高另一方面也减少了日常工作的挫败感和阻力。不同团队的任务差异为了研究不同团队之间任务类型的差异我们进一步细化了任务分类方法为 8 月的每条记录分配了一个主要任务类型并按内部团队进行拆分。下图中的堆叠柱状条展示了各团队中不同任务类型的比例313f1cc36b0eb1fec9ee986f50e8d937ddc796ba-3840x2160.webp图 5每一条横向柱代表一个团队纵轴不同颜色的片段代表该团队中 Claude Code 使用在不同任务类型上的占比横轴。顶部的“All Teams”条代表整体分布。“All Teams” 这一条给出了整体的分布基线其中最常见的任务是新功能构建、调试和代码理解在此基础上其他团队的分布可以对照比较。一些值得注意的团队特征包括预训练Pre-training团队负责训练 Claude非常频繁地用 Claude Code 来构建新功能占比 54.6%其中很多是用来跑额外实验。Alignment Safety 团队和 后训练Post-training 团队在前端开发上的使用占比最高分别为 7.5% 和 7.4%通常是为了构建数据可视化界面。安全Security 团队经常使用 Claude Code 来做代码理解占比 48.9%尤其是用于分析和理解代码库中不同部分的安全影响。非技术背景员工 通常用 Claude Code 做调试占比 51.5%例如排查网络问题或 Git 操作问题同时也会用于数据科学任务占比 12.7%Claude 在这里起到了帮助他们跨越技术门槛的作用。这些团队特定的模式和我们在问卷和访谈中看到的“能力扩展”现象相呼应许多团队正在利用 Claude 来完成那些原本没有时间或能力去做的工作。例如预训练团队可以跑更多实验非技术员工能够自己修复代码错误。而从数据看团队确实会用 Claude 做各自的核心任务例如基础设施团队最常用 Claude Code 做基础设施和 DevOps 相关工作但 Claude 同时也在拓展他们的核心任务边界例如研究人员通过 Claude 来做前端开发以便更好地可视化自己的数据。整体来看Claude 正在帮助每一个人变得更加“全栈”。展望未来过去一年里Anthropic 员工对 Claude 的使用大幅增加他们不仅用它来加速原本就会做的工作还用它来熟悉新的代码库、减少重复劳动、拓展自己的技能边界并处理那些长期被忽视的改进事项。随着 Claude 变得更加自主和强大工程师们也在不断摸索新的任务委托方式同时思考在这种环境下未来需要什么样的技能。这些变化带来了非常实在的生产力和学习收益但也伴随着对软件工程长期走向的真切忧虑这次的变化会像过去从低级语言到高级语言的过渡那样仅仅是一个新的抽象层还是会走得更远把我们对“工程师”的定义也重新写一遍眼下仍然是这场转型的早期阶段——Anthropic 内部拥有大量早期采用者外部环境变化也极其迅速我们的发现未必能直接推广到其他组织或场景更多局限见附录。这些研究结果某种程度上也反映了这种不确定性结论往往是多面的并没有一个统一的“正确答案”或明确的行动指令。但它确实提出了一个问题我们要如何在这样的变革中更加审慎而有效地前行作为这项工作的后续我们正在做几件事与 Anthropic 的工程师、研究人员和管理层持续对话讨论如何回应这次转型带来的机会与挑战重新审视我们如何让团队之间更好地协作与共享上下文如何支持员工的职业发展以及如何建立适合 AI 协作时代的工作实践指南例如借助我们提出的 AI 素养框架。我们也准备将视角扩展到工程师以外的角色去理解 AI 转型在整个组织范围内的影响并支持像 CodePath 这样的外部机构在 AI 辅助已成常态的未来重新设计计算机科学教育。向前看我们也在思考在 AI 能力持续提升的背景下可能需要怎样的组织结构变革——比如为角色演化和再培训设计新的路径。我们预计会在 2026 年分享更具体的计划。Anthropic 希望在“负责任的职场转型”上既是研究对象也是实践场——我们不仅想研究 AI 如何改变工作更希望从自身出发探索如何更好地面对这场变化。