核心思想
当智能体化编程成为默认工作方式，写代码、写测试、做重构都不再是瓶颈——验证、代码评审和安全接了班。作者（Claude Code 团队负责人）据此重写了规划、上下文获取、代码评审、团队构成四类流程，核心取舍是把人类精力从「堆吞吐量」中抽离，集中投到模型仍顶替不了的专业判断上。
配套视频
多年以来，工程带宽一直是构建应用最昂贵的那一环。我们围绕软件规划和交付建立起来的每一套流程——先是瀑布模型，后来是敏捷——都是为这笔成本而设计的。
我的职业生涯始于 2000 年代初，那时我在做 Visual Studio。在那个年代，我们把软件刻在 CD-ROM 上发售，背后是硬性的生产制造截止日期。等到能够通过网络分发软件之后，我们开始越来越频繁地交付更新，直至持续不断地发布。如今，我们又一次改变了工作方式，而这一次，改变的是写软件所需要的时间和人手。
在 Claude Code 团队，写代码、写测试、做重构，如今几乎都不再拖慢我们的脚步。但当智能体化编程(agentic coding)免去了真正动手敲代码的需要之后，瓶颈并没有消失，只是换了位置：验证、代码评审(Code Review)和安全，接了班。
我们现在都能飞快地生成大量代码，可这也带来了新的问题：这些代码正确吗？要怎么维护它？还有一个我从同行工程领导者那里听到最多的问题——“按你们这种代码评审的节奏，人类是怎么跟得上的？“
那些悄悄失效的流程
我们当初设立每一套流程都是有缘由的：为了补上某个缺口，或者把某件事做得更好。可一旦那个缺口不复存在、那些流程变得过时，它们却很少会自行退场。当 Claude Code 团队开始把智能体化编程作为默认的工作方式，我们原有的许多流程都失效了。下面就是我们重写过的那些规矩，以及背后的原因。
规划：把路线图改成即时规划
过去的规矩是把大量时间花在前期规划上，因为写代码的时间太贵了。我刚加入 Claude Code 团队时，我们写出了一份相当不错的六个月路线图，然后——正是因为有了 Claude Code——太多事情发生了变化，到第三个月这份路线图就已经过时了。
如今工程的速度和吞吐量(throughput)都不一样了，所以我们规划冲刺(sprint)的方式也随之改变。我把它叫做即时规划(just-in-time planning，简称 JIT 规划)，几乎就像 JIT 编译一样：怎样才能在恰当的时间、只做恰好够用的那部分？我们的规划仪式不再围着设计文档转，而是转向在 PR（拉取请求）或原型里展开讨论。这个领域变化太快，所以我们不怎么做产品评审。我们现在的做法是：先做个原型，让大量内部用户用起来，再根据他们的反馈行动。
上下文获取：问 Claude，别问作者
工程师写代码的年代，要为大多数问题找到答案，第一步就是去找写这段代码的人。如今，既然我们所有的 PR 都有 Claude 协助，“这处改动是谁做的？“这个问题就不再够用了。我们的新规矩是再往下深挖一层：你究竟想知道什么？比如说：你是想找出谁引入了一处回归（缺陷）？还是想找位专家来回答客户的问题？又或者想了解某个决策背后的来龙去脉？把这个问题抛给 Claude，再想想 Claude 能不能直接回答——而且是结合更多数据和上下文来回答。
在 Claude Code 团队，无论那个问题是什么，我们的做法都会再追问一句：“这件事有没有办法自动化？“举个例子，让 Claude 每天早上汇总各个客户反馈渠道——这件事曾经是我端着咖啡手动完成的例行公事，如今已经变成在后台自动运行的常态。
代码评审：信任，但要验证
我们大量使用 Code Review。风格规范和 lint 检查、响应 PR 上的反馈请求、在正式提交前抓出并修复 bug、补充测试——这些全由 Claude 包办。而我们仍然明确需要人类的地方，是专业判断。
新的规矩是：在真正要紧的地方让人类来审。法务审查方面，凡涉及风险容忍度，我总会让我的法务伙伴参与进来。涉及信任边界(trust boundaries)和安全敏感的代码，我要的是领域专家。产品经理和设计师也得参与进来，贡献他们的产品直觉与品味。
不过有一点很重要：要持续地重新评估，因为随着模型不断进步，信任与验证之间的恰当平衡也会一直变。今天还需要人类来做的事，到了下一代模型那里也许就是另一番光景了。
团队构成：让角色边界变模糊
Claude 和 AI 重塑了团队里的各种角色。我们的产品经理现在写起了大量代码，这场面看着挺有意思。有了 Claude，过去并不算传统意义上写代码的人，如今也能做更多工程的活；而工程师则开始承担起内容、设计这类传统上并不属于技术范畴的工作。
在 Claude Code 工程团队，我重点看重两类人。一类是有产品直觉的创意构建者：他们是怀揣梦想的人，对解决问题、交付产品有着深切的好奇与热情。另一类是拥有深厚系统功底的工程师。举个例子，我刚加入团队时注意到，我们缺少有系统背景的专家，而在构建 Claude Code on the Web 时正需要这样的人，好让我们能在任何地方运行 Claude。
反过来说，我看得比较轻的，是单纯堆吞吐量——那部分交给模型就行。更重要的问题是：你在哪些地方仍然离不开人类的专业能力？那才是我会聚焦的地方。
| 之前 | 之后 | |
|---|---|---|
| 规划 | 六个月的产品路线图。 | 即时规划(JIT)：做原型、让内部用户用起来、按他们的反馈行动。 |
| 上下文获取 | 找到写这段代码的人去问他。 | 先问 Claude。然后再问一句：你要打听的这件事能不能自动化。 |
| 代码评审 | 人类审查一切。 | Claude 包办风格、bug 和测试。人类只在领域专业判断要紧的地方审查。 |
| 团队构成 | 角色固定：工程师写代码、产品经理做规划、设计师做设计。 | 角色边界模糊：产品经理做原型，工程师承担设计和上下文。招人就招有创意的构建者和深厚的系统专家。 |
我们是怎么推行这些新规矩的
随着这些规矩的改变，有些方面定为团队原则、强制执行，另一些则交给小型子团队（即小组，pod）自己去摸索。Claude Code 核心团队有一套不容商量的”必做”原则：
- 不遗余力地吃自家狗粮(dogfood，内部先行试用自己的产品)： 每一位 Claude Code 团队成员，包括跨职能的合作伙伴，都要使用 Claude Code（以及 Claude Cowork）。我们总在琢磨各种办法，让 Claude 帮我们把工作做得更快、更高效。
- 尽可能保持团队扁平。 我加入 Claude Code 时就希望，每一位管理者都先从一线工程师(IC, individual contributor)做起，通过亲手交付来学会怎样成为团队里一名称职的工程师，真正去体验、去理解在 Anthropic 当一名工程师是什么滋味。Claude Code 和 Claude Cowork 共担一个统一的团队使命。管理者为各个小组的工作提供支持，同时保持团队的灵活机动，让人手可以流向最需要的地方。
- 该砍的流程别犹豫： 最后，我们会不留情面地追问：我们为什么要用现在这套方式做事？当某件事不再说得通，团队成员就有明确的授权去质疑它、废除这些老旧的流程。
不过，在这寥寥几条规矩之内，每个小组都拥有很大的自主权。他们可以自由调整：怎样用 Claude 做问题分诊、怎样开各自的规划仪式或站会、以及哪些工作流最先被”Claude 化”。
怎样判断新流程是不是真的扎下了根
下面三个数字，是每一位工程领导者在推行变革时都该从现在起开始追踪的。
- 入职上手时间在下降： 一名工程师、一位设计师或一位产品经理，要多久才能开始发挥作用？我们团队这个时间比一年前快得多，工程师如今在入职第一周内就能交付真正的代码。
- PR 周期时间在下降： 这一项深挖下去很有意思，因为它也许能帮你看出流水线在哪里难以扩展。随着我们生成的代码大幅增多，构建系统和持续集成(CI)有时会有点跟不上。
- Claude 辅助提交在上升：对我们来说，默认每一次提交都有 Claude 协助。过去四个月里，我想我都没见过一次没有 Claude 协助的提交。
关于第三条，别把吞吐量当成成功。吞吐量只是一个指标，而真正的指标，是去衡量你真正想解决的那件事。方向对齐之后，吞吐量能帮你更快地把问题解决掉。
从何处入手
如果只让我给你留下一句话，那就是：挑出你最闹心的那个工作流。 它可能是你成本最高的工作流，可能是你一想到就发怵的那个，又或者是团队都不待见的那个。然后问一句：它还在发挥它该有的作用吗？如果是，那它能不能自动化？
我曾经待过一个团队，每周都有一场成本高昂的评审会，一大群人挤在一间会议室里。我注意到，除了轮到自己做状态汇报的时候，所有人都埋头盯着各自的笔记本电脑。轮到他们时，他们会抬一下头，把状态说一遍，然后又埋回各自的电脑里。我问了一个再简单不过的问题：“我们为什么还要开这个会？这么用大家的时间，似乎太奢侈了。“就这么一个问题，让所有人都意识到这会根本没必要开。于是我们把它取消了。
所以，问问你自己：你的工程工作流里，有哪一环是你或许可以考虑去自动化、甚至干脆彻底舍弃的？
相关笔记
- 为什么你的「AI 优先」战略很可能是错的 —— 对「AI 优先」战略的冷思考，与本文的流程取舍互为镜像
- OpenAI 如何使用 Codex —— 另一家头部公司的智能体编程内部落地与最佳实践
- 我的 AI 工具采用之旅 —— 个体视角的 AI 工具采用历程，可与本文的团队视角对照
- 用了 3 个月 Claude Code，这 9 条最佳实践让我少走了无数弯路 —— Claude Code 实战层面的经验沉淀
- 编排税：你的注意力才是唯一的串行瓶颈 —— 当吞吐量不再稀缺，注意力成为新瓶颈的深入讨论