Claude Code团队实践：智能体编程如何重塑工程组织与流程

在 Code w/ Claude SF 2026 大会上，Claude Code 和 Claude Cowork 工程总监 Fiona Fung 详细讲述了当智能体编程成为默认工作方式后，团队流程与结构发生了怎样的变化。

多年来，工程人力一直是构建应用中最昂贵的部分。我们围绕软件规划与交付所建立的每一个流程——先是瀑布式，然后是敏捷——都是围绕这一成本构建的。

我在 2000 年代初开始职业生涯，当时从事 Visual Studio 相关工作。那时候我们通过 CD-ROM 发布软件，有着硬性的制造截止日期。等到我们能够在线分发软件之后，便开始逐步转向持续发布更新。如今我们又一次改变工作方式，而这一次改变的是编写软件所需的时间和人力。

在 Claude Code 团队，编写代码、编写测试和重构已经很少再拖慢我们的节奏。但当智能体编程消除了实际敲代码的需求后，瓶颈并没有消失。验证、代码审查和安全取而代之。

如今我们都能以极快的速度生成大量代码，但这也带来了新的问题：这些代码正确吗？如何维护？而我从 fellow engineering leaders 那里最常被问到的问题之一是：“人类如何跟上你们做代码审查的节奏？”

那些悄然失效的流程

我们制定流程都是有原因的，要么是为了填补某个缺口，要么是为了让事情运转得更好。但当那个缺口不复存在、这些流程变得过时之后，它们很少会自行消失。当 Claude Code 团队开始把智能体编程作为默认工作方式时，我们现有的许多流程都失效了。以下是我们重写的规范，以及背后的原因。

规划：把路线图转向准时制

过去的规范是花大量时间做前期规划，因为写代码的时间很昂贵。我刚加入 Claude Code 团队时，我们写了一份相当不错的六个月路线图，然后因为 Claude Code，太多事情发生了变化，到第三个月它就已经过时了。

工程速度和吞吐量如今已大不相同，所以我们规划冲刺的方式也变了。我把它叫做准时制（JIT）规划，几乎就像 JIT 编译：你如何在正确的时间只做正确数量的事？我们的规划仪式从设计文档转向了 PR 或原型中的讨论。这个领域变化太快，所以我们不做太多产品评审。我们现在的流程是：先做原型，让大量内部用户用起来，然后开始根据他们的反馈采取行动。

上下文收集：问 Claude，而不是问作者

当工程师们编写代码时，要找到大多数问题的答案，第一步就是找到写这段代码的人。如今，由于我们所有的 PR 都有 Claude 辅助，“这个改动是谁做的？”已经不够了。我们的新常态是再深入一层：你真正需要知道的是什么？比如：你是在找是谁导致了回归？还是找一位专家来回答客户的问题？又或者是想了解某个决策的背景？你把这个问题交给 Claude，同时考虑 Claude 是否能直接回答它，以及是否能借助更多数据和上下文来回答。

在 Claude Code 团队，无论那个问题是什么，我们的流程都是同时问一句“有没有办法把它自动化？”例如，让 Claude 每天早上汇总客户反馈渠道，这件事从过去我喝着咖啡手动完成的例行公事，变成了现在直接在后台自动运行的事情。

代码审查：信任但验证

我们大量使用 代码审查。Claude 处理所有的风格和 linting、PR 反馈请求、在完整提交前发现并修复 bug，以及添加测试。而我们仍然明确需要人类的地方，是专业判断力。

新的常态是在真正重要的地方进行人工审查：对于法律审查，我总是希望我的法律伙伴参与风险容忍度的判断。对于信任边界和安全敏感的代码，我需要领域专家。产品经理和设计师也需要参与，贡献产品直觉和品味。

不过，持续评估很重要，因为信任与验证之间的正确平衡会随着模型的进步而不断变化。你今天需要人类做的事情，在下一个模型面前可能就不一样了。

团队构成：角色边界模糊

Claude 和 AI 重塑了整个团队中的角色。我们的产品经理现在经常写代码，这看着很有意思。有了 Claude，原本非传统意义上的编码者现在能做更多工程工作，而工程师则开始承担内容和设计等传统上不属于技术侧的工作。

在 Claude Code 工程团队，我重点看重两类人。一类是有产品感觉的创意构建者：那些深度好奇、热衷于交付能解决问题的产品的梦想家。另一类是具备深厚系统专业知识的工程师。比如，我加入团队时注意到我们缺少有系统背景的专家，而构建 Claude Code on the Web 时正需要这样的人，以确保我们能在任何地方运行 Claude。

另一方面，我不太看重的是纯粹的产出吞吐量；模型能搞定这些。更重要的问题是，哪里仍然需要人类的专业知识，这才是我会聚焦的地方。

我们如何推行新规范

随着这些规范发生变化，其中一些方面被定为团队原则强制执行，另一些则交由小型子团队（pod）自行摸索。Claude Code 核心团队有一套不可协商的“必须做到”原则：

• 不遗余力地试用自家产品：每一位 Claude Code 团队成员，包括跨职能合作伙伴，都在使用 Claude Code（以及 Claude Cowork）。我们始终在思考如何让 Claude 帮助我们更快、更高效地完成工作。
• 尽可能保持团队扁平化。当我加入 Claude Code 时，我希望每一位管理者都先从 IC 做起，通过实际交付学会如何在团队中成为一名高效的工程师，真正亲身体验并理解在 Anthropic 做一名工程师是什么感觉。我们在 Claude Code 和 Claude Cowork 上有一个统一的团队使命。管理者支持各个工作小组（pod），同时保持团队敏捷，让人们能够流动到工作最需要的地方。
• 毫不犹豫地砍掉不再奏效的流程：最后，我们坚持不懈地质疑我们为什么以现在的方式做事。当某件事不再合理时，团队成员被明确赋予质疑并砍掉旧流程的权力。

不过，在这几条规则之内，每个工作小组都拥有很大的自主权。他们有空间去调整如何使用 Claude 进行问题分诊、如何开展任何规划仪式或站会，以及哪些工作流会最先被“Claude 化”。

如何判断你的新流程是否真正落地

以下是每位工程负责人在推行变革时都应该立即开始追踪的三个数字。

• 上手适应时间缩短：一名工程师、设计师或 PM 多快能开始发挥效用？在我们团队，这比一年前快得多，工程师现在能在入职第一周内交付真实代码。
• PR 周期时间下降：这一点很值得深入探讨，因为它可能帮助你找出流水线在哪些地方难以扩展。随着我们生成越来越多的代码，有时构建系统和持续集成（CI）可能会难以跟上。
• Claude 辅助的提交持续增加：对我们来说，默认情况下，每一次提交都是 Claude 辅助完成的。过去四个月里，我没有见过一次非 Claude 辅助的提交。

关于第三点，不要把吞吐量与成功混为一谈。吞吐量只是一个指标，但真正的指标是衡量你试图解决的那个问题。有了正确的对齐，吞吐量可以帮助你更快地解决问题。

入门指南

如果我要留给你一件事：挑出你最嘈杂的工作流。那可能是你最昂贵的工作流，可能是你一直害怕面对的，或者是你的团队不期待的那个。然后问：它是否仍在发挥其作用？如果是，你能把它自动化吗？

我曾经在一个团队里，每周都有一次昂贵的评审会，会议室里坐着一大群人。我注意到除了轮到自己做状态汇报的时候，每个人都在自己的笔记本电脑上。他们会抬起头，说一下状态，然后又低头回到笔记本电脑上。我问了一个简单的问题：“我们为什么还要开这个会？这似乎是在昂贵地占用我们的时间。”就这一个问题，让所有人都意识到它并不必要。于是我们取消了它。

所以，问问你自己：你的工程工作流中，有哪一部分是你可能考虑自动化、甚至干脆舍弃的？