Claude Code之父的老板解析Agent协作方法成败

Fiona Fung 是 Anthropic 内部负责 Claude Code 和 Cowork 产品的工程与产品团队的负责人，包括被誉为“Claude Code 之父”的 Boris Cherny 以及 Catherine Wu 在内的核心成员，都向她汇报。过去一两个月，她的团队遇到一个前所未有的新问题：随着 Routines 功能上线，团队工作方式加速转向异步，每个人同时运行的 Agent 数量激增。有人一次就跑二十个，光是检查进度和做 review 的负担，就肉眼可见地涨上去了。

最近在 Lenny's Podcast 的一期访谈里，主持人直接问她有什么解决方案，她的回答出乎意料地坦诚：说实话，我还没搞定。

过去一年，关于 AI 如何提升工程效率的讨论，基本都停留在“变得多快”这个单一维度上。Anthropic 自己公布的数据是，工程师人均每季度的代码产出，已经飙升到 2025 年同期的 8 倍。但真正值得深挖的问题其实是：当一个人可以同时指挥十个、二十个 Agent 并行工作，人与 Agent 之间、人与人之间的协作逻辑，需要被彻底重新设计成什么样？而这恰恰是 Fiona 和她的团队自己都还没完全想明白的部分。

这篇文章整理的就是她在访谈中透露的那套协作方法论——既有已经跑通的经验，也有她亲口承认尚未解决的难题。

一、验证，正在取代编写，成为核心动作

过去，工程师的时间是最稀缺的资源，团队必须赶在硬性截止日期前把所有事情规划到位。如今编码不再是瓶颈，团队面对的最大变量变成了“到底能有多大野心”。随着越来越多背景不同的人——不只是工程师，还有设计师、产品经理——开始一起提交代码，吞吐量上去了，一个新问题也浮出水面：怎么确保每个人对代码质量都有足够的信心？

Fiona Fung 提到了一个很具体的做法：把“什么算好”的标准写成一个 spec，直接检入代码仓库，并且保证 spec 随代码同步更新。这样一来，代码审查的本质就变了——不再是逐行人工过一遍，而是核对代码是否仍然符合当初设定的目标。她的原话是，只要把这件事写清楚放到仓库里，Claude 在做 code review 时就能对照 spec 自动校验。

这个做法也让一个由来已久的工程方法论——测试驱动开发（TDD）——重新变得容易坚持。她坦言自己过去一直不太擅长这套流程，感觉就像必须先吃掉那盘西兰花，而她真正享受的是直接把产品做出来的快感。

但她回忆了自己在 Claude Code 上修复的第一个 bug，当时她做的第一件事就是对 Claude 说：我想做测试驱动开发，先帮我写出测试，确保它跑失败，然后再做真正的修复。她认为，很多原本正确、但因为“太麻烦”而被工程师绕开的好方法论，如今因为有模型分担了大量执行工作，反而比以前更容易被坚持下来。

二、这条规律，不止发生在工程师身上

Fiona Fung 判断，产品经理是当前受 AI 冲击第二大的角色。原因很直接：他们不再受限于工程带宽，一旦有想法，很多时候可以自己动手实现，不用排队等工程师有空。

这个变化在数据科学团队身上体现得更明显。她分享了一位朋友的经历：现在很多人会自己用 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 的形式摆在她面前，供她审阅、决定是否合入。

五、没被解决的代价：切换负荷与新型孤独感

协作方式变了，代价也随之出现，而且 Fiona 和她的团队承认，其中一部分目前还没有解决方案。

第一个代价是孤独感。过去的工程协作是“N 个人一起搭一套系统”，有人做后端、有人做前端、有人做 iOS，彼此之间自然产生大量互动。而现在，一个人可能同时运行着十个并行工作的 Claude 实例独自推进项目，团队成员之间的互动反而变少了。Fiona 坦承，过了一段时间之后，团队开始感觉这变成了一种孤独的体验，因为大家都在和自己的 Agent 工作太多了。

为此，团队最近开始组织“结伴编程午餐”，也保留黑客马拉松这样的集体创作时段。但她自己把这种状态形容为一种类似孩子“平行游戏”的状态：各自在做自己的项目，却因为并肩工作而彼此受益。但这更像是一种缓解措施，而不是真正意义上把协作方式改回从前。

第二个代价是切换负荷。随着 Routines 和异步工作方式的普及，团队成员需要同时跟进的并行 Agent 越来越多，有人一次跑二十个，需要不断检查进度、记住每一路任务做到哪一步。Fiona Fung 自己也遇到了这个问题，她的原话很直接：这方面我们还没搞定。这也是这次访谈中少有的、没有给出解决方案的坦诚时刻。

六、管理者怎么参与 AI 协作：先做 IC，再谈管理

Fiona 在团队里推行了一项很有意思的做法：每一位新晋管理者在正式承担管理职责之前，都要先以个人贡献者（IC）身份工作一段时间，此后也要持续保持部分 IC 工作。

这项制度源于她加入团队后做的一轮内部倾听巡回。在与团队成员的交流中，她听到了不少关于“审批层级太多”“希望有更清晰的优先级”的真实反馈，才决定从制度层面做出调整。她的判断是：如果一个管理者一上来就急着打开管理工具箱、做管理该做的事，反而容易造成过多的审批层级；而如果先花时间深入代码库和产品本身，往往能和团队建立起真正的信任关系。

她自己也延续了这个习惯。加入 Claude Code 团队的第一周，她原本准备走老路，请每位工程师喝咖啡聊需求，后来却改成向 Claude 提问了解代码库。她认为，哪怕模型再强，工程师依然要花时间“双击”自己所依赖的那一层。因为只有理解依赖关系，才能真正意识到底层发生了什么变化，也才能更好地利用这些变化。

写在最后

回到开头那个问题。Anthropic 工程师人均代码产出涨到 8 倍，靠的不只是模型变强，还有一整套配套的协作方法论：把“什么算好”写进 spec，把自由和责任绑定在一起，把管理者的日常判断模板化成可以自动运行的 Routine，把新晋管理者先按回 IC 的位置。

但这套方法论并不完整。协作中的孤独感，团队用结伴编程午餐和黑客马拉松去缓解，却没有真正解决；并行 Agent 带来的切换负荷，Fiona 自己的说法是“还没搞定”。

这大概才是这轮变化更真实的样子：不是一套已经跑通、可以直接复制的完美方案，而是一个团队在真实压力下，一边搭建方法论，一边坦承哪些地方暂时没有答案。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：Claude Code之父的老板解析Agent协作方法成败要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题