Lenny's Podcast 精华 | EP.015 — Fiona Fung:代码不是瓶颈之后1×0:0010:480:08开场:代码不再是瓶颈1:02Highlight 1:代码便宜以后,验证变成新的瓶颈2:47Highlight 2:高 agency 要配高 accountability4:17Highlight 3:管理者也要进入产品和代码现场5:46Highlight 4:「bad vs sad」:质量不要只看数字7:19Highlight 5:角色边界正在消失,但深度不能一起消失8:59收尾:真正难的是文化0:08主播这一期,我们看 Lenny's Podcast 对 Fiona Fung 的访谈。Fiona 现在带 Anthropic 里 Claude Code 和 Cowork 背后的团队,过去在微软做过 Visual Studio 和 TypeScript,也在 Meta 做过 Marketplace、智能眼镜和 Instagram 的基础设施、增长、安全团队。她这集最有冲击力的一句话是,Anthropic 工程师每个季度平均提交的代码量,比二零二五年高了八倍。0:38主播但这期真正值得听的地方,不是八倍代码本身。Fiona 反复在讲一个更难的问题:当写代码不再是最稀缺的能力,工程团队到底要怎么管理速度、质量、判断力和文化?她的答案很具体,也很适合产品经理、创业者和 AI 团队参考。1:02主播先说第一个重点。Fiona 认为,AI 原生工程团队已经不是传统意义上的工程团队了。她说,过去工程时间非常贵,软件还要刻进光盘,所有计划都围绕稀缺的开发资源展开。现在 Claude Code 让工程、产品、设计都能参与提交代码,真正的问题从「能不能写出来」,变成「怎么知道它真的好」。1:33主播她给出的做法不是简单加更多人工 code review。相反,她强调把「什么叫好」写进代码仓库。比如产品规格、内容设计规范、测试框架,都应该成为模型可以检查的材料。这样 Claude 不只是帮你写代码,也能按既定标准做验证。1:57主播这很像测试驱动开发的升级版。Fiona 说,她过去也觉得先写测试像「先吃西兰花」,知道有用,但不够有快感。现在她会让 Claude 先写会失败的测试,再修 bug,最后让测试通过。AI 把那部分枯燥税降下来了,老方法反而变得更容易执行。2:24主播这对团队管理有一个很直接的启发:AI 时代的质量体系,不能只靠资深工程师盯着每个 pull request。你要把判断标准外化,让模型、测试、监控和人一起工作。越是代码产量上升,越要提前定义验收标准。2:47主播第二个重点,是 Fiona 对人才的判断。她说,现在特别需要两类人:一类是有产品感的 creative builder,能从一个想法一路做出能用的体验;另一类是 deep systems expert,在关键复杂系统里做最后的验证和把关。3:09主播Lenny 在访谈里用了一个词,ambition。以前听到一个功能,工程师可能先想这很难、依赖很多、排期很长。现在有人会想,先让 Claude 试试,移动端也可以试试,复杂系统也可以先打个样。能力上限被抬高以后,团队的问题变成:你敢不敢想得更大。3:35主播不过 Fiona 没有把这件事说成无边界的自由。她很喜欢 agency,但她马上补了一句,高 agency 也要有高 accountability。团队可以有自由去做,但每个人都要说清楚自己的假设是什么,想解决什么问题,做完以后怎么证明有效。3:57主播这句话很关键。很多公司学 AI 原生团队,只学到「大家都去试」。结果试了很多 demo,留下很多半成品。Fiona 讲的是另一套系统:先给人足够空间做事,再用假设、结果和反馈把它拉回现实。4:17主播第三个重点,是管理方式本身变了。Fiona 现在会开一个 Claude Code remote session,让它能看团队的代码仓库、Slack 反馈频道和指标。每个月,她会和团队一起回看:哪些东西发出去了,市场反馈怎么样,有没有造成 bug,下一步质量投资应该放在哪里。4:39主播她还把自己的早晨例行动作自动化。过去,她会一边喝咖啡,一边翻用户反馈频道,找主题、挑 bug、看哪里需要修。现在她用 routines,让 Claude 每天自动看反馈、总结模式,甚至提前开出一些可 review 的修复 pull request。5:02主播这不是说管理者可以躲到仪表盘后面。恰恰相反,Fiona 很强调 dogfooding。她说,作为领导者,如果你不每天使用自己的产品,就会只剩下指标和汇报。指标能告诉你趋势,但很多真正的问题,只有你自己用一次才会撞见。5:25主播她举过 Marketplace 的例子。离开团队以后,她有一次想卖一台 MacBook Air,刚发布就遇到买家骗局,于是发现了一个新的欺诈路径。她想表达的是,产品领导不能只看平均值。一个真实用户瞬间,可能比十张 dashboard 更快暴露问题。5:46主播第四个 highlight,是她提出的「bad versus sad」质量框架。Bad 是很严重、不可恢复的错误,比如命令行崩溃,让用户丢工作。Sad 是可恢复但很烦的体验,比如闪烁、卡顿、绕路。一个 sad 可能还能忍,很多 sad 叠在一起,就会变成 bad。6:12主播这个框架的好处,是让不同团队都能按自己的产品面定义质量。一个命令行工具的 bad,可能是 crash rate;一个界面产品的 sad,可能是加载慢或反馈不清楚。Fiona 不想让团队只盯着一堆原始数字,而是先把用户体验分层,再让每个团队承担自己的质量目标。6:38主播她还提到一个很有 Anthropic 风格的信号:团队会看用户反馈里骂脏话的频率。听起来很轻松,但背后其实是严肃的产品判断。用户什么时候会生气,什么时候只是卡了一下,这些情绪信号也应该进入质量系统。6:57主播对中国团队来说,这个框架也很好用。不要只问「可用率是多少」或「接口耗时多少」。还要问:用户在哪一步会彻底放弃?哪一步只是忍着继续用?前者要立刻救火,后者要持续清债。7:19主播第五个重点,是角色边界。Fiona 说,变化最快的不只是工程师,还有所有 coding-adjacent roles。产品经理不再完全等待工程排期,设计、数据科学也开始被 AI 改写。工程师则要更有产品感,因为他们现在能更快把想法变成真实体验。7:44主播但她也担心另一件事:如果新人从来不真正理解底层系统,只是让模型写代码,下一代工程师怎么形成判断?她没有给出确定答案,只说也许会更像 fellowship 或 apprenticeship,让新人更快进入真实系统,同时仍然学会 double click 到自己依赖的那一层。8:09主播这也是本期最重要的张力。AI 把抽象层继续往上推,就像我们从汇编走到高级语言,再走到 IDE。问题不是每个人都要手写底层代码,而是团队里必须有人理解底层,知道什么时候模型的答案看起来对、其实不对。8:33主播还有一个更人味的细节。Fiona 说,大家都在和自己的 agent 一起工作以后,工程师会有一点孤独。Claude Code 团队开始做 pairwise programming lunch,让大家一起看彼此怎么用工具。不是为了回到旧世界,而是为了别把学习和团队感都外包给 agent。8:59主播最后,Fiona 被问到什么让她睡不着。她没有说模型能力,也没有说竞争,而是说团队文化。她担心团队高速增长时,能不能继续保持开放讨论、彼此帮助和 one team mentality。她说文化不是贴在墙上的海报,而是每天大家怎么对待彼此。9:24主播她还给了一个很实用的建议:杀掉不再服务你的流程。她自己刚加入 Claude Code 团队时,也想做六个月 roadmap。三个月后,她发现变化太快,文档已经不再被参考,于是改成更轻量的 just-in-time planning:按月看优先级,每周快速检查一次。9:47主播所以,这期的核心不是「AI 让工程师八倍高产」这么简单。更准确地说,AI 让代码从稀缺资源变成廉价资源,于是团队真正稀缺的东西浮出来了:判断标准、验证系统、产品触感、学习速度,以及能不能在高速度里保持诚实的文化。10:13主播如果你现在在带产品或工程团队,可以从一个小动作开始:找一个大家最讨厌、最吵、最手工的流程,先问它还服务目标吗?如果还服务,就让 AI 帮你自动化;如果已经不服务,就把它关掉。今天的 Lenny's Podcast 精华就到这里,我们下一期继续。
Add more perspectives or context around this Post.