【翻译自用】如何运营一个 AI 原生工程团队

https://claude.com/blog/running-an-ai-native-engineering-org

2026年旧金山 Code w/ Claude 大会上，Claude Code 与 Cowork 工程总监 Fiona Fung 分享了：当 Agent 式编码成为默认工作方式之后，团队的流程与架构究竟发生了哪些改变。

多年来，工程人力一直是构建应用最昂贵的部分。从瀑布式开发到敏捷，我们所有的软件规划与交付流程，本质上都是围绕这一成本约束搭建起来的。

我职业生涯始于 2000 年代初，彼时在 Visual Studio 团队工作。那个年代，软件装在 CD-ROM 里发行，截止日期铁板钉钉。后来可以在线分发了，我们开始持续交付更新。而今，我们正在经历又一次范式迁移——这次变的，是写代码所需的时间与人力。

在 Claude Code 团队，写代码、写测试、重构，这些事情几乎已不再是瓶颈。但瓶颈并没有消失——当 Agent 式编码取代了手敲代码的必要，验收、代码审查和安全性接过了接力棒。

我们现在都能极快地生成大量代码，但这也带来了新的追问：这些代码是对的吗？可维护性如何？还有一个我被同行工程负责人问烂了的问题："人工代码审查跟得上这个速度吗？"

那些悄然失效的流程

每一条流程当初都有它存在的理由——填补某个空缺，或让某件事运转得更顺畅。但当那个空缺不复存在，这些流程却鲜少自动退场。当 Claude Code 团队开始把 Agent 式编码作为默认工作方式，我们原有的很多流程都失灵了。以下是我们重写的规范，以及为什么要改。

规划：拥抱即时规划

以前的惯例是花大量时间做前期规划，因为写代码代价高昂。我刚加入 Claude Code 团队时，我们做了一份相当扎实的六个月路线图——然后 正因为 Claude Code，太多事情在三个月内就变了，那份路线图成了废纸。

工程速度和产出已今非昔比，冲刺规划的方式因此改变。我称之为即时规划（JIT Planning），有点像即时编译：在恰当的时机做恰当程度的规划。我们的规划仪式从写设计文档转向在 PR 或原型中直接讨论。这个领域变化太快，我们不再做大量的产品评审。现在的流程是：先做原型，让内部用户跑起来，再根据反馈行动。

上下文获取：去问 Claude，不要去找作者

以前工程师写代码，遇到问题的第一步是找到写那段代码的人。如今，由于我们所有的 PR 都有 Claude 参与，"这是谁改的？"已经不是充分答案了。新规范是再往深处走一层：你到底想知道什么？比如：你是在追查谁引入了一个回归 Bug？还是想找领域专家回答客户问题？还是需要了解某个决策的来龙去脉？直接把这个问题问 Claude——Claude 往往能直接给出答案，而且上下文更丰富、数据更充分。

在 Claude Code 团队，不管那个问题是什么，我们都会追加一问："有没有办法把它自动化？"比如，让 Claude 每天早上汇总客户反馈渠道——这件事从我端着咖啡手动做的晨间仪式，变成了在后台静默运行的自动化流程。

代码审查：信任，但验证

我们大量使用 Code Review 功能。代码风格检查、Lint、PR 反馈、提交前捕捉并修复 Bug、补充测试——这些全交给 Claude。人工仍然不可或缺的地方，是专业判断。

新规范是：在真正重要的地方保留人工审查。法律审查，我一定要让法务伙伴参与把握风险边界；涉及信任边界和安全敏感的代码，我要领域专家上；产品感知与品味，产品经理和设计师必须在场。

但这个平衡需要持续审视——随着模型能力不断提升，"信任"与"验证"的比例会一直在变。今天需要人来做的事，下一代模型出来后可能就不同了。

团队构成：角色边界的消融

Claude 和 AI 重塑了团队里的每个角色。我们的产品经理现在写了很多代码，看着挺有意思的。借助 Claude，非传统意义上的程序员现在能承担更多工程工作，而工程师也开始接手内容和设计——这些传统上不属于技术侧的工作。

在 Claude Code 工程团队，我重点挑两类人：一类是有产品感的创造型构建者——那些天马行空、对交付解决真实问题的产品充满热情的人；另一类是具备深厚系统底层功底的工程师。举个例子，我刚入团队时发现缺乏有系统背景的专家——而构建 Claude Code Web 版时，这恰恰至关重要，我们需要确保 Claude 能在任何地方运行。

反倒是纯粹的产出吞吐量，我不太看重——那是模型的活。更关键的问题是：哪里依然需要人的专业判断，那才是值得押注的地方。

我们如何推行新规范

在这些规范演变的过程中，一部分被定为团队层面的强制原则，另一部分则让各个小组（Pod）自己摸索。以下是 Claude Code 核心团队不可商量的"必做项"：

无情地以自己的产品为食（Dogfood）：包括跨职能伙伴在内的每一位 Claude Code 团队成员，都在使用 Claude Code（以及 Claude Cowork）。我们时刻在想：怎样让 Claude 帮我们把工作做得更快、更高效。

保持团队尽可能扁平：我加入 Claude Code 时，希望每一位管理者都先以独立贡献者（IC）的身份开始——通过实际交付学会如何做一名高效的工程师，切身理解在 Anthropic 做工程师是什么感受。我们有一个统一的团队使命。管理者以支持各个 Pod 的方式运作，同时保持团队敏捷，让人力可以自由流向最需要的地方。

毫不犹豫地废掉失效的流程：我们对自己做事方式的质疑，是不留情面的。当某件事不再有意义，团队成员有明确的授权去质疑并废除旧流程。

在这几条规则之内，每个 Pod 拥有很大的自主权——如何用 Claude 做 Triage、如何组织规划仪式或站会、哪些工作流先"Claude 化"，都由各组自行决定。

怎么知道新流程真的落地了

以下三个数字，是每位工程负责人在推行变革时应该现在就开始追踪的：

新人上手时间缩短：一名工程师、设计师或 PM，多快能真正产出贡献？我们团队比一年前快得多，工程师现在入职第一周就能提交真实代码。

PR 周期时间缩短：这个值得深挖，因为它能帮你找到流水线里的扩展瓶颈。当我们产生的代码量急剧增加，构建系统和 CI 有时会跟不上节奏。

Claude 辅助提交比例提升：对我们来说，默认情况下每一次提交都有 Claude 参与。过去四个月，我已经不记得见过哪次是非 Claude 辅助的提交。

关于第三点：不要把吞吐量当成成功本身。吞吐量是一个指标，但真正的指标是你试图解决的那件事有没有变好。对齐做对了，吞吐量才能帮你更快解决问题。

如何开始

如果只留一句话：从你最嘈杂的工作流下手。 可能是最贵的那个，可能是你最头疼的那个，或者是你的团队最不期待做的那个。然后问：它现在还在发挥应有的作用吗？如果是，能不能自动化？

我曾在一个团队里，他们有一个代价高昂的周度评审会，一大堆人挤在会议室。我发现每个人都在低头看电脑，只有轮到自己汇报时才抬起头，说完状态，又埋回去。我就问了一个简单的问题："我们为什么还在开这个会？这好像是在很贵地消耗大家的时间。"就这一个问题，让所有人意识到——不需要了。然后我们就取消了它。

所以，问问自己：你工程流程里，有哪一块，你可能会考虑自动化，甚至直接砍掉？