2025-12-03 08:00:00
原文： https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic
作者： Saffron Huang, Bryan Seethor, Esin Durmus, Kunal Handa, Miles McCain, Michael Stern, Deep Ganguli
译者： Gemini 2.5 Pro
AI 是如何改变我们的工作方式的？我们之前关于 AI 经济影响的研究着眼于整个劳动力市场，涵盖了各种不同的工作。但如果我们更深入地研究 AI 技术的首批使用者——也就是我们自己，会怎么样？
我们将镜头转向内部，在2025年8月，我们调研了 132 名 Anthropic 工程师和研究员，进行了 53 次深度定性访谈，并研究了内部 Claude Code 的使用数据，以了解 AI 的使用正在如何改变 Anthropic。我们发现，AI 的使用正在从根本上改变软件开发者的工作性质，这既带来了希望，也引发了担忧。
我们的研究揭示了一个正在经历重大变革的工作场所：工程师们完成的工作量大大增加，变得更加“全栈”（full-stack），即能够胜任超出其常规专业领域的任务，他们加快了学习和迭代的速度，并开始处理以前被忽略的任务。这种工作广度的拓展也让人们思考其中的权衡——一些人担心这可能意味着失去更深层次的技术能力，或者无法有效监督 Claude 的输出，而另一些人则拥抱这个机会，以更广阔、更高层次的视角进行思考。一些人发现，与 AI 的协作越多，意味着与同事的协作越少；还有一些人则在想，自己最终是否会把自己自动化掉。
我们认识到，在一家开发 AI 的公司研究 AI 的影响，意味着我们处在一个特殊的位置——我们的工程师能优先接触到最前沿的工具，在一个相对稳定的领域工作，并且他们自己也在为影响其他行业的 AI 转型做出贡献。尽管如此，我们认为研究并公布这些发现总体上是有益的，因为 Anthropic 工程师们正在经历的变化，可能仍然是更广泛社会变革的一个有启发性的预兆。我们的发现揭示了一些挑战和考量，可能值得各行各业及早关注（不过，请参阅附录中的局限性部分以了解注意事项）。在收集这些数据时，Claude Sonnet 4 和 Claude Opus 4 是当时最强大的模型，而模型的能力还在不断进步。
更强大的 AI 带来了生产力的提升，但它也引发了一些问题：如何保持技术专长，如何维系有意义的协作，以及如何为一个不确定的未来做准备。这个未来可能需要在 AI 增强的工作场所中采用新的学习、指导和职业发展方法。在下文的“展望未来”部分，我们讨论了公司内部为探索这些问题而采取的一些初步措施。我们也在最近关于 AI 相关经济政策构想的博文中探讨了可能的政策应对方案。
在本节中，我们简要总结了我们的调研、访谈和 Claude Code 数据的发现。我们将在下文的章节中提供详细的发现、方法和注意事项。
调研数据
定性访谈
Claude Code 使用趋势
我们调研了来自公司各部门的 132 名 Anthropic 工程师和研究员，了解他们对 Claude 的使用情况，以便更好地理解他们日常究竟是如何使用它的。我们通过内部沟通渠道分发了问卷，并直接联系了代表研究和产品职能的多个不同团队的员工。我们在附录的局限性部分包含了更多方法论的细节，并分享了我们的问卷问题，以便他人可以评估我们的方法并将其用于自己的研究。
我们请接受调研的工程师和研究员评估他们使用 Claude 进行各类编程任务的频率，例如“调试”（debugging，用 Claude 帮助修复代码错误）、“代码理解”（code understanding，让 Claude 解释现有代码以帮助用户理解代码库）、“重构”（refactoring，用 Claude 帮助重构现有代码）以及“数据科学”（data science，例如让 Claude 分析数据集并制作条形图）。
以下是最常见的日常任务。大多数员工（55%）每天都使用 Claude 进行调试。42% 的人每天使用 Claude 进行代码理解，37% 的人每天使用 Claude 实现新功能。频率较低的任务是高层级的设计/规划（可能是因为人们倾向于将这些任务掌握在自己手中），以及数据科学和前端开发（可能是因为这些任务总体上不太常见）。这与“Claude Code 使用趋势”部分报告的 Claude Code 使用数据分布大致相符。
图1：各类编程任务（y轴）的每日用户比例（x轴）。
员工自述，12 个月前，他们在 28% 的日常工作中使用 Claude，并从中获得了 20% 的生产力提升；而现在，他们在 59% 的工作中使用 Claude，平均生产力提升了 50%。（这与我们在整个工程部门采用 Claude Code 后观察到的每位工程师每日合并的 pull requests——即成功并入代码的变更——增加 67% 的情况大致相符。）年度对比相当显著——这表明在一年内，这两项指标都增长了两倍以上。使用率和生产力也密切相关，在分布的极端情况下，14% 的受访者通过使用 Claude 将生产力提高了 100% 以上——这些是我们的内部“超级用户”。
需要说明的是（以及下文其他自述的生产力发现），生产力很难精确衡量（更多局限性请参见附录）。AI 研究非营利组织 METR 的近期研究表明，经验丰富的开发者在非常熟悉的代码库上与 AI 合作时，会高估 AI 带来的生产力提升。话虽如此，METR 发现的导致生产力低于预期的因素（例如，AI 在大型、复杂的环境中表现较差，或者需要大量隐性知识/上下文），恰好与我们的员工所说他们不会委托给 Claude 的任务类型相对应（见下文的AI 委托方法）。我们员工自述的跨任务的生产力提升，可能反映了他们发展出了战略性的 AI 委托技能——这一点在 METR 的研究中并未考虑。
当询问员工，在他们目前使用 Claude 的任务类别中，Claude 如何影响他们在该类别上的总耗时和工作产出量时，一个有趣的生产力模式出现了。在几乎所有任务类别中，我们都观察到耗时的净减少，以及产出量的更大幅度的净增加：
图2：按任务（y轴）划分，对耗时（左图）和产出量（右图）的影响。每张图的 x 轴对应与不使用 Claude 相比，在 Claude 辅助的任务类别中，自述的耗时或产出量的减少（负值）、增加（正值）或无变化（垂直虚线）。误差线显示 95% 置信区间。圆圈面积与每个评分点的回复数成正比。仅包含报告在每个任务类别中使用 Claude 的受访者。
然而，当我们深入研究原始数据时，我们发现节省时间的回答聚集在两个极端——有些人在 Claude 辅助的任务上花费的时间反而显著增加了。
为什么会这样？人们普遍解释说，他们需要花更多时间调试和清理 Claude 的代码（例如，“当我自己凭感觉写代码把自己绕进去时”），并且因为代码不是自己写的，理解它需要承担更多的认知负荷。一些人提到，在某些情况下花更多时间是一种赋能——有人说，使用 Claude 帮助他们“坚持完成以前可能立刻就放弃的任务”；另一个人说，它帮助他们进行更彻底的测试，以及在新的代码库中进行更多的学习和探索。总的来说，似乎节省了时间的工程师，可能是那些为 Claude 划定易于快速验证任务范围的人，而花费更多时间的人，可能是在调试 AI 生成的代码，或是在 Claude 需要更多指导的领域工作。
我们的数据也无法清楚地表明，节省下来的时间被重新投入到了哪里——是投入到额外的工程任务、非工程任务、与 Claude 互动或审查其输出，还是工作之外的活动。我们的任务分类框架并未涵盖工程师可能分配时间的所有方式。此外，节省时间的感觉可能反映了自述中的感知偏差。需要进一步的研究来理清这些影响。
产出量的增加则更为直接和显著；所有任务类别的净增长都更大。当我们考虑到人们报告的是任务类别（例如整个“调试”类别）而非单个任务时，这个模式就说得通了——也就是说，人们可以在调试这个类别上花费稍少的时间，但总体上产出更多的调试工作。生产力很难直接衡量，但这些自述数据表明，在 Anthropic，AI 提升生产力主要是通过增加产出量来实现的。
我们好奇的一点是：Claude 是在催生性质上全新的工作，还是说那些 Claude 辅助的工作，员工最终也会完成（尽管可能速度会慢一些）？
员工们估计，他们通过 Claude 辅助完成的工作中，有 27% 是若没有 Claude 就不会去做的。工程师们举例说，他们使用 AI 来扩展项目、制作“锦上添花”的功能（例如交互式数据看板）、完成有用但繁琐的工作（如文档和测试），以及进行手动操作不划算的探索性工作。正如一个人解释的，他们现在可以修复更多以前影响工作体验的“小毛病”（papercuts），比如重构结构糟糕的代码，或者构建“能帮助更快完成另一项任务的小工具”。我们也在使用数据分析中寻找这一点，并发现 8.6% 的 Claude Code 任务涉及“修复小毛病”。
另一位研究员解释说，他们会同时运行多个版本的 Claude，让它们各自探索解决一个问题的不同方法：
人们倾向于将超强模型看作一个单一实例，就像得到一辆更快的车。但拥有一百万匹马……让你能测试一大堆不同的想法……当你拥有了这种额外的探索广度时，会感到兴奋，也更有创造力。
正如我们将在下文看到的，这种新工作常常涉及工程师们处理其核心专长之外的任务。
尽管工程师们频繁使用 Claude，但超过一半的人表示，他们只能将 0-20% 的工作“完全委托”给 Claude。（值得注意的是，受访者对“完全委托”的理解可能有所不同——从完全不需要验证的任务，到足够可靠、只需轻度监督的任务。）在解释原因时，工程师们描述了他们与 Claude 主动地、迭代地合作，并验证其输出——尤其是在复杂任务或代码质量标准至关重要的高风险领域。这表明，工程师们倾向于与 Claude 密切合作并检查其工作，而不是不经验证就交出任务，并且他们对何为“完全委托”设定了很高的标准。
虽然这些调研发现揭示了显著的生产力提升和工作模式的变化，但它们也引出了一个问题：工程师们在日常工作中究竟是如何体验这些变化的。为了理解这些数据背后的人为因素，我们对 53 名参与调研的 Anthropic 工程师和研究员进行了深度访谈，以更深入地了解他们对工作场所变化的所思所感。
工程师和研究员正在开发各种策略，以便在工作流程中高效地利用 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 就不会完成，这反映了一个更广泛的模式：工程师正利用 AI 在其核心专业领域之外工作。许多员工报告称，他们完成了以前超出其专业范围的工作——后端工程师构建用户界面；研究员创建可视化图表。一位后端工程师描述了他通过与 Claude 迭代构建一个复杂用户界面的过程：“它做得比我能做的任何时候都好。我本来是做不到的，肯定无法按时完成……（设计师们）都说‘等等，这是你做的？’我说‘不，是 Claude 做的——我只是给了它提示。’”
工程师们报告说正在“变得更加全栈……我现在可以很胜任地处理前端、事务性数据库或 API 代码，而以前我可能会害怕去碰那些我不太擅长的东西。” 这种能力扩展使得反馈循环更紧密，学习速度更快——一位工程师说，一个原本需要“几周时间”的构建、安排会议和迭代的过程，现在可以变成“几小时的工作坊”，同事们在场提供实时反馈。
总的来说，人们对自己新获得的能力感到兴奋，包括快速制作原型、并行处理工作、减少重复劳动，以及普遍提升了他们的抱负水平。一位资深工程师告诉我们：“这些工具确实让初级工程师的生产力更高，也更有勇气去承担各种类型的项目。” 还有人说，使用 Claude 降低了“启动能量”，使他们更容易克服拖延症，“极大地减少了我想开始解决一个问题所需的能量，因此我愿意去处理更多额外的事情。”
与此同时，一些人担心“随着委托得越来越多，技能会退化”，并失去在手动解决问题过程中发生的附带（或“ collateral”）学习：
如果你自己去调试一个难题，你会花时间阅读那些对解决问题并非直接有用的文档和代码——但在这整个过程中，你都在构建一个关于系统如何工作的模型。现在这种情况少了很多，因为 Claude 可以直接带你找到问题所在。
我过去常常探索每一个配置，以了解工具能做什么，但现在我依赖 AI 告诉我如何使用新工具，所以我缺乏这方面的专业知识。在与团队成员的对话中，我过去能立刻回忆起事情，而现在我必须去问 AI。
使用 Claude 可能会跳过我通过解决一个简单实例来学习如何执行一项任务的环节，导致之后在解决更复杂的实例时遇到困难。
一位资深工程师说，如果他更年轻，他会更担心自己的技能：
我主要在那些我知道答案应该是什么或长什么样的场景下使用 AI。我是通过‘硬核’方式做软件工程才培养出这种能力的……但如果我还处于职业生涯的早期，我认为需要付出很多刻意的努力来继续提升自己的能力，而不是盲目地接受模型的输出。
编程技能的退化之所以令人担忧，其中一个原因是“监督悖论”——如上所述，有效使用 Claude 需要监督，而监督 Claude 所需的正是那些可能因过度使用 AI 而退化的编程技能。有人说：
老实说，比起我具体的技能集，我更担心监督和监管问题……我的技能退化或未能发展，主要会在我安全使用 AI 完成我关心的任务的能力方面产生问题，而不是在我独立完成这些任务的能力方面。
为了对抗这一点，一些工程师会刻意不使用 AI 进行练习：“每隔一段时间，即使我知道 Claude 能搞定一个问题，我也不会去问它。这能帮助我保持敏锐。”
也许软件工程正朝着更高层次的抽象发展，这在过去也发生过。早期的程序员工作时更接近机器——手动管理内存、用汇编语言编写，甚至拨动物理开关来输入指令。随着时间的推移，更高级别、更易于人类阅读的语言出现了，它们能自动处理复杂的底层操作。也许，特别是随着“vibe coding”（凭感觉编程）的兴起，我们现在正转向将英语作为一种编程语言。我们的一位员工建议，有抱负的工程师应该“擅长让 AI（写代码），并专注于学习更高层次的概念和模式。”
一些员工表示，他们觉得这种转变使他们能够从更高的层次思考——“关于最终产品和最终用户”，而不仅仅是代码。有人将当前的转变与过去在计算机科学中必须学习链表（linked-lists）作比较——这些基本结构现在已经被更高级的编程语言自动处理了。“我很高兴我曾学会怎么做……（但）做那些底层操作在情感上并不特别重要。我更愿意关心代码能让我做什么。” 另一位工程师也做了类似的比较，但他指出，抽象是有代价的——随着向更高级语言的转变，大多数工程师失去了对内存处理的深入理解。
在某个领域持续发展技能可以带来对 Claude 更好的监督和更高效的工作（“我注意到，当处理我熟悉的事情时，我自己做通常会更快”）。但工程师们对这是否重要看法不一。一些人保持乐观：
我不太担心技能退化。AI 仍然促使我仔细思考问题，并帮助我学习新方法。如果说有什么不同的话，那就是能够更快地探索和测试想法，这加速了我在某些领域的学习。
另一个人则更务实：“我作为软件工程师的技能肯定在退化……但如果有一天需要，那些技能还能找回来，而我现在根本就不需要它们了！” 有人指出，他们只失去了像制作图表这样不太重要的技能，而“那些关键的代码我仍然能写得很好。”
也许最有趣的是，一位工程师对这个前提提出了挑战：“‘手生了’这种说法，是建立在编程总有一天会回到 Claude 3.5 之前的样子的假设之上的。而我认为不会。”
对于是否怀念亲手编码，工程师们的看法大相径庭。一些人感到真正的失落——“这对我来说是一个时代的终结——我编程 25 年了，对那套技能感到胜任是我职业满足感的核心部分。” 另一些人则担心自己不喜欢这种新的工作性质：“整天给 Claude 写提示词并不怎么有趣或有成就感。更有趣、更有成就感的是放上音乐，进入状态，然后自己实现一些东西。”
一些人直接面对这种权衡并接受了它：“（写代码）的某些部分我确实会怀念——比如在重构代码时进入一种禅意的心流状态，但总的来说，我现在生产力高太多了，我愿意放弃那些。”
有人说，与 Claude 迭代反而更有趣，因为他们可以比对人类同事更挑剔地给出反馈。其他人则更关心结果。一位工程师说：
我原以为到了这个阶段我会感到害怕或无聊……然而我并没有这些感觉。相反，我感到相当兴奋，因为我能做的事情多得多了。我原以为自己真的很喜欢写代码，但我发现，我实际上只是喜欢写代码所带来的成果。
人们是拥抱 AI 辅助，还是哀悼亲手编码的失落，似乎取决于他们认为软件工程的哪些方面最有意义。
一个比较突出的主题是，过去会问同事的问题，现在首先会问 Claude。“我现在问的问题总体上多得多，但大概 80-90% 都问了 Claude，”一位员工说。这就形成了一个过滤机制：Claude 处理常规的询问，而同事们则负责处理那些超出 AI 能力的、更复杂、更具战略性或需要大量背景信息的问题（“它减少了我对（团队）80% 的依赖，（但）最后的 20% 至关重要，我会去找他们谈”）。人们也会和 Claude “交流想法”，这与和人类合作者的互动类似。
大约一半的人报告说团队协作模式没有变化。一位工程师说，他仍然在和人开会、分享背景信息、确定方向，他认为在不久的将来，协作仍然会很多，但是“你将不再是做常规的专注工作，而是会和很多个 Claude 交谈。”
然而，其他人则描述说与同事的互动变少了（“我和 Claude 一起工作的时间比和我任何同事都多。”）一些人欣赏这种社交摩擦的减少（“我不用再为占用同事的时间而感到不好意思了”）。另一些人则抗拒这种变化（“我其实不喜欢那种‘你问过 Claude 了吗？’的普遍回应。我真的很享受和人面对面工作，并且非常珍视这一点”）或者怀念旧的工作方式：“我喜欢和人一起工作，现在我‘需要’他们的机会变少了，这挺难过的。” 有几个人指出了这对传统导师制动态的影响，因为“Claude 可以为初级员工提供大量指导”，取代了资深工程师的角色。一位资深工程师说：
更年轻的员工不像以前那样经常来问我问题了，这挺令人难过的，尽管他们的问题确实得到了更有效的解答，学习得也更快了。
许多工程师描述他们的角色正在从写代码转向管理 AI。工程师们越来越将自己视为“AI 代理的管理者”——有些人已经“经常同时运行着至少几个（Claude）实例”。有人估计，他的工作已经“70% 以上转变为代码审查者/修订者，而不是从零开始写代码的人”，另一个人则认为，他未来角色的部分工作是“为 1 个、5 个或 100 个 Claude 的工作成果负责”。
从长远来看，职业不确定性普遍存在。工程师们将这些变化视为更广泛行业变革的预兆，许多人说“很难讲”几年后他们的职业会是什么样子。一些人表达了短期乐观与长期不确定之间的矛盾。“短期内我感到乐观，但长期来看，我认为 AI 最终会做所有事情，让我和许多其他人变得无关紧要，”一位员工说。另一些人说得更直接：“感觉就像我每天来上班，都是为了让自己失业。”
一些工程师则更为乐观。一位说：“我为初级开发者担心，但我也认识到，初级开发者可能正是对新技术最渴望的群体。我总体上对这个行业的发展轨迹非常乐观。” 他们认为，虽然存在经验不足的工程师发布有问题代码的潜在风险，但更好的 AI 护栏、更多内置的教育资源，以及从错误中自然学习的结合，将帮助这个领域随时间推移而适应。
我们询问了人们如何设想自己未来的角色，以及他们是否有任何适应策略。一些人提到了进一步专业化的计划（“培养有意义地审查 AI 工作成果的技能将需要更长时间和更强的专业化”），一些人预计未来将专注于更多的人际和战略性工作（“我们将花更多时间达成共识，让 AI 花更多时间在实现上”）。有人说他专门用 Claude 来进行职业发展，从它那里获得关于工作和领导技能的反馈（“我学习事物的速度，甚至在没有完全学会的情况下就能高效工作的能力，都完全改变了。我几乎感觉自己的天花板被打破了”）。
总的来说，许多人承认存在深刻的不确定性：“对于我认为未来哪些具体技能会有用，我的信心非常低。” 一位团队负责人说：“没人知道会发生什么……重要的是要保持真正的适应性。”
调研和访谈数据显示，Claude 使用量的增加正在帮助人们工作得更快，并承担新类型的工作，尽管这也伴随着关于 AI 委托和技能发展的矛盾。然而，自述数据只讲述了故事的一部分。为了补充这一点，我们还分析了 Anthropic 各团队的实际 Claude 使用数据。由于受访者报告他们主要使用的是 Claude Code，我们使用了我们的隐私保护分析工具来分析 2025 年 2 月和 8 月的 20 万份内部 Claude Code 对话记录。
过去六个月，Claude Code 的使用已经转向了更困难、更自主的编码任务：（图3）：
图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 应用于不同工作流程的变化，而非绝对工作量的增加（更多局限性请参见附录）。
我们从调研中发现，工程师们现在花更多时间进行一些提升工作体验的小改进；与此相符的是，目前 8.6% 的 Claude Code 任务被归类为“修复小毛病”（papercut fixes）。这些任务包括创建性能可视化工具和为可维护性重构代码等较大的任务，也包括创建终端快捷方式等较小的任务。这可能有助于工程师们报告的生产力提升（解决以前被忽略的、能提升工作体验的问题，可能会随时间推移带来更高的效率），并可能减少日常工作中的摩擦和挫败感。
为了研究当前任务在不同团队之间的差异，我们改进了分类方法，为 8 月的每份对话记录分配一个主要编码任务，并按内部团队（y轴）拆分数据。堆叠条形图显示了每个团队的编码任务分解：
图5. 每个水平条代表一个团队（y轴），其中的分段显示了该团队在不同编码任务（x轴）上使用 Claude Code 的比例，按编码任务（图例）进行颜色编码。顶部的条（“所有团队”）代表总体分布。
“所有团队”条显示了总体分布，最常见的任务是构建新功能、调试和代码理解。这为特定团队的比较提供了一个基准。
值得注意的团队特定模式：
这些特定于团队的模式中，许多都展示了我们在调研和访谈中观察到的同样的能力扩展：催生了团队成员若非如此，便没有时间或技能去完成的新工作。例如，预训练团队进行了大量额外的实验，非技术员工能够修复代码中的错误。而且，尽管数据显示团队确实将 Claude 用于其核心任务（例如，基础设施团队最常使用 Claude Code 进行基础设施和 DevOps 工作），但 Claude 也常常增强了他们的核心任务（例如，研究员使用 Claude 进行前端开发以更好地可视化他们的数据）。这表明，Claude 正在让每个人在工作中都变得更加全栈。
过去一年，Anthropic 的员工大幅增加了对 Claude 的使用，他们不仅用它来加速现有工作，还用它来学习新的代码库、减少重复劳动、扩展到新领域，并处理以前被忽略的改进。随着 Claude 变得越来越自主和强大，工程师们正在发现使用 AI 委托的新方法，同时也在思考未来需要哪些技能。这些转变带来了明显的生产力和学习效益，同时也带来了对软件工程工作长期发展轨迹的真实不确定性。AI 会像过去软件工程的转型——从低级到高级编程语言，或从个人贡献者到管理者，正如几位工程师所暗示的那样吗？还是会走得更远？
现在还为时尚早——Anthropic 内部有很多早期使用者，行业格局瞬息万变，我们的发现目前可能不适用于其他组织或情境（更多局限性请参见附录）。这项研究反映了这种不确定性：研究结果是微妙的，没有形成单一的共识或明确的指导方针。但它确实提出了问题：我们如何才能深思熟虑且有效地驾驭这些变化。
作为这项初步工作的后续，我们正在采取几个步骤。我们正在与 Anthropic 的工程师、研究员和领导层交谈，以应对提出的机遇和挑战。这包括审视我们如何组织团队和相互协作，如何支持职业发展，以及/或者如何为 AI 增强的工作建立最佳实践（例如，以我们的 AI 流利度框架为指导）。我们还在将这项研究扩展到工程师之外，以了解 AI 转型如何影响整个组织的角色，并支持像 CodePath 这样的外部组织，因为他们正在为 AI 辅助的未来调整计算机科学课程。展望未来，随着 AI 能力的进步，我们也在考虑一些可能变得越来越重要的结构性方法，例如组织内部的角色演变或再培训的新路径。
随着我们思考的成熟，我们预计将在 2026 年分享更具体的计划。Anthropic 是一个负责任的工作场所转型的实验室；我们不仅想研究 AI 如何改变工作，还想实验如何深思熟虑地驾驭这种转型，从我们自己开始。
如果你想引用这篇文章，可以使用以下 Bibtex 键：
@online{huang2025aiwork,
author = {Saffron Huang and Bryan Seethor and Esin Durmus and Kunal Handa and Miles McCain and Michael Stern and Deep Ganguli},
title = {How AI Is Transforming Work at Anthropic},
date = {2025-12-02},
year = {2025},
url = {https://anthropic.com/research/how-ai-is-transforming-work-at-anthropic/},
}
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, and Heather Whitney 提供了有益的想法、讨论、反馈和支持。感谢 Casey Yamaguma 绘制了图表。我们也感谢 Anton Korinek, Ioana Marinescu, Silvana Tenreyro, and Neil Thompson 提出的富有成效的评论和讨论。
我们的调研发现受到一些方法论上的限制。我们通过便利抽样和目的性抽样（以确保广泛的组织代表性）来选择受访者。我们在多个内部 Slack 频道发布了调研，获得了 68 份回复；我们还从组织结构图中选择了 20 个跨研究和产品职能的不同团队，并直接向每个团队的 5-10 人发送了消息（总共联系了 207 人），最终获得了 64 份回复，回复率为 31%。我们访谈了最先回复的 53 人。这里可能存在一些选择性偏差，因为那些特别积极使用 Claude 或持有强烈观点（无论正面或负面）的人可能更倾向于回复，而那些体验较为中性的人可能代表性不足。
此外，回复可能受到社会期望偏差（由于回复不是匿名的，且所有参与者都是 Anthropic 员工，受访者可能夸大了对 Claude 影响的正面评价）和近期偏差（要求参与者回忆 12 个月前的生产力和使用模式，容易受到记忆扭曲的影响）的影响。而且，如前所述，生产力通常很难估计，所以这些自述报告应持保留态度。这些自述的感知应与我们更客观的 Claude Code 使用数据结合解读，未来的研究将受益于匿名数据收集和更经过充分验证的测量工具。
我们的 Claude Code 分析在不同时间段内使用比例抽样，这意味着我们只能衡量任务分布的相对变化，而不能衡量工作量的绝对变化。例如，当我们报告说功能实现的占比从 14% 增加到 37% 时，这并不一定意味着总的功能实现工作量增加了。
最后，这项研究是在 2025 年 8 月进行的，当时 Claude Sonnet 4 和 Claude Opus 4 是我们最先进的模型。鉴于 AI 发展的迅猛速度，随着更新模型的出现，我们观察到的模式可能已经发生了变化。
2025-12-02 08:01:00
原文： https://a16z.com/the-trillion-dollar-ai-software-development-stack/
作者： Guido Appenzeller and Yoko Li
译者： Gemini 2.5 Pro
发布于 2025 年 10 月 9 日
收听 Guido 和 Yoko 在 Apple 或 Spotify 上讨论万亿美元的 AI 软件开发技术栈。
生成式 AI 已经到来，而它引爆的第一个巨大市场就是软件开发。乍一看，这可能有点让人意外。从历史上看，开发者工具的市场规模从来都不是顶级软件类别。但仔细想想，这完全合乎逻辑，原因有二：(1) 开发者总是先为自己构建工具；(2) 这个潜在市场真的非常大。
不妨这样算一笔账：==全球大约有 3000 万名软件开发者，Evans Data 的数据是 2700 万，SlashData 的数据是 4700 万。如果我们假设每个开发者每年创造 10 万美元的经济价值——这个数字在美国可能偏保守，但在全球范围略高——那么 AI 软件开发的总经济贡献每年将达到 3 万亿美元。==根据过去 12 个月我们与数十家企业和软件公司的交流，我们估计，如今一个简单的 AI 编码助手就能将开发者的生产力提高约 20%。
但这仅仅是个开始。根据一些实例证据，我们估计，一套顶级的 AI 部署方案至少能将开发者生产力翻倍，从而带来每年 3 万亿美元的 GDP 贡献。这大约相当于法国的 GDP。硅谷和其他地方的一些初创公司开发的技术，对世界 GDP 的影响将超过世界第七大经济体所有居民的总生产力。
巨大的价值创造也带来了初创公司收入和估值的巨大增长。Cursor 在 15 个月内达到了 5 亿美元的 ARR 和近 100 亿美元的估值。Google 花了 24 亿美元进行了一次人才收购，从 OpenAI 手中抢走了 Windsurf。Anthropic 推出了 Claude Code，并向作为其主要分销渠道的 AI 开发者工具宣战。而 OpenAI 的 GPT-5 发布会，核心也全是关于编码。面对如此巨大的蛋糕，我们已经进入了 AI 软件开发的“战国时代”。
最初，AI 编码似乎只是一个单一的类别，但今天它已经发展成一个生态系统，有潜力支撑起数十家十亿美元级别的公司，甚至一个万亿美元的巨头。在过去几十年里，软件一直是人类进步和经济增长的主要驱动力。它颠覆了每一个行业，而现在，软件本身也正在被颠覆。AI 加速开发，以及模型成为软件新的基本构件，这两股力量的双重推动，很可能会让软件市场在质量和数量上都迎来巨大的扩张。市场规模也可能随之扩大（我们相信杰文斯悖论在这里同样适用）。
AI 编码技术栈会是什么样子？虽然现在还为时尚早，但下面这张图是我们今天所看到的景象。橙色方框代表着我们看到有大量初创公司正在构建的 AI 工具领域。每个类别都给出了一个例子。更多的例子以及与流程正交的其他类别，都在下面的市场版图中列出。
十八个月前，早期的 AI 编码还只是向 LLM 请求一段特定的代码，然后把生成的代码粘贴到源代码里，这种方式在今天看来已经很原始了。如今的工作流有时被称为规划 -> 编码 -> 审查 (Plan -> Code -> Review)。它从一开始就让 LLM 参与进来：首先为新功能制定一份详细的描述，然后确定需要做出的决策或需要的信息。代码生成通常由一个 Agentic 循环完成，可能还包括测试环节。最后，开发者审查 AI 的工作，并根据需要进行调整。
上图是一个启动新项目的简单工作流示例。模型被要求起草一份高级规范——但更重要的是，它被指示返回一份它所需要的额外信息的完整清单。在这个例子中，这份清单长达数页，包含了对一系列需求和架构决策的澄清。它还包括对 API 密钥以及完成工作所需工具和系统访问权限的请求。
最终生成的规范有两个作用：首先，它指导代码生成，确保意图与实现保持一致。但除此之外，规范对于确保人类或 LLM 能够持续理解大型代码库中特定文件或模块的功能至关重要。人机协作是迭代的：在人类开发者编辑完一段代码后，他们通常会指示语言模型修改项目规范，从而确保最新的代码变更被准确反映出来。这样做的结果是代码文档清晰，对人类开发者和语言模型都有好处。
除了项目特定要求，大多数 AI 编码系统现在都集成了全面的架构和编码指南（例如 .cursor/rules）。这些指南可能包含公司级、项目级甚至模块级的规则。我们看到网上出现了许多针对特定用例、为 AI 优化的编码最佳实践集合（如上例，更多关于 Cursor 的可以在这里的 GitHub 上找到，或者 Claude Code 的在这里），这些集合完全是为 LLM 设计的。我们正在见证第一批纯粹为 AI 而非人类设计的自然语言知识库的诞生。
在这种新范式下，AI 不再仅仅是响应提示的代码生成器。LLM 现在是真正的合作伙伴，帮助开发者进行设计和实现，做出架构决策，并识别潜在的风险或限制。这些系统对公司政策、项目特定指令、第三方最佳实践和全面的技术文档都有丰富的上下文理解。
用于 AI 规划的工具仍处于早期阶段。一些老牌公司和初创公司已经构建了一些应用，可以从论坛、Slack、电子邮件或像 Salesforce 和 Hubspot 这样的 CRM 系统中汇总客户反馈（例如 Nexoro）。另一批公司（例如 Delty 或 Traycer）则开发网站或 VS Code 插件，帮助将规范分解成详细的用户故事，并辅助处理票务流程（例如 Linear）。展望未来，很明显，像 wiki 和故事追踪器这类现有的记录系统也需要进行彻底的变革或被完全取代。
一旦我们有了可靠的计划，就进入了一个迭代循环：AI 编码助手生成代码，开发者审查代码。最佳的用户界面和集成点主要取决于任务的长度以及是否需要异步运行。
Tab 自动补全与编辑 无缝集成到现代编辑器或 IDE 中，例如 Cursor、Windsurf、Sourcegraph Amp 以及数十种 VSCode 插件。这个功能可以自动补全当前行或执行局部编辑，无需明确提示，因为 AI 会根据上下文直观地推断出所需的操作。该功能依赖于紧凑、高效的模型，这些模型都为这个特定目的进行了精细调整，以确保快速和准确的性能。
基于聊天的文件编辑 允许用户通过聊天提供提示和必要的上下文给 AI。这种方法利用了具有大上下文窗口的更强大的推理模型，可以在整个代码库上工作，并经常使用文件创建或添加包等基本工具。该系统可以集成到 IDE 中，也可以通过 Web 界面访问，为用户的每次操作提供实时反馈。
后台 Agent 的工作方式不同，它们可以在没有直接用户交互的情况下长时间工作。它们通常使用自动化测试来确保解决方案的准确性，这在没有即时用户反馈的情况下至关重要。其结果是一个修改后的代码树或一个提交到代码仓库的 pull request。例子包括 Devin、Anthropic Code 和 Cursor Background Agents。
AI 应用构建器和原型工具——例如 Lovable、Bolt/Stackblitz、Vercel v0 和 Replit——代表了一个快速增长的类别。这些平台可以根据自然语言提示、线框图或视觉示例生成功能齐全的应用程序，而不仅仅是 UI。如今，它们在构建简单应用的“感觉流”程序员和制作功能齐全原型的专业人士中都很受欢迎。虽然到目前为止，很少有 AI 生成的 UI 进入生产代码库，但这可能只是反映了这些工具目前还不够成熟。
为 AI Agent 设计的版本控制：随着 AI Agent 承担越来越多的实现工作，开发者关心的重点从代码如何改变，转向了为什么改变以及它是否有效。当整个文件一次性生成时，传统的 diff 就失去了意义。像 Gitbutler 这样的工具正在围绕意图而非文本重新构想版本控制——捕捉提示历史、测试结果和 Agent 的来源。在这个世界里，Git 变成了一个后端的账本，而真正的交互发生在一个追踪目标、决策和结果的语义层。
源代码管理系统集成 使 AI 能够审查 issue 和 pull request，并参与讨论。这种集成利用了源代码管理的协作特性，其中围绕 issue 或 pull request 的讨论为 AI 提供了宝贵的实现上下文。此外，AI 还能辅助审查开发者的 pull request，重点关注正确性、安全性和合规性。例子包括 Graphite 和 CodeRabbit 的解决方案。
如今编码助手的主要循环通常是 Agentic 的（即 LLM 决定下一步行动并使用工具，也就是 HF 框架中的 3 星级）。现在，像文本修改、库更新或添加非常简单的功能这类简单任务，通常可以完全自主完成。我们曾经历过一些神奇的时刻：GitHub 上关于功能的群组讨论，最终以一句简短的“请实现 @aihelper”评论告终，然后就得到了一个完美无瑕、随时可以合并的 pull request。但对于更复杂的需求来说，这还不是常态。
遗留代码迁移 一直是 AI 编码最成功的用例之一。（例如，参见此处）。常见的用例包括将 Fortran 或 COBOL 迁移到 Java，Perl 迁移到 Python，或者替换陈旧的 Java 库。一种常见的策略是，首先从遗留代码生成功能规范，一旦规范正确，就用它来生成新的实现，只在解决歧义时才参考旧代码库。我们看到这个领域正在诞生新的公司，而且市场非常巨大。
代码编写完成后，就需要集成测试和文档。这个阶段也催生了自己的一套专门工具。
为开发者和 LLM 编写的文档 – LLM 现在不仅非常擅长生成面向用户的文档，还擅长生成供 LLM 在运行时使用的文档。像 Context7 这样的工具可以在恰当的时机自动拉取正确的上下文——检索相关的代码、注释和示例——从而使生成的文档与实际实现保持一致。除了静态页面，像 Mintlify 这样的产品可以创建动态文档网站，开发者可以直接与问答助手互动，甚至提供 Agent，让用户通过简单的提示按需更新或重新生成某些部分。最后，AI 还可以生成安全和合规方面的专门文档，这在大型企业中非常重要。我们也看到这个领域出现了专门的工具（例如，用于合规的 Delve）。
AI 质量保证 (QA) – 开发者现在可以依靠 AI Agent 来生成、运行和评估跨 UI、API 和后端层的测试，而无需手动编写测试用例。这些系统的行为就像自主的 QA 工程师，它们会遍历流程，断言预期行为，并生成带有修复建议的错误报告。随着软件越来越多地由 AI 生成，AI QA 闭合了开发循环：不再是编码 -> 审查 -> 测试 -> 提交。在极端情况下，代码变得不透明，开发者唯一关心的就是正确性、性能和预期行为。
除了上述为人类开发者设计的工具外，还出现了一个专门为 Agent 使用而构建的独立工具类别。
代码搜索与索引 – 当处理大型代码库（数百万或数十亿行代码）时，已经不可能（更不用说成本上不可行）在每次推理操作时都向 LLM 提供整个代码库。相反，最好的方法是为 LLM 配备一个搜索工具来查找相关的代码片段。对于小型代码库，简单的 RAG 或 grep 搜索可能就足够了。对于大型代码库（例如，参见谷歌的这篇论文），能够解析代码并创建调用图的专用软件就成了必需品，以确保能找到所有引用。这个新兴类别包括像 Sourcegraph 这样的公司，它们提供分析大型代码库的工具，以及像 Relace 这样的公司提供的专门模型，帮助识别和排序相关文件。
网页与文档搜索 –像 Mintlify 和 Context7 这样的工具擅长生成和维护与代码相关的文档，它们从实时代码库中提取最相关的片段、注释和使用示例，以保持文档的准确和最新。相比之下，像 Exa、Brave 和 Tavily 这样的网页搜索工具则针对即时检索进行了优化，帮助 Agent 快速按需查找外部参考和长尾知识。
代码沙箱 – 测试代码和运行简单的命令行工具进行分析和调试，是 Agent 的一个重要工具。然而，由于幻觉或潜在的恶意上下文，在本地开发系统上执行代码存在风险。在其他情况下，开发环境可能很复杂，而自动化环境则具有确保测试可重复性的优势。像 E2B、Daytona、Morph、Runloop 和 Together’s Code Sandbox 这样的执行沙箱供应商解决了这一需求，并已成为 AI 开发技术栈中的关键组件。
下面我们试图勾勒出更广泛的 AI 编码创业生态系统。布局大致遵循前面概述的软件开发生命周期，并增加了一些其他类别。公司排名不分先后。偶尔也包括一些老牌公司的产品。
基于 AI 的软件开发技术已经到来，现在组织需要将其投入运营。最近一个 Reddit 帖子问道：“Claude Code 实在太贵了，有什么优化的建议吗？” 成本确实可能很高：假设你的代码库占满了整个 100k 的上下文窗口，我们使用 Claude Opus 4.1 的推理模式，生成 10k 的输出和思考 token。按输入/输出每百万 token 15/75 美元的价格计算，每次查询的成本是 2.50 美元。如果扩大到每小时 3 次查询，每天 7 小时，每年 200 天，那么每年的花费大约是 10,000 美元。在许多地区，这已经超过了一名初级开发者的成本。
但我们认为，成本最终不会减缓 AI 开发工具的普及。像 Cursor 这样的许多平台通过同一个界面支持多种模型，并且擅长选择合适的模型来优化成本。即使是最便宜的模型也能带来巨大的好处。但讨论的焦点已经从“谁拥有最好的模型”转向了“谁能以合适的价格提供价值”。几十年来，软件开发的成本几乎完全是人力成本，但现在 LLM 增加了一个可观的运营支出 (opex) 部分。这是否意味着 IT 外包到低成本国家的终结？也许不会，但它确实改变了商业逻辑。
这一切对全球 3000 万软件开发者意味着什么？在可预见的未来，AI 会取代软件开发者吗？当然不会。这种无稽之谈是由媒体的耸人听闻和激进的市场营销共同造成的，他们试图将软件定价为对人力成本的替代，而不是按席位收费。历史告诉我们，虽然替代定价在早期市场有效，但最终商品的成本会趋向于其边际成本，定价也是如此。到目前为止，我们掌握的有限实际数据表明，最精通 AI 的企业反而增加了开发者的招聘，因为他们看到了大量短期内具有正投资回报率 (ROI) 的用例。
然而，软件开发者这个工作本身已经改变了，相应的培训也必须改变。 今天的大学课程将发生巨变；不幸的是，没有人（包括我们）真正知道该怎么变。算法、架构和人机交互仍然重要，甚至编码本身也很重要，因为你经常需要把 LLM 从它自己挖的坑里拉出来。但典型的大学软件开发课程，最好被看作是另一个时代的遗物，对今天的软件行业几乎没有实际意义。
从更长远来看，AI 编码技术栈允许软件自我扩展。例如，Gumloop 允许用户描述他们希望在产品中看到的额外功能，然后应用程序会使用 AI 编写代码来实现这个功能。这能走多远？我们是否能让 LLM 基于人类语言的 API 规范进行后期绑定，从而实现应用程序集成？普通的桌面应用会不会有一个“感觉流编码添加功能”的菜单按钮？从长远来看，一个应用程序作为不可变的代码发布，而没有任何自我扩展的能力，这似乎是难以想象的。
我们最终能完全消除代码，转而让 LLM 直接执行我们的高级意图吗（正如 Andrej 在这里建议的）？在最简单的情况下，这已经是现实了：ChatGPT 很乐意执行简单的算法。但对于更复杂的任务，编写代码仍然更优越，主要因为效率。在现代 GPU 上使用优化代码将两个 16 位整数相加大约需要 10^-14 秒。而 LLM 生成输出 token 至少需要 10^-3 秒。快 1000 亿倍足以构成一条护城河，我们预计代码还会存在很长很长时间。
从历史上看，技术超级周期是创业的最佳时机，这次也不例外。AI 需要新工具，同时又加速了开发周期，这种结合对初创公司极为有利。以编码助手为例：微软的 GitHub Copilot 似乎势不可挡，它率先进入市场，拥有 OpenAI 的合作关系，排名第一的 IDE (VSCode)，排名第一的 SCM (GitHub) 和排名第一的企业销售团队。然而，多家初创公司都有效地与之竞争。在超级周期中，作为现有巨头是很难的。
我们正处于可能是自软件开发诞生以来最大革命的早期阶段。软件工程师正在获得使他们比以往任何时候都更高效、更强大的工具。最终用户则可以期待更多、更好的软件。最后但同样重要的是，历史上从未有过比现在更好的时机在软件开发领域创业。如果你想成为这场革命的一部分，我们 a16z 希望能与你合作！
订阅我们的 a16z 新闻通讯，获取关于重塑 AI 和基础设施最新趋势的分析和新闻。
2025-12-01 08:00:00
原文： https://www.humanlayer.dev/blog/writing-a-good-claude-md
作者： Kyle Mistele
译者： Gemini 2.5 Pro
注意：本文同样适用于 AGENTS.md，它是 CLAUDE.md 的开源等价物，用于像 OpenCode、Zed、Cursor 和 Codex 这类 agent 和工具框架。
LLM 是无状态的函数。当它们用于推理时，其权重是固定的，所以它们不会随着时间的推移而学习。模型对你代码库的全部了解，仅限于你输入给它的 token。
同样，像 Claude Code 这样的编程 agent 框架，通常需要你明确地管理 agent 的记忆。CLAUDE.md (或 AGENTS.md) 是唯一一个默认情况下会进入你与 agent 每一次对话 的文件。
这带来了三个重要的启示：
CLAUDE.md 是做这件事的最佳方式。CLAUDE.md 帮助 Claude 熟悉你的代码库由于 Claude 在每次会话开始时对你的代码库一无所知，你应该使用 CLAUDE.md 来引导它熟悉你的代码库。从高层次来看，这应该包括：
bun 而不是 node 吗？你需要包含所有它能真正开展有意义工作所需的信息。Claude 如何验证自己的修改？它如何运行测试、类型检查和编译步骤？但你做这件事的方式很重要！不要试图把 Claude 可能需要运行的每一个命令都塞进你的 CLAUDE.md 文件里——这样做的结果并不会太好。
CLAUDE.md
无论你用的是哪个模型，你可能都会注意到 Claude 经常忽略你 CLAUDE.md 文件里的内容。
你可以自己验证这一点，方法是使用 ANTHROPIC_BASE_URL 在 Claude Code CLI 和 Anthropic API 之间放一个日志代理。Claude Code 会在给 agent 的用户消息中，连同你的 CLAUDE.md 文件一起，注入下面这条系统提醒：
<system-reminder>
IMPORTANT: this context may or may not be relevant to your tasks. You should not respond to this context unless it is highly relevant to your task.
</system-reminder>
结果就是，如果 Claude 认为 CLAUDE.md 的内容与当前任务无关，它就会忽略这些内容。你在文件中放的那些不具有普遍适用性的信息越多，Claude 就越有可能忽略你在文件中给出的指令。
为什么 Anthropic 要加上这个？ 很难说得准，但我们可以推测一下。我们见过的大多数 CLAUDE.md 文件都包含一堆并不普适的指令。很多用户把这个文件当作一种“热修复”手段，通过追加大量不一定普适的指令来修正他们不喜欢的行为。
我们只能猜测，Claude Code 团队发现，通过告诉 Claude 忽略那些不好的指令，整个工具框架实际上能产生更好的结果。
CLAUDE.md 文件以下部分将根据上下文工程最佳实践提供一些关于如何写好 CLAUDE.md 文件的建议。
效果因人而异。 并非所有这些规则都适用于每一种情况。和其他事情一样，你可以随时打破规则，只要……
把 Claude 可能需要运行的每一个命令，以及你的代码标准和风格指南都塞进 CLAUDE.md，这很诱人。但我们不建议这样做。
虽然这个话题还没有经过非常严谨的研究，但已有的一些研究表明：
CLAUDE.md），以及最末尾的部分（最近的用户消息）。
我们对 Claude Code 工具框架的分析表明，Claude Code 的系统提示词本身就包含了约 50 条独立指令。这取决于你使用的模型，但这已经占了你的 agent 能可靠遵循的指令数量的近三分之一——而这还没算上规则、插件、技能或用户消息。
这意味着你的 CLAUDE.md 文件应该包含尽可能少的指令——理想情况下，只包含那些对你的任务普遍适用的指令。
CLAUDE.md 的长度与适用性在其他条件相同的情况下，当 LLM 的上下文窗口充满了专注、相关的上下文时（包括示例、相关文件、工具调用和工具结果），它在任务上的表现会更好，而不是当它的上下文窗口里有很多无关上下文的时候。
因为 CLAUDE.md 会进入每一次会话，你应该确保其内容尽可能地普遍适用。
例如，避免包含关于如何构建新数据库模式的指令——当你处理其他不相关的事情时，这不仅无关紧要，还会分散模型的注意力！
在长度方面，“少即是多”的原则同样适用。虽然 Anthropic 没有官方建议你的 CLAUDE.md 文件应该有多长，但普遍的共识是少于 300 行是最好的，而且越短越好。
在 HumanLayer，我们的根 CLAUDE.md 文件不到六十行。
写一个简洁的 CLAUDE.md 文件，又要涵盖你想让 Claude 知道的一切，这可能很有挑战性，尤其是在大型项目中。
为了解决这个问题，我们可以利用渐进式披露（Progressive Disclosure）的原则，来确保 Claude 只在需要时才看到特定于任务或项目的指令。
我们建议，不要把你所有关于构建项目、运行测试、代码规范或其他重要上下文的指令都放在 CLAUDE.md 文件里，而是把特定于任务的指令保存在项目某处的、独立的 markdown 文件中，并给它们起一些自解释的文件名。
例如：
agent_docs/
|- building_the_project.md
|- running_tests.md
|- code_conventions.md
|- service_architecture.md
|- database_schema.md
|- service_communication_patterns.md
然后，在你的 CLAUDE.md 文件里，你可以列出这些文件并附上简短的描述，然后指示 Claude 自己决定哪些文件是相关的（如果有的话），并在开始工作前阅读它们。或者，你也可以让 Claude 先把它想读的文件列出来给你批准，然后再去读。
优先使用指针，而不是复制内容。如果可能，不要在这些文件中包含代码片段——它们很快就会过时。相反，应该使用 file:line 这样的引用，来引导 Claude 去查看权威的上下文。
从概念上讲，这与 Claude Skills 的工作方式非常相似，尽管 skills 更侧重于工具的使用而不是指令。
我们看到人们放在 CLAUDE.md 文件里最常见的东西之一就是代码风格指南。永远不要派一个 LLM 去做 linter 的工作。与传统的 linter 和格式化工具相比，LLM 相对昂贵且极其缓慢。我们认为，只要有可能，你永远都应该使用确定性的工具。
代码风格指南不可避免地会给你的上下文窗口增加一堆指令和大多无关的代码片段，这会降低 LLM 的性能和指令遵循能力，并消耗你的上下文窗口空间。
LLM 是在上下文中学习的！如果你的代码遵循一套特定的风格指南或模式，你会发现，只要让 agent 在你的代码库里搜索几下（或者给它一份好的研究文档！），它就会倾向于遵循现有的代码模式和惯例，而无需你明确告知。
如果你对此非常执着，你甚至可以考虑设置一个 Claude Code 的 Stop 钩子，运行你的格式化工具和 linter，然后把错误呈现给 Claude 让它去修复。不要让 Claude 自己去发现格式问题。
加分项：使用一个能自动修复问题的 linter（我们喜欢用 Biome），并仔细调整你的规则，明确哪些问题可以安全地自动修复，以实现最大化（且安全）的覆盖范围。
你也可以创建一个斜杠命令 (Slash Command)，其中包含你的代码指南，并让它指向版本控制中的变更，或者你的 git status 之类的。这样，你就可以把实现和格式化分开处理。最终，两者都能取得更好的结果。
/init 或自动生成你的 CLAUDE.md
无论是 Claude Code 还是其他使用 OpenCode 的框架，都提供了自动生成 CLAUDE.md (或 AGENTS.md) 文件的方法。
因为 CLAUDE.md 会进入与 Claude Code 的每一次会话，所以它是整个工具框架中杠杆作用最高的点之一——无论好坏，都取决于你如何使用它。
一行烂代码就是一行烂代码。实施计划中一行烂指令可能会制造出大量烂代码。研究中一行对系统理解错误的描述，可能会导致计划中出现大量烂指令，并因此产生更多更多的烂代码。
但是 CLAUDE.md 文件会影响你工作流的每一个阶段以及它产出的每一件东西。因此，我们认为你应该花些时间，非常仔细地思考进入这个文件的每一行内容：
CLAUDE.md 用于帮助 Claude 熟悉你的代码库。它应该定义你项目的 WHY（为什么）、WHAT（是什么） 和 HOW（怎么做）。CLAUDE.md 内容简洁且普遍适用。CLAUDE.md 是整个工具框架中杠杆作用最高的点，所以要避免自动生成它。你应该精心打造其内容以获得最佳效果。
