分享一场Claude Code负责人的对话

近期有一期播客，嘉宾是Anthropic Claude Code和Cowork团队的负责人Fiona Fung。这期内容很值得聊，因为它跳过了“AI能不能写代码”这种基础讨论，直接切入到了更纵深的问题：当编码不再是瓶颈，接下来会发生什么？

Fiona有25年的工程经验，经历过好几轮技术变革。正因如此，她对这波AI浪潮的判断，跟刚入行的新人完全是两个维度。以下是我听完后，结合她的核心观点所做的重新组织。

代码不再是瓶颈，那瓶颈去哪了？

播客一开始，Fiona就抛出了一个观点：敲代码这件事，已经不再是限制团队产出的瓶颈了。

一个数据足以说明问题：Anthropic的工程师，平均每个季度交付的代码量，是2021到2025年间的8倍。图表走势是稳定、稳定、稳定，然后一根直线往上冲。但真正让Fiona觉得有意思的，不是代码量本身，而是提交代码的人变了。

在Claude Code团队，设计师在提交代码，产品经理也在提交代码，几乎所有人都在check in code。搁以前，“写代码”是工程师的专属动作，现在它变成了一种跨角色的基础能力，跟发邮件一样稀松平常。

Fiona的原话是：问题变成了，瓶颈转移到了哪里？不仅更多人在提交代码，而且来自不同学科，吞吐量变得非常高。那我们怎么做验证？怎么确认这些高速生成的东西是对的、质量是过关的？

这是一个很微妙的转向。过去工程团队的核心约束叫“工程带宽”，写代码是贵的，时间是稀缺的，所以大家围着这个约束做大量规划。现在这个约束消失了，代码可以很便宜、很快地被生成出来。但约束没有真的消失，它只是换了个位置，转移到了验证、审查、质量保障这些过去相对次要的环节上。

拿她微软的经历一比就特别清楚：Visual Studio时代，软件刻在CD上，截止日是真正不可推迟的，工程时间极其金贵。后来在线发布，交付方式变了一次。到今天，编码本身被AI大幅加速，又变了一次。这三轮的模式其实一模一样：旧的瓶颈被打穿，新的瓶颈浮出水面。

Lenny在对话里讲了一个故事。他认识一个工程师，过去听到功能需求，第一反应是“太难了，太复杂了，做不了”。现在他的反应完全变了：这完全可以做，让Claude Code搞就行了。Fiona也讲了一个类似的。她团队有个工程师，本来不做移动端，一个功能需要扩展到移动端。搁以前这事就卡住了，因为他不是Android专家。现在有Claude做搭档，不熟的技术领域也能推进。

Fiona说，这确实抬高了每个人能做事情的上限。这句话很轻，指向的东西很大。过去限制一个工程师产出的是技术复杂度，现在限制产出的东西变了，变成了你的判断力和雄心。你选做什么，你怎么验证做对了。“写多快”不再是问题，写得对不对，才是。

这就是Fiona看到的全貌：代码量爆炸、角色边界模糊、能力上限被拉高，三件事同时发生。听起来全是好消息，但好消息的背面是一堆新问题：质量谁来兜底？团队产出速度涨了8倍，过去那套管理方式、质量框架、规划节奏还能不能用？Fiona在Anthropic的日常，就是在回答这些问题。

管理者的工作流被重写了

她做的第一个改变是在所有仓库里部署了一个Claude Code远程会话。这个实例能访问团队全部的repo、Slack频道、指标仪表板；说白了，她有了一个上帝视角，随时能看到每个人在干嘛、做得怎么样。

搁以前，她的早晨是这样的：端一杯咖啡，打开各种反馈渠道，一条一条看用户说了什么、内部同事提了什么。现在这套流程全变了。大概一两个月前，Claude Code推出了Routines，她整个工作流被重写了。Fiona自己说的：“以前我得自己写prompt，现在有了Routines，就像有个Agent帮我生成prompt，甚至帮我生成PR。比如，我设一个Routine，让它每天早上盯着反馈频道，自动把主题提炼出来。等我醒来，一份反馈摘要已经生成好了，旁边还躺着几个PR等着我审。”

Lenny追问她：那你作为管理者，过去看到问题会派人去修，现在是Claude已经把修复方案做出来了，你只需要审一下要不要合并？Fiona说对，还不止；如果验证做得足够好，甚至可以给Agent更多自主权，让它直接执行。

这里有一个很有意思的角色跃迁。过去是你自己写指令，坐在那儿等结果；后来变成你一次发好几条指令出去，不用干等，回头一起收。现在更进一步了：你设定一个固定流程，这个流程自己帮你写指令，再分给不同的AI助手去干活；你的角色从“亲自上手干”，变成了“事后审一下”，再往前走一步，就成了“搭系统的人”。

Fiona自己也很坦诚：以前她得专门留出大块时间写代码，现在她得专门留出大块时间，去消化所有AI助手异步干完的活。说白了，以前脑子累在写代码上，现在是脑子累在来回切换、挨个验收上，这是一种全新的上下文切换负担。

质量谁兜底？四个硬核做法

效率拉满了，紧跟着一个问题就来了：东西是出得快了，质量谁兜底？Fiona在这块讲了几个做法，有的很硬，有的路子很野。

她说了一句话：想想看，去年我们连Claude Code自动审代码的功能都还没有，搁以前，人类审查者是个巨大的瓶颈。当然，需要很深专业知识的地方，还是得人来。很多可以定成标准的检查项，现在完全丢给Claude就行。她的建议很具体：你如果对“什么算好”有一套定义，不管是设计规范、代码风格、还是架构原则，直接写下来，放进代码仓库里，做成一个规则文件。Claude拿到明确的框架之后，按规矩做验证这件事上表现特别好。只有一个前提：这个规范文档得跟代码同步更新。写完扔一边不管，那就是一份过期的废纸，比没有还糟糕。

说白了，先写测试用例、再写代码。先把你要达到的标准定好，再动手干活。她在Claude Code上修的第一个bug，就让AI帮她走这套流程：先写测试，确保测试过不了，然后修代码让测试通过。她自己的原话：TDD在2000年代特别火，理论很好。我当时有点挣扎，感觉自己像被逼着先吃西兰花，我真正想干的是做产品、发出去。现在测试生成被自动化了，过去那些正确但让人提不起劲的做法，突然又活过来了。这个比喻很贴切：西兰花健康但不好吃，测试重要但写起来烦。现在AI帮你把西兰花嚼了，你只管吃现成的。

英文不重要，你记住意思就行。Bad，是那种不可恢复的严重错误；比如，你用着用着，命令行直接崩了，写的东西全丢了。这就是Bad。Sad，是有点痛苦但你还能恢复的问题，比如界面闪了一下，有点烦，没丢数据，继续干活没问题。每个产品不一样，每个团队得自己定义：在你这儿，什么算Bad，什么算Sad。这里有一个很关键的洞察：Sad攒多了，会变成Bad。Fiona说：过去我们有太多监控面板，很难退一步看大局；所以，与其盯着一堆原始性能数据，不如先有一个判断框架，帮你区分什么是真糟糕的体验、什么是不舒服但还能忍的。确保你在解决真正的Bad，同时盯着Sad的趋势，别让它恶化。

Fiona说好主意。听起来很荒诞对吧？这个指标后来真成了团队监测用户情绪的一种方式。脏话频率上去了，说明产品在某个地方让人抓狂。它代替不了正经的性能指标，它给了一个完全不一样的角度：用户在用你产品的时候，到底是愉快的，还是在骂娘？

招什么样的人，怎么管？

质量框架有了，检测的手段也有了；谁来执行？什么样的人能在这种速度下活下来，还活得好？

Fiona现在招两类人。第一类，她叫dreamers。翻译过来就是，有产品触觉的创造型选手。这种人脑子里有个想法，自己就动手干了，干完盯着反馈，不好就改，一直打磨到体验过关为止；整个产品从想法到落地，她一个人从头扛到尾。第二类，深度系统专家。她刚加入Claude Code的时候发现，团队有很不错的全能型产品人，就是缺一种人：真正懂底层系统和分布式架构的工程师；模型再强，很多地方还是得有人理解底层到底在跑什么，才能做出靠谱的判断。

光有人还不够。她反复提一个配对概念：高主动性，配高责任感。团队里每个人都可以有自己的想法去解决问题，这叫高主动性；前提是你得回答两个问题：你要解决什么？你的假设是什么？你不能光有冲劲，不给交代。说白了，你可以撒开了干，结果你得认。

然后她有一个做法，我觉得挺狠的：所有新来的管理者，必须先回到一线写代码，扎进代码库里，至少一个季度，是为了让你保持对产品的手感。她的逻辑很简单：Cowork和Claude Code的变化速度是以周计的。你作为管理者不每天亲手用产品，很快就会丧失判断力；到那时，你看数据、听汇报，心里其实已经没底了。她自己是这么过来的。在Instagram管过500人，到了Anthropic回到一线；她上次发布生产代码是2017年，中间很多年没碰过。加入团队第一周，差点又走了管理者的老路：挨个请工程师喝咖啡、做一轮倾听。然后她停住了。“让我先问问Claude。它帮我熟悉代码库，帮我跑自动化测试，甚至帮我设计手动测试方案。这给了我信心，让我可以再次交付代码。”

后来很多很久没写过代码的朋友跟她说同一句话：多亏了Claude，我又开始交付代码了。她有一点一直没变：坚持自己吃自己的狗粮。做VR的时候，她没在那套代码库里提交过代码，怕搞乱操作系统，她花大量时间亲自用产品、找问题。她说每次这样做，团队成员都很感激。因为除了冷冰冰的数字，每个人都需要感觉到自己的活是被看见的。如果领导者自己在用团队做的东西，团队会觉得这个人还跟我们站在一起，而不是只盯着报表。

规划、流程与指标，都得重新审视

人到位了，那这些人每天干什么、先干什么后干什么，怎么排？以前做产品的管理思路、排期思路，现在还行吗？答案是：不行了。

Fiona刚加入Claude Code的时候，试着做了一份轻量版的六个月路线图；三个月之后她发现，没人再看了。她的结论很干脆：六个月路线图已经没用了，直接毙了。现在团队搞的叫即时规划，用大白话说就是：只排一个月的计划；非常轻量，连正式文档都没有，就在一个电子表格里大家对一下觉得重要的事。也不是完全不想远的，每半年会有一次主题对齐，整个团队一起定几个大方向；具体做什么功能、怎么做，全在一个月的窗口里现定。她还提到一个细节：就连这个月度电子表格，她都在琢磨怎么把它自动化；理由很实在：她不想让“更新表格”本身变成一种新的负担。表格本来是帮你干活的东西，别反过来成了你要伺候的爷。

另外，流程这件事，她的态度更干脆：没用就杀。她建议任何团队都可以试试这个动作：挑一个让你头疼的流程。噪音大的、成本高的、特别手动的，随便挑一个；然后问自己一句话：这破玩意儿还在服务于它原本要解决的那个问题吗？如果答案是“不了”，那就别留了；别心疼，别觉得“万一以后用得上”。

规划可以做得再轻，流程可以砍得再狠，有一个问题始终绕不过去：你怎么知道你干的这些事到底有没有用？这是贯穿前面所有做法的一条暗线。Lenny提到一个现象，行业氛围在变。之前大家更像是在疯狂烧算力，能用多少用多少，先看看能搞出什么来。现在越来越多人开始问：我们到底搞出了啥？花了多少？划不划算？Fiona的回应很直接：不要把折腾当进步；你如果盯的是工具使用量，你盯的只是折腾的量；它到底有没有推动你真正想要的那个结果？

她拿Facebook Marketplace举了个例子。当年Marketplace按地区一个一个上线，团队盯的指标是卖家数量；第一个地区上了之后，卖家数量确实不多。按原来的标准看，好像没达标。她注意到另一件事：用户找到想要的东西了。后来发现那个地区有几个超级卖家，一个人就覆盖了一大片品类。如果团队死盯着“卖家数量”这个门槛指标不放，就会完全错过这个洞察。他们后来更新了指标体系，把超级卖家这个维度补了进去。这个故事的要害不只在于“选对指标”，更深一层的东西是：指标只有在你真能据此做决策的时候才值钱；环境变得太快，连指标本身都得被反复质疑。你天天盯的那个数，还是你真正想要的那个结果吗？面对任何指标，不管是代码行数、提交次数还是算力消耗量，确保自己没戴上眼罩。今天有用的指标，明天可能就是你的盲区。

人在变化里，怎么办？

前面全在讲“怎么干”。还有一个面必须聊：人在这种剧烈变化里，怎么办？

Fiona跟团队一个工程师聊过这事。以前做工程师有一种特别爽的体验：碰上一个棘手的问题，放上音乐，一头扎进去，跟它死磕，最后灵光一闪，搞定了。那个大彻大悟的时刻，是很多人干这行的原因。现在这种感觉在变少。代码丢给AI写了，产品层面依然有成就感，她听到不少工程师说：最难的那部分，曾经是我最喜欢的东西。还有一个变化她很敏锐地捕捉到了：长时间只跟AI协作，人会开始觉得孤独。以前一个团队一起写代码，有人做后端、有人做前端、有人做iOS，大家在一个项目里协作，有交集、有摩擦、也有默契。现在呢？你可以同时开十个AI助手并行跑，所有事都在推进，就你一个人。

她团队最近搞了一个活动，叫“结对编程午餐”。你以为是两个人坐一起结对写代码？不是。是每个人带着自己的AI助手，坐在一起各干各的。像什么？像小孩子的那种平行游戏；几个孩子坐一块儿，各玩各的玩具，谁也不理谁，偏偏就是有一种陪伴感。Lenny说了一句很精准的话：你看别人怎么跟AI对话，光这个动作本身就能学到新技巧。Fiona说没错。因为工具变化太快，团队里每个人的使用方式都不一样，每次看别人操作，她自己也偷偷学两招。

说到适应变化这件事，Fiona讲了她自己的故事。她小时候从香港搬到加拿大，不会说英语，父母忙着打工，奶奶搬来照顾她。奶奶也不会英语，在异国他乡特别孤独。后来她们找到了一家毛线店，店主是个会说粤语的女人，那个夏天奶奶终于有了自己的圈子。这段记忆，是她后来为什么对小企业那么上心的源头。后来她用Cowork帮一个开两家餐厅的朋友整理文件。那位朋友有一个跟垃圾抽屉一样的文件夹，一堆菜单存在里面根本找不到。Cowork帮她整理完之后，朋友又干了一件让Fiona没想到的事：让AI帮她分析，她的菜品定价在本地市场是不是合理。对你我这种人来说，AI是效率工具；对利润薄如纸的小商户来说，这玩意儿可能是活下去还是被淘汰的分水岭。她给了一个很具体的建议：如果你身边有还没碰过AI的朋友，或者你楼下喜欢的小店老板，花点时间手把手带他们试一次；一开始肯定有点别扭，结果往往比你想的有意思。

关于变化面前的心态，她给了一个特别朴素的建议：当你焦虑、恐惧时，问自己一个问题：有没有一件事，是我能控制的？她自己的例子：当年怕付不起大学学费，去做了银&行出纳，拿最低时薪一个暑假一个暑假地攒。2000年互联网泡沫破裂，找不到实习，她又干了两年出纳。这就是当时她唯一能控制的事。Lenny引了一句话：你最怕进的那个洞xue里，就藏着你一直在找的宝藏；Fiona说她很喜欢这句。最让你害怕的事，往往就是最该做的事。恐惧是最好的指南针。

一些还没答案的问题

聊到最后，Fiona很坦诚地列了几个她还没答案的问题。还需不需要独立的iOS和Android团队？现在人可以灵活跨平台干活了，保留专家仍然重要，独立的组织架构可能不需要了。这个平衡点在哪，她还在摸。紧挨着的是另一个边界问题：自动化审查该推到什么程度？哪些地方可以完全丢给AI，哪些地方必须有人兜底？这个边界不是固定的，模型在变强，边界一直在挪。

更让她头疼的是角色本身在变。工程师开始有产品感，产品经理和设计师开始写代码，数据分析师一半时间在审AI生成的分析；所有边界都在化开。怎么保证在这种模糊里，每个人的效率还能跟上？还有一个更大的问题：下一代工程师怎么带？她跟Lenny聊到，她自己成为工程师的路径，跟今天的新人已经完全不一样了。从学校毕业之后怎么快速上手，同时还能理解底层在跑什么？也许有一天模型强到这些都不重要了，眼下这个阶段，理解你所依赖的那一层仍然值钱。也许未来软件工程的训练，会更像师傅带徒弟。她提到一位前上司，那个人的软件工程生涯是从打孔卡开始的。没错，就是在纸卡上打洞写程序那种。现在这位老爷子每天用AI写代码、搭东西。从打孔卡到AI写代码，一整段变革浓缩在一个人的职业生涯里。Lenny说了一句：这就是又一层新的抽象；从汇编到高级语言，一直在往上走。现在我们连代码都不用看了，新的抽象层是你的指令和AI的思考过程。

让Fiona真正睡不着的，是团队文化。产品上的挑战，有仪表板、有理论、有假设可以对。文化这东西，是人与人之间的化学反应，没有任何工具能替你搞定。在Anthropic这种前所未有的增长速度下，她最怕的场景是这样的：一个管理者跟她说一切都挺好的，她知道有问题。Fiona说：就像那个表情包，一个人端着咖啡杯坐在着火的房间里，说一切正常。那就是我的噩梦。她说，保持坦诚、保持多元视角、保持互助，这些事比任何工程难题都更难，也更重要。团队快冲到终点的时候，回头看一眼有没有人需要拉一把。最终是作为一个团队一起到的。

Lenny问她在Airbnb快速增长那几年学到了什么。他说最有效的方法，是创始人对文化极度重视，在每一次全员会、每一个重要场合反复念叨。他还提到Sheryl Sandberg来Meta做过一次炉边谈话，有人问她怎么在大规模扩张里守住文化。Sandberg的回答是：你应该高兴你有这个问题；因为它说明你在成长、在做对的事。如果什么都不变、什么问题都没有，那才是真麻烦了。Fiona说这个视角很受用。她跟团队的共识是：不只聊做得好的，也必须坦诚面对做得不好的；因为只有当你能讨论问题的时候，你才有可能真正解决它。

闪电问答与个人印记

播客最后十分钟是个闪电问答，Lenny连砸了五个问题，Fiona答得很轻快。她推荐的书：Margaret Atwood、村上春树，还有《小王子》。她说《小王子》建议每年重读一次。手机里一直存着三部电影：《天使爱美丽》《千与千寻》《风之谷》。她说《风之谷》的主角娜乌西卡，是她领导力观念的启蒙。八九岁的时候看的。一个八九岁看动画片的小姑娘，长大了管过五百人的团队，回头发现很多东西的种子那时候就埋下了。她的人生格言分两块：工作上：“保持简单”。生活里：“在一个你可以成为任何事物的世界里，请善良。”

最后这个我特别喜欢；她说自己跟奶奶学了一辈子编织。下针和上针，就像0和1，她说自己像一个编译器在生成可执行文件。她的梦想是开一家毛线店，用奶奶的名字命名。

参考链接：

[1].参考来源：Lenny's Podcast「What happens after coding is solved?」2026.06.21，时长 1:38:44；YouTube：https://www.youtube.com/watch?v=Ybrl4FYM57c