AI 时代团队管理重心转移——从编码到验证和流程

Fiona Fung 在 Anthropic 大会上讲了 28 分钟，聊了聊 AI 时代到底该怎么管一个工程团队。

她做这套幻灯片时，Anthropic 还没有推出 Routines 功能。

三周后，Routines 上线了。这是一个让 Claude Code 在云端按计划自动跑任务的功能，不需要在本地一直开着终端。等到她真正站上 Code with Claude 2026 大会的讲台时，幻灯片里好几张就已经过时了。

Fiona Fung 是 Anthropic 旗下 Claude Code 和 Cowork 两条产品线的工程与产品负责人。她之前在微软干了十二年（从 Visual Studio 做起），后来去 Meta 带过 Facebook Marketplace 和 Instagram 的工程团队，在 2025 年 9 月加入了 Anthropic。这次演讲不到三十分钟，主题听起来很普通：“AI 时代怎么管一个工程团队”，但她讲的全是这一年来在 Claude Code 团队踩过的坑、砸碎的旧规则，以及还没想明白的现实挑战，一点也不讲抽象的空话。

软件工程的瓶颈过去是“写代码慢”，现在则转移到了验证、评审、跨职能协作和安全性上。过去的各种流程都是基于“写代码很贵”这个假设设计的，现在既然“写代码几乎免费”，流程就必须全部重构。

软件工程的瓶颈过去是“写代码慢”，现在则转移到了验证、评审、跨职能协作和安全性上。过去的各种流程都是基于“写代码很贵”这个假设设计的，现在既然“写代码几乎免费”，流程就必须全部重构。

流程极少会自然消亡，组织只会一层层地往上叠加 SLA、规章制度和评审。用 AI 改造工程团队的第一步，其实就是明确允许大家砍掉陈旧流程。

流程极少会自然消亡，组织只会一层层地往上叠加 SLA、规章制度和评审。用 AI 改造工程团队的第一步，其实就是明确允许大家砍掉陈旧流程。

技术辩论的方式变了。过去是把人拉到白板房里画架构图，现在是让 Claude 同时搓出三个 PR，连着对 API 的实际影响范围一起对着代码讨论。

技术辩论的方式变了。过去是把人拉到白板房里画架构图，现在是让 Claude 同时搓出三个 PR，连着对 API 的实际影响范围一起对着代码讨论。

在 Claude Code 团队，所有的 PR 都有 Claude 的参与。“这段代码到底是谁写的？”这个问题已经渐渐失去意义。

在 Claude Code 团队，所有的 PR 都有 Claude 的参与。“这段代码到底是谁写的？”这个问题已经渐渐失去意义。

经理必须从一线 IC（个人贡献者）做起。Fiona 在招人时死死咬住这一条，负责招聘的同事一开始甚至不能理解：“现在哪有经理愿意倒回去先写代码的。”她的回应很干脆：“不愿意就趁早好聚好散。”

经理必须从一线 IC（个人贡献者）做起。Fiona 在招人时死死咬住这一条，负责招聘的同事一开始甚至不能理解：“现在哪有经理愿意倒回去先写代码的。”她的回应很干脆：“不愿意就趁早好聚好散。”

组织尽量扁平，所有小组共享一个团队目标（mission）。理由很简单：目标一变，层级越多越容易产生对齐损耗，扁平意味着灵活。

组织尽量扁平，所有小组共享一个团队目标（mission）。理由很简单：目标一变，层级越多越容易产生对齐损耗，扁平意味着灵活。

代码就是唯一的“事实来源”（source of truth），而不是设计文档。如果非要保留 spec，就把 spec 提交进代码库，让 Claude 去校验代码与文档是否一致。

代码就是唯一的“事实来源”（source of truth），而不是设计文档。如果非要保留 spec，就把 spec 提交进代码库，让 Claude 去校验代码与文档是否一致。

衡量效果看三个指标：新人上手时间、PR 的生命周期、Claude 辅助提交的比例。但她也警告，别死盯着“有多少代码是 AI 写的”，那只是虚荣指标，关键要看产品质量和可靠性。

衡量效果看三个指标：新人上手时间、PR 的生命周期、Claude 辅助提交的比例。但她也警告，别死盯着“有多少代码是 AI 写的”，那只是虚荣指标，关键要看产品质量和可靠性。

演讲一开始，Fiona 把时间线拉回了 2000 年代初。她当时在微软做 Visual Studio 2005——全球主流的开发工具之一。那会儿软件还是靠 CD 发行的（再早点是软盘）。因为软件要送到流水线上刻盘、装盒、铺货到店里，每个版本都有雷打不动的发布主线。

后来互联网来了，把发行方式从 CD 变成了在线分发，工程节奏随之被颠覆。现在轮到 AI，但这次变的不只是发行节奏，而是“写代码”这件事本身。

过去管用的老经验，现在未必行得通了。

“过去对你有效的东西，现在可能已经不再适用。”

她在演讲里反复回到这一句。多年来，工程节奏围绕一个假设搭建：写代码贵、写测试贵、重构贵。从瀑布到敏捷，每一种方法论都是在分配这块稀缺资源。

去年她还在抱怨 vibe coding（凭感觉编程，由 OpenAI 联合创始人 Andrej Karpathy 在 2025 年初提出）：“为什么到处用常量，工程实践不好。”一年之后，模型变得能干太多。这种突破已经远超单纯的“提速”范畴，而是整体的吞吐量直接跃升了一个数量级。

当编码不再是瓶颈，新的卡点出现在哪里

Claude Code 团队现在的瓶颈是验证、评审、跨职能协作和安全。

代码量提升后，她被其他工程负责人问得最多的问题是：“这些代码人怎么审得过来？”她也想知道维护成本怎么算。生成代码的成本几乎为零，但维护成本不会跟着归零。

注：演讲提到的“用 Claude Code 构建 Claude Code”是 Anthropic 公司层面的公开做法。Boris Cherny 此前在多次访谈中讲过，自己用 Claude Code 在 10 天内构建了 Cowork 这个面向非技术用户的桌面 Agent。这是工程现实，不是修辞。

她列出了一份“正在悄然失效”的旧流程清单：长达半年的产品路线图、繁琐的排期会议、对代码的所有权划分、马拉松式的代码评审会议、按部就班的传统团队结构、知识库分享，以及漫长的新人入职培训（onboarding）。这些统统都是因为当初“开发成本太高”而被现实倒逼出来的历史产物。

流程极少会自然消亡。我们习惯的做法是不断地往上叠加新流程。

“流程极少会自行消亡，我们往往只会不断地叠加越来越多的流程。”

她举了个痛点例子：之前在某个团队，SLA（服务级承诺）多到需要拉个大表格强制排序，工程师才能弄清楚哪条需要优先响应。她早就觉得这种过度堆砌该清理了，但真正下决心动手，还是到了 Anthropic 之后。

少做什么：六个月路线图、设计文档、产品评审

刚加入 Claude Code 时，她还在问：“不需要做六个月路线图吗？”

写出来了，前三个月还能用，过完新年再看，已经变了大半。她现在用一个词：jit planning（即时规划），借编程概念里的 just-in-time 编译，意思是什么时候需要再做什么。因为原型成本已经趋近于零，“提前规划”的杠杆消失了。

设计文档也大量减少。Claude Code 团队的默认讨论媒介从“先写一份 doc”换成了“先发一个 PR”，有想法直接做出来。产品评审会同样开得少，因为产品形态变化太快。与其评审 mock，不如把内部版本推给 Anthropic 全员——她管这个叫 ant-fooding，因为公司名 Anthropic 含有“ant”——再推给外部用户，听他们怎么用。

她希望团队在验证上加倍投入，叫 shift left（左移）。传统软件流水线左边是源头，右边是交付；所谓左移，就是把质量保障从靠近交付端的人工测试，推向更靠近源头的自动化。

为什么这件事变重要？因为角色边界正在模糊。她的设计师同事现在也在提交代码。Fiona 顺带讲了一个真实的小焦虑：她有次修了个跟求职简历相关的 bug，第二天扫了一眼 Boris 的消息流，看到有人在群里 @ 他报新 bug。她形容自己当时的感触是“心跳都漏了半拍”，生怕是自己捅的娄子。

每个人都不希望因为自己的提交把服务搞挂。在这个高吞吐量的环境下，这是非常真实的心理负担。传统的人工 QA 根本接不住这么高的代码产出率，所以质量保障必须更早地依赖自动化机制。

技术辩论的方式变了：从白板到三个 PR

刚加入 Claude Code 团队时，她想做一次重构，借机熟悉代码库。她和 Boris 在技术方案上有分歧，差点习惯性地拍肩膀说：“走，去白板房画一下。”

下一秒她马上意识到，其实完全可以让 Claude 同时搓出三个版本的 PR，直接对比完整的代码实现，甚至能拉出对所有调用方的影响。白板上可画不出这么直观的全局视角，但代码可以。

当写代码变得轻而易举，无休止的争论就显得极其昂贵。

“当构建变得廉价，争论就变得昂贵。”

抛出这个判断时，她的语气尤为严肃。她随即提醒听众：正因为生成代码的成本趋近于零，团队文化和底线共识反而变得越发关键。

决不能沦为“谁最后一个 commit 谁赢”。比如有人熬夜到凌晨三点偷偷交代码，或者设个定时任务抢在上线前压哨操作，这绝对不行。恰恰是因为代码不值钱了，团队横向对齐反而更需要明确的底线。

代码评审：Claude 接什么，人保留什么

Cat Wu 在大会上午的 keynote 已经讲了 Claude 自动评审 PR 的能力。Fiona 这里的视角更具体：什么交给 Claude，什么继续留给人。

注：Cat Wu 是 Claude Code 的产品负责人，与 Boris Cherny 同台主理 Claude Code 产品方向。

交给 Claude 去做的：风格检查、lint 去重、回应代码评审意见、抓常规 bug，以及补全单元测试。她说 Claude 现在非常擅长“打理”PR，通常在人工接手之前，就把大部分脏活累活干完了。

依然需要人工介入的有三类：法律和合规层面的审核，因为涉及风险口径；安全敏感代码的边界确认，因为出漏洞的代价太高；针对产品体验的 sense（直觉）和品味，这也是当前大模型相当难跨越的一道门槛。

第三类她讲了个轻松的例子。她有个小爱好：按节日装饰 Claude 的终端形象。圣诞节那次，她想把 Claude 变成雪人，让 Claude 用 ASCII 字符画。她把结果发给设计师同事征求意见，对方一句话：“你把它画成了 Mr. Peanut。”

注：Mr. Peanut 是美国知名零食品牌 Planters 的吉祥物，戴礼帽和单片眼镜，长得跟雪人在轮廓上有点像。

她最终采用了简单方案：冰蓝色加雪花。这个故事她拿来说明产品 sense 的意义：抽象判断很难自动化。

代码边界日渐模糊，角色分工也在重新洗牌

在 Claude Code 团队，几乎所有的 PR 都有 Claude 参与。“这段代码到底是谁写的？”这个问题正在变得荒诞，甚至没有意义。

Fiona 建议不要纠结于这种表象，而是深挖你真正想搞懂的是什么：是谁的修改引爆了 bug？谁有足够的背景上下文去跟客户解释技术细节？谁对这块代码模块的来龙去脉更清楚？

如果你问的是后面细分的这几个问题，就会发现往往有更好的自动化路径来回答。比如她原来有个习惯：每天早上泡一杯咖啡，用 Claude Code 对接客户反馈频道，跑一遍信息汇总摘要；现在这个动作已经被编排进了 Routines 自动化任务里，连手动敲命令都省了。

注：Routines 是 Claude Code 的一项功能，可以设置定时或触发式的自动化任务。Fiona 在准备这个演讲的一个月期间，这个功能才刚上线，连她自己的幻灯片内容都因此需要更新。

这种角色的模糊化是双向发生的。一面是非技术出身的人员也开始卷起袖子写代码，Claude Code 团队里的 PM 就在实打实地提交 PR。另一面则是让工程师跳出自己的一亩三分地，去抢传统上属于其他岗位的活儿。

Fiona 拿自己举了个例子：她原本想优化一下 Claude Code 的用户问卷调查，又找不到内容设计师。过去她可能要拉着内容团队的人反复抠文案字眼，现在她直接用 Claude 作为文案搭档。她自嘲，作为一个典型的工程师，自己“在把文案写得精炼这件事情上可谓是一塌糊涂”。

在招聘上，Claude Code 团队重点看两类人。一类是有产品感觉的创意建造者：好奇心强，看到问题就想做产品来解决，会反复打磨体验。另一类是深度系统专家：团队搭建 Claude Code Remote 时，发现缺少有分布式系统经验的人。她不再看重的是原始编码吞吐量，模型已经把这部分拉平了。

组织形态：尽量扁平，经理从 IC 做起

Anthropic 招她进 Claude Code 时，对方默认按“10 个 IC 配 1 个经理，再向下嵌套”的结构来招人。Fiona 不要这种。

她想要的是尽量扁平。Claude Code 和 Cowork 两条线只共用一个团队 mission，不让每个小组各自定 mission。理由很实在：mission 一变，多层级要花很多时间向下对齐，扁平等于灵活。

她还坚持一条：Claude Code 团队里所有经理都要先做 IC（individual contributor，一线工程师）。

招聘官最初的反应是“你疯了”，意思是没有经理愿意先做 IC。

我希望 Claude Code 团队的每个经理都从 IC 起步，这是我对团队的期望，不接受就早点分开。

“这就是 Claude Code 团队践行 dogfooding 的方式，也是我对团队的期望。如果有人对此不感兴趣，那我们最好尽早分开。”

这一条对她自己也是。她上一次把代码 push 到生产环境还是 2017 年，加入 Anthropic 之后才重新写起代码。她说自己在 Meta 时每年还试着提交一次 PR，但内部工具变得太快，一年学一个命令，第二年就过期了。

现在我连 git 命令都不记得了，全靠 Claude 帮我搞定。

“现在我甚至连 git 命令都不记得了，这些事情我总是直接让 Claude 帮我处理。”

从文档退位，让代码成为“唯一事实来源”

Claude Code 团队现在把代码视作最终的 source of truth（唯一事实来源）。比如 Fiona 现在是怎么答复技术客诉的？她会直接启动桌面版 Claude Code，挂载本地 repo 后，让大模型直接从代码中寻找逻辑并给出回答。这种做法彻底干掉了软件行业的一个千年遗留问题：开发文档总是与代码不同步。

但她特意补充说明：这条经验并不是放之四海而皆准的。如果你们团队的业务要求必须有完备的需求文档，那就顺理成章地把 spec 也提交到代码库里，让 Claude 交叉校验最终运行的代码与文档描述是否吻合。

在推行这些变化时，Fiona 区分了“必须统一”和“交给小组”两层。

必须统一的几条核心准则：每个团队成员都要用 Claude Code，包括跨职能伙伴，Cowork 也是；尽可能把能够自动化的工作 Claude 化，团队内部称之为“claudify everything”；明确允许杀掉已经不再服务于人的旧流程。

最后一条，她给了个具体例子。Claude Code 团队曾经搞过站会，团队变大后改成在共享表格里填写周进度。某天，她看着这张大表觉得索然无味：因为信息明明都在 Claude 能读到的地方，其实让 Claude 写个总结脚本放在那里，任何人随时都能拉取其他人的状态摘要，这不比催人填表高到不知道哪里去了。

不过，给小组自行拿捏的空间也非常清晰：诸如 bug 的 triage（分诊）机制、排期节奏、谁值班以及怎么值班，乃至哪些工作流优先级较高、需要率先接入 Claude，统统放权让小组自己说了算。

新人爬坡时间显著下降。工程师、设计师和 PM 在新团队产生有效产出的速度明显更快。

PR 所需的周期明显变短了。她顺带一提，这其实是个值得深挖的指标，因为它的变化折射出的不仅仅是团队对 AI 工具的接受度，有时也会暴露下游基础设施拉胯的弊端，比如 CI（持续集成）管线或产品基础设施环境根本吃不消工程师当前暴增的提交速率。

Claude 介入提交的覆盖比例越来越高。在 Claude Code 团队的氛围里，每一次 commit 带上 Claude 才是被默认的常规操作：

我已经差不多四个月没看到一次非 Claude 辅助的提交了。

“我想，在过去四个月左右的时间里，我可能一次没有 Claude 辅助的提交都没见过。”

但她在指标这一段明确加了警告：不要只看“代码有多少由 AI 生成”。各家公司新闻稿里这个比例越说越高，但吞吐量本身不是目的。你必须回头看自己究竟在解决什么问题，以及产品质量和可靠性是否还守得住。

Fiona 在演讲最后承认，有三个问题她还没有答案：

第一，工程师能跨平台流转之后，传统的“iOS 团队加 Android 团队”分队方式还有没有意义。

第二，自动化评审要推到多远。“信任但验证”的边界在哪里，会随着模型升级再次移动。她提到当天稍早一场关于模型能力的演讲，意思是把多少评审工作托管给 Claude，并不是一个能够一次定下来的决定。

第三，角色模糊之后，怎样让所有人感觉自己同样有产出感。当工程师能做内容、PM 能写代码、设计师能修 bug，传统的产出归属变模糊了，公平感的设计是一个新课题。

挑出极其折腾人、尤为啰嗦的那条工作流，重新审视一下它到底还在为谁服务。

“挑出你们最吵闹的那条工作流……它真的还在发挥作用吗？它存在的目的究竟是什么？”

她拿自己的亲身经历当了反例。以前在带某个团队时，有个雷打不动的周例会，五十多号人挤在一个大屋子里。但 Fiona 仔细观察后发现，除了被点到名字、需要起来汇报状态的人会假装抬一下头，其他人全都不约而同地低头敲键盘。

后来她只问了一句：“我们到底图什么，还在开这破会？”瞬间全票通过，会议顺带原地解散了。