AI 原生工程组织如何运转

2026 年 6 月 3 日，Anthropic 在 Claude 博客发布了 Running an AI-native engineering org。这篇文章来自 Code w/ Claude SF 2026 的分享，主讲人是 Claude Code 与 Claude Cowork 的工程总监 Fiona Fung。

这篇文章最有价值的地方，不是说 Claude Code 能让工程师多快写完代码。它真正讨论的是：当编码、测试和重构不再是主要瓶颈，工程组织原有的流程会在哪些地方失效。

原文有一句判断很直接：

Verification, code review, and security took their place.

也就是说，Agentic Coding 把“敲代码”这件事加速之后，瓶颈并没有消失，只是转移到了验证、代码评审、安全边界、上下文判断和组织协作上。

为什么旧流程会悄悄失效

过去几十年，软件工程流程基本围绕一个假设展开：工程带宽很贵，写代码慢，所以要提前规划、反复对齐、控制返工。

瀑布模型是这样，敏捷流程也是这样。差别只是交付周期从很长变成较短，但底层约束仍然是“代码生产能力有限”。

Claude Code 团队的经验是，当 AI 辅助编码成为默认工作方式后，这个约束开始变化。写代码、写测试、做重构不再经常拖慢团队，旧流程中很多原本合理的成本控制动作，反而变成了新的摩擦。

可以把变化理解成下面这条链路：

flowchart LR
    A[编码成本下降] --> B[产出速度上升]
    B --> C[旧流程不再匹配]
    C --> D[瓶颈转向验证和判断]
    D --> E[重写规划、评审和团队分工]

重点不是“流程都不要了”，而是不要让旧流程继续解决一个已经不再成立的问题。

规划：从六个月路线图转向 JIT

Fiona Fung 在文中提到，她刚加入 Claude Code 团队时，团队写过一份不错的六个月路线图。但由于 Claude Code 改变了执行速度，很多事情到第三个月就已经过时。

这不是路线图写得不好，而是节奏变了。

Claude Code 团队现在更接近 Just-in-Time（JIT）规划：在合适的时间做刚好足够的规划。相比把大量时间投入前期设计文档，他们更倾向于用 PR 讨论和原型推进，先让内部用户使用，再基于反馈调整。

这对工程管理有一个直接提醒：如果团队已经能很快产出可运行原型，过度前置的产品评审和长周期路线图就可能降低学习速度。更实用的做法，是把规划粒度压小，让真实反馈更早进入决策。

上下文：不要只问“谁写的”

传统工程团队里，遇到代码问题时常见动作是找作者。这个动作背后有一个默认假设：代码主要由某个人写出来，作者最了解上下文。

但在 Claude Code 团队里，PR 默认都由 Claude 辅助完成。“谁改了这段代码”仍然有价值，却不再是最关键的问题。更好的问题是：

你想定位一次回归的原因吗？
你需要找能回答客户问题的专家吗？
你是在追溯某个技术或产品决策的上下文吗？

不同问题需要不同路径。原文给出的新习惯是先问 Claude，并继续追问这件事能否自动化。例如，作者过去每天早上手动汇总客户反馈渠道，现在让 Claude 在后台自动完成。

这其实是一个很重要的组织习惯：把“找人问”改成“先明确问题，再判断信息能否被系统化获取”。

代码评审：信任，但要验证

原文把代码评审部分概括为 trust but verify。Claude Code 团队大量使用 Code Review：风格、lint、PR 反馈请求、缺陷发现、提交前修复和补测试，都会先让 Claude 分担。

但人没有退出评审。人的位置变得更精确。

在法律风险、信任边界、安全敏感代码、产品判断和设计品味上，Claude Code 团队仍然强调领域专家参与。原因很简单：这些地方不只是“代码是否能跑”，还涉及风险容忍度、产品取舍和长期维护成本。

这也是 AI 原生工程组织最容易被误解的地方。它不是把所有评审都外包给模型，而是让模型处理高频、低判断负担的问题，让人类专家集中在真正需要责任和判断的地方。

团队分工：角色边界会变模糊

Claude 和 AI 改变了 Claude Code 团队的角色边界。原文提到，PM 现在也会大量写代码；非传统编码背景的人可以承担更多工程工作，工程师也会进入内容、设计等过去不太属于技术侧的工作。

这会改变招聘和团队配置的重点。

Fiona Fung 说她更看重两类人：一类是有产品感的创意型构建者，另一类是有深厚系统经验的工程师。相反，在 Claude Code 团队的语境里，单纯的原始吞吐量没有以前那么关键，因为模型已经能承担很大一部分产出工作。

这不是说工程能力不重要，而是工程能力的稀缺点在变化。未来更稀缺的，可能是提出好问题、定义好边界、理解系统约束、判断哪些工作应该自动化的人。

推行新规范：少数原则，更多自治

Claude Code 团队没有把所有流程统一规定死。原文提到，有些原则是不可协商的，其他部分则让小团队自行适配。

不可协商的原则包括三类：

持续 dogfood 自己的产品。Claude Code 团队成员，包括跨职能伙伴，都使用 Claude Code 和 Claude Cowork。
尽量保持团队扁平。Fiona Fung 希望经理先作为 IC 参与交付，真正理解在团队中用 Claude Code 工作是什么体验。
允许并鼓励杀掉不再有效的流程。当某个流程不再有意义，团队成员有明确权限去质疑和移除它。

在这些原则之外，每个 pod 可以自行决定如何用 Claude 做 triage、如何安排计划会议和站会，以及先把哪些工作流“Claudified”。

这个做法值得借鉴：AI 原生组织不应该把所有团队都压成同一种操作手册。更合理的是固定少数底层原则，然后允许不同小团队根据自己的工作负载寻找最佳流程。

如何判断新流程真的生效

原文建议工程负责人开始跟踪三个指标。

第一是 onboarding ramp time 是否下降。也就是新人，包括工程师、设计师和 PM，需要多久才能真正有效工作。Claude Code 团队观察到，这个时间比一年前短得多，工程师入职第一周就能交付真实代码。

第二是 PR cycle time 是否下降。这个指标还可以帮助团队发现流水线里新的瓶颈。例如，当代码生成速度大幅上升，构建系统和 CI 可能会成为扩展受限点。

第三是 Claude-assisted commits 是否上升。Claude Code 团队的默认状态是每个提交都有 Claude 辅助，Fiona Fung 表示自己过去四个月没有看到非 Claude 辅助的提交。

但原文也提醒，不要把吞吐量误当成成功。吞吐量可以帮助团队更快解决问题，但真正应该衡量的，仍然是你原本要解决的业务或工程问题。

可以从哪里开始

如果要把这篇文章落到自己的团队里，最小的切入点不是“全员立刻换流程”，而是挑一个最吵、最贵、最让团队抗拒的工作流。

问三个问题：

这个流程现在还服务于原来的目的吗？
如果服务于目的，是否能被 AI 辅助或自动化？
如果不再服务于目的，是否应该直接删掉？

原文举了一个例子：一个成本很高的每周评审会，很多人坐在会议室里，大多数时间都在看电脑，只有轮到自己汇报时才抬头说几句。这样的流程过去可能是必要的，但在新的工作方式下，完全可能被自动化摘要、异步更新或更小范围的决策机制替代。

AI 原生工程组织的关键，不是把所有工作都交给 AI，而是重新审视每个流程背后的约束。约束变了，流程也应该变。