Anthropic已停止的六项团队工作实践

Fiona在演讲结尾留了个思考题：找找你最不想开的会，或者最不想写的报告，然后问自己两个问题——它还在完成最初设立它的目的吗？如果不能，是能用AI（Claudify）优化掉，还是干脆直接砍掉？

上周，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日在旧金山举行，吸引了数千名工程师、产品经理和技术负责人到场，后续还会移师伦敦和东京。Fiona的这场演讲是下午的重头戏，主题直指许多团队正在回避的核心问题：当AI写代码成为日常，整个工程组织该如何随之进化。

写代码，不再是成本最高的环节了

她的核心洞察其实可以用一句话概括：写代码这件事，已经不再是软件开发中最昂贵的那部分了。

过去几十年，整个软件工程的组织方式，都是围绕一个稀缺资源搭建的——工程师的时间。多少人、多少天能产出多少行代码，这个公式决定了团队规模、冲刺节奏、设计文档的评审流程，以及代码所有权的划分。无论是瀑布模型还是敏捷开发，本质上都是在管理这种稀缺性。

Fiona指出，在Claude Code团队，这种稀缺性基本消失了。团队产出的代码量，不是增加了一点点，而是大幅跃升。另一位演讲者Noah Zweben的团队给出了具体数字：三个月内，每周合并的Pull Request从500个增长到了1150个，增幅高达300%，而团队规模保持不变。

代码像洪水一样涌来，堵不住了。于是，新的瓶颈浮出水面：如何验证这些代码的正确性？谁来评审？法务、设计、安全团队如何跟上这个节奏？日益庞大的代码库又该如何&维护？

她做了一个精妙的类比。在微软的早期岁月，所有工作都必须赶在光盘压制的出厂日期前完成。发布周期长达三年，因为刻录光盘需要时间。互联网发行模式的出现，彻底改变了节奏——这不是因为工程师突然变厉害了，而是成本结构发生了根本变化。如今，同样的事情正在重演。成本结构一变，流程就必须跟着变。

但问题是，很多团队还没开始行动。

他们重新设计了这六项工作规范

接下来，Fiona详细分享了Anthropic工程团队实际调整了哪些具体规范。每一条都源自真实故事，逻辑清晰，极具参考价值。

第一，规划方式。

她刚加入Anthropic时，团队还在做传统的六个月路线图。结果发现，这份路线图大概三个月后就开始失效，然后不得不推倒重来。

现在他们推行的是“JIT规划”，即即时规划。只在需要的时候，制定刚好够用的计划，把省下来的时间全部投入去做原型。这不是不要规划，而是把花在纸面争论上的时间，置换成了真实的产出和验证。

第二，技术争论的解决之道。

她讲了一个非常具体的故事。有一次，她和Claude Code的负责人Boris Cherny在讨论一个API该如何重构，两人意见相左，眼看就要陷入白板拉锯战。她叫了暂停，然后让Claude将两个人的方案分别实现成可运行的Pull Request。

他们不仅看到了两种代码实现，更清晰地看到了每种方案对调用方产生的具体影响。争论就这样自然而然地结束了。

“当构建（代码）变得廉价，争论就成了一种奢侈品。”这句话，可谓一针见血。

第三，代码评审（Code Review）的分工。

在这方面，他们形成了一套清晰的边界。Claude负责代码风格检查、Lint规则、PR格式反馈、小bug修复以及补充测试用例。而人类则专注于法务相关代码、安全敏感逻辑以及产品层面的判断。

她分享了一个有趣的细节，令人忍俊不禁。团队有个终端吉祥物，一次她让Claude给它加个节日主题。Claude返回的结果，是一个穿着礼服、戴着单片眼镜的“花生先生”（Mr. Peanut），而不是她想要的雪人。

她说，这件事说明了一个关键点：审美和“感觉对不对”这类主观判断，AI目前还搞不定。产品的品味和体验，依然需要人类来把关。所以，评审分工的边界，绝不是随意划定的。

第四，招聘逻辑。

公司的招聘团队曾想沿用经典公式：10个工程师配1个经理，层层向上搭建管理层。Fiona明确反对，她坚持要扁平化的组织架构，并且要求每一位新经理入职后，必须先从独立贡献者（IC）做起，亲手写代码，亲自摸清团队在做什么。

招聘团队的反应是：“没有经理愿意先去做写代码的活儿。”

她的回答斩钉截铁：“那我们早点知道这一点，总比晚点知道要好。”

这个逻辑非常硬核：如果一个人不愿意先深入理解他即将负责的系统，那你真的放心让他来管理这个系统吗？

第五，团队构成。

过去在评估工程师时，代码产出量是一个重要维度。现在，这部分工作大半已被Claude替代。她不再优先寻找“高吞吐量的通才”，而是转向两类人才：一是具有产品感的创意型工程师（那种看到问题就手痒想动手做原型的人），二是在分布式系统、底层基础设施等领域有深厚背景的专家。

同时，角色边界也在变得模糊。她团队里的设计师和产品经理现在也开始写代码；而当她自己需要起草用户调研问卷时，也会让Claude先出个初稿。

第六，信息的源头。

以前开会讨论功能细节，大家翻的是产品文档或规格说明书。现在，Fiona收到用户反馈后，会直接打开Claude Code，询问代码库本身。代码成了最终的真相来源，文档则退居为辅助参考。

她建议，如果团队有维护得比较好的设计文档，不妨把它也提交（check in）到代码库里。这样Claude就能同时看到设计规格和实际实现，自动发现两者之间的偏差。这项工作原本需要人眼逐行对照，现在可以省掉了。

三条不容商量的原则

在这六条可以因地制宜落地的规范之外，她还强调了在Claude Code团队内部三条不容置疑的原则。

第一，全员使用Claude Code。 不只是工程师，产品经理、设计师以及所有跨职能伙伴都必须使用。否则，大家的工作方式和理解框架就无法对齐，AI协作的优势就会支离破碎。

第二，“Claudify”一切可自动化的环节。 她举了自己的例子：以前每天早晨要手动打开用户反馈频道，再让Claude总结一遍。Anthropic的“Routines”功能上线后，这件事变成了自动定时任务，每天醒来，摘要已经躺在邮箱里了。

第三，明确授权团队成员“杀掉旧流程”。 这条听起来最虚，但她认为是最难落地的一条，因为它需要管理层在文化上做出真正的表态，而不是空喊口号。

她讲了那个“50人周例会”的故事。会上所有人开着电脑各忙各的，只有轮到自己发言时才抬起头。她直接问了一句：“我们为什么要开这个会？”

整个会议室的人点了点头。这个会随即被取消。

那个会存在了多久？没人说得清。也从来没人问过这个问题。

几个尚未找到答案的问题

演讲最后，她列出了几个自己也没有明确答案的问题。这段或许最值得细品，因为它表明她提供的并非一套完整的“卖方案”。

当Claude能让工程师低成本地在iOS和Android代码间切换时，独立的iOS团队和Android团队还有存在的必要吗？她不知道。

自动化评审应该推进到哪一步？她的原则是“信任但要验证”，但信任多少、验证多少，这条界线仍在动态移动，没有固定答案。

当设计师、产品经理、工程师都开始“借用”彼此的工作产出时，如何确保每个人仍有清晰的价值感和归属感？顺风顺水时一切美好，但这需要刻意去维护一种新的文化契约。

这三个问题目前都没有标准答案，但任何一个认真运营技术团队的人，都值得花时间坐下来好好思考一下。

瓶颈转移了，但工作不会消失

Fiona在演讲结尾布置的那个“作业”，值得我们所有人带入自己的工作场景：找到那个你最不想开的会，或最不想写的报告，然后认真审视它。

这让人联想到工业化早期，许多工匠担心自己的手艺会失去用武之地。但历史的走向是，手艺并未消失，工匠们转而开始管理和优化流水线了。

工程师们大概率也会走上类似的道路。只是这一次，变化来得快得多，而且很多团队尚未意识到，他们赖以运转的“流水线”，可能早已在悄无声息中停止了有效工作。

Fiona那句话依然精准：那些流程并没有正式宣告死亡，它们只是悄悄地停止了运转。

不妨也问问自己：你们团队里，现在有多少个这样的流程？