在 Code w/ Claude SF 2026 上，Claude Code 与 Claude Cowork 工程总监 Fiona Fung 分享了一个关键变化：当智能体编码成为默认工作方式后，团队的流程和组织结构也随之发生了变化。

很多年来，构建应用时最昂贵的部分一直是工程带宽。我们过去围绕软件规划和交付建立的所有流程，无论是最早的瀑布式开发，还是后来的敏捷开发，本质上都是围绕这个成本设计的。

我在 21 世纪初开始职业生涯，当时参与的是 Visual Studio。那时候，我们把软件刻录到 CD-ROM 里发布，还必须遵守严格的制造交付截止时间。后来，软件可以在线分发，我们开始持续提升发布频率，逐步走向连续更新。现在，我们又一次改变工作方式，这一次改变的是写软件所需的时间和人力。

在 Claude Code 团队，写代码、写测试、重构代码，已经很少再成为拖慢我们的因素。但当智能体编码消除了“亲手敲代码”这个瓶颈后，瓶颈并没有消失，而是转移到了验证、代码评审和安全上。

现在，我们都可以非常快速地生成大量代码，但这也带来了新的问题：这些代码正确吗？后续如何维护？而我从其他工程负责人那里听到最多的问题之一是：

“你们是怎么让人类跟上这种代码评审节奏的？”

那些悄悄失效的流程

我们建立流程，通常都有原因：要么是为了弥补某个缺口，要么是为了让某件事运转得更好。但当那个缺口已经不存在、流程已经过时时，它们很少会自动消失。

当 Claude Code 团队开始把智能体编码作为默认工作方式时，我们原有的很多流程都不再适用了。下面是我们重写的一些团队规范，以及背后的原因。

规划：从路线图转向即时规划

过去的默认做法，是花大量时间做前期规划，因为编码时间很昂贵。

我刚加入 Claude Code 团队时，我们写过一份相当不错的六个月路线图。但因为 Claude Code 带来的变化太快，这份路线图到了第三个月就已经过时了。

现在，工程速度和吞吐量已经不同了，所以我们做 sprint 规划的方式也发生了变化。我把它称为“即时规划”，也就是 JIT planning，有点像 JIT compiling：如何在正确的时间，做刚刚好的规划？

我们的规划仪式，不再以设计文档为中心，而是更多转向 PR 讨论或原型验证。这个领域变化太快，所以我们不会做很多传统意义上的产品评审。现在的流程是：先做原型，让大量内部用户用起来，然后迅速基于反馈行动。

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

以前，当工程师写代码时，如果你想搞清楚某个问题，第一步通常是找到写这段代码的人。

现在，由于我们的所有 PR 都有 Claude 参与，“是谁做了这个改动？”已经不再是一个足够好的问题。

新的规范是往下再问一层：你真正想知道的到底是什么？

比如：

• 你是在找是谁引入了某个回归问题吗？

• 你是在找能回答客户问题的专家吗？

• 你是在寻找某个决策背后的上下文吗？

你应该直接把这个问题问 Claude，并判断 Claude 是否可以基于更多数据和上下文直接回答。

在 Claude Code 团队，不管问题是什么，我们都会继续追问一句：

“这件事有没有办法自动化？”

例如，过去我每天早上喝咖啡时，会手动让 Claude 总结客户反馈渠道。后来，这变成了一个后台自动运行的流程。

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

我们非常重度地使用 Code Review。Claude 会处理风格和 linting 问题、PR 反馈请求、在完整提交之前发现并修复 bug，以及补充测试。

但我们仍然明确需要人类参与的地方，是专业判断。

新的规范是：在人类真正重要的地方进行人工评审。

比如，涉及法律审查时，我一定希望法务伙伴参与风险容忍度判断；涉及信任边界和安全敏感代码时，我希望领域专家参与；产品经理和设计师也需要参与产品感觉和审美判断。

不过，这件事需要持续评估。因为随着模型能力提升，信任与验证之间的平衡点会持续变化。今天必须由人类完成的事情，到了下一个模型版本，可能就会变得不一样。

团队构成：角色边界正在模糊

Claude 和 AI 已经重塑了团队里的很多角色。

现在，我们的产品经理也会写很多代码，这一点很有意思。借助 Claude，很多非传统程序员也可以做更多工程工作；同时，工程师也开始承担内容、设计等过去通常不属于技术侧的工作。

在 Claude Code 工程团队，我尤其看重两类人。

第一类，是有产品感觉的创意型构建者。他们是那种充满想象力的人，对交付真正解决问题的产品充满好奇和热情。

第二类，是拥有深厚系统能力的工程师。比如我刚加入团队时，就注意到我们缺少系统背景专家。而当我们开始构建 Claude Code on the Web，希望确保 Claude 能在各种环境中运行时，这类能力就变得非常关键。

相反，我不那么看重纯粹的原始吞吐量，因为模型已经可以处理这部分工作。更重要的问题是：哪里仍然需要人类的专业能力？那才是我会重点投入的地方。

从“之前”到“之后”

规划方式的变化：

之前是六个月产品路线图。

之后是即时规划，也就是先做原型，让内部用户用起来，再基于反馈快速行动。

上下文获取的变化：

之前是找到写代码的人，然后问他。

之后是先问 Claude，再判断你正在询问的事情是否可以被自动化。

代码评审的变化：

之前是人类审查所有内容。

之后是 Claude 处理代码风格、bug 和测试，人类只在领域专业判断重要的地方进行评审。

团队构成的变化：

之前是固定角色：工程师写代码，产品经理做规划，设计师做设计。

之后是角色边界模糊：产品经理做原型，工程师参与设计和上下文工作。招聘时更看重创意型构建者和深度系统专家。

我们如何推广这些新规范

随着这些规范发生变化，有些内容被明确规定为团队原则，有些则交给小团队，也就是 pod，自行探索。

Claude Code 核心团队有一组不可协商、必须遵守的原则。

第一，极致使用自己的产品

Claude Code 团队的每一位成员，包括跨职能合作伙伴，都会使用 Claude Code，也会使用 Claude Cowork。

我们一直在思考，如何让 Claude 帮助我们更快、更高效地完成工作。

第二，让团队尽可能扁平

我加入 Claude Code 时，希望每一位管理者一开始都先以 IC，也就是个人贡献者的身份参与团队，先通过交付来学习如何成为团队里高效的工程师，并真正体验和理解在 Anthropic 做工程师是什么感受。

在 Claude Code 和 Claude Cowork 上，我们只有一个整体团队使命。管理者支持不同的工作 pod，同时保持团队敏捷，让人可以流动到最需要他们的地方。

第三，不要犹豫，杀掉已经失效的流程

最后，我们会持续追问：为什么我们要这样做？

当某件事不再合理时，团队成员被明确授权去质疑并废除旧流程。

不过，在这些少数原则之内，每个 pod 都拥有很大的自主权。

他们可以自行调整如何使用 Claude 做 triage，如何运行规划仪式或站会，以及哪些工作流应该最先被“Claude 化”。

如何判断新流程是否真正落地

当你开始推广这些变化时，工程负责人应该从现在开始追踪三个数字。

第一，新人上手时间下降

一个工程师、设计师或产品经理，需要多久才能真正开始产生有效产出？

在我们团队，这个速度比一年前快了很多。现在工程师在入职第一周就能交付真实代码。

第二，PR 周期时间下降

这个指标很值得深入分析，因为它可以帮助你发现工程流水线里哪些环节难以扩展。

当我们生成的代码越来越多时，构建系统和持续集成，也就是 CI，有时可能会跟不上。

第三，Claude 辅助提交比例上升

对我们来说，默认情况下，每一次提交都是 Claude 辅助完成的。我已经有四个月没有见过非 Claude 辅助的提交了。

不过，在第三点上，不要把吞吐量误认为成功本身。吞吐量只是一个指标，真正重要的指标，是你到底想解决什么问题。

只要目标对齐，吞吐量可以帮助你更快地解决问题。

如何开始

如果只让我留给你一个建议，那就是：挑出你团队里最吵、最烦、最耗精力的工作流。

它可能是成本最高的工作流，也可能是你一直不想碰的工作流，或者是团队最不期待的工作流。

然后问自己：它现在还在发挥原本的作用吗？如果是，它能不能被自动化？

我曾经待过一个团队，每周都有一次成本很高的评审会，会议室里坐着很多人。我注意到，除了轮到自己汇报状态时，其他人几乎都在用笔记本电脑做自己的事。

轮到他们时，他们会抬起头，汇报一下状态，然后又低头回到自己的电脑上。

我问了一个很简单的问题：

“我们为什么还要开这个会？这看起来像是在用一种非常昂贵的方式消耗大家的时间。”

就是这一个问题，让所有人意识到这个会议已经没有必要了。于是我们取消了它。

所以，你也可以问问自己：

在你的工程工作流里，有哪一个环节可以考虑自动化，甚至直接取消？