Title: Claude Code 之父的老板，坦白 Agent 协作方法：他们做对的，和还没解决的！ | BestBlogs.dev
URL Source: https://www.bestblogs.dev/article/9fe5102f?amp%3Butm_medium=feed&%3Butm_campaign=resources&%3Bentry=rss_article_item
Published Time: 2026-07-05 22:23:00
Markdown Content: 87
Based on an interview with Fiona Fung, head of the Anthropic Claude Code team, this article summarizes proven effective methods in AI Agent collaboration (verification replacing writing, Agency tied to Accountability, Routines automation) and the unresolved costs (loneliness, switching overhead). D Datawhale
Yesterday 3681 words (about 15 min) View Source →
Sign in to highlight text and take notes as you read. Sign in now
原创 Datawhale 2026-07-05 22:23 浙江
Datawhale干货
访谈：Fiona Fung，编辑：Data whaleFiona 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、Accountability，与"别把动作当成进步"
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 自己也遇到这个问题，她的原话很直接：这方面我们还没搞定。这也是这次访谈里少有的、没有给出解决方案的坦诚时刻。
六、管理者怎么参与 AI 协作：先做 IC，再谈管理
Fiona Fung 在团队里推行了一项做法：每一位新晋管理者在正式承担管理职责之前，都要先以个人贡献者（IC）身份工作一段时间，此后也要持续保持部分 IC 工作。
这项制度来自她加入团队后做的一轮内部倾听巡回。她在与团队成员的交流中，听到不少关于"审批层级太多""希望有更清晰的优先级"的真实反馈，才决定从制度层面做出调整。她的判断是：如果一个管理者一上来就急着打开管理工具箱、做管理该做的事，反而容易造成过多的审批层级；而如果先花时间深入代码库和产品本身，往往能和团队建立起真正的信任关系。
她自己也延续了这个习惯。加入 Claude Code 团队的第一周，她原本准备走老路，请每位工程师喝咖啡聊需求，后来却改成向 Claude 提问了解代码库。她认为，哪怕模型再强，工程师依然要花时间"双击"自己所依赖的那一层。因为只有理解依赖关系，才能真正意识到底层发生了什么变化，也才能更好地利用这些变化。
写在最后
回到开头那个问题。Anthropic 工程师人均代码产出涨到 8 倍，靠的不只是模型变强，还有一整套配套的协作方法论：把"什么算好"写进 spec，把自由和责任绑定在一起，把管理者的日常判断模板化成可以自动运行的 Routine，把新晋管理者先按回 IC 的位置。
但这套方法论并不完整。协作中的孤独感，团队用结伴编程午餐和黑客马拉松去缓解，却没有真正解决；并行 Agent 带来的切换负荷，Fiona Fung 自己的说法是"还没搞定"。
这大概才是这轮变化更真实的样子：不是一套已经跑通、可以直接复制的完美方案，而是一个团队在真实压力下，一边搭方法论，一边承认哪些地方暂时没有答案。
!Image 7: 图片 一起“点**赞”三连↓**