# Claude Code团队实践：智能体编程如何重塑工程组织与流程 - 来源：Claude：Blog（网页） - 发布时间：2026-06-03 00:45 - AIHOT 分数：74 - AIHOT 标记：精选 - AIHOT 链接：https://aihot.virxact.com/items/cmpwvc9sl012csl79zvo91150 - 原文链接：https://claude.com/blog/running-an-ai-native-engineering-org ## 精选理由 Anthropic 工程总监把 Claude Code 团队流程全晒了出来，从抛弃半年路线图到代码审查只留专家复审，每一步都反直觉但实战有效，工程领导者直接抄作业。 ## AI 摘要 在Code w/ Claude SF 2026活动上，Claude Code工程团队分享了将智能体编程设为默认工作方式后带来的流程与结构变革。核心变化包括：规划转向即时（JIT）模式，强调快速原型与反馈；上下文收集变为“先问Claude”；代码审查中Claude处理风格与测试，人工专注于法律、安全等专业判断。新范式下，工程瓶颈从编写代码转向验证、审查与安全维护。 ## 正文 在 2026 年旧金山举办的 Code w/ Claude 大会上，Claude Code 与 Claude Cowork 工程总监 Fiona Fung 详细阐述了，当智能体编程成为默认工作方式后，团队流程与结构发生了怎样的变化。 分类 Claude Code 产品 Claude Code 日期 2026 年 6 月 3 日 阅读时间 5 分钟 https://claude.com/blog/running-an-ai-native-engineering-org 多年来，工程人力一直是构建应用成本高昂的部分。我们过去围绕软件规划和交付所采用的所有流程——先是瀑布模型，后是敏捷开发——都是基于这一成本构建的。 我的职业生涯始于 2000 年代初期，当时在 Visual Studio 团队工作。那个年代，我们通过 CD-ROM 交付软件，受制于硬性的制造截止日期。一旦我们能够在线分发软件，便开始持续增加更新频率。如今，我们再次改变工作方式，这次变革的核心是编写软件所需的时间和人力。 在 Claude Code 团队，编写代码、编写测试和重构已经很少再拖慢我们的速度。但当智能体编程消除了实际键入代码的需求后，瓶颈并未消失。取而代之的是验证、代码审查和安全问题。 现在，我们所有人都能非常快速地生成大量代码，但这同时也带来了新的问题：这段代码正确吗？如何维护它？以及我从其他工程领导者那里收到的最常见问题之一：“人类如何跟上你们进行代码审查的速度？” 那些悄然失效的流程 我们当初设立所有流程都是有原因的——为了弥补某个缺口或让某件事运作得更好。但当那个缺口不复存在、这些流程变得过时时，它们很少会自行消失。当 Claude Code 团队开始将智能体编程作为默认工作方式后，我们许多现有的流程都失效了。以下是我们重写的规范及其原因。 规划：将路线图转变为即时模式 过去的常态是花大量时间进行预先规划，因为编码时间很昂贵。当我刚加入 Claude Code 团队时，我们制定了一份相当不错的六个月路线图，但由于 Claude Code 的出现，太多事情发生了变化，导致这份路线图在第三个月就过时了。 工程速度和吞吐量如今已截然不同，因此我们规划冲刺的方式也发生了变化。我称之为即时（JIT）规划，几乎就像即时编译：如何在正确的时间做恰到好处的事？我们的规划流程已从设计文档转向在 PR 或原型中进行讨论。这个领域发展太快，所以我们不做大量的产品评审。我们现在的流程是：先做原型，让大量内部用户试用，然后根据他们的反馈采取行动。 上下文收集：问 Claude，而不是问作者 过去工程师写代码时，要回答大多数问题，第一步是找到写代码的人。现在，由于我们所有的 PR 都有 Claude 辅助，“谁做了这个改动？”已经不够了。我们的新常态是深入一层：你真正需要知道的是什么？例如：你是想找导致性能回退的人？找能回答客户问题的专家？还是想了解某个决策的背景？你向 Claude 提出那个问题，并考虑 Claude 是否可以直接回答，同时还能提供更多数据和上下文。 在 Claude Code 团队，无论问题是什么，我们的流程都会问一句：“有没有办法自动化？”例如，让 Claude 每天早上汇总客户反馈渠道，这件事从我以前边喝咖啡边手动完成的习惯，变成了我在后台自动运行的任务。 代码审查：信任但要验证 我们大量使用代码审查。Claude 负责所有的代码风格和 lint 检查、PR 反馈请求、在完整提交前捕获并修复 bug，以及添加测试。而我们仍然明确需要人类介入的地方是专业知识。 新的常态是在关键之处进行人工审查：对于法律审查，我始终希望我的法务合作伙伴参与风险容忍度的判断。对于信任边界和安全敏感的代码，我需要领域专家。产品经理和设计师也需要参与产品感觉和品味的把控。 不过，持续评估很重要，因为信任与验证之间的恰当平衡会随着模型的改进而不断变化。今天需要人类来做的事情，到了下一代模型可能就不同了。 团队构成：角色界限模糊 Claude 和 AI 已经重塑了整个团队的角色。现在我们的产品经理经常写代码，这很有趣。有了 Claude，非传统意义上的编码人员现在能够承担更多工程工作，而工程师们则开始涉足内容和设计等传统上不属于技术侧的工作。 在 Claude Code 工程团队，我重点考察两类人才。一类是具有产品直觉的创意型构建者：那些充满好奇心、对交付能解决问题的产品充满热情的梦想家。另一类是拥有深厚系统专业知识的工程师。例如，当我加入团队时，我注意到我们缺少具有系统背景的专家，而在 Web 端构建 Claude Code 时，我们需要确保 Claude 能在任何地方运行。 另一方面，我不太看重的是原始吞吐量；模型会处理这个。更重要的问题是你仍然需要人类专业知识的领域，而这正是我关注的重点。 过去 现在 规划 六个月的产品路线图。 即时（JIT）规划：先做原型，让内部用户试用，然后根据他们的反馈采取行动。 上下文收集 找到写那段代码的人，直接去问他们。 先问 Claude。然后再问你所问的事情是否可以被自动化。 代码审查 人类审查所有内容。 Claude 负责处理代码风格、错误和测试。人类负责审查需要领域专业知识的部分。 团队构成 固定角色：工程师写代码，产品经理做规划，设计师搞设计。 角色模糊化：产品经理做原型，工程师承担设计和上下文收集工作。招聘时侧重创意型构建者和深厚系统专业知识人才。 我们如何推行新规范 随着这些规范的变化，有些方面被定为团队必须遵守的原则，而其他方面我们则让小型子团队自行摸索。Claude Code 核心团队有一套不可妥协的“必须执行”原则： 坚持不懈地吃自己的狗粮：每一位 Claude Code 团队成员，包括跨职能合作伙伴，都要使用 Claude Code（以及 Claude Cowork）。我们一直在思考如何让 Claude 帮助我们更快、更高效地完成工作。 尽可能保持团队扁平化。我加入 Claude Code 时，希望每位管理者首先以独立贡献者的身份起步，通过交付产品学会如何成为团队中高效的工程师，并真正经历和理解在 Anthropic 做一名工程师是怎样的体验。我们在 Claude Code 和 Claude Cowork 上有一个统一的团队使命。管理者在支持各个工作小组的同时，保持团队的敏捷性，让人们能够灵活地转移到需要他们的地方去。 果断淘汰不再有效的流程：最后，我们会不断追问为什么我们要以现在这种方式做事。当某件事不再合理时，团队成员被明确授权可以质疑并废除旧的流程。 不过，在这些为数不多的规则之下，每个工作小组都拥有很大的自主权。他们可以灵活调整如何使用 Claude 进行任务分类，如何开展任何规划仪式或站会，以及哪些工作流程会优先实现“Claude 化”。 如何判断你的新流程是否被真正采纳 以下是每位工程领导者在推行变革时，现在就应该开始追踪的三个关键指标。 新员工上手时间缩短：一名工程师、设计师或产品经理需要多久才能开始高效工作？在我们团队，这个时间比一年前快得多，工程师现在入职第一周就能交付真实代码。 拉取请求周期缩短：这个指标值得深入分析，因为它可能帮助你找出流程中难以扩展的瓶颈。随着我们生成的代码量大幅增加，有时构建系统和持续集成可能难以跟上节奏。 Claude 辅助的提交量上升：对我们来说，默认情况下，每一次提交都是 Claude 辅助完成的。我想在过去四个月里，我都没见过一次非 Claude 辅助的提交。 关于第三点，不要把吞吐量等同于成功。吞吐量只是一个指标，但真正的衡量标准是看你是否解决了你试图解决的问题。在正确的对齐下，吞吐量可以帮助你更快地解决问题。 如何开始 如果我只留给你一句话：选择你团队中最令人头疼的工作流程。它可能是你最昂贵的工作流程，也可能是你害怕面对、或者你的团队不期待去做的那个。然后问一问：它是否还在发挥其应有的作用？如果是，你能把它自动化吗？ 我曾在一个团队工作，当时我们每周都要开一次成本高昂的评审会，会议室里坐满了人。我注意到，除了轮到每个人汇报进度时，大家全程都在低头看笔记本电脑。他们会抬起头，说完进度，然后又埋头回到电脑前。我问了一个简单的问题：“我们为什么还要开这个会？这看起来既费钱又费时。”就这一个问题，让所有人都意识到这个会确实没必要开。于是我们把它取消了。 所以，问问你自己：在你的工程工作流中，有哪些环节可以考虑自动化，甚至直接砍掉？ 视频 · 前往原文观看 用 Claude 改变你组织的运作方式。