多年来，工程师的工作时间一直是构建应用程序中最昂贵的部分。无论是传统的瀑布模型，还是后来的敏捷开发，所有的软件规划和交付流程都是围绕这一成本设计的。

我在2000年代初开始职业生涯，参与开发Visual Studio。那时软件通过CD-ROM发放，制造和发行有严格的截止时间。随着在线分发的兴起，我们开始实现持续更新。如今，我们的工作方式再次发生变化，这次的焦点是编写软件所需的时间和人员。

在Claude Code团队，编写代码、测试和重构几乎不再成为我们的瓶颈。但当智能编码（agentic coding）减少了实际敲代码的需求后，新的瓶颈出现了：代码验证、代码审查和安全性。

虽然我们现在能快速生成大量代码，但也带来了新的问题：代码是否正确？如何维护？我作为工程领导经常被问到：“人类如何跟上你们的代码审查速度？”

失效的流程

我们制定流程是为了解决问题或提升效率，但当问题消失后，流程往往不会自动消失。Claude Code团队采用智能编码作为默认工作方式后，许多旧流程不再适用。以下是我们重塑的几个核心规范及原因。

规划：转向即时规划

过去因为编码成本高，我们会花大量时间做前期规划。刚加入Claude Code团队时，我们制定了一个六个月的路线图，但由于Claude Code带来的变化，三个月后路线图就过时了。

工程速度和产出发生了变化，冲刺规划方式也随之改变。我称之为即时规划（Just-In-Time Planning），类似即时编译：如何在恰当时间做恰当的事？我们的规划仪式从设计文档转向在PR或原型中讨论。节奏很快，我们不做大量产品评审，而是先做原型，邀请内部用户试用，并根据反馈快速迭代。

获取上下文：问Claude，而非作者

以前工程师遇到问题，第一步是找代码作者。现在所有PR都有Claude辅助，单纯问“谁改了这段代码？”已不够。新规范是深入问：“你真正需要知道什么？”比如：你是在找导致回归的原因？还是需要专家回答客户问题？或者是了解某个决策的背景？你直接问Claude，看看它是否能给出更丰富的答案。

Claude Code团队的流程还包括一个原则：“有没有办法自动化？”例如，Claude每天早上自动汇总客户反馈，取代了我以前喝咖啡时手动做的工作。

代码审查：信任但需验证

我们大量使用代码审查。Claude负责代码风格、lint检查、PR反馈、发现并修复bug、添加测试。人类审查则聚焦于专业领域。

新规范是：关键环节必须有人类审核。法律审查需要法律伙伴参与风险评估；信任边界和安全敏感代码需要领域专家；产品经理和设计师参与产品感知和体验把控。

随着模型不断进步，信任与验证的平衡也需持续调整。今天需要人类介入的部分，未来可能会有所不同。

团队构成：角色模糊化

Claude和AI重塑了团队角色。我们的产品经理现在也大量编写代码，令人欣喜。非传统编码人员能做更多工程工作，工程师也参与内容和设计，这些传统上不属于技术范畴的工作。

Claude Code团队我重点关注两类人才：一是具备产品感知的创造型构建者，他们充满好奇心和热情，致力于交付解决问题的产品；二是拥有深厚系统专业知识的工程师。比如我加入时发现缺少系统专家，建设Claude Code on the Web时就需要他们确保Claude能在任何地方运行。

我不太关注的是纯粹的产出量，因为模型能处理。更重要的是识别仍需人类专业知识的领域，并重点投入。

新规范的推广

这些规范变化中，有些被定为团队原则，必须遵守；有些则由小团队（pod）自行探索。Claude Code核心团队有三条不可妥协的原则：

  • 持续自用产品：团队所有成员，包括跨职能伙伴，都使用Claude Code和Claude Cowork，持续寻找让Claude帮助我们更快更高效工作的方式。
  • 保持团队扁平化：我加入时希望每位管理者先作为个体贡献者（IC）开始，通过交付代码学习如何成为有效工程师，真正理解Anthropic工程师的工作体验。团队有统一使命，管理者支持各pod工作，同时保持敏捷，方便成员流动。
  • 勇于废除无效流程：我们不断质疑现有做法，流程不再合理时，团队成员有明确权限质疑并废除旧流程。

在这些规则框架下，每个pod拥有很大自主权，决定如何利用Claude进行任务分流、规划仪式和日常站会，以及优先“Claude化”的工作流程。

如何判断新流程有效

每位工程领导在推行变革时应关注三项指标：

  • 入职适应时间缩短：新工程师、设计师或产品经理多快能开始高效工作？我们团队现在新成员第一周就能交付真实代码。
  • PR周期缩短：这能帮助发现流水线瓶颈。代码量激增时，构建系统和持续集成（CI）可能跟不上。
  • Claude辅助提交增加：我们默认所有提交都有Claude辅助，过去四个月几乎没见过非Claude辅助的提交。

但要注意，产出量并非成功的唯一指标，关键是衡量你想解决的问题。正确的对齐下，产出能加速问题解决。

如何开始

我给大家的建议是：选出你最繁琐的工作流程。可能是最昂贵、最让人头疼或团队最不喜欢的流程。问问自己：它还在发挥作用吗？能否自动化？

我曾在一个团队，周会非常昂贵，很多人坐在会议室里，除了汇报时抬头，其他时间都在看笔记本。我问了一个简单问题：“我们为什么还要开这个会？这时间花得值吗？”大家顿时意识到没必要，于是取消了会议。

所以，问问自己：你工程流程中有没有一环可以自动化，甚至直接舍弃？