以前写代码是挺贵的，所以搞了那么多流程，什么瀑布啊敏捷啊，都是绕着这个成本转的。
我刚开始干这行的时候在Visual Studio，那时候软件靠光盘发，有个死线的。后来能在线更新了，发版本的频率就越来越高。现在呢，写代码需要的时间和人力又变了。
在Claude Code团队，写代码、写测试、重构这些事儿，基本不怎么会拖慢我们了。但是智能体把敲代码的活儿干了，瓶颈并没消失，换成验证、代码审查和安全性这些事儿了。
我们现在都能哗哗生成一大堆代码，但新问题来了：这代码对吗？怎么维护？别的工程领导老问我：“人怎么跟得上你们审查代码的速度啊？”
一些流程悄悄不管用了
我们搞流程都是有原因的，要么补缺口，要么让事情更好办。但缺口没了，流程过时了，它们自己可不会消失。Claude Code团队开始默认用智能体编程的时候，好多现有流程就废了。下面是我们重写的几条规矩，还有为啥改。
规划：路线图改成即时制
老规矩是花大把时间预先规划，因为写代码贵啊。我刚来Claude Code团队时，我们搞了个不错的六个月路线图，结果因为Claude Code，变化太快了，第三个月就没啥用了。
现在工程速度和吞吐量不一样了，所以我们规划冲刺的方式也变了。我叫它即时(JIT)规划，有点像JIT编译：怎么在刚好需要的时候做刚好够的事？我们的规划会从写设计文档，变成了在PR或者原型里讨论。这领域发展太快，我们不做太多产品评审。现在流程是：先搞个原型，让大量内部用户用，然后根据他们反馈开干。
找上下文：问Claude，别问作者
以前工程师写代码，有问题第一步就是找写代码的人问。现在，我们所有PR都让Claude帮忙，“谁改的？”这问题不够了。新规矩是往深一层想：你到底需要知道啥？比如：你是想找导致bug的人？还是能回答客户问题的专家？或者是某个决定的上下文？你把那个问题拿去问Claude，同时想想Claude能不能直接回答，还能给更多数据和上下文。
在Claude Code团队，不管啥问题，我们的流程还包括问“这能自动化吗？”。比如，让Claude每天早上总结客户反馈，这事儿从我边喝咖啡边手动搞，变成了后台自动跑的东西。
代码审查：信任但要验证
我们大量用代码审查。Claude管所有的代码风格检查、PR反馈请求、提交前抓错修错，还有加测试。我们绝对还需要人的地方是专业知识。
新规矩是在重要的地方让人审：涉及法律审查，我肯定要法律合作伙伴来判断风险。涉及信任边界和安全敏感的代码，我需要领域专家。产品经理和设计师也得来把把关，看看产品感觉和品味对不对。
不过，持续评估挺重要，因为模型在改进，信任和验证的平衡一直在变。你今天需要人的地方，下个模型版本可能就不一样了。
团队构成：角色模糊了
Claude和AI把整个团队的角色都重塑了。我们的产品经理现在经常写代码，挺有意思的。有了Claude，不太会写代码的人现在也能干更多工程活儿，而工程师呢，开始干内容和设计这些传统上非技术的活儿。
在Claude Code工程团队，我特别看重两种人。一种是有产品感觉的创意构建者：那种充满好奇心、热衷于交付能解决问题的产品的梦想家。另一种是有深厚系统专业知识的工程师。比如我刚来团队时，注意到我们缺有系统背景的专家，而做Claude Code on the Web的时候我们需要这种人，确保Claude在哪都能跑。
另一方面，我不太看重的是原始吞吐量；模型会搞定那部分。更重要的问题是，哪里还需要人的专业知识，那才是我关注的重点。
| 之前 | 之后 | |
|---|---|---|
| 规划 | 六个月产品路线图。 | 即时(JIT)规划：做原型，让内部用户用，按反馈行动。 |
| 找上下文 | 找写代码的人问。 | 先问Claude。然后问这事儿能不能自动化。 |
| 代码审查 | 人审所有东西。 | Claude管风格、错误和测试。人在需要专业知识的地方审。 |
| 团队构成 | 固定角色：工程师写代码，产品经理做规划，设计师做设计。 | 角色模糊：产品经理做原型，工程师干设计和上下文工作。招创意构建者和有深厚系统专业知识的人。 |
我们怎么推行新规矩
这些规矩变了，有些成了团队必须遵守的原则，其他的我们让小的子团队（小组）自己摸索。Claude Code核心团队有几条没得商量的“必须做”：
- 死命用自己的产品： 每个Claude Code团队成员，包括跨职能的伙伴，都用Claude Code（还有Claude Cowork）。我们老琢磨怎么让Claude帮我们更快更高效地干活。
- 团队尽量扁平。 我刚来Claude Code时，希望每个管理者都先从个人贡献者做起，通过实际交付学怎么当团队里高效的工程师，真正体验一下在Anthropic当工程师是啥感觉。我们在Claude Code和Claude Cowork上有个整体的团队使命。管理者支持各个工作小组，同时保持团队灵活，让人能流动到需要的地方。
- 别犹豫，废掉不管用的流程： 最后，我们不停地问为啥要这么做。当一件事没意义了，团队成员被明确授权去质疑，然后废掉它。
不过，在这几条规则之内，每个小组自主权挺大的。他们可以灵活调整怎么用Claude来分类、怎么开规划会或站会、哪些工作流程先被“Claude化”。
怎么知道新流程站稳了
每个工程领导推变革时，现在就该开始盯三个数。
- 上手时间降了： 一个工程师、设计师或产品经理要多久才能高效干活？在我们团队，这比一年前快多了，工程师现在第一周就能交付真实代码。
- PR周期时间降了： 深挖这个挺有意思，可能帮你发现流水线在哪儿卡住了。我们生成这么多代码，有时候构建系统和持续集成(CI)可能跟不上。
- Claude辅助的提交比例升了： 对我们来说，默认每次提交都是Claude辅助的。我过去四个月好像就没见过不是Claude辅助的提交。
关于第三点，别把吞吐量和成功混一块。吞吐量是个指标，但真正的指标是你想解决的问题解决了多少。目标一致的话，吞吐量能帮你更快解决问题。
怎么开始
要我说，就一条建议：选你最烦人的工作流程。 可能是最贵的那个，可能是你有点怕的那个，也可能是你团队不爱干的那个。然后问：它还有用吗？如果有，能自动化吗？
我以前在一个团队，每周都有个贼贵的评审会，会议室一堆人。我注意到除了轮到自己说状态，其他人都在看笔记本。他们会抬头说一下，然后又低头看。我就问了个简单问题：“我们为啥还要开这会？好像挺浪费时间的。”就这一个问题，大家都觉得没必要开了。我们就把它取消了。
所以，问问自己：在你的工程工作流里，有哪部分你可能会想着自动化，甚至干脆扔掉？