编码被解决之后会发生什么?——Fiona Fung(Claude Code 与 Cowork)

• Fiona Fung 在 Anthropic 带领 Claude Code 和 Cowork（把 AI 能力带进「知识工作」的产品）背后的全部团队，Boris Cherny 和 Kat Wu（两位都上过本播客、且那两期都进了史上收听量前十）都向她汇报。她当工程师已超过 25 年。→ 详细
• 来 Anthropic 之前她在微软带过打造 TypeScript 和 Visual Studio 的团队；之后去 Facebook，从零创立 Facebook Marketplace 团队，一手把它从点子带到上线——如今每年 GMV（成交总额）超过一千亿美元。→ 详细
• 还在 Meta 主导了第一款智能眼镜产品，帮忙打造 AR 眼镜 Orion；后来去 Instagram 带基础设施、增长、合规与安全等团队，在 Meta/Instagram 管理着一个 500 多人的组织。→ 详细
• Lenny 评价她「对未来的思考远远走在所有人前头」，这也是请她上节目的原因。本期话题由 Kat Lo、Boris Cherny、Mohammad Hegazi 提供建议。→ 详细

• 开场金句：「Coding is no longer the bottleneck. It's lifted the ceiling of what anyone is able to do.（写代码不再是瓶颈了，它把每个人能做到的事的天花板整个抬高了。）」她紧接着说「理论上现在什么都做得到了，问题变成了：你能有多大的野心？」→ 详细
• Anthropic 昨天发的一条推文：工程师平均每季度交付的代码量，是 2021–2025 年的 8 倍。Lenny 形容那条曲线是「平、平、平、平，然后『砰』地一下冲上月球」。→ 详细
• Boris 的那句名言被反复引用：「coding is salt（写代码已经像盐一样廉价了）」。Lenny 提醒：不久前还是 100% 代码由人写，现在正逼近 100% 由 AI 写。→ 详细
• 一位 10x 工程师的心态转变被当作典型：过去听到功能想法第一反应是「不行，这太难太复杂了」，现在是「这太可行了，我直接让 Claude Code 去做」——关键从「能不能做」变成了「你敢想多大」。→ 详细

• Fiona 从 IBM 起步（做 DB2、操作系统服务团队），当时用的是 Vim + 终端调试，没有 IDE——她那时坚信「越往底层走、越贴近操作系统，越硬核、学得越多」。→ 详细
• 2000 年互联网泡沫破裂，她这届毕业生很多公司冻结招聘，微软给她 offer 让她做 Visual Studio——她那时连 IDE 都不知道，还问「Visual Studio 是不是个更高级的画图程序」，经理一脸「这是在搞什么」。→ 详细
• 第一次用 IDE（VS）看到「能打断点、能多线程调试」让她觉得「脑洞大开」，这种「台阶式变化」是她反复强调的——我们这代人正经历的 AI 变革，是这条历史脉络上又一次（更剧烈的）台阶。→ 详细
• 她做 VS 时软件还是刻在 CD 上发行，所以截止日期硬到不行（要赶在交给生产部门刻盘上架前完工），那个年代「工程师时间极其宝贵 + 硬截止」逼出大量前期规划。后来能在线发布，又是一次转变。→ 详细

• 她在 Visual Studio 的编辑器团队，是「用 VS 编辑器去构建 VS 编辑器」——她对 dogfooding（吃自家狗粮，即自己天天用自己做的产品）的全部热爱就来自这里。→ 详细
• 那个年代社交媒体还没出现（Twitter 约 2006 年才有），大多数工程师很难快速拿到用户反馈；但 VS 团队人人是重度用户，彼此之间就能给出大量即时反馈，这是她当年最大的幸运。→ 详细

• 因为角色边界在被打破、融合，整个重心更多往「构建者（builder）」这边挪——「每个人都开始成了一个 builder」。在 Claude Code 团队，不光是工程师，设计师、PM——每个人都在提交代码。→ 详细
• 当更多人、且来自不同工种都在提交代码，再加上吞吐量高得吓人，瓶颈就从「写」转移到了「验证（verification）」：怎么确保那被放大了 8 倍的代码质量是真的高、是心里有数能跑起来的。→ 详细
• 这条「验证」主线贯穿全片：后面她会反复说「trust but verify（信任但要验证）」，并把「怎么搭一套验证机制确认体验确实是你想要的样子」列为团队当前最难啃的开放问题之一。→ 详细

• 她做的一个关键转变：跑一个 Claude Code 远程会话，把所有代码仓库都接进去，对每个人在做什么一览无遗；这个实例还接入了所有 Slack 频道、所有追踪的指标。→ 详细
• 每个月她会主动发起「咱们一起回头看看」，共享屏幕、和团队一起跑这个会话，聊「这阵子的重点方向是什么？哪些产品上线了？表现怎么样？反馈从哪些渠道来？」→ 详细
• 这是一次「用途升级」：以前她只拿这种会话去生成 PR、修 bug，现在用它来支撑和团队的对话——从「让它干活」升级成「靠它把全局聊清楚」。→ 详细
• 一个具体用法：「鉴于我们出过的几次事故，把这些整个梳一遍，能不能归纳出一个共性？从质量角度看，有没有反复出问题的热点区域、哪里可能有缺口？」她说这种洞察「倒回一年前，靠 Claude 是拿不到的」。→ 详细

• 她常挂嘴边的一句话：「Make new mistakes（去犯新的错误）」——犯错没关系，但要犯新的，这样团队才一直在学。→ 详细
• 配套的判断：「如果你的目标是零失误，那大概意味着你跑得还不够快，或者太过谨慎了。」这是她对「速度 vs 质量」张力的基本态度——不是不要质量，而是不接受「为了零错误而过度保守」。→ 详细

• 她原来的晨间习惯：泡杯咖啡 → 翻反馈渠道 → 如果有「动手时间（maker time）」就挑个能帮上忙的缺口去补。一两个月前上线的 routines（例行任务）彻底改变了这套。→ 详细
• routines 的关键升级：以前她顶多自己生成几个 prompt，现在几乎像是「有个 agent 在帮她生成那些 prompt 和 PR」。比如设一个 routine「盯着这个反馈渠道，看看有哪些共性主题」，等她一醒来就有一份好总结，甚至有些 PR 可以直接拿来 review。→ 详细
• 反馈渠道的来源是「大杂烩」：很大一部分来自内部，也有邮件、各种频道、合作伙伴；连朋友私信、LinkedIn/社交媒体上看到的，所有人都会贴回 Slack——正因为涌进来的反馈实在太多，她才「需要 Claude 来帮我跟上」。→ 详细
• 工作方式的本质转变（Lenny 复述、Fiona 确认）：以前是「行，谁去把这个修了」，现在变成「喏，这就是能修好这个问题的 PR，你看一下，想发我们就可以发了」。→ 详细

• 「去年我们都还没有 Claude Code Reviews」——当时人工 reviewer 是个特别大的瓶颈。对真正需要深度专业知识的重要领域，仍然要有人来 review。→ 详细
• 真正帮到他们的是：越能把「什么是好」的框架自动化地检查出来越好。「你给 Claude 一个框架去对照验证，它做得非常好。」 例子：他们最近给内容设计加了一套评分标准（scale）。→ 详细
• 可上手的做法：把 spec（规格说明）也提交进 repo，并让 spec 和代码经常保持同步更新；只要你对「什么是好」有明确表述、放进 repo，Claude Code Review 就能确保代码始终符合你设定的标准。→ 详细

• Lenny 把上面那套总结为「测试驱动开发（TDD）的进化版」。TDD（先写测试 → 确认测试失败 → 再写代码让它通过）在 2000 年代是件大事。→ 详细
• Fiona 坦白自己当年「有点挣扎，感觉就像得先把西兰花吃掉」——她从交付、做产品里得到巨大快感，先写测试这种事让她发憷。→ 详细
• 她在 Claude Code 上修的第一个 bug，就是让 Claude「帮我先写测试、确认它会失败、然后再修、最后让测试通过」。过去「生成测试是一笔不得不付的税」，如今被自动化了。→ 详细
• 一个更大的启示：那些早就存在的老原则（TDD 等），现在可能反而更高效了，因为有模型能替你做更多的活——值得重新审视。Lenny 调侃「这简直太不公平了，它直接就先把测试给你写好了」。→ 详细

• Fiona 演讲里 Lenny 最喜欢的一张幻灯片，讲的就是她招人的两个画像：「creative builders with product sense（有产品 sense 的创造型 builder）」和「deep systems experts for the hard parts（能搞定硬骨头的深度系统专家）」。→ 详细
• 深度系统专家：她刚加入 Claude Code 时，团队有一批很厉害的产品通才，但她发现「缺有系统/分布式系统背景的人」。逻辑是「trust but verify」——模型很强，但凡是需要深度专业知识去验证的部分，仍然绝对值得投入。→ 详细
• 创造型 builder（"梦想家"）：这种人会说「我对某个产品特别有热情」，有想法就把它做出来，然后盯着反馈、不断迭代打磨，端到端地把这个产品扛在自己肩上，确保它是一种让人愉悦的体验。→ 详细
• 一个「天花板被抬高」的真实例子：她昨天聊过的一位工程师本职不是移动端工程师，但团队需要给功能做移动端呈现；过去会卡在「我又不是 Android 专家」，现在多亏 Claude，他"有了个搭档"，把这事也在移动端做出来了。→ 详细

• 她最核心的回答：「成长型心态（growth mindset）真的真的很有帮助」，而且早在 AI 工具出现前就极其宝贵。她第一次真正学到这点，是从微软跳到 Meta 的头一年。→ 详细
• 成长型心态的内核：「永远在学习」，以及「把你带到今天这一步的东西，可能往后就不再管用了」。这很难——因为你正是靠某种做事方式才成功的，被要求「改掉让你成功的东西」确实吓人。→ 详细
• 共性特征：总是带着好奇心去投入、总是能去学习。她注意到做得好的人都有这个特点。→ 详细
• 一个反直觉但重要的点（后面 t153 也呼应）：当你把事情做得又好又专业、到了巅峰效率，继续成长的方式就是去做一件让你害怕、以前没做过的事——你会经历一段低谷，因为你得重新学习，但这正是逼自己成长的方式。她最爱的两句旧格言是「如果你不害怕，你会去做什么？」和「偶尔去做一件让你害怕的事」。→ 详细

• 沮丧背后她常看到的是「恐惧（fear）」。她的建议：「对任何让你恐惧的东西，迎上去，问自己『我能为它做点什么？哪些是我能掌控的？』」→ 详细
• 关键的心态翻转：沮丧往往来自「一切都在我掌控之外、是它在『冲我』发生（happening to you）」的感觉；换个角度想「什么在我掌控之内」，它就变成「为我发生（happening for you）」。→ 详细
• 她的亲身故事：高中时家里穷、连电脑都接触不到（九年级才在「打字课」第一次用上电脑），本来想当视觉艺术家，爱上编程是因为「有了想法就能动手创造、去讲故事」。但她怕付不起工程学院学费（安大略有助学项目 OSAP，但不知能覆盖多少）。→ 详细
• 她当时找到的那个「掌控之内的行动」：加拿大国家银行在高中贴传单招高中实习生当银行柜员（虽然她最讨厌的课就是会计）。她报了名，整个暑假打工攒钱、之后周末继续当柜员（周一到周五上学，周六做柜员），2000 年泡沫期还干了整整两年——这根「救命稻草」让她付清了学费。→ 详细
• Lenny 补了他在播客里引用最多的一句金句：「你所恐惧的那个洞穴里，藏着你所追寻的宝藏（the cave you fear contains the treasure you seek）」，Fiona 当场说「我要把这句偷走」。→ 详细

• 她对「全力拥抱 AI 的人 vs 完全不碰的人」之间正在形成的鸿沟很在意，花大量时间和小企业打交道、教人在工作中用 AI 是她的一大热情。→ 详细
• 这份热情的源头：她出生在香港、小时候搬到加拿大，一句英语不会，父母一直工作，靠「最好的外婆」陪伴照顾。某个夏天她们碰巧发现一家会说广东话的毛线店，外婆在那儿找到了她的「编织小圈子」，Fiona 也在那时学会了马克拉梅编织——她由此爱上「小店营造出的社区感」。→ 详细
• 怎么打开话匣子：「从一件你真正觉得给你生活带来了有意义改变的事说起」，看能不能成为引子。她对 AI 的定位是「工具」，回到「光明与黑暗」的比喻——「知识就是力量，必须学会用工具，它可能成为那个方程里的『光明』那一面」。→ 详细
• 她坦白「开口确实有点尴尬」：第一次联系朋友时（平时不跟他们聊工作）说「嘿，我算是做 AI 的……我能给你看看 Claude 能做什么吗」都觉得不自然，但最后「总能玩得很开心」。Lenny 举例自己用 Claude 帮儿子填夏令营表格、发推后一堆人「我都没想到还能这么用」。→ 详细

• 起点很私人：Fiona 自己特别讨厌做业务差旅报销，用 Cowork 处理时「简直像魔法——所有我不喜欢做的事它都替我做了」。她由此想到：小企业主拼了命干活、利润又薄，常坐在吧台后面对着一摞摞账单开发票报销，没人真喜欢干这个。→ 详细
• 她帮几位朋友做了上手引导，看他们走 onboarding 流程「还真发现了几个不错的 bug」，是个双赢；而且他们用 Claude 的方式是她想不到的（她原本一门心思盯着「处理 PDF/发票有多厉害」）。→ 详细
• 一个生动的用户故事：开两家餐厅的朋友说自己的文档/下载文件夹是个「杂物抽屉（junk drawer）」，知道里面有菜单却找不到 → 给 Claude 目录访问权限找出菜单 → 她又让 Claude「横向看看本地区同类菜系同行的价格」，返回了一份「几乎像市场分析」的东西，用来确保定价对本地人和游客都合理。→ 详细
• 后续真的催生了产品线 Claude for Small Business（她强调「完全不是出自我，我不抢功」）：起因是小企业主总问「它有没有这个插件、那个插件」，于是这条线把这些打包好，在 Cowork 里给一个小开关一键搞定。→ 详细

• 她的解释核心是「latent demand（潜在需求）」：留意那些你没预料到、正在悄悄冒头的用户行为，然后全力押注、去探索、去做点东西。编程这个用例他们特别幸运——「那么多 Anthropic 自己人就是最早的客户」，能做到极快的反馈循环。→ 详细
• Cowork 本身就是潜在需求的产物：他们注意到「很多本身不是程序员的人却在用 Claude Code」，于是想「能不能把那种体验做得更好」。→ 详细
• 关键动作是「带着一个假设」：当你看到「人们为了把某件事跑通而绞尽脑汁、各种折腾（jumping through hoops）」时，问自己能不能把那件事做成更顺滑、更好的体验。→ 详细
• 一条她从做软件学到的底层规律：「用户会以你根本没设想过的方式来用你的产品，好的坏的都有；最好的办法就是迭代、学习、紧贴反馈。」→ 详细

• 她明确判断：「我们正越来越往异步（async）的方向转。」这正是 routines 有意思的地方——抽象层级在不断往上拔。→ 详细
• 抽象层级的演进阶梯（她的原话拆解）：① 以前是同步敲一个 prompt → ② 后来异步零散启动几个不同 prompt → ③ 现在有一个 routine 来替我生成这些 prompt、并替我去派生（spawn）不同的 agent。→ 详细
• 和老办法的对比：以前最多设个 cron job 自动化某件事；现在是「看看这些反馈，如果发现 bug，有哪些打磨性的小修复是你能顺手搞定的」→ 它去启动 → 我一觉醒来手上就有一堆可 review 的 PR，而不用自己再想「那我现在拿这些信息怎么办」。→ 详细
• 更进一步会「赋予更多自主权」：到某个程度就是「放手去干吧（go for it）」——前提是「如果验证环节真的做得很到位」。她对一年后的演变充满好奇，说「真希望我有个水晶球」。→ 详细
• Lenny 把这套总结为「把你作为管理者每天几乎都要做的那些事写下来（项目进展如何？什么落后了？该解哪个卡点？谁遇到困难了？），让 Claude 替你去做，再给你呈现『这是我在做的、这是有待 review 的』」。→ 详细

• 受 Tyler Cowen（经济学家）一场演讲启发，Lenny 提到「做得最好的人都有 initiative（主动性）/ agency（能动性）」。Fiona 接：「agency 正是 Claude Code 和 Cowork 团队最看重的东西。」→ 详细
• 团队运作的方式：有一个问题摆在这儿，团队里每个人都有自己解决它的想法（高 agency）。→ 详细
• 关键的配套约束：「与高 agency 配套的，是高 accountability（高担责）」——核心是确保大家有充分发挥的自由（freedom to cook），但同时要想清楚「我要为这件事负什么责」，这又回到「你试图解决的问题、你的假设到底是什么」。她形容 agency 和 accountability「几乎就是同一枚硬币的两面」。→ 详细

• 大背景：氛围正从「token maxing（疯狂烧 token、能花多少花多少、就想看极限）」转向「我们到底从中得到了什么？花了多少钱？ROI 是多少？」（注：Boris 在 Meta 时就是负责衡量工程生产力的产品负责人。）→ 详细
• 她亲历的「指标踩坑史」：先用代码行数 → 有人靠移植一个库刷出爆炸代码量，于是改提「有意义的代码量」 → 又有人说「升级框架后生成的代码更少但效果一样呢」 → 于是改用「PR 落地的时间（time to land PR）」。结论是：不管用哪个指标，关键始终是「这个产出有没有真正导向你想要的结果（outcome）」。她说 token maxing「本质上跟以前的代码行数很像」。→ 详细
• 一句她特别喜欢的话：「别把『动作』当成『进展』（don't forsake motion for progress）」——衡量工具使用量只是在衡量「动作」，但它真的推动了你最终想要的结果吗？所以要往后退一步，聚焦「我们要解决的问题是什么、用什么方式衡量它最合适」。→ 详细
• 抛开指标的建议：去做「倾听之旅（listening tour）」，尤其去听资深工程师讲什么有用、什么没用、怎么做得更好——他们还能帮你把经验在整个团队放大铺开，而且这种共同学习常比看指标仪表盘更有收获。→ 详细

• Facebook Marketplace 早期按地区逐步上线，扩张前想先把产品打磨好；当时紧盯的一个指标是「卖家数量」。→ 详细
• 第一个地区上线后她发现：这个区域卖家数量很低，但人们确实在找到他们想要的东西（而「帮人找到需要的物品」才是真正目标）。原因是那个地区卖家不多，但有一批「超级卖家（power sellers）」。→ 详细
• 可扩张前的第一道关卡本会很看重「卖家数量」——这个指标没把超级卖家算进去，差点误判。于是他们更新了指标。→ 详细
• 通用结论：「不管是生产力指标还是产品指标，永远盯着点、别戴上眼罩盲目追随一个『曾经合理』的指标，因为局势变化太快，连指标本身都可能需要调整。」（呼应她的成长型思维：永远问「它还在为我服务吗」。）→ 详细

• 她想继续多做、做得更好的方向是「主动式质量保障（proactive quality）」：弄清哪些体验是关键的，越能主动出击、越早探测到质量问题就越好。→ 详细
• 她自创的高层框架：区分「bad」和「sad」——bad = 非常糟糕、不可恢复的错误；sad = 有点难受、但可恢复的痛点。一个反直觉的洞察：「当 sad 一个个堆起来，整体上往往就会演变成 bad。」→ 详细
• 为什么需要这个框架：仪表盘上有「加载时间」等一堆原始指标，但面对很多不同产品界面时，很难判断「这个数字到底算好还是不好」；与其只看原始的性能/可靠性数字，不如再加一套「什么算糟糕体验」的框架去聚焦。→ 详细
• 落地方式（呼应 agency）：每个团队自己针对负责的界面/服务去定义 bad 和 sad。例：CLI 端 bad = 崩溃率（崩溃很糟，工作丢了）；sad = 界面闪烁（通常可恢复）。各队再自定目标。→ 详细

• Lenny 提炼的主要收获：「把控质量最好的工具之一，其实是监控和测试，而不是花更多时间去做代码评审」——因为速度快到根本盯不过来。→ 详细
• 它呼应「为 agent 闭环（closing the loop）」的理念：让 agent 能自己把事情搞定——它们知道成功长什么样，于是「好，我们自己来修」。投入重点应放在测试、eval（评估集）、以及监控故障/速度上。Fiona 确认「没错」。→ 详细

• 团队有个仪表盘专门追踪用户骂的脏话（F-words）——因为用户气得不行时会骂街。→ 详细
• 来历：那是去年九月的事，她刚加入，当时大家都遇到一些挫败感，是团队里一位工程师提议「咱们也许该追踪一下脏话」，她觉得「这主意太棒了」。→ 详细
• 它指向一个更深的点：eval 之所以难，正是因为它回到「用户体验」——怎么确保是一段愉悦、而非令人沮丧的体验。→ 详细

• 她推行的少见做法：让每位管理者都从 IC（独立贡献者）做起，且持续兼着一部分 IC 的活。起因是她做的一次「倾听之旅」——很多人反馈「我很感激这份 agency，但怎么确保优先级排得对」，还有人希望「评审层级别太多」。→ 详细
• 为何让新管理者先做 IC：「带人」是很重的责任；在扛起那份全部责任之前，先给自己一段「造物时间（maker time）」深入代码库/产品，反而能和团队建立非常好的默契。否则新管理者容易一来就「翻出管理工具箱、做管理者该做的事」，而错过「先体会做这个团队的工程师/队友是什么感觉」。→ 详细
• 她自己做 PR 的真正目的：「重点不在于我修了什么，而在于我每天都在用这个产品、保持那种触感」——因为对 Cowork 和 Code 改动太多，做 PR 能让她保持在「心流」里。「指标再好，作为领导者如果不每天『活在』产品里、亲身感受它，就会和产品的手感脱节。」→ 详细
• 一个反复出现的小细节：她加入过的每个团队（VR、智能眼镜、Instagram）刚到时，常有人说「我真的特别喜欢你在亲自用我们做的东西、看到你给出用户反馈，让人觉得很新鲜」。→ 详细

• 大反差：她在 Meta 管着约 500 人的组织，加入 Anthropic 时基本是以一名 IC 工程师身份（虽然时间很短）。这套「先做 IC」其实是她从微软到 Meta 就有的习惯——在 Meta 头一个季度也兼 IC，为的是搞明白「做一名 Meta 工程师是什么样」。→ 详细
• 一个很真实的坦白：她上一次上线生产软件大概是 2017 年，之所以这么久没碰，部分是「怕搞砸——万一引入 bug、又没好好验证，岂不是在浪费别人时间」，加上工具流程会变。→ 详细
• Claude 怎么帮她破冰：第一周她差点又走老路（约所有工程师喝咖啡），然后想「先问问 Claude」——Claude 成了她「超棒的入职搭子」，帮她熟悉代码库、做自动化测试；她还让 Claude「帮我想想怎么手动测这个、把所有情况都覆盖到」，这些加起来给了她「我又能上线 PR 了」的底气。→ 详细
• 一个有趣的连锁效应：不少做了很久管理者的朋友找她说「多亏 Claude，我又开始写代码上线了」。她总结：作为领导者，确保你在用团队所打造的产品，非常重要。→ 详细

• 这是个「很 meta 的角色」：她带的团队恰恰是当下最在改变「工程师」这个角色的团队——工程师的工作正因为她们做的软件而被重塑。→ 详细
• 她的核心主张：要求所有新加入的工程师「你做的每一项工作，都要花点时间去真正理解它的架构、理解那次改动」，这回到「trust but verify」。例子：Boris 早期亲手写代码，现在不写了，但他从当年「在代码库里」积累了那份认知。→ 详细
• 她把这种能力本身称作一种「元能力（meta skill）」：「永远花点时间去了解你的依赖（double click / 往下钻一层），这样当依赖变化时你会更敏锐、也不至于错过新好处。」她也承认「也许有一天模型够强，这就不重要了，但以现在这个速度，理解仍然重要」。→ 详细

• 一个很真实的代价：「它可能会慢慢变成一种很孤独的体验，因为我们都开始大量地只跟自己的 agent 打交道。」→ 详细
• Claude Code 团队最近搞起「结对编程午餐（pairwise programming lunch）」。意外收获：因为每个人用 Claude Code / Cowork 的「flow」都太不一样，结对时「竟然能从彼此身上学到这么多」。→ 详细
• 还用黑客松（hackathon）等方式确保团队「在一起」、有互动。Lenny 把这种新形态精准类比为孩子成长时的「平行游戏（parallel play）」——彼此挨着工作、各自搭各自的东西，但光是看别人怎么搭就很有价值。→ 详细
• 关于「会不会有人过度沉迷优化工作流」：她说团队里这种人不多，大家更多是兴奋于「能带来更高可靠性的架构更新或某个产品体验」；「我不觉得我们会过度优化，因为其实根本就没有完美答案」——要做的事太多了。→ 详细

• Lenny（当过 10 年工程师）和 Fiona 都怀念那种「碰上棘手难题、戴上耳机放音乐、整个人进入状态」的心流，以及结尾处「终于把它攻克了那一刻的『耶！』（巨大顿悟时刻）」。→ 详细
• 她从多位工程师那儿听到同一句话：「有些最难的部分，恰恰是我以前最享受的。」现在很多乐趣转移到了「产品本身」，但失落是真实的——这也是她推结对编程/黑客松的直接原因（最近大家更明显地感到孤独）。→ 详细

• 问到「Anthropic 内部第二被重塑得最厉害的角色」，她答：「所有『与编码相邻』的角色都在变」，PM 首当其冲——「因为 PM 有了想法，不再被卡在等工程资源（engineering bandwidth）上了」。→ 详细
• 具体表现：他们的 PM 们会撸起袖子上手帮忙推进功能——当团队想做某件事、而工程师暂时腾不出手时。→ 详细
• 但更多人提交也带来挑战：「当有更多不同职能的人在提交、参与时，我们怎么确保每个人都有高度的信心」——又回到「验证」。她还点名设计、数据科学是下一批值得去改善体验的领域。→ 详细

• Lenny 转述一位数据科学家朋友：现在大部分工作，是别人自己用 AI 做了点算不上出色的数据科学活儿，拿来问「你能不能帮我确认对不对」——而一半时间它都是错的。→ 详细
• 这份工作「完全变成另一回事」：不再是做他们以为自己想做的工作，而是「整天审查这些 AI 做的数据科学」。这与前面数据科学被列为「下一批待改善领域」相互印证。→ 详细

• 最明显的变化：「现在绝大多数提交都是借助 Claude 完成的」——这本身就是一个新基线。→ 详细
• 期待工程师不断锻炼更强的「产品直觉（product sense）」肌肉（借助收集反馈的 Slack 频道 + 接入 Claude 的各种 dashboard），由此培养出「产品思维特别强的工程师」。→ 详细
• 卡点显著减少：很多过去不属于工程范畴的角色现在工程师也能干；以前会被「等跨职能搭档配合」卡住，现在这种卡点少多了，因为模型能补足工程师本身不具备的额外能力。→ 详细

• Lenny 精准概括「这是双向同时发生的」：工程师变得更有产品思维、开始对产品成败负责；与此同时，每个人都越来越像工程师。Fiona 一句话收束：「对，没错。边界全在模糊化（It's all blurring）。」→ 详细
• 一个被引用的「角色新定义」：在如今时代，所谓「角色」就是「你日常工作的一个平均值——你花时间占比最高的那件事是什么，那基本就是你现在的角色」。→ 详细

• 和她共事过的人提她，提得最多的就是「近乎痴迷地沉浸在产品里、不停地用」。她的理由：任何时候做产品背后都有一个「梦想」（希望让某种体验成为可能/更好），亲身用才能贴得离这个脉搏特别近。→ 详细
• 一个生动的反例故事：她离开 Facebook Marketplace 团队后想卖台旧 MacBook Air，刚一挂出去就遇到一种她以前没识别过的全新诈骗套路——再次印证「人们会以你完全意想不到的方式用你的产品」。→ 详细
• 另一个例子：她支持 VR/AR 团队时，因为自己摆设备的方式特殊，总能发现那些诡异的「地面高度（floor height）」问题，她那台机器成了「很好的复现环境」，于是主动「我来帮大家排查」。结论：「这就是你把住产品脉搏的方式，别让自己只迷失在指标、dashboard 或 PPT 里。」→ 详细
• 当领导者「用不动」产品时怎么办（例：她带 VR 团队时怕搞坏操作系统、没提交过代码）：那就用 dogfooding 时间亲自去「把关体验」，这同样能实打实地帮团队守住质量线；而且「让大家看到领导也在用产品，团队就会觉得领导依然真正投入、没脱离一线」。→ 详细

• 它如何连回「工程师要更有产品思维」：作为工程师，不停地用产品，就能以用户视角发现产品里缺了什么。她还补充：如果你带的团队产品你很难亲身用，那就去跟客户见面，找那条替代路子。→ 详细
• 经典亲历：Facebook Marketplace 准备往拉美上线、在智利测试，表现就是不如别的地区、试过的招都不管用。她带只有三个人的小调研团亲自飞去、买了一大堆安卓手机；一落地打开手机就发现当地 LTE 网速远慢于美国，Marketplace 信息流在弱网下根本加载不出来——「连内容都加载不出来，多大的增长拦路虎」。→ 详细
• Lenny 补刀（引 Jeff Bezos）：「如果你既有数据又有一个个案，那就信个案别信数据」——这正是她从「个案/具体小特例」里收获大量成功、而非一味盯数据的体现。→ 详细

• ① 还需要把 iOS 和 Android 拆成两个独立大组织吗？ 她的当前判断：深度专家仍然非常重要、要招，但「不再需要那种一个大平台一个大平台、人头很多的 mobile 组织」，因为大家都在灵活切换。仍在摸索「专业能力配置得对不对、够不够」的平衡。→ 详细
• ② 完全自动化的代码审查要推到多远？ 这归到「验证（verification）」这道坎（对应她的第二、第三个开放问题），她认为「还有特别多空间」。要点是看「哪些地方专家依然重要」，并不断反问「有没有办法把专业能力也利用起来去做自动化」。→ 详细
• 验证里最难的不是准确度，是「体验」：「怎么搭一套验证机制，确认体验确实就是你想要的样子」——eval 用例里一部分是准确度，但另一部分是体验，这块「仍然是块难啃的硬骨头，还在琢磨」。→ 详细
• ③ 角色都在模糊，怎么确保每个人产出都同样高？（演讲里列的第三个开放问题，与上面验证问题并列。）→ 详细

• 一个新冒出来的难题：因为有了 routines、一切更异步，「上下文切换（context switching）」的负荷开始变得很高——「我自己都记得会想『哦我刚启动了一个……』」。这是另一件「得想清楚怎么把体验做得更好、降低这个负荷」的事。→ 详细
• 一个微妙的「既变好又变差」：以前要连续几小时心流；现在 agent 反而能提醒你「进行到哪儿了」，让重新切回去更容易（不用把代码库/架构重学一遍，看一眼「这就是我们想做的事」就行）。→ 详细
• 一个反直觉的自我观察：她以前会专门空出「整块专注时间写代码」；现在因为能更频繁地异步切换，反而要回头给自己空出一块专注时间，专门去「消化之前启动的那一堆异步任务」。对「怎么既做更多又不一直切上下文」，她坦白「确实还没搞定」。→ 详细

• Lenny 抛出当下最热的悖论：本以为 AI 会让工程师变得没那么必要，可Anthropic、OpenAI 都在疯狂招工程师，需求大得不行。→ 详细
• 她「暴露一点脆弱」地坦白：自己没有现成答案，但最大的开放问题是「我们该怎么培养下一代人」——因为「你和我走上工程这条路的方式，跟现在太不一样了」。→ 详细
• 她的一个设想：对软件工程，也许会更像走向「fellowship / 师徒制（apprenticeship）」的项目。现有实习生（约 3 个月、做点小项目）不太够；难点是「怎么把我们当年攒下的那些人生历练（也许最后并不重要）硬塞进去一部分、教给下一代 builder」。→ 详细
• 核心担忧（Lenny 替她点破）：「如果你这辈子都不用再看一行代码，新工程师还有什么动力去真正搞懂基础设施怎么跑、内存怎么分配这些地基的东西？」她回到「double click 里藏着改进产品/系统的机会」，但「得想清楚怎么习得这种能力——不一定靠多年一行行敲代码」。→ 详细

• 她讲了个跨越半世纪的例子：她以前一位经理入行时还是「打孔卡（punch cards）」的年代，如今一直给她发「他用 Claude Code 做的各种东西」——「从打孔卡一路走过来，亲眼见证了整个变迁」。→ 详细
• 她由此提出一个「理论」：「什么东西会一直重要、什么东西在重要性上会发生变化，本身会随时间推移而改变；关键是你怎么把对应的熟练度重新构建进去。」→ 详细
• 它呼应「抽象层级不断上移」的说法（汇编→二进制→…→现在不用看代码，prompt 和 Claude 的思考/message 就是新一层抽象）。但 Lenny 提醒新的判断点变成了「我们到底是在堆一坨垃圾（slop），还是在搭一个真正能跑的架构」，以及「东西做出来后怎么知道它真的引起共鸣、确实在做你想让它做的事」。→ 详细

• 她对「指数级改进速度」的亲历：第一次用大概是 Sonnet 3.5 或 3.6，做边角事情时它还会犯错（「你这是在干嘛」）；抵触 AI 的工程师会拿这些错说「你看吧」，但很多人当时难以理解这种近乎指数级的进步速度。→ 详细
• 一个可直接用的工作习惯：「我之前想自动化某件事、Claude 当时还不够格；到下一个模型，诶，现在它就够用了。所以要时常回头重试那些当初没成的尝试，因为现在说不定已经成了一种新能力。」→ 详细
• Lenny 提炼成本播客的高频建议：「去做一些当下几乎能跑、刚好卡在能力边缘的东西，因为一旦模型追上来，你就会比所有人都领先一大截。」→ 详细
• 年轻人的优势：「顺势用新方式干活要容易得多，不会被困在老路子里」；而像 Fiona 这样的资深工程师能适应、拥抱变化「很难得」，因为「把一切推倒重来真的太难了」。→ 详细

• 她的最大焦虑：「让我夜里睡不着的，是团队文化。」她讲究「一个团队（one team）的心态」。文化是「有生命、会呼吸的东西，不是往墙上贴张海报就完事的」，它体现在「我们怎么对待彼此、怎么在关键时刻互相托底」。→ 详细
• 为什么扩张是威胁：「我们在不断扩张，而扩张会让文化漂移」。她特别看重「多元视角」，好让团队能在台面上展开「健康、开放、坦诚的辩论」。她对「one team」的定义很具体：「当你快冲到终点线时，回头看看有没有队友需要拉一把，因为我们是作为一个团队一起冲线的。」→ 详细
• 为什么唯独文化最难：「别的难题多是产品或工程挑战，那些好歹有 dashboard、有理论、有假设；但文化是关乎『人』的那一面」，一旦开始漂移，她总担心「我们有没有及时察觉、有没有作为一个团队坐下来好好谈」。→ 详细

• Lenny 分享 Airbnb 的两条经验（他在那儿时也是陡增长，但「跟你们现在根本没法比」）：① 创始人对文化近乎痴迷——每次全员大会/重要会议都反复重申文化、价值观，几乎没有哪次会议不把它拎出来讲。→ 详细
• ② Sheryl Sandberg 炉边谈话的金句：被问「规模扩张怎么守文化」，她答「这其实是你应该庆幸自己拥有的『好问题』，因为它意味着你在增长、在做得好，这是正常的；反过来，做得很糟时什么都不会变——那才是糟糕得多、带来更多痛苦的处境」。→ 详细

• 她尤其要求管理者做到：不只聊进展顺利的事，也要坦诚讲哪些事情不顺——「只有真正把『哪里不顺』摆出来谈，才能着手去解决它。」→ 详细
• 她的「噩梦」原话：问某个管理者「最近怎么样」，对方答「一切都好」，她心里却知道明明有状况——「就像那个梗图：着火的房间里，一只猫端着咖啡说『一切安好（this is fine）』，这就是我的噩梦。」所以她会在管理者刚加入时就约定「以后一定保持这种开放对话」。→ 详细
• 一个普遍痛点（Lenny 点出）：当身边人表面上都「所向披靡」时，承认「我过得不太好、在挣扎、快掉队了」会格外难。→ 详细

• Claude Code/Cowork 团队文化里非常重要的一条：「明确授权（explicit permission）大家去『砍掉』那些不再为我们服务的流程。」→ 详细
• 可立即上手的动作：「挑一个你做起来最发怵、噪音最大、代价最高、或最手工的流程，先问自己：它现在还有存在的意义吗？」→ 详细
• 她自己的「第一个大教训」：刚加入 Claude Code 时她引入了一份「六个月路线图文档」（号称超轻量）；做这件事的过程本身是好的（启动对话、确保对齐），但三个月后她发现「我们还有在参照它吗？因为变化太大了」，于是亲手把自己引进的东西改掉。结论：「永远对学习保持开放，永远问自己：手头这套流程现在还在发挥作用吗？因为领域变化太快。」→ 详细

• 她现在管它叫「JIT planning（just-in-time / 即时规划）」，因为「六个月太长了」。做法极轻：按一个月规划，连文档都没有，就是大家在一张小表格上对齐「什么最重要」（有些项目当然会超过一个月）。→ 详细
• 节奏：列出下个月要做的事 → 每周快速核对一次「这还是本月优先级吗」。Lenny 这颗 PM 脑子直呼「这种事怎么可能不去做」。→ 详细
• 极度聚焦 + 留 agency：「表格上的条目不多」，团队只共享「我们认为优先级最高的几件事」，然后每个人在这些优先级之下、各自想出自己那一项用合适方式去回应。→ 详细
• 更大尺度的「主题」：整个团队约每六个月聚一次、启动一些「主题（themes）」标方向，但关键仍是「持续把住脉搏，因为大环境一变、连主题都会变得很快」。她对连「更新那张小表格」都不想让它变成「税」、还在琢磨「怎么把它进一步自动化」——又回到那句「永远问自己：这件事能不能做得更自动化一点？」→ 详细

• 三句核心暴击：写代码不再是瓶颈 / 天花板被抬高 / 问题变成「你能有多大野心」；Anthropic 工程师季度交付代码量是 2021–2025 的 8 倍。→ 详细
• 介绍 Fiona 履历：微软 TypeScript/Visual Studio → Facebook Marketplace（年 GMV 1000 亿+）→ Meta 智能眼镜/Orion → Instagram 管 500 人。→ 详细
• 软件工程史上的台阶式飞跃（IBM 用 Vim → 微软第一次用 IDE → CD 发行的硬截止 → 在线发布），dogfooding 之爱源自「用 VS 编辑器构建 VS 编辑器」。→ 详细
• 抛出全片主题：人人变 builder、瓶颈转向「验证」。→ 详细

• 跑一个接入所有仓库/Slack/指标的 Claude 远程会话，每月共享屏幕和团队一起复盘。→ 详细
• 「Make new mistakes」：零失误意味着跑得不够快。→ 详细
• routines 把晨间管理动作自动化：醒来就有总结 + 可 review 的 PR。→ 详细
• 代码评审：把「什么是好」写成框架/spec 塞进 repo，让 Claude 对照验证；TDD 从「不得不付的税」变成 AI 替你先写测试。→ 详细

• 只招两类人：有产品 sense 的创造型 builder + 啃硬骨头的深度系统专家。→ 详细
• 做得好的人共性 = 成长型心态、好奇心、敢做让自己害怕的事。→ 详细
• 把「冲我发生」翻转成「为我发生」，找一个掌控之内的行动；她高中当银行柜员供自己读工程学院的亲历。→ 详细
• 金句「你恐惧的洞穴里藏着你追寻的宝藏」。→ 详细

• 外婆、毛线店与社区感：她帮小企业用 AI 的热情之源。→ 详细
• Cowork 缘起于她自己讨厌报销；催生 Claude for Small Business；餐厅老板用 Claude 做菜单定价市场分析。→ 详细
• Anthropic 总能早押大机会的关键 = 紧盯「潜在需求」、看人们为跑通某事而折腾的地方。→ 详细

• 工程下一前沿 = 异步 + fleets of agents + routines 派生 agent，抽象层级上移。→ 详细
• 高 agency 必配高 accountability。→ 详细
• 衡量生产力别用代码行数（会被刷量/被框架升级误导），盯「产出有没有导向结果」；Marketplace「卖家数量 vs 超级卖家」指标踩坑。→ 详细
• 主动式质量 + bad/sad 框架 + 监控测试胜过人工评审 + 脏话仪表盘。→ 详细

• 每位管理者先做 IC、持续兼 IC；她从管 500 人到在 Anthropic 重做 IC、Claude 当入职搭子。→ 详细
• 编码能力会不会退化 → 要保留「往下钻一层（double click）」的元能力。→ 详细
• 新世界丢失的：孤独感（对策结对编程午餐/黑客松）、写代码的心流与顿悟时刻。→ 详细
• PM/数据科学等「编码相邻」角色全在变；边界双向模糊。→ 详细

• 痴迷用产品才能把住脉搏（卖 MacBook 遇诈骗、VR 地面高度 bug）。→ 详细
• 智利弱网拖垮 Marketplace 增长 → 信个案胜过信数据。→ 详细
• 三个开放问题（iOS/Android 组织、自动化评审推多远、产出公平）；异步带来上下文切换负荷飙升、她也没解。→ 详细
• 招聘悖论 + 怎么培养下一代（fellowship/师徒制）+ 在能力边缘做东西。→ 详细

• 让她睡不着的是团队文化漂移；坦诚讲「哪里不顺」，噩梦是「着火房间里说一切安好」。→ 详细
• Airbnb 守文化经验：创始人自上而下痴迷 + Sandberg「这是好问题」。→ 详细
• 留给听众：明确授权砍掉不再服务你的流程；她现在用「JIT 月度规划」（一张小表 + 每周核对）。→ 详细
• 快问快答 + 织毛衣彩蛋（见下节）。→ 详细

Q1 · 最常推荐给别人的两三本书？

• 小说作家两位：Margaret Atwood（玛格丽特·阿特伍德）——她在加拿大长大读了很多，爱其「推想小说（speculative fiction）」（眯眼一看「这真有可能发生在某个社会吗」）；Haruki Murakami（村上春树）——爱其「魔幻现实主义」风格。→ 详细
• 一本她每年至少读一遍、推荐给所有人的书：《小王子》（The Little Prince）——「提醒我去想一想，到底什么才是真正重要的」。→ 详细

Q2 · 最近喜欢的电影/电视剧？

• 她基本不看电视剧（Lenny 说这在 Anthropic 嘉宾里是「共同主题」）。但手机里常存三部「复古片」供飞机上看：→ 详细
• 《天使爱美丽》（Amelie）——法国电影，超天马行空；捕捉到了她 16 岁高中去巴黎旅行时感受到的「魔力」（她当年想当视觉艺术家）。→ 详细
• 《千与千寻》（Spirited Away）——吉卜力，她最爱的吉卜力电影之一。→ 详细
• 《风之谷》（Nausicaä of the Valley of the Wind）——吉卜力（改编自漫画）；她八九岁看的，女主角娜乌西卡的领导方式深深影响了她许多领导原则。Lenny 调侃：这相当于把它和 Andy Grove 的《High Output Management》并列成「两本顶级管理学读物」。→ 详细

Q3 · 最近发现的、特别喜欢的产品？

• Sweet Sisters Bodycare——Whidbey Island 上的一家本地小店，一整套有机护发/护体/护肤产品（她强调「这不是广告」）。→ 详细
• 故事：她几年前鼻子长了种很疼、会出血的疹子，查不出原因；后来发现是身体对用了十几年的普通棕瓶洗发水里的化学成分过敏了（洗头时洗发水会流到全身）。换成这家有机洗发水后就好了，从此全换；最近出差用了一周酒店洗发水皮肤又有反应，提醒她该带旅行装。→ 详细
• （插曲：她这趟出差是去参加全球巡回的 Code with Claude 活动，SF/伦敦已办，下周东京是最后一站，将来还会有更多场。）→ 详细

Q4 · 经常回想的人生格言？

• 工作上：「keep it simple（保持简单）」——真正想做好的那件事是什么，专注在它上面，因为「我们有时候会想得太复杂」。→ 详细
• 生活上：「在一个你可以成为任何样子的世界里，选择善良（in a world where you can be anything, be kind）」。→ 详细
• 配套故事（疫情期间的一次「小善意」）：她外婆住加拿大养老院、疫情没法探望，只能偶尔 FaceTime，时间难定；某天阿姨突然说「外婆今天中午 12 点能 FaceTime」，正撞上她一直想约的一对一；她临时跟下属请求改期，对方一句「当然没问题，完全 OK」、毫无负担——这个小小善意让她得以和外婆 FaceTime，意义重大。→ 详细

Q5 · 织毛衣彩蛋（Boris 爆料：重要会议背景里常听到 Fiona 织毛衣的咔哒声）

• 她自己织自己的衣服（最近织了一件上衣）。Lenny 笑称「这简直就是 Claude Code 自己构建自己，特别 meta」，她接「我们一直在『构建』自己的衣服嘛」。→ 详细
• 一个编织 ⇆ 编程的妙喻：织毛衣基本就两种针法——下针（knit）和上针（purl），相当于 0 和 1，很多栈/队列概念都能对上，「我织毛衣时有点像一个编译器、像在生成一个可执行文件」。→ 详细
• 八岁时是外婆教她织的（呼应前面毛线店的故事），每次织都想起外婆；她熟练到「不用看手在干嘛」，「就像别人玩指尖陀螺」，且一心多用——「坐着闲下来就 kick off 好几个 agent、同时『生成』更多毛衣」（还自嘲有「轻微毛线囤积症」）。→ 详细
• 她的终极梦想：「以外婆的名字开一家毛线店，营造那样一个社区」——然后让 Cowork 帮她自动化一切，「尤其是开发票」。→ 详细

• LinkedIn：Fiona 说自己主要在 LinkedIn 上。→ 详细
• 她希望听众能帮的两件事：① 反馈「哪里做得好、哪里做得不好」，以及你正在用的任何有意思的「潜在需求」用例（她举例：有朋友用 Claude 帮自己生成一个小棚屋的搭建方案）；② 花点时间手把手带身边一个还没接触 AI 的人/小店，看 AI 能在哪些地方帮到他们。→ 详细