Claude 母公司 Anthropic 新发布了一份报告：调查内部 132 名工程师，进行 53 场访谈，分析 20 万条 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 增强的职场中，如何保持技术专精？如何维持有意义的人际协作？如何通过新的学习机制、师徒带教和职业发展路径，去应对那个充满不确定性的未来？我们在下文的“展望未来”部分探讨了内部正在采取的初步措施。此外，我们在最近关于AI经济政策构想的博客文章中，也探讨了潜在的政策应对方案。本节简要概述调研、访谈和 Claude Code 数据中的核心发现。详细数据、方法和说明将在后文展开。修复 Bug 和理解代码库是首选。 Anthropic 的工程师和研究员最常让 Claude 干两件事：改错代码，以及搞懂现有的代码库（图 1）。用得越多，产出越高。 员工自述在 60% 的工作中使用了 Claude，生产力提升了 50%，这是去年同期的 2-3 倍。这种效率提升并非体现为每个任务花的时间变少了，而是体现为完成的任务总量变多了（图 2）。27% 的活儿是“锦上添花”。 在 Claude 辅助完成的工作中，有 27% 属于“如果没有 AI 根本就不会做”的任务。比如扩大项目规模、制作好用的内部工具（如交互式数据仪表盘），以及那些如果人工做不太划算的探索性工作。离不开它，但不能全信它。 大多数员工高频使用 Claude，但表示能“完全甩手”给它的工作仅占 0-20%。Claude 更像是一个时刻在线的协作者，但在关键任务上，依然需要人类进行积极的监督和验证——它还没到能让人当“甩手掌柜”的地步。员工正在通过“直觉”决定放权程度。 工程师倾向于把那些容易验证的任务外包给 AI，标准是“我也能轻松一眼看出对不对”，或者是低风险任务（如“用完即弃的测试代码”），再或者是那些无聊的活儿（“我对这任务越感兴趣，就越不想用 Claude”）。许多人描述了一种信任建立的过程：从简单任务开始，慢慢试水复杂工作。虽然目前大家还把持着核心设计和“品位”把控的关口，但随着模型变强，这道边界正在被重新商定。技能树变宽了，但有些根基松动了。 Claude 让大家敢于涉足陌生领域（“我现在能很自信地搞定前端或者事务性数据库……以前我都不敢碰这些”）。但悖论在于，这种便利引发了对深度技能退化的担忧——“当产出结果变得如此容易和快速，你就越来越难静下心来去真正学习点什么了。”对“编程手艺”的看法变了。 一些工程师拥抱 AI 辅助，专注于结果（“我以为我喜欢写代码，其实我只是喜欢代码跑通带来的成果”）；但也有些人表示怀旧，“我确实怀念（写代码过程中的）某些部分。”职场社交关系网在改变。 以前遇到问题先问同事，现在 Claude 成了第一站。结果是，有人觉得获得指导和协作的机会少了。（“我喜欢和人一起工作，现在我没那么‘需要’他们了，这挺让人伤感的……初级员工也不像以前那样经常来问我问题了。”）职业生涯的进化与迷茫。 工程师们表示工作重心正转向管理 AI 系统等更高层级的任务，产出也大幅提升。但这也引发了对软件工程这一职业长远未来的质疑。有人心情矛盾：“短期我很乐观，但长期来看，AI 可能会包揽一切，让我和其他人都变得无关紧要。”还有人强调这种纯粹的不确定性，坦言“很难说”几年后自己的角色会变成什么样。Claude 正变得更自主，能扛更重的活。 六个月前，Claude Code 在需要人类介入前大约能自动执行 10 个操作。现在，这个数字变成了 20，它能在更少的人类指引下完成更复杂的工作流（图 3）。工程师越来越多地用它来处理代码设计/规划（占比从 1% 升至 10%）和实现新功能（从 14% 升至 37%）等复杂任务（图 4）。随手修补“小毛病”。 8.6% 的 Claude Code 任务是在处理那些能改善生活质量的琐碎问题，比如为了代码可维护性进行重构（也就是修复“papercuts”——那些平日里忍忍就过去的小痛点）。这些以前会被排在优先级末尾的小修小补，累积起来带来了巨大的效率提升。全员“全栈化”。 不同团队对 Claude 的用法各异，通常用来补齐自己的短板——安全团队用它分析陌生的代码，对齐与安全团队用它构建前端数据可视化界面，等等（图 5）。为了摸清 Claude 在日常工作中的真实样貌，我们对公司内部 132 位工程师和研究员展开了调研。这次调研覆盖面很广，横跨研究和产品两大职能部门，既有内部频道的广播，也有针对特定团队的定向邀约。关于调研方法的局限性，我们已在附录中详细说明；同时，我们也公开了调研问卷，希望能为同行的研究提供参考。我们请受访者对自己使用 Claude 处理各类编程任务的频率进行了评级。这些任务包括“调试”（Debug，让 Claude 帮忙修 Bug）、“代码理解”（让 Claude 解释现有的代码库）、“重构”（优化代码结构）以及“数据科学”（比如分析数据集或画柱状图）。统计结果显示，最高频的日常任务如下：超过半数（55%）的员工每天都用 Claude 进行调试；42% 每天用它来理解代码；37% 用来实现新功能。相比之下，高层设计与规划的使用频率较低（这部分工作通常还得靠人脑），数据科学和前端开发的频率也不高（这主要因为相关任务本身的总量就相对较少）。这一分布趋势，与我们在“Claude Code 使用趋势”一节中汇报的数据大致吻合。据员工自述，一年前，Claude 仅渗透了他们 28% 的日常工作，带来的生产力提升约为 20%；而如今，这两个数字分别飙升到了 59% 和 50%。这一结果也印证了我们引入 Claude Code 后观测到的硬指标——每位工程师每天合并的代码请求（PR）数量增长了 67%（详情见）。同比来看，变化堪称剧烈：一年之内，渗透率和效能几乎都翻了一番。此外，使用深度与生产力提升呈强正相关。在分布曲线的顶端，有 14% 的受访者表示效率提升超过 100%——这些就是我们内部的“超级用户”。这里需要泼一盆冷水（更多局限性详见）：生产力从来都难以精确量化。非营利 AI 研究机构 指出，经验丰富的开发者在处理非常熟悉的代码库时，往往会高估 AI 带来的效率提升。话虽如此，METR 总结的那些导致“AI 帮倒忙”的因素（例如环境庞大复杂，或需要大量隐性知识），恰恰与我们员工不愿交给 Claude 的任务高度重合（详见下文）。因此，我们报告的生产力提升，很可能反映了员工已经练就了一套“战略性委派”的技能——只把合适的活儿给 AI，而这正是 METR 研究中未曾考量的变量。当我们询问员工 Claude 如何影响具体任务的“耗时”与“产出量”时，一个有趣的模式浮现了出来：几乎在所有任务类别中，耗时都在净减少，而产出量却出现了更大幅度的净增长。图 2：分任务统计的耗时影响（左图）与产出量影响（右图）。X轴代表自述的变化：减少（负值）、增加（正值）或不变（垂直虚线）。误差棒显示 95% 置信区间。圆圈大小对应样本数量。仅统计了实际使用 Claude 执行该任务的受访者。
然而，深挖原始数据后，我们发现了两极分化的现象：虽然总体耗时减少，但也有一部分人在使用 Claude 辅助的任务上花了更多时间。一类是“善后”的成本：需要花时间调试和清理 Claude 的代码（有人戏称这是“凭直觉写代码（vibe code）把自己逼到了死角”），而且理解非自己亲手写的代码也带来了额外的认知负担。另一类则是“赋能”带来的投入：有人表示 Claude 让他们“坚持完成了以前会直接放弃的任务”；还有人说能进行更彻底的测试，或在陌生代码库中进行更多探索。总体来看，那些能省时间的工程师，似乎更擅长把“易于验证”的任务切分给 Claude；而那些花时间更多的人，往往正忙着调试 AI 生成的代码，或是在 Claude 需要更多指引的复杂领域中攻坚。目前的数据还不足以说明省下来的时间“去哪儿了”——是投入到了其他工程任务、非工程工作、与 Claude 的交互中，还是变成了工作之外的闲暇？我们的任务分类框架没能捕捉到工程师时间分配的全貌，而且自述的“省时”也可能存在感知偏差。这需要后续研究来剥离干扰因素。相比之下，产出量的增长则更为直观且显著。几乎所有任务类别的产出都在大幅净增。这个逻辑很通顺：大家并不是不做某类任务了（比如“调试”），而是在这类任务上，虽然单次耗时略有下降，但产出的总量却多得多了。虽然生产力难以直接测量，但这些自述数据表明，AI 在 Anthropic 提升生产力的主要方式，是带来巨大的产出增量。我们一直心存疑问：Claude 究竟是开启了前所未有的新工作领域，还是仅仅充当了加速器，把本该由人完成的工作提前了？员工的估算给出了答案：在 Claude 辅助完成的工作中，有 27% 若无 AI 相助，根本就不会发生。工程师们列举了种种场景：或用于项目的大规模扩张，或搞些“锦上添花”的功能（比如交互式数据仪表盘）；或是写文档、做测试这类枯燥却必要的基础工作；又或是那些靠人力去试错成本太高、本来不划算的探索性工作。有人打了个比方，现在终于能腾出手来处理那些长期影响体验的“芒刺”了——比如重构那些结构糟糕的代码，或者随手造个小工具来给主任务提速。我们在后台数据中也印证了这一点：8.6% 的 Claude Code 任务确实是在“拔刺”。另一位研究员提到，他会让多个 Claude 实例齐头并进，分头探索解题思路：“人们常把大模型想象成一个单点，像是一辆跑得更快的车。但如果你拥有一万匹马……你就能同时验证无数个点子……这种广度带来的探索空间，才是激发创造力的关键。”正如下文将要展示的，这类“新工作”往往意味着工程师要跨出自己的专业舒适区。尽管工程师们频繁使用 Claude，但超过半数的人表示，真正能完全交给 AI、自己当“甩手掌柜”的工作，占比不到 20%。（当然，“完全放权”的定义因人而异——有人觉得是完全不用看，有人觉得是只需扫一眼。）究其原因，工程师们描述的是一种“人机共舞”的状态：反复迭代、核验输出。尤其是在任务复杂、或对代码质量要求极高的关键领域，必须有人把关。这表明，大家倾向于把 Claude 当作紧密的合作伙伴，而非无需过问的外包工。对于什么是“完全放权”，工程师们的门槛设得很高。问卷数据虽然揭示了效率的提升，但数字不仅冰冷，也掩盖了工程师们每天真实的所思所感。为了探究这背后的“人味儿”，我们深度访谈了 53 位参与问卷的 Anthropic 工程师和研究员。大家在实战中逐渐摸索出了一套策略，对于把什么活儿派给 Claude，有着明确的判断标准：盲区里的简单活 | 只要是我不熟悉但又不复杂的活，全给它。比如好多基础设施的问题其实不难，但我对 Git 或 Linux 一知半解……这时候 Claude 就能完美补位。 |
一眼能看穿的 | 如果检查一遍的时间远少于自己写的时间，那用它简直爽翻了。 |
独立成块的 | 只要某个模块跟其他部分解耦得够干净，我就让 Claude 先试一手。 |
不求完美的 | 那种用完即弃的调试代码或实验代码，直接扔给 Claude。但要是涉及核心概念、复杂的调试注入或架构设计，还得我自己来。 |
枯燥乏味的 | 越是想做的事，我越不用 Claude；越是心里抵触、不想动手的……我就越容易找 Claude 聊聊。” <br>调查显示，平均有 44% 的 AI 辅助工作是大家本就不想干的苦差事。 |
动嘴不如动手的 | 要是这事儿我也就花十分钟，那就不麻烦 Claude 了。”<br>“现在最大的障碍是‘冷启动’——很多代码库的潜规则只有我懂，Claude 不知道。与其费劲写提示词教它，不如我自己直接搞定。 |
员工们提到的这些考量，与 METR 的一份不谋而合。那里也指出，如果开发者对代码库太熟，或者仓库太大太杂，AI 提效反而受阻。这种共识告诉我们：选对任务，是 AI 提效的关键（这一点在未来的生产力研究中应作为重要变量加以控制）。许多用户都提到，他们对 Claude 的依赖是循序渐进的：起初只是试探性地把简单的活儿交给它，后来才逐渐加码。“起初我只拿它问点 Rust 语言的基础问题……但这阵子，我写代码已经全靠 Claude Code 了。”有位工程师打了个精妙的比方，把这种信任的建立过程比作使用谷歌地图：“刚开始，我只在去陌生地方时才开导航……这就好比让 Claude 写我不懂的 SQL，但绝不会让它写我拿手的 Python。后来，哪怕是熟路，为了搞定‘最后两公里’，我也开始用导航……到了今天，我上下班都离不开它了。如果它让我换条路走，我会照做，因为我相信它已经算过了所有方案……我现在用 Claude Code 也是这个路数。”关于是在自己擅长的领域用，还是在不擅长的领域用，工程师们看法不一。一派人把它当“外包”，专门处理辅助性领域，省时省力；另一派更愿意在舒适区里用，因为方便核查（“只有在我完全能看懂它在干嘛的时候，我才用”）。一位安全工程师特别指出了经验的重要性，因为 Claude 给出的方案有时“聪明得让人后背发凉——就像那种才华横溢但经验不足的初级工程师写出来的代码”。也就是说，这种代码里的隐患，只有具备判断力的老手才能一眼看穿。还有些工程师属于“通吃型”，要么干脆“遇事不决先问 Claude”，要么看菜下碟，根据自己对任务的熟悉程度调整策略：“对于我的核心专业领域，我把它当加速器，因为我知道大概会得到什么结果，也能有效地引导它；对于稍微超纲的领域，我虽然心里有数，但可能记不清具体定义，就让 Claude 来填补这些记忆空白。”“如果是行家里的活儿，我会强势一点，明确告诉 Claude 去查什么。如果是我拿不准的，我就让它扮演专家，给我出谋划策，列出我该考虑和研究的方向。”大家一致认为：涉及顶层战略、需要组织背景或体现“品味”的设计决策，还得靠人。一位工程师解释道：“宏观构思和设计我通常自己把关。至于其他的，从开发新功能到修 Bug，能甩出去的我都甩给它。”调查数据也印证了这点：在设计和规划任务上，生产力的提升幅度最小（见图2）。不过，这根“红线”也是动态的。随着模型变强，大家也在不断重新划定边界（Claude Code 的使用数据表明，相比半年前，现在交给它做的代码设计和规划任务明显变多了）。调查发现，27% 由 Claude 辅助完成的工作，如果没有 AI 根本就不会发生。这反映出一个大趋势：工程师们正在突破自己的技能边界。许多员工报告说，他们搞定了不少以前干不了的活儿——后端工程师搭起了前端 UI，研究员做出了数据可视化。一个后端工程师描述了他如何靠 Claude “磨”出了一个复杂的 UI：“它干得比我漂亮多了。要我自己弄，且不说能不能做出来，按时交付肯定是没戏……设计师看到都惊了：‘等等，这是你做的？’ 我说：‘不，Claude 做的，我就是个提示词输入员。’”工程师们觉得自己越来越像“全栈”了……“我现在的能力足以应付前端、事务性数据库或者 API 代码，以前碰到这些不熟的技术栈，我可是绕着走的。”这种能力的延伸带来了更紧密的反馈循环——以前需要几周的“开发-约会-修改”流程，现在拉上同事开个几小时的“现场编程会”就能搞定。总体而言，大家对这种新常态很兴奋：原型出得快、多线程并行、脏活累活少了，心气儿也高了。一位资深工程师告诉我们：“这些工具无疑让初级工程师效率更高了，胆子也更大了，什么项目都敢接。”还有人提到，Claude 降低了“启动门槛”，治好了拖延症。“它极大地降低了我想解决一个问题所需的心理建设成本，所以我现在愿意去攻克更多额外的难题。”与此同时，另一种担忧也在蔓延：随着我们把越来越多的活儿甩出去，自身的技能会不会「用进废退」？更要命的是，我们正在失去那种「伴随性学习」（incidental learning）的机会——也就是以前我们在亲自排查故障时，顺带学到的那些东西。「以前为了修一个棘手的 bug，我得把文档翻个底朝天，还得读好多看似无关的代码。虽然这些功夫对解决眼前的问题没直接用处，但在这个过程中，我建立了一套关于系统如何运转的完整认知。这种构建认知的过程现在少多了，因为 Claude 直接就能把答案喂到嘴边。」「以前为了摸透一个新工具，我会把所有配置项都试一遍，看看它到底能干嘛；现在全靠 AI 告诉我怎么用，结果反而没了那份专业底气。以前跟队友讨论，我脑子里立马能调出知识点；现在？稍等，我得先问问 AI。」「用 Claude 最大的隐患在于，它让我跳过了『通过解决简单问题来练手』的阶段。结果真等到以后遇到复杂难题时，我反而抓瞎了。」一位资深工程师直言，如果自己还是个菜鸟，恐怕会焦虑得多：「我现在主要在心里大概知道答案该长什么样的时候才用 AI。这种直觉是我当年硬着头皮、一步一个脚印写代码练出来的（doing SWE 'the hard way'）……但如果我还是个初出茅庐的新手，恐怕得极度自律，才能克制住全盘接受大模型输出的冲动，逼自己去真正成长。」编程技能退化的核心症结，在于所谓的「监管悖论」（paradox of supervision）——就像前面提到的，想用好 Claude，你得盯着它；可要盯着它，你自己得懂行。如果你因过度依赖 AI 而导致技能退化，恰恰会失去这种「懂行」的能力。「老实说，相比于具体技能的生疏，我更担心的是『瞎指挥』。如果我的技术废了，最大的问题不是我能不能独立干活，而是我还有没有能力安全地驾驭 AI 去干我在乎的活。」为了对抗这种「脑力萎缩」，一些工程师开始刻意进行「无 AI 训练」：「偶尔即便我知道 Claude 能秒杀这个问题，我也偏不用。这是为了给自己磨刀，保持敏锐。」也许，软件工程只是像过去一样，正在向更高的抽象层级跃迁。早期的程序员那是真的「贴着机器写」，手动管理内存、写汇编语言，甚至还得拨动物理开关输入指令。后来，更像人话的高级语言出现了，把那些繁琐的底层操作都打包自动化了。如今，随着「Vibe Coding」（凭感觉编程）的兴起，英语本身可能正在变成一种编程语言。正如我们一位员工建议的那样，未来的工程师应该「擅长指挥 AI 写代码，把精力集中在理解更高层的概念和模式上」。不少员工觉得这种转变是种解放——让他们能从更高维度思考，「多想想最终产品和用户」，而不是死磕代码。有人拿计算机科学里的「链表」做比喻：这是以前的基础必修课，现在高级语言早就自动搞定了。「我很庆幸我懂那个原理……但实操中去写那些底层代码？没那个必要，也没那份情怀。我更在意代码能帮我实现什么。」另一位工程师在赞同之余也指出了代价：抽象层级越高，丢失的深度理解就越多——就像现在的工程师大多已经不懂内存管理的门道了。尽管保留专业技能确实能让你更好地监督 Claude，干活也更利索（「我发现如果是熟门熟路的领域，我自己写往往比 AI 快」），但在「这事儿到底重不重要」上，工程师们分歧很大。「我不太担心技能腐蚀。AI 反而逼着我把问题想得更透彻，还教会了我不少新路子。真要说起来，这种快速试错的能力反而加速了我的学习。」「我的软件工程手艺肯定是在退步……但真到了非用不可的时候，捡起来就是了，关键是现在根本用不上啊！」丢掉的都是些画图表之类的皮毛技能，「真正核心的代码，我依然写得溜得飞起。」「所谓的『生锈论』基于一个假设——即编程总有一天会退回到 Claude 3.5 出现之前的样子。还想不想念亲手写代码的感觉？在这个问题上，工程师们的态度两极分化。有人感到实实在在的失落：“对我来说，一个时代结束了。我敲了25年代码，那种‘我很在行’的胜任感，本是我职业满足感的核心。”也有人担心这剥夺了工作的乐趣：“整天给Claude写提示词（Prompting）既没意思也没成就感。还是放点音乐，进入状态，亲手实现个什么功能更爽。”另一些人则直面这种权衡，并坦然接受：“我确实怀念某些环节——比如重构代码时那种‘禅定’般的心流状态。但总体来说，现在的效率实在是高太多了，我愿意为此放弃前者。”甚至有人觉得跟Claude打交道更有趣，因为对它挑刺儿可比对人挑刺儿容易多了，不用顾忌面子。“我本以为到现在我会感到恐慌或者厌倦……结果都没有。相反，我很兴奋，因为我能做的事变多了。我原以为我热爱的是‘写代码’本身，原来我真正享受的是代码带来的‘成果’。”到底是拥抱AI助手，还是悼念逝去的编程时光？这似乎取决于你眼中的软件工程，究竟哪一部分最有意义。一个最显著的变化是：Claude成了许多问题的“第一站”，以前这些问题都是去问同事的。“我现在问的问题比以前多多了，但八九成先丢给Claude，”一位员工提到。这形成了一层“过滤器”：Claude搞定日常琐事，同事只处理那些复杂的、需要战略眼光或深厚背景的难题（“它帮我减少了80%对他人的依赖，但剩下的20%至关重要，还得靠人”）。大家也开始拿Claude当“陪练”，像跟真人搭档一样跟它碰撞思路。约有一半人表示团队协作模式没变。一位工程师说，开会、对齐背景、定方向还得靠人，但未来即使还得协作，可能不再是大家各自埋头苦干，而是“你得跟好几个Claude同时对话”。然而，也有人发现跟同事的互动变少了（“我现在跟Claude共事的时间远超任何同事”）。有人庆幸这种社交摩擦的减少（“不用占用同事时间，心里没负担”）；也有人抗拒这种冷漠（“我挺讨厌别人回一句‘你问过Claude了吗’，我更喜欢面对面交流并珍视这种连接”）；或者怀念旧时光：“我不那么‘需要’同事了，这事儿想想挺伤感的。”传统的师徒带教关系也受到了冲击，因为现在是Claude在给职场新人当教练，而不是资深工程师。一位老资历的工程师感慨道：“挺失落的，新人不怎么来问我问题了。虽说他们确实得到更快的解答，学得也更快了。”许多工程师形容自己的角色发生了转变：从“写代码的”变成了“AI管理员”。大家越来越觉得自己像是在管理一群AI代理（Agents）——有人手头时刻跑着好几个Claude实例。有人估算，70%以上的工作变成了代码审查和修改，不再是产出新代码；还有人认为未来就是“对1个、5个甚至100个Claude产出的工作负责”。放眼长远，迷茫情绪弥漫。工程师们将这些变化视为行业剧变的先兆，关于几年后的饭碗长啥样，大家都觉得“很难说”。一种矛盾的心态很普遍：短期乐观，长期焦虑。“短期看挺乐观，长期看AI可能包圆了一切，把我和其他人都淘汰掉，”一位受访者直言。还有人说得更扎心：“感觉每天上班都在忙着砸自己的饭碗。”当然也有乐观派。有人说：“我确实替新人捏把汗，但新人往往对新技术最求知若渴。我觉得这行的前景总体还是好的。” 他们认为，虽然经验不足的工程师可能由AI辅助产出问题代码，但随着AI护栏更完善、教育资源更丰富，加上从错误中自然学习，行业自会适应。我们问大家对未来角色有何设想，以及有什么应对策略。有人计划走向专精（“要有能力审查AI的代码，你需要更深更专的功力”）；有人准备转向更偏人际和战略的工作（“我们负责达成共识，让AI负责具体实现”）。还有人直接拿Claude当职业导师，用它来打磨工作成果和领导力（“学习效率的天花板直接被掀翻了，哪怕没完全学会，也能高效产出”）。总的来说，不确定性是唯一的确定。“对于未来哪些技能有用，我非常没信心。” 一位团队负责人总结道：“没人知道未来会怎样……关键在于，你得时刻准备着，灵活应变。”问卷与访谈揭示了一个明显的趋势：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。这 0.6 的分差意味着什么？3.2 分的任务通常是“排查 Python 模块导入错误”，而 3.8 分的任务则是“实现并优化缓存系统”。单次对话中的连续工具调用上限增长了 116%。 所谓“工具调用”，即 Claude 自主调用外部工具（如编辑文件、运行指令）的操作。如今，Claude 已能自主串联 21.2 次独立操作而无需人工干预，而在六个月前，这一数字仅为 9.8 次。人类介入的频次下降了 33%。 平均每段对话中，人类的交互轮次从 6.2 降至 4.1。这表明，完成同样一项任务，现在所需的人工指引比半年前更少。图 3：Claude Code 使用情况变化对比（2025年2月 vs 2025年8月）。随时间推移，平均任务复杂度上升（左图），单次对话最大连续工具调用数增加（中图），人类交互轮次减少（右图）。误差线表示 95% 置信区间。数据表明，人们正逐步给予 Claude 更高的自主权。
实际使用数据与问卷结果不谋而合：工程师正将越来越复杂的工作委托给 Claude，且所需的监督越来越少。这很有可能是生产力显著提升背后的真实推手。我们对 Claude Code 的交互记录进行了任务分类，以观察过去半年间不同用途的消长：图 4：各类编程任务占比分布（纵轴）与总记录数百分比（横轴）的关系。对比了半年前（粉色）与当下（紫色）的分布情况。纵轴按 2025 年 2 月的频率排序。
后台数据的任务频率分布与员工自述大致吻合。而在 2025 年 2 月至 8 月间，最引人注目的变化在于：利用 Claude 开发新功能（14.3% → 36.9%）以及进行代码设计或规划（1.0% → 9.9%）的比例大幅跃升。这种任务重心的转移，既可能意味着 Claude 在处理复杂任务上能力精进，也可能反映了团队在不同工作流中对 Claude Code 采用方式的转变，而未必仅仅是绝对工作量的增加（局限性详见附录）。问卷调查发现，工程师现在投入更多时间在改善“生活质量”的小修小补上。数据显示，当前 8.6% 的 Claude Code 任务属于“痛点修复”（papercut fixes）。这类任务跨度很大：大到创建性能可视化工具、重构代码以提升可维护性，小到创建终端快捷指令。这些改进虽然琐碎，却能有效减少日常工作的摩擦与挫败感，通过解决由于历史遗留问题带来的效率瓶颈，潜移默化地推动了生产力的提升。为探究不同团队的使用习惯，我们将 8 月份的每条记录归类为一个主任务，并按团队拆解。堆叠柱状图展示了各团队的任务构成：图 5：每一横条代表一个团队（纵轴），色块分段表示该团队使用 Claude Code 进行不同编程任务（横轴）的比例，按任务类型颜色编码（图例）。顶部的“All Teams”代表整体分布。
“All Teams”一栏展示了全公司的整体分布，最常见的任务是构建新功能、调试和代码理解。这为观察各团队的特性提供了基准。- 预训练团队（负责协助训练 Claude）：主要用于构建新功能（54.6%），其中很大一部分是运行额外的实验。
- 对齐与安全团队及后训练团队：最常使用 Claude Code 进行前端开发（分别为 7.5% 和 7.4%），通常是为了创建数据可视化工具。
- 安全团队：高度依赖 Claude Code 进行代码理解（48.9%），特别是分析和理解代码库中不同部分的安全性影响。
- 非技术员工：主要用于调试（51.5%），如排查网络问题或 Git 操作，以及数据科学任务（12.7%）。Claude 似乎成为了填补技术知识鸿沟的重要桥梁。
这些团队特有的使用模式，印证了我们在调研中观察到的“能力扩张”现象：Claude 让团队得以涉足那些以前没时间做、或者没技能做的新工作。例如，预训练团队跑了更多的实验，非技术员工也能自己修复代码错误。数据还揭示了一个有趣的现象：团队不仅用 Claude 处理核心业务（如基础设施团队主要用它做运维），更用它来增强非核心能力（如研究员用它写前端来可视化数据）。这表明，Claude 正赋能每一位员工，让他们在工作中逐渐向“全栈”迈进。过去这一年，Anthropic 内部对 Claude 的使用早已不可同日而语。这不仅仅是为手头的工作加速，大家更在利用它熟悉陌生的代码库、从繁琐的机械劳动中抽身、涉足全新的业务领域，甚至回头去填补那些往日无暇顾及的技术债。随着 Claude 愈发独立干练，工程师们在探索如何“放权”给 AI 的同时，也在反思自己未来的核心竞争力。这种转变带来了肉眼可见的效率提升和学习红利，但也给软件工程的长期走向蒙上了一层迷雾。AI 的介入，究竟是像过去从低级语言向高级语言的进化？还是像从“单兵作战”到“管理团队”的职能跃迁？亦或是，它将把我们带向一个从未涉足的远方？必须承认，一切尚处草莽阶段。Anthropic 内部有一群热衷尝鲜的“早鸟”，但技术迭代瞬息万变，我们在公司内部看到的景象，未必能代表外界的广阔天地（详见附录中的局限性说明）。这份研究本身也充满了这种“不确定性”：结论并不单一，没有标准答案，只有错综复杂的现实。但它向我们抛出了一个核心命题：如何在巨变中深思熟虑、行之有效地把稳这一舵？为了回应这些初探，我们已迈出下一步。我们正与内部的工程师、研究员及管理层深度对话，直面机遇与挑战。这包括重新审视团队协作模式，探索职业成长路径，并着手建立 AI 辅助工作的最佳实践（例如以我们的AI fluency framework为指引）。我们的视野也不再局限于工程师，而是扩展至全公司的各个角色，去理解 AI 转型带来的全方位冲击；同时，我们也支持像 CodePath 这样的外部机构，协助他们调整计算机科学课程，以适应人机协作的未来。放眼长远，随着 AI 能力精进，我们在构思更底层的组织架构变革，比如职能演进的新路径，或是内部的技能重塑机制。待到 2026 年思考更成熟时，我们会分享更具体的规划。Anthropic 本身就是一场“负责任职场转型”的实验；我们不仅要观察 AI 如何重塑工作，更要亲身试水，探索如何稳妥地驾驭这场变革——这一切，先从我们自己开始。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 提出的富有成效的建议与讨论表示衷心感谢。我们的问卷调查在方法论上存在一定局限。我们在选人时采用了便利抽样（Convenience Sampling）和目的抽样（Purposive Sampling）相结合的方式，以期覆盖更广泛的组织职能。我们在多个内部 Slack 频道发布了问卷，回收了 68 份答卷；同时，我们也从组织架构图中特意挑选了 20 个涵盖研究与产品职能的多元化团队，每个团队定向联系了 5-10 人（共触达 207 人），最终获得 64 份有效回复（响应率 31%）。随后，我们对前 53 位受访者进行了深入访谈。这里难免存在幸存者偏差（Selection Bias）：那些对 Claude 极度依赖或抱有强烈观点（无论好坏）的人往往更愿意发声，而体验平淡的“沉默大多数”可能被忽略了。此外，社会期许误差（Social Desirability Bias）也不容忽视——毕竟这不是匿名调查，面对自家产品，受访者可能下意识地美化了 AI 的作用。同时还存在近因效应（Recency Bias），让人回忆 12 个月前的生产力状态，记忆难免会出现偏差。毕竟，生产力本身就是一个难以量化的模糊概念，因此对于这些主观自述，读时不妨多一份审慎。这些主观感知应与客观的 Claude Code 使用数据互为参照，未来的研究若能采用匿名数据收集和更严谨的测量工具，将会更加扎实。关于 Claude Code 的分析使用了分层比例抽样，这意味着我们看到的是任务权重的“此消彼长”，而非工作总量的绝对增减。举个例子，如果说“功能实现”的占比从 14% 涨到了 37%，这并不一定意味着我们写了两倍的功能代码，而是说在所有操作中，这类工作变得更突出了。最后，本研究定格于 2025 年 8 月，彼时的当家模型还是 Claude Sonnet 4 和 Claude Opus 4。AI 进化一日千里，随着新模型问世，我们要讲述的故事可能早已翻开了新的一页。
立即咨询 JOTO
JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务，帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。 联系 JOTO 获取 AI 落地咨询
