上周，Anthropic 在旧金山开了一场开发者大会，叫 Code with Claude 2026。有个演讲我翻来覆去看了好几遍，不是因为发布了什么新产品，而是因为演讲者 Fiona Fung 说了一句话，让我一下子坐直了。「这些流程没有哪个明着死掉，它们只是悄悄停止发挥作用了。」没有警报，没有人站出来说「这个会没必要开了」，没有人质疑「这份设计文档还有没有人看」。那些流程就那么活着，消耗着时间，直到有人忍不住问了一句：我们为什么还在做这个？这件事就发生在 Anthropic 工程团队的内部，当 AI 辅助编程从个别人的习惯变成整个组织的默认选项之后。Fiona Fung 是谁先说一下背景。Fiona Fung 是 Anthropic 的 Claude Code 团队工程负责人，职业履历从 2000 年代初的微软开始，后来去了 Meta，现在在 Anthropic。不是那种刚接触 AI 工具的人，她见过软件工程在互联网普及时经历的那次大变，现在她觉得正在经历第二次。Code with Claude 2026 是 Anthropic 的开发者大会，5 月 6 日在旧金山，几千名工程师、PM、技术负责人到场，之后还会去伦敦和东京。这场演讲是大会下午的重头，讲的是一件很多团队正在回避的事，当 AI 写代码变成日常，整个工程组织怎么跟着变。写代码这件事，不贵了她讲的核心洞察其实可以用一句话说完，写代码这件事，不再是最贵的那个环节了。过去几十年，整个软件工程的组织方式都是围绕一个稀缺资源搭建的，工程师的时间。多少人多少天能写出多少代码，这件事决定了需要几个人、要不要冲刺、设计文档怎么评审、谁负责哪块代码。瀑布也好、敏捷也好，说到底都是在管理这个稀缺性。Fiona 说，在 Claude Code 团队，这个稀缺性基本消失了。大家生产的代码量，不是多了一点点，是多了很多。另一个演讲者 Noah Zweben 的团队给出了一个具体数字，3 个月内，每周合并的 PR 从 500 涨到了 1150，增幅 300%，而团队规模没变。代码堵不住了。于是新的瓶颈冒出来，怎么验证这些代码是对的？谁来 review？法务、设计、安全怎么跟上节奏？越来越大的代码库怎么维护？她做了一个类比。她在微软的早年，一切都得赶在 CD 出厂日期之前做完。发布周期是三年，因为刻盘需要时间。互联网发行来了，整个节奏变了，不是工程师更厉害了，是成本结构变了。现在这件事再发生一次，而成本结构一变，流程必须跟着变。但很多团队还没动。他们重写了这 6 件事然后 Fiona 讲了 Anthropic 工程团队实际改了哪些规范。每一条都很具体，有故事，有逻辑。第一件，规划的方式。她加入 Anthropic 的时候，团队做六个月路线图。结果这份图大概三个月就开始失效，然后不得不推倒重做。现在他们做的叫 JIT Planning，Just-In-Time，即时规划。需要的时候做刚好够用的计划，省下来的时间去做原型。不是不规划，是把花在纸上争论的时间换成了真实产出。第二件，技术争论怎么解决。她讲了一个很具体的故事。她和 Claude Code 负责人 Boris Cherny 在讨论一个 API 怎么重构，两个人意见不一样，快要走向白板了。她停下来，让 Claude 把两个方案各自实现成 PR。他们不只看到了两种代码实现，还看到了两种写法对调用方的影响分别是什么。争论就这么结束了。「当构建变得便宜，争论就变成了奢侈品。」这句话我觉得挺狠的。第三件，Code Review 的分工。这块他们有一套分得比较清楚的逻辑。Claude 负责代码风格检查、lint、PR 自身的格式反馈、小 bug、补充测试。人负责法务相关代码、安全敏感逻辑、产品判断。她讲了一个细节，笑死我了。团队有个终端吉祥物，有一次她让 Claude 给它加个节日主题。Claude 返回来的是一个穿礼服、戴单片眼镜的「Mr. Peanut」，而不是她想要的雪人。她说，这件事说明了什么，你看不看着顺不顺眼，这个 AI 现在还没搞定。产品审美这件事还是得人来把关。所以 review 分工的边界，不是随便划的。第四件，招聘逻辑。她的招聘团队想用经典公式，10 个工程师对 1 个经理，层层往上搭管理层。Fiona 说不行，她要扁平组织，而且每个经理入职必须先从 IC 开始，自己动手写代码，自己摸清楚团队在做什么。招聘团队的反应是，「没有经理愿意先去写代码的。」她的回答是，「那我们早点知道这件事，好过晚点知道。」这个逻辑很硬。如果一个人不愿意先进入自己要负责的那个系统，那你真的想要他来管这个系统吗？第五件，团队构成。以前工程师评估里，代码产出量是很重要的维度。现在这件事 Claude 替代了大半，她不再首选「高吞吐量的通才」，而是两类人，有产品感的创意型工程师（那种看到问题就想动手做原型的），以及有深厚系统背景的专家（分布式、底层基础设施）。同时，角色边界也在变。她团队的设计师和 PM 现在也在写代码，她自己需要起草用户调研问卷的时候，也会让 Claude 帮她出初稿。第六件，信息的来源在哪里。以前开会讲功能细节，大家翻的是产品文档或者规格书。Fiona 现在收到用户问题，直接打开 Claude Code，问代码库本身。代码是最终的真相，文档是附属品。她建议如果你们团队有维护得比较好的设计文档，把它 check in 到代码库里，让 Claude 可以同时看到规格和实现，用来发现两者之间的偏差。这件事本来靠人眼逐行对照，现在可以不用了。3 件不能商量的事在这 6 条可以商量怎么落地的规范之外，她还说了 3 件在 Claude Code 团队不容置疑的原则。第一，所有人都用 Claude Code。不只工程师，PM、设计师、所有跨职能伙伴都用。不然大家的工作方式和理解框架就没法对齐，AI 协作的优势就碎掉了。第二，「Claudify」一切可以自动化的环节。她举了个自己的例子，以前每天早上要手动打开用户反馈频道，让 Claude 给她总结一遍。Anthropic 的 Routines 功能上线之后，这件事变成了定时任务，她现在每天醒来邮件里就有摘要了。第三，明确授权团队成员「杀掉旧流程」。这条听起来最虚，但她觉得是最难落地的一条，因为它需要管理层真的在文化上表个态，而不只是说说。她讲了那个 50 人周例会的故事。所有人开着电脑各干各的，只在轮到自己发言的时候抬头。她去问了一句，「我们为什么要开这个会？」整个会议室点了点头。这个会直接取消了。那个会存在了多久，没有人说得清楚。也没有人问过这个问题。她还不知道答案的几件事演讲最后，她列了几个自己也没有答案的问题。我觉得这段最值得看，因为说明她没有在卖完整方案。当 Claude 可以让工程师低成本来回切换 iOS 和 Android 代码，独立的 iOS 团队和 Android 团队还有没有必要存在？她不知道。自动化 review 该推进到哪一步？她说的原则是「信任但要验证」，但信任多少、验证多少，这条线还在移动，没有固定答案。当设计师、PM、工程师都开始互相「借用」对方的工作，怎么确保每个人都有清晰的价值感和归属感？好看的时候很好看，但需要刻意去维护这个文化契约。这三个问题没有答案，但任何一个认真运营技术团队的人，都该找个时间坐下来认真想一想。瓶颈消失，工作不消失Fiona 在演讲结尾给了一个作业，找一个你自己最不想开的会，或者最不想写的报告，问自己两件事，它还在完成它原本的目的吗？如果没有，能 Claudify，还是直接砍掉？我想起工业化早期，很多工匠担心手艺没了用武之地。后来事情的走向是，手艺没消失，工匠开始管理流水线了。工程师大概也是这条路。只是这次变得快很多，而且很多团队还没意识到，他们的「流水线」早就在悄悄停止发挥作用了。Fiona 那句话我还是觉得说得最准，那些流程没有明着死掉，只是悄悄不工作了。你们团队里，现在有几个这样的流程？