人工智能如何改变 Anthropic 的工作方式

程序猿DD

发布于 2025-12-29 12:06:40

2340

如果有一天，你走进公司，发现写代码、查 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 数据给出的主要结论。更详细的结果、方法和注意事项，会在后面的章节中展开。

问卷数据

1. Anthropic 的工程师和研究人员最常用 Claude 来修复代码错误和理解代码库。 调试和代码理解是最常见的使用场景（对应图 1）。
2. 大家报告 Claude 使用频率与生产力提升都在持续上升。 员工自报目前有约 60% 的工作会使用 Claude，平均带来约 50% 的生产力提升——相比一年前，这是 2～3 倍的增长。生产力提升的表现形式，是各类任务上单个任务花费的时间略有下降，但整体产出量明显增加（对应图 2）。
3. 约 27% 的 Claude 辅助工作，是本来不会发生的。 比如扩展项目规模、做各种“锦上添花”的工具（如交互式数据看板），以及一些如果完全人工完成就不划算的探索性工作。
4. 多数员工频繁使用 Claude，但认为“可以完全交给 Claude 不用自己验证”的工作只占 0–20%。 Claude 更像是一个始终在线的协作者；使用它通常仍然需要主动监督和验证，尤其是在高风险场景下，而不是完全不用检查就把任务直接“甩手”出去。

定性访谈

1. 员工正在逐渐形成关于“什么任务适合交给 AI”的直觉。 工程师倾向于把那些易于验证、自己“可以比较轻松地嗅一嗅就知道对不对”的任务、低风险任务（例如“一次性的调试脚本或研究代码”），或者枯燥无聊的事情交给 Claude（“我越是对一件事感到兴奋，就越不太会用 Claude；反之，如果对这件事本身有很多心理阻力，我往往会先和 Claude 开个头”）。许多人会从简单任务开始试探性地交给 Claude，然后逐步扩大到更复杂的工作——目前大家仍倾向于把大部分设计或“品味”相关的工作留在自己手中，不过随着模型能力提升，这条边界也在不断被重新谈判。
2. 技能在更多方向上被拓展，但动手练习的机会变少了。 Claude 让大家可以在更多领域“伸出触角”（比如软件工程的不同层面：“我现在可以很熟练地做前端、事务型数据库、API 代码这些东西——这些以前是我不太敢碰的部分”），但也有人担忧，深层次的技能在写代码和审代码上的积累会因此萎缩——“当产出某个结果变得这么容易、这么快时，你就更难逼自己停下来，花时间真正去学一个东西。”
3. 人与“编程手艺”的关系在改变。 有人拥抱 AI 助手，把重点放在结果上（“我以前以为自己喜欢的是写代码，现在发现我喜欢的其实是写完代码之后得到的那些东西”）；也有人坦言“对写代码这件事本身有些怀念”。
4. 工作场所的社交动态也在变化。 Claude 已经成为很多工程师提问时的“第一站”，那些过去会去问同事的问题，现在都先问 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，往往是用来增强各自的核心专长——比如安全团队用它来分析陌生代码，Alignment & Safety 团队用它来构建数据可视化前端，等等（对应图 5）。

问卷数据

我们向 Anthropic 各个团队的 132 名工程师和研究人员发放了问卷，希望更好地理解他们在日常工作中到底是如何使用 Claude 的。问卷通过内部沟通渠道和直接私信的方式分发，覆盖了来自不同研究和产品团队的成员。附录中有更详细的方法说明，我们也公开了问卷题目，方便其他人评估我们的方法并在自己的研究中借鉴。

人们在什么编码任务上使用 Claude？

我们请受访的工程师和研究人员，评估自己在不同类型编码任务中使用 Claude 的频率，比如“调试”（用 Claude 帮助修复代码错误）、“代码理解”（让 Claude 解释既有代码，帮助自己理解代码库）、“重构”（用 Claude 帮助重组已有代码）、“数据科学”（例如让 Claude 分析数据集、画柱状图）。

下面是最常见的一些日常任务。多数员工（55%）表示自己每天都会用 Claude 做调试；42% 的人每天会用 Claude 做代码理解；37% 的人每天会用 Claude 来实现新功能。使用相对较少的，是高层设计/规划（很可能是因为大家普遍倾向把这类任务保留在“人手里”），以及数据科学和前端开发（因为这些任务本身在整体工作中的比例就较低）。这和 Claude Code 使用数据中不同任务类型的分布大致相符（见前文提到的“Claude Code 使用趋势”部分）。

Figure 1: Proportion of daily users (x-axis) for various coding tasks (y-axis).

图 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 的任务类别中，它会如何影响该类别总体花费的时间和产出量时，一个有趣的模式出现了：几乎在所有任务类别上，员工都报告了总体时间投入略有下降，而产出数量的增加更加明显。

Figure 2: Impact on time spent (left panel) and output volume (right panel) by task (y-axis). The x-axis on each plot corresponds to either a self-reported decrease (negative values), increase (positive values) or no change (vertical dashed line) in time spent or output volume for categories of Claude-assisted tasks, compared to not using Claude. Error bars show 95% confidence intervals. Circle area is proportional to the number of responses at each rating point. Only respondents who reported using Claude for each task category are included.

图 2：在不同任务类别（纵轴）中，Claude 使用对“时间投入”（左图）和“产出数量”（右图）的影响。横轴为自报的时间/产出增减（负值代表减少，正值代表增加，虚线为“无变化”），误差条为 95% 置信区间，圆点面积与该评价点的回答数量成正比。只统计在该任务类别中使用过 Claude 的受访者。

不过，进一步观察原始数据会发现，时间节省的回答在分布上呈现两极——有些人在 Claude 辅助的任务上反而花了明显更多的时间。

为什么会这样？人们普遍解释说，他们需要花更多时间调试和清理 Claude 写出的代码（例如“当我自己随手写着写着把自己写进死胡同时”），也要承担理解 Claude 代码的额外认知负担，因为那不是自己一行行写出来的。有些人则表示，花更多时间是“赋能意义上的多投入”——有人说，Claude 让他们能“在以前马上就会放弃的问题上坚持下去”；也有人说，它让自己能做更全面的测试，并在新的代码库中投入更多学习和探索。从整体看，那些体验到时间节省的人，很可能正是善于把“易验证任务”打包交给 Claude 的人；而那些花了更多时间的人，则往往要为 AI 生成的代码做更多调试，或者在模型需要大量引导的领域中工作。

从数据中也看不出，这些被节省出来的时间最终流向了哪里——是投入到额外的工程任务、非工程任务、与 Claude 互动或审查其输出，还是工作之外的活动？我们的任务分类框架无法覆盖工程师时间分配的全部维度。此外，时间节省本身也可能受到自报偏差的影响。这些问题都需要进一步研究来拆解。

相比之下，产出数量的提升要更直接、更显著：几乎所有任务类别上，净产出增加都更大。这一模式也很合理——受访者报告的是“调试”这一类任务，而不是某一条具体的 bug。也就是说，即使在“调试”这个类别上花的总时间略有减少，人们依然可以完成更多的调试任务。从严格意义上讲，生产力很难被直接测量，但这些自报数据至少表明：在 Anthropic，AI 主要是通过增加产出来提升生产力的。

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，这说明现在完成同样复杂的任务，所需的人类输入比六个月前更少了。

Figure 3. Changes in Claude Code usage between August 2025 and February 2025 (x-axes). Average task complexity increased over time (left panel), average maximum consecutive tool calls per transcript increased over time (middle panel), and number of human turns decreased over time (right panel). Error bars show 95% confidence intervals. The data suggest people are increasingly delegating more autonomy to Claude over time.

图 3：2025 年 2 月与 8 月之间 Claude Code 使用情况的变化。左图为平均任务复杂度，中图为每条记录中连续工具调用的最大次数，右图为人类发言轮次。误差条为 95% 置信区间，整体上看，人们正在把更多自主性委托给 Claude

这些使用数据与问卷的定性结论相互印证：工程师正在持续把更复杂的工作交给 Claude，且 Claude 所需的人类监督也在减少。这很可能是我们观察到的生产力提升背后的重要驱动力之一。

任务分布

我们把 Claude Code 的记录按任务类型进行了分类，并对比了过去六个月中，不同任务类型在整体使用中的占比变化：

Figure 4. Distribution of various coding tasks (y-axis) as a percentage of the overall number of records (x-axis). We compare the distribution 6 months ago (pink) to present day (purple). The y-axis is ordered by frequency in Feb 2025.

图 4：不同编码任务（纵轴）在所有记录中所占比例（横轴）。粉色为 6 个月前的分布，紫色为当前分布，按 2025 年 2 月的频率排序

整体任务频率分布与自报数据大致一致。最显著的变化，是现在用于实现新功能的记录占比明显提高（从 14.3% 到 36.9%），用于代码设计或规划的占比也有明显提升（从 1.0% 到 9.9%）。这种相对分布的变化，可能说明 Claude 在这些更复杂任务上的表现变好了；当然，也可能仅仅反映了团队在不同工作流中采用 Claude Code 的方式发生了变化，而不一定意味着绝对工作量的增加（更多限制与说明见附录）。

修补“纸割伤”

我们从问卷中了解到，工程师现在花更多时间做那些“改善日常体验的小修小补”；与此相呼应的是，大约 8.6% 的 Claude Code 任务被归类为“papercut 修复”。这些任务既包括构建性能可视化工具、为可维护性而做的大规模重构等较大工作，也包括创建终端快捷方式这样的小改动。这些工作可能一方面提升了自报的生产力（长期来看，修复那些一直积累的“小摩擦点”会让整体效率提高），另一方面也减少了日常工作的挫败感和阻力。

不同团队的任务差异

为了研究不同团队之间任务类型的差异，我们进一步细化了任务分类方法，为 8 月的每条记录分配了一个主要任务类型，并按内部团队进行拆分。下图中的堆叠柱状条展示了各团队中不同任务类型的比例：

Figure 5. Each horizontal bar represents a team (y-axis) with segments showing the proportion of that team’s Claude Code usage for different coding tasks (x-axis), color-coded by coding task (legend). Top bar (“All Teams”) represents the overall distribution.

图 5：每一条横向柱代表一个团队（纵轴），不同颜色的片段代表该团队中 Claude Code 使用在不同任务类型上的占比（横轴）。顶部的“All Teams”条代表整体分布

“All Teams” 这一条给出了整体的分布基线，其中最常见的任务是新功能构建、调试和代码理解，在此基础上，其他团队的分布可以对照比较。

一些值得注意的团队特征包括：

1. 预训练（Pre-training）团队（负责训练 Claude）非常频繁地用 Claude Code 来构建新功能（占比 54.6%），其中很多是用来跑额外实验。
2. Alignment & Safety 团队和 后训练（Post-training） 团队在前端开发上的使用占比最高（分别为 7.5% 和 7.4%），通常是为了构建数据可视化界面。
3. 安全（Security） 团队经常使用 Claude Code 来做代码理解（占比 48.9%），尤其是用于分析和理解代码库中不同部分的安全影响。
4. 非技术背景员工 通常用 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 如何改变工作，更希望从自身出发，探索如何更好地面对这场变化。

原文：How AI Is Transforming Work at Anthropic 作者：Saffron Huang, Bryan Seethor, Esin Durmus, Kunal Handa, Miles McCain, Michael Stern, Deep Ganguli 原文链接：https://anthropic.com/research/how-ai-is-transforming-work-at-anthropic/

我们创建了一个高质量的技术交流群，与优秀的人在一起，自己也会优秀起来，赶紧 点击加群 ，享受一起成长的快乐。