#模型时代# Claude Code和Cowork负责人：AI原生产品团队是如何运作的？

Lenny's Podcast新鲜出炉的一期播客，嘉宾是Fiona Fung，负责Anthropic的Claude Code和Cowork团队的工程与产品工作。向她汇报的包括Claude Code创始人Boris Cherny和Kat Wu。加入Anthropic之前，她在Microsoft做了11年，从Visual Studio编辑器团队一路做到TypeScript；2015年加入Facebook后创建了Marketplace团队，从概念做到上线；之后在Meta经历了VR/AR、Instagram基础设施、增长、安全等多个团队，管理规模超过500人。2025年9月加入Anthropic时，她先做IC，以个人贡献者身份写代码、熟悉代码库，然后才开始带团队。

一、AI原生团队的运行逻辑

1、编码不再是瓶颈，验证才是

Anthropic内部的变化分两个拐点：2025年Claude Code从只建议代码变成能执行代码，曲线开始上扬；2026年模型能在更长时间窗口内自主工作，曲线再次陡升。工程师的日常从"自己写代码"转变为"指挥和审查Claude写的代码"。

当吞吐量翻了8倍，原来的人工代码审查立刻变成新瓶颈。Fiona的做法是把"好的标准"文档化后存入代码仓库，让Claude Code Review对照这些标准自动检查。她举了内容设计规范的例子：团队更新了设计规范后，把规范和代码放在一起维护，Claude就能自动校验代码是否还符合规范。

这本质上是测试驱动开发的进化版。TDD的理念在2000年代就流行过，先写测试、再写代码。Fiona自己当年的体验是"像先吃西兰花一样痛苦"。现在的区别是测试生成本身也被自动化了，这让一个好理念终于不再需要靠意志力来执行。

2、bad、sad和脏话：三层质量信号

面对不同产品线、不同服务各有各的指标仪表盘，Fiona引入了一个两层分类：bad是严重的、不可恢复的错误，比如CLI崩溃导致用户丢失工作；sad是可恢复的体验问题，比如界面闪烁。每个子团队自主定义什么是自己领域里的bad和sad，设定各自的改进目标。

这个框架解决的问题是：当你有大量产品表面积时，raw数字很难让人一眼判断"这到底算好还是不好"。bad/sad提供了一个人人能理解的语义层。Fiona特别提醒，sad堆积起来可以升级为bad，所以两层都需要持续关注。

除了bad和sad，团队还有一个更直接的信号来源：用户在对话中骂人的频率。2024年9月有工程师提议"我们是不是该跟踪一下脏话"，Fiona觉得这个主意好，于是真的做了一个swear word dashboard。这个仪表盘不能告诉你具体哪里出了问题，但当脏话率飙升时，你知道用户体验在变差。它是一个情绪层面的前置信号，和bad/sad的技术分级互为补充。

3、各角色都在提交代码

Claude Code团队里不只是工程师在提交代码，设计师和产品经理也在check in代码。角色边界在模糊化：工程师在长产品肌肉，产品经理不再被工程带宽卡住，以前要等工程师的功能现在可以自己先做出来。

Fiona认为下一波需要Claude化的领域是设计和数据科学，这两个方向目前的工具支持还不够成熟。她还注意到一个正在发生的现象：数据科学家的工作正在变成"帮各部门review他们用AI做的分析"，大部分时间花在验证别人的产出上。

二、用Claude管Claude团队：管理工具箱重建

Anthropic自己的工程管理实践可能是对"AI改变工作方式"最极端的压力测试。Fiona分享了几个已经跑通的具体做法。

1、开一个常驻Claude Code会话，接入所有仓库和Slack

Fiona有一个长期运行的Claude Code远程会话，挂载了团队所有代码仓库，接入了全部Slack频道，还能查看各项跟踪指标。每月她会打开这个会话，和团队成员一起回顾：这个月的重点方向是什么？哪些产品发布了？市场表现怎么样？反馈渠道说了什么？

它的价值在于让对话有更扎实的事实基础，面对面沟通仍然要做，只是讨论中有了更多数据可以引用。当一个季度的代码量翻8倍，靠人脑记"上季度发了什么"已经不现实。Claude把散落在仓库、Slack、指标看板里的信息拉到一个会话窗口里，管理者才有可能跟上节奏。

2、routines把晨间仪式变成了后台自动化

Fiona以前每天早上的流程是：泡咖啡，打开反馈频道，逐条浏览用户反馈，找到自己有空动手时能顺手修的问题。现在这个流程被Claude Code的routines功能接管了。Routines允许用户设定一个定时任务，在指定时间自动执行一组操作，而且它能在执行过程中自主派出多个agent并行处理子任务。她设定了一个每天早晨跑的routine：扫描反馈频道，提炼主题，甚至生成修复PR供她审核。

关键变化在于抽象层又往上提了一层。以前是人写prompt让Claude干活，现在是写一个routine，让routine帮你生成prompt并分发给不同的agent去执行。"It's almost like the level of abstraction keeps pulling up a little bit。"抽象层持续上移，每一次上移都释放出新的效率空间。Fiona认为异步、多agent并行将是工程团队接下来的主要工作方式。

3、反馈来源要全通道覆盖

团队的反馈通道不只是正式渠道。朋友在LinkedIn上随手提到的一句话、社交媒体上的吐槽、合作伙伴的邮件，团队成员都会搬到Slack里。Fiona坦言正因为反馈量太大，"我需要Claude帮我才能跟得上"。

背后是一个管理认知的转变：反馈不分官方和非官方，分的是有没有被看到。靠人力根本处理不过来的信息量，要么靠Claude帮你过滤和归纳，要么就放弃一部分关键信号。

三、两种人才画像与角色重塑

1、招人只看两个方向：有产品直觉的创意builder，和硬核系统专家

Fiona加入Claude Code团队时发现团队有很好的产品通才，但缺分布式系统方面的深度专家。她的补课方式是定向招具有系统和分布式系统背景的人。

两种画像各有分工。创意builder是"做梦的人"，他们热爱某个产品想法，自己构建、收集反馈、迭代打磨，端到端拥有产品体验。系统专家解决的是"信任但要验证"中验证那一半的问题。模型写的代码在大多数场景够用，但在需要深度领域知识的地方仍然需要人类专家把关。

2、工程师的天花板被掀掉了

Fiona讲了一个例子：一个非移动端出身的工程师需要给某功能加移动端支持，放在以前他可能会说"我不是Android专家"，但现在有Claude做搭档，他直接把活接了下来。

"It's lifted the ceiling of what anyone is able to do。"这句话指向的不是效率提升，而是能力边界的扩展。一个人能做的事情类型变多了，不仅仅是做同类事情更快。

3、高agency配高accountability

Fiona团队反复强调的原则是"高自主性配高问责"。团队里每个人都有很大的自由度去定义自己怎么解决问题，但同时需要明确回答：你试图验证什么假设？结果怎么样？

这看起来简单，实际上是对"agency"这个高频词的一个重要约束。只有agency没有accountability，容易变成各干各的散沙；只有accountability没有agency，退回到指令式管理。两条腿缺一不可。

4、新一代工程师怎么培养，是她没有答案的问题

Fiona没有回避这个问题：她和主持人走过的工程师成长路径，未来的人根本没法复制了。如果不需要手写代码，新人怎么理解基础设施和内存分配这些底层概念？她的建议是永远往下多看一层你的依赖，因为依赖发生变化时你需要知道意味着什么。

她提到这可能需要类似学徒制的培养模式。传统三个月的实习做小项目已经不够了，但具体的替代方案她也还在想。不过历史本身或许能提供一些安慰：她的一位前任经理，职业生涯从打孔卡开始，现在正在用Claude Code做东西，还兴奋地给她发消息展示自己的成果。从打孔卡到Claude Code，这条职业弧线横跨了整个计算机史。每一代工程师觉得重要的知识都在变，但适应力本身好像可以传递。

四、衡量产出：别把动作当进展

1、生产力指标的连环陷阱

Fiona回顾了生产力指标的演变史：先是lines of code，然后有人只是搬了个库进来就刷到最高，于是改成significant lines of code；后来框架升级导致代码量变少但产出不变，又有人提议用PR合入时间。每换一个指标，都解决了上一个指标的漏洞，又制造了新的盲区。

她把现在的token消耗量计算直接类比为当年的lines of code。"Don't forsake motion for progress"，别把动作误认为进展。如果你衡量的是工具使用量，你衡量的只是行为，不是结果。

2、Facebook Marketplace的power seller教训

做Marketplace时，团队最初用"卖家数量"做扩张前的门槛指标。某个新区域的卖家数量偏低，按旧标准不该扩张。但数据一细拆，发现虽然卖家少，买家却在找到想要的东西，因为这个区域有少量power seller贡献了大部分供给。

团队差点因为指标设计的盲区放弃了一个健康的市场。教训是：任何指标，哪怕当初定得合理，也要随着对市场的理解不断校准。环境变化太快，指标本身也需要迭代。

3、与其看仪表盘，不如去听

对于正在推动AI工具落地的团队leader，Fiona建议做一轮listening tour，重点找资深工程师聊：什么在起作用，什么不起作用，怎么能更好。这些对话能触发仪表盘看不到的洞察，也是把个人经验变成团队知识的最有效方式。

五、狗粮哲学：为什么管理者必须自己用产品

Dog fooding，直译是"吃自己的狗粮"，指开发团队自己日常使用自己构建的产品。这是Fiona从Visual Studio时代就养成的习惯，当年她用VS编辑器来构建VS编辑器本身，产品问题在团队内部就能被高频触发。

1、新manager先做IC，后带人

Fiona在Claude Code团队推行的规则是：新入职的manager不急着进入管理角色，先留出maker time，腾出专注编码的时间来深入代码库和产品。好处有两层：一是真正理解团队日常面对的技术和体验挑战；二是用行动建立信任，而不是靠头衔。她观察到，manager一入职就掏出"manager toolbox"做管理动作，反而不如先做队友更有效。

这条原则对她自己也适用。从Meta管500人团队到Anthropic做IC，她重新走了一遍写代码、提交PR、跑测试的完整流程。她坦言上一次提交生产代码大约是2017年，多年来一直怕"万一我搞坏了什么"。Claude Code帮她重建了这个信心：它既是onboarding buddy，帮她理解代码库、回答问题；又帮她自动生成测试、设计手动测试方案，让她重新有底气往生产环境里推代码。

2、在Marketplace卖二手电脑，上架几分钟就遇到新型诈骗

Fiona离开Marketplace团队之后，有一次想卖自己的旧MacBook Air。上架几分钟内，一个买家试图用她没见过的新手法诈骗。这个亲身经历让她意识到，fraud向量一直在演变，团队的安全策略需要持续更新。

类似的故事也发生在VR团队。她的使用环境因为某种原因特别容易触发地板高度bug，于是这个repro环境反过来帮团队定位了一个长期未解的问题。

3、智利之行发现的增长阻碍

Marketplace准备进入拉丁美洲时，在智利的数据表现远不如其他区域。所有可能的原因都排查过了。Fiona带了三个人飞到智利，买了一批当地的Android手机，落地一开机就发现了仪表盘上看不到的问题：LTE网速远低于美国，Marketplace的信息流在这个网络条件下根本加载不出来。

她用这个案例说明：当数据告诉你结果但不告诉你原因时，去现场、亲自用才能找到答案。

六、从六个月到JIT：规划方式的坍缩

1、六个月路线图三个月就废了

Fiona加入Claude Code团队后做的第一件事之一是推一个"超轻量级"六个月路线图。她认为做了最小化的规划负担。但三个月后回头看，团队几乎没有人再翻那个文档，因为实际情况变化太快，路线图已经过期了。

这给了她一个教训：规划的价值在于对齐的过程，不在于文档本身。如果文档产出之后没有人维护或引用，那个规划就已经失去意义了。

2、现在的做法：JIT月度规划 + 周检

JIT是just-in-time的缩写，借用的是制造业"即时生产"的概念。团队现在用一个轻量的电子表格对齐每月优先级，甚至没有正式文档。每周快速确认一次："这些还是本月优先级吗？"更长期的方向以主题形式存在，每半年全团队聚一次来刷新主题，但具体执行只规划一个月。

Fiona补充说，即使这个月度对齐的流程她也在想怎么进一步自动化。她的焦虑是流程变成"税"，迫使人们去更新表格却没有产生实际价值。

3、明确授权砍掉不再有用的流程

"Explicit permission to kill processes that no longer serve us"，明确授权砍掉不再有用的流程，这是Claude Code和Cowork团队文化中被写出来的条款。Fiona建议所有team lead做一件事：从日常流程中挑出一个你最怕做的、或噪音最大的、或最消耗人力的，先问一句"这件事还在达成它当初的目的吗？"

如果答案不确定，尝试砍掉它观察一段时间。如果答案是肯定的，问能不能用Claude自动化。这个思维模式本身比任何具体的流程改进都重要。

七、前方路况：还没解开的题

1、异步agent带来的上下文切换超载

当你可以同时踢出20个agent异步跑任务，你的上下文切换负担反而加重了。每个agent回来都需要你重新载入上下文、审核结果、决定下一步。Fiona说她以前会专门block时间给编码，现在反而要block时间来"追赶所有异步任务的进展"。

她坦承还没有解法。一个观察是：agent可以帮你快速重建上下文，所以切换的单次成本比纯人工时代低一些，但总量的增加可能抵消了这个优势。

2、工程师开始感到孤独

当每个人都和自己的agent搭档干活，团队协作的物理感消失了。以前后端、前端、iOS的人一起构建一个功能，现在一个人加10个Claude并行就把活干了。还有一层失落更个人化：以前遇到一个棘手问题，戴上耳机进入flow state，最后解出来的那一刻有巨大的成就感。这种aha moment正在减少。

Claude Code团队的应对是pair-wise programming lunch：两人一组，边吃午饭边并行编程。不是经典结对编程那种一人写一人看，更像小孩子的"平行游戏"，各干各的但在旁边。Fiona说每次看别人工作都能学到新东西，因为团队里每个人使用Claude Code和Cowork的方式都不一样。Hackathon也是保持团队连接的手段之一。

3、在模型能力边界处构建

Fiona提到一个实用的策略：有些自动化在当前模型版本上还做不好，但模型改进的速度是指数级的。她回忆早期用Sonnet 3.5的时候，模型还会犯不少错误，有些工程师据此判断"AI工具不行"然后就不再碰了。但她发现，上个月做不好的事情，这个月的模型可能已经能做了。

由此引出的建议是：如果某件事Claude几乎能做好但还差一点，值得提前把周边流程搭好。等下一个模型版本到来时，你已经站在起跑线上了，而那些等到"完全成熟"才开始的人还在画流程图。

4、iOS和Android是否还需要独立建制？

模型能力让工程师跨平台灵活切换变得可行，但深度平台专家仍然必要。Fiona的判断是不需要原来那么大的独立mobile org了，但需要保证有足够的平台专家把关。这个平衡点还在摸索中。

5、文化是最让她夜不能寐的事

技术问题和产品问题有仪表盘、有假设、有迭代路径。团队文化没有。Fiona在乎的是"one team mentality"：多元视角、开放辩论、接近终点线时回头拉一把掉队的人。团队快速扩张的时候，文化会漂移，如果漂移了没察觉，等问题浮出水面时修复成本极高。

她最怕的画面是：问manager"最近怎么样"，对方说"everything's fine"。那个"着火的房间里端着咖啡的猫"meme，就是她的噩梦。她对团队里所有manager的要求是：永远主动说出不顺利的部分，这样才能一起解决。Sheryl Sandberg曾在Airbnb的一次fireside chat上被问到同样的问题：规模扩张中怎么维持文化？她的回答是"这恰恰是你想要的问题，因为它说明你在增长。不增长、不招人的局面才是真正糟糕的。"Fiona觉得这个视角对所有正在高速扩张的团队都适用。