# AI时代如何重塑工程团队管理

- 来源：宝玉 (@dotey)
- 发布时间：2026-05-12 14:28
- AIHOT 分数：66
- AIHOT 链接：https://aihot.virxact.com/items/cmp2996wd055hslbphr583sbo
- 原文链接：https://x.com/dotey/status/2054086398328656383

## AI 摘要

Anthropic的Fiona Fung指出，AI使代码生成成本趋近于零，工程瓶颈已从“写代码慢”转向验证、评审与协作。基于“写代码贵”假设的旧流程（如冗长路线图、繁琐评审）必须重构。技术辩论应从白板讨论转为让AI生成多个PR进行对比；代码成为唯一事实来源。经理需从一线工程师做起，组织应扁平化。质量保障需“左移”，依赖自动化。代码评审中，AI处理风格检查等常规任务，人类则专注于合规、安全及产品体验等关键决策。

## 正文

http://x.com/i/article/2054083068839796737

# 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 团队踩过的坑、砸碎的旧规则，以及还没想明白的现实挑战，一点也不讲抽象的空话。

视频原链接：https://www.youtube.com/watch?v=igO8iyca2_g

## 要点速览

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

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

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

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

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

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

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

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

## 【1】二十年里，行业被重塑了两次

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

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

> 过去管用的老经验，现在未必行得通了。
（"What served you prior may not serve you any longer."）

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

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

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

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

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

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

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

> 流程极少会自然消亡。我们习惯的做法是不断地往上叠加新流程。
（"Rarely do processes kill themselves， we tend to just layer more and more and more processes on."）

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

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

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

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

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

## 【4】多做什么：验证，把质量保障往源头推

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

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

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

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

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

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

> 当写代码变得轻而易举，无休止的争论就显得极其昂贵。
（"When building is cheap， arguing is expensive."）

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

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

## 【6】代码评审：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 的意义：抽象判断很难自动化。

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

在 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 时发现缺少有分布式系统经验的人。她不再看重的是原始编码吞吐量，模型已经把这部分拉平了。

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

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

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

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

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

> 我希望 Claude Code 团队的每个经理都从 IC 起步，这是我对团队的期望，不接受就早点分开。
（"This is what dogfooding on the Claude Code team's about， this is what I expect and if someone's not interested it's better for us to do earlier separation."）

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

> 现在我连 git 命令都不记得了，全靠 Claude 帮我搞定。
（"Nowadays I don't even remember git commands， I just always ask Claude to help me out with all of that."）

## 【9】从文档退位，让代码成为"唯一事实来源"

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，统统放权让小组自己说了算。

## 【10】三个可观察的指标，和一个警告

她没透露具体数字，但点了三个方向：

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

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

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

> 我已经差不多四个月没看到一次非 Claude 辅助的提交了。
（"I don't think I've seen a non-Cloud assisted commit probably in the last four months or so."）

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

## 【11】她自己也没想清楚的三件事

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

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

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

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

她给听众的最后建议其实非常朴素直接：

> 挑出极其折腾人、尤为啰嗦的那条工作流，重新审视一下它到底还在为谁干活。
（"Pick your noisiest workflow … is it still really serving， what's the purpose of there."）

她拿自己的亲身经历当了反例。以前在带某个团队时有个雷打不动的周例会，五十多号人挤在一个大屋子里。但 Fiona 细看发现，除了被点到名字起来汇报状态的人会假装抬一下头，其他人全都不约而同在低头敲键盘。后来她只问了一句"我们到底图什么还在开这破会"，瞬间全票通过顺带原地解散了。

视频原链接：https://www.youtube.com/watch?v=igO8iyca2_g