如何运营一个AI原生的工程团队

运行一个AI原生的工程组织

多年来，工程带宽一直是构建应用最昂贵的部分。我们过去围绕软件规划和交付的每一个流程——先是瀑布模型，然后是敏捷——都是围绕这个成本建立的。我的职业生涯始于21世纪初，在Visual Studio团队工作。那时候我们以CD-ROM形式交付软件，有硬性的制造截止日期。一旦我们能够在线分发软件，就开始不断增加持续更新的频率。现在我们又一次改变了工作方式，这次是围绕编写软件所需的时间和人力。

在Claude Code团队，编写代码、编写测试和重构很少再成为我们的瓶颈。但当智能体编码取代了实际打字输入代码的需要时，瓶颈并没有消失。验证、代码审查和安全取代了它们的位置。如今我们都可以非常快速地生成大量代码，但这同时也带来了新的问题：这些代码正确吗？如何维护它？我从其他工程领导者那里得到最多的问题之一是：“人类如何跟上你们进行代码审查的速度？”

那些悄然失效的流程

我们制定流程总是有原因的——为了填补某个缺口或让某件事更好地运行。但当这个缺口不再存在，这些流程变得过时时，它们很少自动消失。当Claude Code团队开始将智能体编码作为默认工作方式时，我们现有的很多流程都失效了。以下是我们重新编写的规范及其原因。

规划：将路线图转向即时化

旧的规范是花费大量时间进行预先规划，因为编码时间很昂贵。当我刚加入Claude Code团队时，我们制定了一份相当不错的六个月路线图，但随后由于Claude Code，很多事情都发生了变化，到了第三个月路线图就过时了。

现在工程速度和吞吐量已经不同，因此我们规划冲刺的方式也发生了变化。我称之为即时规划（JIT planning），几乎像JIT编译一样：如何在正确的时间做正确数量的事？我们的规划仪式从设计文档转向了PR或原型中的讨论。这个领域发展很快，所以我们不做大量的产品评审。我们现在的流程是：先做原型，让大量内部用户试用，然后根据他们的反馈行动。

上下文获取：问Claude，而不是问作者

过去当工程师写代码时，获取大多数问题答案的第一步是找到写这段代码的人。现在，由于我们所有的PR都由Claude辅助，“这是谁做的更改？”已经不够了。我们的新规范是更深入一层：你实际上需要知道什么？例如：你是想找出导致回归的人？还是需要专家回答客户问题？或者需要决策的背景信息？你向Claude提出那个问题，并考虑Claude是否能够直接回答，同时还能提供更多数据和上下文。

在Claude Code团队，无论问题是什么，我们的流程也会问：“有没有办法自动化它？”例如，让Claude每天早晨汇总客户反馈渠道，这从我自己喝着咖啡手动做的仪式变成了后台自动运行的事情。

代码审查：信任但验证

我们大量使用代码审查。Claude处理所有样式和格式问题、PR反馈请求、在完整提交前捕获并修复bug、以及添加测试。对于人类，我们仍然需要的是专业知识。

新的规范是有重点地进行人工审查：对于法律审查，我总是希望法律合作伙伴参与风险评估。对于信任边界和安全关键代码，我希望领域专家参与。产品经理和设计师也需要参与产品感觉和品味。

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

团队构成：角色模糊化

Claude和AI重塑了团队中的角色。我们的产品经理现在经常写代码，看到这一点很有趣。有了Claude，非传统的程序员现在能够做更多工程工作，而工程师也开始承担内容、设计等传统上不属于技术侧的工作。

在Claude Code工程团队，我重点招募了两类人才。一类是有产品感觉的创造性建设者：那些充满好奇心、热衷于交付解决实际问题的产品的梦想家。另一类是拥有深厚系统专业知识的工程师。例如，当我加入团队时，我注意到我们缺少系统背景的专家，而在构建Web版Claude Code以确保Claude随处可运行时，我们正需要这样的人才。

另一方面，我不再那么看重的是原始产出能力；模型已经处理了这部分。更重要的问题是你仍然需要人类专业知识的领域，而这正是我关注的重点。

（以下将原文表格转化为文字列表）

规划（Planning）：之前是六个月的产品路线图；之后是即时规划（JIT）：原型、让内部用户试用、根据反馈行动。

上下文获取（Context gathering）：之前是找到写代码的人并询问；之后是先问Claude，然后询问所问之事是否可以自动化。

代码审查（Code review）：之前是人类审查所有内容；之后是Claude处理样式、bug和测试，人类在需要领域专业知识时进行审查。

团队构成（Team makeup）：之前是固定角色：工程师写代码，PM规划，设计师设计；之后是角色模糊：PM写原型，工程师承担设计和上下文工作。招聘偏向创造性建设者和深度系统专家。

我们如何推行新规范

随着这些规范的变化，有些方面被强制作为团队原则，而其他方面我们让小的子团队（pods）自行摸索。以下是Claude Code核心团队的一系列不可协商的“必须做”：

- 不懈地吃自己的狗粮：每个Claude Code团队成员，包括跨职能合作伙伴，都使用Claude Code（也使用Claude Cowork）。我们一直在思考让Claude帮助我们更快、更高效地完成工作的方式。 - 保持团队尽可能扁平：当我加入Claude Code时，我要求每个管理者首先以独立贡献者（IC）的身份开始，通过交付学习如何成为团队中高效的工程师，真正体验并理解在Anthropic做工程师是怎样的感觉。在Claude Code和Claude Cowork上，我们有一个统一的团队使命。管理者支持各个pod的工作，同时保持团队敏捷，以便人们可以转移到有工作的地方。 - 毫不犹豫地废除不再有效的流程：最后，我们不断质疑我们做事的方式。当某件事不再合理时，团队成员有明确的权限去质疑并废除旧流程。

在这些少数规则之内，每个pod拥有很大的自主权。它们有空间去调整如何使用Claude进行分诊、如何运行任何规划仪式或站会、以及哪些工作流会先被“Claud化”。

如何知道你的新流程正在生效

以下是每个工程领导者在推行变革时现在就应该开始追踪的三个数字。

- 入职上手时间减少：一个工程师、设计师或产品经理需要多久才能开始高效工作？在我们的团队中，这比一年前快得多，工程师现在在入职第一周就能交付真正的代码。 - PR周期时间减少：这个指标值得深入挖掘，因为它可能帮助你找到管道中难以扩展的瓶颈。随着我们生成越来越多的代码，有时构建系统和持续集成（CI）可能难以跟上。 - Claude辅助的提交增加：对我们来说，默认每个提交都是Claude辅助的。我想在过去四个月里我没有见过非Claude辅助的提交。

关于第三点，不要将吞吐量等同于成功。吞吐量是一个指标，但真正的指标是衡量你试图解决的问题。在正确的对齐下，吞吐量可以帮助你更快地解决问题。

入门建议

如果我只想留给你一件事：找出你噪音最大的工作流。那可能是你最昂贵的工作流、你或许正在畏惧的、或者你的团队不期待的工作流。然后问：它还在服务于它的目的吗？如果是，你能自动化它吗？

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

所以，问问自己：你的工程工作流中哪一部分可以考虑自动化甚至完全放弃？