过去一年，关于 AI 提升工程效率的叙事大多停留在”变得多快”。Anthropic 自己公布的数据是，工程师人均每季度代码产出已经涨到 2025 年同期的 8 倍。但更有意思的问题其实是：当一个人可以同时指挥十个、二十个 Agent 干活，人和 Agent 之间、人和人之间的协作方式，要重新设计成什么样？
Fiona Fung 管理着 Anthropic Claude Code 与 Cowork 背后的整个工程与产品团队，Boris Cherny（Claude Code 之父）与 Catherine Wu 都向她汇报。她在 Lenny’s Podcast 里坦白：协作方式变了，代价也随之出现，而且其中一部分目前还没有解决方案。这篇文章梳理的就是她透露的整套方法论：包括已经跑通的部分，也包括她自己承认还没解决的部分。
Anthropic 工程师人均代码产出涨到 8 倍，靠的不只是模型变强，还有一整套配套的协作方法论——把”什么算好”写进 spec，把自由和责任绑定，把管理者的日常判断模板化成可以自动运行的 Routine，把新晋管理者先按回 IC 的位置；但这套方法论并不完整——协作中的孤独感用结伴编程午餐缓解却没有真正解决，并行 Agent 带来的切换负荷 Fiona 自己说”还没搞定”。
Datawhale干货
访谈：Fiona Fung，编辑：Datawhale
Fiona Fung 管理着 Anthropic Claude Code 与 Cowork 背后的整个工程与产品团队，Boris Cherny（Claude Code 之父）与 Catherine Wu 都向她汇报。最近一两个月，她的团队里出现了一个新问题：随着 Routines 上线、工作方式转向异步，团队成员同时运行的 Agent 越来越多，有人一次跑二十个，checking in 和 review 的负荷肉眼可见地在上升。
在 Lenny’s Podcast 的一期访谈里，主持人问她有没有解决方案，她的回答很直接：我还没搞定。
访谈地址：https://www.youtube.com/watch?v=Ybrl4FYM57c
过去一年，关于 AI 提升工程效率的叙事，大多停留在”变得多快”这个层面。Anthropic 自己公布的数据是，工程师人均每季度代码产出已经涨到 2025 年同期的 8 倍。但更有意思的问题其实是：当一个人可以同时指挥十个、二十个 Agent 干活，人和 Agent 之间、人和人之间的协作方式，要重新设计成什么样？这也是团队自己还没完全想清楚的部分。
这篇文章梳理的，就是 Fiona Fung 在访谈里透露的这套协作方法论：包括已经跑通的部分，也包括她自己承认还没解决的部分。
过去，工程时间是稀缺资源，团队必须在硬性死线前把所有事情规划到位。如今编码不再是瓶颈，团队面对的最大变量变成了”能有多大野心”。随着更多背景各异的人，不止工程师，还有设计师、产品经理，都一起提交代码，吞吐量上升，一个新问题随之出现：怎么让每个人都对代码质量有足够的信心？
Fiona Fung 提到一个具体做法：把”什么算好”写成一份 spec，直接检入代码仓库，并保证 spec 随代码同步更新。代码审查因此变成了核对代码是否仍然符合当初设定的目标，而不是逐行人工过一遍。她的说法是，只要把这件事写清楚放进仓库里，Claude 做 code review 时就能对照 spec 校验。
这也让一个由来已久的工程方法论：测试驱动开发（TDD），重新变得容易坚持。她坦言自己过去一直不太擅长这套流程，感觉像是必须先吃掉那盘西兰花，而她真正享受的是直接把产品做出来的那份快感。
但她记得自己在 Claude Code 上修复的第一个 bug，做法正是先对 Claude 说：我想做测试驱动开发，帮我先把测试写出来，确保它先失败，然后再做真正的修复。她认为，这类原本正确、却因为”太麻烦”被工程师绕开的好方法论，如今因为有模型分担了大量执行工作，反而比以前更容易被坚持下来。
Fiona Fung 认为，PM 是目前受 AI 冲击第二大的角色。原因很直接：PM 不再受限于工程带宽，一旦有想法，很多时候可以自己动手实现，不用排队等工程师有空。
这个变化在数据科学团队体现得更明显。她提到一位朋友的经历：现在很多人会自己用 AI 做一版数据分析，再拿给数据科学家”过目把关”，而这些分析往往有一半时候是错的。数据科学家的工作因此变成了不断审核别人用 AI 生成的分析结果，而不是自己动手做分析。
这两件事说明，”验证取代编写”并不是工程师这一个群体的特殊情况，而是一条正在跨角色重复出现的规律。不管产出的是代码、产品方案还是数据分析，核心动作都在从”做出来”变成”判断做得对不对”。
Agency（自主行动力）是 Fiona Fung 反复强调的团队文化关键词。团队信奉的原则是：遇到问题，每个人都可以有自己的解法，给予充分自由去大胆尝试。但她紧跟着补一句：高 Agency 意味着高 Accountability，你解决问题的假设是什么，做完之后效果如何，都要说得清楚。
她提出过一个管理原则，叫”犯新的错误”。允许犯错是必要的，只要每次犯的是新错误，因为如果目标是零错误，往往意味着团队推进得不够快，或者过于谨慎。
在质量管理上，团队摸索出一套简单的分级框架：”Bad”指严重、不可恢复的错误，比如 CLI 崩溃、丢失工作进度；”Sad”则是可恢复但影响体验的问题，比如界面闪烁。这套分类的具体定义权被下放给各个小组，让他们根据自己负责的界面或服务自行判断”什么算 Bad、什么算 Sad”，因为不同产品面的仪表盘数字很难直接比较。
责任的另一面，是不要被”动作量”骗过去。团队内部有过一次关于代码行数的争论：曾有工程师提交了巨量代码行数，后来发现只是把一个现成的库搬运了过来；也有相反的情况：团队升级了底层框架后，同样的产出反而生成了更少的代码。她的结论是：不要把动作误当成进步。如果只是在衡量工具的使用量，衡量的是”行动”，但这真的在推动你想要的结果吗？
这条经验她在更早的 Facebook Marketplace 时期就吃过亏。当时团队按区域逐步上线产品，盯着的核心指标是卖家数量，而第一个上线的地区卖家数量偏低，用户却依然能顺利找到想要的商品。后来发现，这个地区虽然卖家总数不多，却聚集了不少”超级卖家”。如果当时机械地按卖家数量这一个指标决定是否扩张，很可能会得出错误结论。这次经历让她此后始终提醒自己：任何指标，哪怕曾经很合理，都要不断追问它是否仍然服务于最初想要达成的结果。
Fiona Fung 描述了自己作为管理者，工作方式的一次颠覆性转变。她现在会在团队维护的所有代码仓库里常驻一个 Claude Code 远程会话，这个实例同时能访问团队的 Slack 频道和各类指标仪表盘。每个月，她会和团队成员一起打开这个会话，共同回顾：这个月聚焦做了什么？上线了哪些产品？市场反馈如何？有没有引发什么问题？用她自己的话说：以前可能只会用这些会话生成 PR 和修复 bug，现在用它们来和自己支持的人展开对话。
过去一两个月，这套流程又被一次新功能：Routines，彻底改变了。过去每天早上喝咖啡时，她会人工浏览各个反馈渠道，判断当天有没有时间去修一些小问题；现在她设置了一个每天固定时间运行的 Routine，自动帮她扫描反馈渠道、提炼主题，甚至直接生成可供审核的 PR。她的说法是：以前可能还会自己生成一些 prompt，但现在有了 Routines，几乎是在让一个 Agent 帮她生成 prompt 和 PR。
她把这种变化理解为工作方式正在朝更”异步”的方向演进——过去需要同步地写一个 prompt、等它跑完，再决定下一步要不要再起几个任务；现在 Routines 能按她设定的节奏自动生成 prompt、派发给多个 Agent 去执行，等她第二天早上醒来，成果已经以 PR 的形式摆在她面前，供她审阅、决定是否合入。
协作方式变了，代价也随之出现，而且团队自己承认，其中一部分目前还没有解决方案。
第一个代价是孤独感。过去的工程协作是”N 个人一起搭一套系统”，有人做后端、有人做前端、有人做 iOS，彼此之间自然产生大量互动；而现在，一个人可能同时运行着十个并行工作的 Claude 实例独自推进项目，团队成员之间的互动反而变少了。Fiona Fung 坦承，过了一段时间之后，团队开始感觉这变成了一种孤独的体验，因为大家都在和自己的 Agent 工作太多了。
为此，团队最近开始组织”结伴编程午餐”，也保留黑客马拉松这样的集体创作时段。但她自己把这种状态形容为一种类似孩子”平行游戏”的状态：各自在做自己的项目，却因为并肩工作而彼此受益。但这更像是缓解，而不是真正意义上把协作方式改回从前。
第二个代价是切换负荷。随着 Routines 和异步工作方式的普及，团队成员需要同时跟进的并行 Agent 越来越多，有人一次跑二十个，需要不断检查进度、记住每一路任务做到哪一步。Fiona Fung 自己也遇到这个问题，她的原话很直接：这方面我们还没搞定。这也是这次访谈里少有的、没有给出解决方案的坦诚时刻。
Fiona Fung 在团队里推行了一项做法：每一位新晋管理者在正式承担管理职责之前，都要先以个人贡献者（IC）身份工作一段时间，此后也要持续保持部分 IC 工作。
这项制度来自她加入团队后做的一轮内部倾听巡回。她在与团队成员的交流中，听到不少关于”审批层级太多”“希望有更清晰的优先级”的真实反馈，才决定从制度层面做出调整。她的判断是：如果一个管理者一上来就急着打开管理工具箱、做管理该做的事，反而容易造成过多的审批层级；而如果先花时间深入代码库和产品本身，往往能和团队建立起真正的信任关系。
她自己也延续了这个习惯。加入 Claude Code 团队的第一周，她原本准备走老路，请每位工程师喝咖啡聊需求，后来却改成向 Claude 提问了解代码库。她认为，哪怕模型再强，工程师依然要花时间”双击”自己所依赖的那一层。因为只有理解依赖关系，才能真正意识到底层发生了什么变化，也才能更好地利用这些变化。
回到开头那个问题。Anthropic 工程师人均代码产出涨到 8 倍，靠的不只是模型变强，还有一整套配套的协作方法论：把”什么算好”写进 spec，把自由和责任绑定在一起，把管理者的日常判断模板化成可以自动运行的 Routine，把新晋管理者先按回 IC 的位置。
但这套方法论并不完整。协作中的孤独感，团队用结伴编程午餐和黑客马拉松去缓解，却没有真正解决；并行 Agent 带来的切换负荷，Fiona Fung 自己的说法是”还没搞定”。
这大概才是这轮变化更真实的样子：不是一套已经跑通、可以直接复制的完美方案，而是一个团队在真实压力下，一边搭方法论，一边承认哪些地方暂时没有答案。
一起”点赞”三连↓