运营一个 AI 原生的工程组织
关键要点
- 瓶颈发生了转移，而非消失：当智能体式编码 (agentic coding) 接管了"敲代码"这件事后，写代码、写测试、重构都不再是瓶颈；取而代之的新瓶颈是验证、代码评审与安全。
- 规划转向准时制 (JIT)：昂贵的不再是编码，于是六个月路线图在第三个月就过时了。团队改用准时制规划——先做原型、推给内部用户、再依据反馈行动，而非靠厚重的设计文档。
- "信任但要验证"的代码评审：Claude 包办风格、Lint、抓 Bug 与补测试；人类只在真正需要专业判断的地方介入（法务风险、安全边界、产品品味）。这一信任/验证的平衡会随模型变强而持续移动。
- 角色边界正在模糊，招聘重心转移：PM 开始写代码，工程师接手设计与内容。招聘不再追求"原始产能"（模型已能提供），而是聚焦两类人——有产品嗅觉的创造型建设者，以及有深厚系统功底的工程师。
- 用三个指标判断变革是否真正落地：上手爬坡时间下降、PR 周期时间下降、Claude 协助的提交占比上升；但不要把吞吐量误当成功。上手的方法是：挑出最"吵闹"的工作流，自问它是否还有存在价值、能否被自动化。
原文信息 本文译自 Anthropic（Claude）官方博客，作者 Fiona Fung（Claude Code 与 Claude Cowork 工程总监），系其在 Code w/ Claude SF 2026 上的演讲整理。 英文原文存档：English Original 视频：https://www.youtube.com/watch?v=igO8iyca2_g 来源：https://claude.com/blog/running-an-ai-native-engineering-org
在 Code w/ Claude SF 2026 大会上，Claude Code 与 Claude Cowork 的工程总监 Fiona Fung 讲述了当智能体式编码 (agentic coding) 成为默认工作方式后，团队的流程和结构发生了怎样的改变。
多年以来，工程带宽 (engineering bandwidth) 一直是构建应用过程中最昂贵的环节。我们围绕软件规划与交付所建立的每一套流程——先是瀑布模型 (waterfall)、后来是敏捷 (agile)——都是围绕这项成本而设计的。
我的职业生涯始于 2000 年代初，当时在做 Visual Studio。那个年代，我们把软件刻在 CD-ROM 光盘上交付，背后是硬性的生产制造截止日期。等到可以在线分发软件之后，我们逐渐转向了持续不断地发布更新。如今，我们又一次在改变工作方式——这一次改变的，是写软件所需要的时间和人力。
在 Claude Code 团队里，写代码、写测试、做重构早已很少再拖慢我们了。但当智能体式编码免去了实际敲代码的需要时，瓶颈并没有就此消失——验证 (verification)、代码评审 (code review) 和安全 (security) 取代了它们的位置。
我们现在都能非常快速地生成大量代码，但这也带来了新的问题：这些代码正确吗？它该如何维护？还有一个我从其他工程负责人那里最常被问到的问题："在你们这种代码评审方式下，人到底是怎么跟得上节奏的？"
那些悄然失效的流程
我们当初制定每一套流程都是有理由的——为了弥补某个缺口，或让某件事运转得更好。但当那个缺口不复存在、流程变得过时之后，它们却很少会自动消失。当 Claude Code 团队开始把智能体式编码当作默认的工作方式时，我们许多既有流程都失效了。下面是我们重写过的那些规范，以及背后的原因。
规划：把路线图改为准时制
旧的做法是花大量时间做前期规划，因为编码的时间太贵了。我刚加入 Claude Code 团队时，我们写了一份相当不错的六个月路线图；然后，正是因为有了 Claude Code，太多事情都变了，以至于这份路线图到第三个月就已经过时了。
如今工程的速度和吞吐量都不一样了，于是我们规划冲刺 (sprint) 的方式也随之改变。我把它称为准时制 (just-in-time, JIT) 规划，几乎就像 JIT 编译一样：你如何在恰当的时间，只做恰到好处的那部分？我们的规划仪式已经从设计文档，转向了在 PR 或原型中展开的讨论。这个领域变化飞快，所以我们不做太多的产品评审。我们现在的流程是：先做原型，让大量内部用户用起来，然后开始根据他们的反馈行动。
上下文获取：问 Claude，而不是问作者
过去工程师写代码时，要回答大多数问题，第一步是先找到写这段代码的人。如今，由于我们所有的 PR 都有 Claude 协助，"这个改动是谁做的？"已经不再是个足够好的问题了。我们的新规范是再往深一层去想：你真正需要知道的到底是什么？比如说：你是想找出谁引入了某个回归 (regression)？想找一位专家来回答客户的问题？还是想了解某个决策背后的来龙去脉？你把这个问题抛给 Claude，并考虑 Claude 能否直接回答它——往往还能附带更多数据和上下文。
在 Claude Code 团队，无论问题是什么，我们的流程还会再追问一句："有没有办法把它自动化？"举个例子，让 Claude 每天早上汇总客户反馈渠道这件事，已经从过去我端着咖啡手动执行的一项仪式，变成了如今在后台自动运行、我什么都不用管的事情。
代码评审：信任，但要验证
我们大量使用 Code Review（代码评审）功能。Claude 包办了所有的代码风格与 Lint 检查、PR 反馈意见、在正式提交前抓出并修复 Bug，以及补充测试。我们仍然明确需要人类介入的地方，是专业判断。
新的规范是：让人类在真正重要的地方做评审。对于法务评审，我总是希望我的法务伙伴参与到风险容忍度的判断中来；对于信任边界 (trust boundaries) 和安全敏感的代码，我希望由领域专家把关；产品经理和设计师也需要参与进来，提供产品判断力与品味。
不过，持续地重新评估这件事很重要，因为"信任"与"验证"之间的恰当平衡点会随着模型的进步而不断移动。今天你需要人来做的事，到了下一代模型问世时，可能就是另一番样子了。
团队构成：模糊化的角色
Claude 和 AI 重塑了整个团队的角色分工。我们的 PM 现在写很多代码，这看着挺有意思。有了 Claude，原本并非传统意义上的程序员的人，如今也能做更多工程工作；而工程师则开始承担内容、设计这类传统上并不属于技术范畴的工作。
在 Claude Code 工程团队，我重点押注了两类人。一类是有产品嗅觉的创造型建设者 (creative builders)：那些充满好奇心、热衷于打造能真正解决问题的产品的"梦想家"。另一类是拥有深厚系统功底的工程师。举个例子，我刚加入团队时，注意到我们缺少有系统背景的专家，而在构建 Claude Code on the Web（网页版 Claude Code）时我们恰恰需要这样的人，以确保我们能让 Claude 在任何环境下都跑起来。
相反，我越来越不看重的，是原始产能 (raw throughput)——这部分交给模型就好。更重要的问题是：你究竟在哪些地方仍然需要人类的专业能力？那才是我会去聚焦的地方。
| 过去 | 现在 | |
|---|---|---|
| 规划 | 制定六个月的产品路线图。 | 准时制 (JIT) 规划：先做原型，推给内部用户使用，再根据反馈行动。 |
| 上下文获取 | 找到写这段代码的人去问他。 | 先问 Claude。然后再问：所问的这件事能不能被自动化？ |
| 代码评审 | 人类评审一切。 | Claude 处理代码风格、Bug 和测试；人类只在需要领域专业判断的地方评审。 |
| 团队构成 | 角色固定：工程师写代码，PM 做规划，设计师做设计。 | 角色边界模糊：PM 做原型，工程师承担设计与上下文工作。招聘上重点找创造型建设者和深厚系统功底的工程师。 |
我们是如何推行这些新规范的
随着这些规范的改变，有些被定为团队层面的硬性原则，另一些则交给各个小组 (pod) 自己去摸索。Claude Code 核心团队有一组不容妥协的、必须做到的原则：
- 不遗余力地内部试用 (dogfood) 自己的产品：每一位 Claude Code 团队成员，包括跨职能的合作伙伴，都在使用 Claude Code（也包括 Claude Cowork）。我们始终在琢磨各种办法，让 Claude 帮我们把工作做得更快、更高效。
- 让团队尽可能扁平：我加入 Claude Code 时，希望每一位管理者都先从一线工程师 (IC) 做起，通过亲手交付来学会如何成为团队里一名高效的工程师，真切地体验并理解在 Anthropic 当一名工程师是什么感觉。我们在 Claude Code 和 Claude Cowork 上有一个统一的整体团队使命。管理者负责支撑各个工作小组，同时保持团队的敏捷，让人手能随时流动到工作最需要的地方去。
- 不要犹豫，果断砍掉已经失效的流程：最后，我们会毫不留情地追问：我们为什么还要这样做事？当某件事不再有道理时，团队成员有明确的授权去质疑并废除那些陈旧的流程。
不过，在这几条规则之内，每个小组都拥有很大的自主权。他们可以自行调整：如何用 Claude 做问题分诊 (triage)、如何进行各种规划仪式或站会 (standup)，以及哪些工作流最先被"Claude 化 (Claudified)"。
如何判断你的新流程是否真正落地
下面是每一位工程负责人在推行变革时，从现在起就应该开始追踪的三个数字。
- 上手爬坡时间 (onboarding ramp time) 下降：一名工程师、设计师或 PM 多快能开始产出价值？在我们团队，这比一年前快了太多，工程师如今在入职第一周内就能交付真正的代码。
- PR 周期时间 (PR cycle time) 下降：这个指标值得深挖，因为它或许能帮你发现流水线中哪个环节难以扩展。由于我们生成的代码量大了太多，有时构建系统和持续集成 (continuous integration, CI) 会有些跟不上。
- Claude 协助的提交 (Claude-assisted commits) 占比上升：对我们而言，默认情况下每一次提交都有 Claude 协助。过去四个月里，我想我都没见过一次没有 Claude 协助的提交。
关于第三点，不要把吞吐量和成功混为一谈。吞吐量只是一个指标，而真正的指标，是衡量你正试图解决的那个问题本身。当方向对齐时，吞吐量能帮你更快地解决问题。
如何开始
如果只让我留给你一句话，那就是：挑出你最"吵闹"的那个工作流。 它可能是你最昂贵的工作流，可能是你最害怕面对的那个，或者是你的团队一想到就头疼的那个。然后问自己：它还在发挥它本来的作用吗？如果还在，那它能不能被自动化？
我曾经待过一个团队，有一个开销很大的每周评审会，一大群人挤在一个会议室里。我注意到，除了轮到自己汇报进度的那一刻，几乎所有人都埋头在自己的笔记本电脑上。他们会冒个头，报一下状态，然后又埋回电脑里。我只问了一个简单的问题："我们为什么还要开这个会？这看起来是对我们时间的一种昂贵浪费。"就这一个问题，让所有人意识到它其实根本没必要存在。于是我们把它取消了。
所以，问问你自己：你的工程工作流里，有哪一个环节是你可以考虑自动化、甚至干脆彻底取消的？
Related Documents
- English Original
- AI 技术博客索引