编辑｜Panda
Anthropic 工程师人均每个季度产出的代码量，是 2025 年同期的 8 倍。这可不是某个孤立团队的战绩，而是一整条从「稳定」直接拉升到「起飞」的曲线：过去几年几乎持平的产出量，在过去一年里近乎垂直上升。
图源：《When AI Builds Itself》，Anthropic
写代码，正在从工程师工作中最耗时、最稀缺的环节，变成一项「理论上人人皆可拥有」的能力。
带来这条曲线、也亲身管理着这条曲线背后所有人的，是 Anthropic Claude Code 与 Cowork 团队的负责人Fiona Fung
在 Lenny's Podcast 的一期访谈中，她讲述了当「编码不再是瓶颈」之后，一个工程组织真正需要面对的问题：野心的上限在哪里？质量怎么守住？管理者每天该做什么？团队里那些不再写代码、只是「等 Agent 干活」的人，会不会觉得孤独？
视频地址：https://www.youtube.com/watch?v=Ybrl4FYM57c&t=3s
这篇文章梳理了这场访谈的核心内容。
Fiona Fung 简介
Fiona Fung 在软件行业已经工作超过 25 年。她的职业生涯始于 IBM，在 DB2 操作系统服务团队做实习生，当时用的还是 Vim 和终端调试器。此后她加入微软，在 Visual Studio 团队一待就是 11 年，参与打造了 Visual Studio 和 TypeScript。她曾在 Visual Studio 编辑器组工作，用 VS 编辑器本身来构建 VS 编辑器，这也是她「dogfooding（尝自己的狗粮）」情结的起点。
离开微软后，她加入 Meta，从零到一带出了 Facebook Marketplace 团队，这项业务如今每年产生的商品交易总额（GMV）已超过 1000 亿美元。在 Meta 期间，她还负责过公司第一款智能眼镜产品，并参与打造了初代 AR 眼镜项目 Orion。随后她转到 Instagram，统领基础设施、增长、诚信与安全团队，管理规模一度超过 500 人。
如今在 Anthropic，Fiona Fung 统领 Claude Code 与 Cowork 背后的整个工程与产品团队，Boris Cherny（Claude Code 之父）与 Catherine Wu 都向她汇报。两人此前都曾登上 Lenny's Podcast，且都是节目历史上收听量最高的几期嘉宾之一。
从「刻录 CD」到「编码不再是瓶颈」
Fiona Fung 回忆，她在 Visual Studio 时期，软件是要刻录进 CD 再上架销售的，这意味着团队必须在一个「硬性死线」之前把所有事情做完。正因为工程时间是极其稀缺的资源，那个年代的工作方式高度依赖前期规划。一旦定了范围，几乎没有回旋余地。
这种稀缺性，正是今天被彻底打破的东西。她说：「以前工程时间是非常宝贵的资源，你还有这些非常硬性的死线……现在的转变是，编码不再是瓶颈了。」
这表明：不只是工程师，Claude Code 团队里的设计师、产品经理，几乎每个人都在提交代码
参与提交代码的人变多了，学科背景也更多元了，但吞吐量本身也高到前所未有。这就带出了她反复强调的一个词：验证（verification）
当越来越多不同背景的人都能产出代码，如何确保每个人对代码质量都有足够的信心，成了新的核心问题。
「现在是关于你能有多大野心」
Fiona Fung 提到一个细节：一位工程师原本不是移动端出身，团队却需要一个新功能覆盖到移动端。过去他大概率会说「这个太难了、太复杂了」，但现在的反应变成「等等，这其实完全可行，我让 Claude Code 去做就行了」。
这呼应了访谈中反复出现的一个判断：编码这件事本身不再是限制，限制变成了你敢不敢想。「一切理论上都变得可能了。现在的问题是你能有多大野心。」
Fiona Fung 将这种变化形容为「天花板被抬高了，任何人都能做到以前做不到的事」。这种转变并非人人都能轻松适应。访谈一开始，Lenny 就提到一个被反复讨论的现象：团队和整个行业内部，正在出现一种「拥抱 AI、干得风生水起」与「抵触 AI、感到挫败甚至愤怒」两类人之间的分裂。
对此，Fiona Fung 认为成长型思维是分水岭所在：那些始终保持好奇、愿意持续学习的人，往往适应得更好；而挫败感背后，很多时候藏着一种更本能的情绪——恐惧
她的建议是：与其被这种恐惧支配，不如主动去问自己「这件事里，哪些是我能控制的」，这个思路会在文章后半部分她讲述自己成长经历时再次出现。
这也是她对招聘画像的重新定义。她现在寻找两类人：
- 有产品感的创意 builder：他们是那种对某个产品有强烈热情、会把想法从零构建出来、并持续根据反馈打磨迭代的「造梦者」；
- 深度系统专家：负责那些模型目前仍处理不好、必须靠人类专业知识兜底的硬核部分。
她说，这两类人「信任但要验证」的原则同样适用：模型很强，但总有一些领域仍然需要真正的专业判断
Claude 替她盯着整个团队
Fiona Fung 描述了她作为管理者，工作方式的一次颠覆性转变。
她现在会在团队维护的所有代码仓库里常驻一个 Claude Code 远程会话，这个实例同时能访问团队的 Slack 频道和各类指标仪表盘。每个月，她会和团队成员一起打开这个会话，共同回顾：这个月聚焦做了什么？上线了哪些产品？市场反馈如何？有没有引发什么问题？
「以前我可能只会用这些会话生成 PR 和修复 bug，现在我用它们来和我支持的人展开对话。」
她提出了一个管理原则：「犯新的错误」。她说，允许犯错是必要的，「只要每次犯的是新错误」，因为如果目标是零错误，往往意味着团队推进得不够快，或是过于谨慎。
而在过去一两个月里，这套流程又被一次新功能「Routines（例行程序）」彻底改变了。
她过去每天早上喝咖啡时会人工浏览各个反馈渠道，判断当天有没有时间去修一些小问题；现在她设置了一个每天固定时间运行的 Routine，自动帮她扫描反馈渠道、提炼主题、甚至直接生成可供审核的 PR。她这样形容这层变化：「以前我可能还会自己生成一些 prompt，但现在有了 Routines，几乎是我在让一个 Agent 帮我生成 prompt 和 PR。
Bad 与 Sad：8 倍产出下如何守住质量
代码审查曾是团队最大的瓶颈之一。Fiona Fung 坦言，去年 Claude Code 团队甚至还没有「Claude 做代码审查」这件事。
如今，团队仍然坚持对需要深度专业判断的领域保留人工审查，但更多情况下，团队会把「什么是好的标准」写成一份规范（spec），直接检入代码仓库，并保证规范随代码同步更新。她的经验是：「只要你把『什么才算好』这件事写清楚放进仓库里，代码审查就能去核对它是否仍然符合当初设定的目标。」
她还提到一个有意思的细节：团队重新审视了测试驱动开发（TDD）这个由来已久的工程原则：先写测试、确保测试失败，再去实现功能。
她说自己过去一直不太擅长这套流程，「感觉像是必须先吃掉那盘西兰花」，而她本人享受的是直接动手把产品做出来的那份快感。但她记得自己在 Claude Code 上修复的第一个 bug，正是先对 Claude 说「我想做测试驱动开发，帮我先把测试写出来，确保它先失败」，然后再去做真正的修复，看着测试由红转绿。
她认为，这说明了一件事：那些一直存在、原本正确却因为「太麻烦」而被工程师绕开的好方法论，如今因为有模型分担了大量执行工作，反而变得比以前更容易被坚持下来。
在质量管理上，团队摸索出了一套简单的分级框架：「Bad」指的是那种严重、不可恢复的错误，比如 CLI 崩溃、丢失工作进度；「Sad」则是可恢复但影响体验的问题，比如界面闪烁。团队把这套分类的具体定义权下放给各个小组，让他们根据自己负责的界面或服务来定义「什么算 Bad、什么算 Sad」，因为不同产品面之间的仪表盘数字很难直接比较，而一个统一的高层框架能帮团队更快看清全局体验的走向。
团队还专门做了一个略带幽默感的仪表盘：追踪反馈渠道里「脏话」出现的频率，用来侧面感知用户的挫败情绪。这个想法诞生于去年九月，Fiona Fung 笑称这是团队一次很有意思的头脑风暴产物。
高 Agency，也意味着高 Accountability
Agency（自主行动力）」是 Fiona Fung 反复强调的团队文化关键词。谈到经济学家 Tyler Cowen 近期一场演讲中提到「主动性（initiative）」是当下表现最好的人的共同特质时，她立刻表示这与团队信奉的价值高度一致：「这就是我们在 Claude Code 和 Cowork 团队特别看重的东西——遇到问题，团队里每个人都会有自己的解法。所以我们非常强调高 Agency，但我们也说，高 Agency 意味着高 Accountability。
她解释，这意味着团队给予成员充分的自由去「大胆尝试」，但同时也要求每个人对结果负责：你解决问题的假设是什么？做完之后效果如何？这种「自由与责任对等」的机制，她认为是团队保持高产出同时不失控的关键平衡点。
用她的话说，团队文化里那种「大家都在放手去做」的状态，最终都要回到一个很朴素的追问：你到底解决了什么问题，又是怎么验证自己确实解决了它。
别把「动作」当成「进步」
关于如何衡量 AI 时代的工程师生产力和投入产出比，Fiona Fung 的态度相当审慎。她回顾了团队内部关于「代码行数」这个指标的争论：曾有工程师提交了巨量代码行数，后来发现只是把一个现成的库搬运了过来；也有相反的情况：团队升级了底层框架后，同样的产出反而生成了更少的代码。
她的结论是：「不要把动作误当成进步。如果你只是在衡量工具的使用量，你衡量的是『行动』，但这真的在推动你想要的结果吗？」
她分享了一个来自 Facebook Marketplace 早期的例子：团队按区域逐步上线产品时，最初盯着的核心指标是「卖家数量」。但在第一个上线的地区，卖家数量偏低，用户却依然能顺利找到想要的商品；后来才发现，这个地区虽然卖家总数不多，却聚集了不少「超级卖家」。
如果当时机械地按卖家数量这一个指标来决定是否扩张，可能会得出错误结论。这次经历让她此后始终提醒自己：任何指标，哪怕曾经很合理，都要不断追问它是否仍然服务于最初想要达成的结果。
除了指标本身，她也强调「倾听巡回」（listening tour）的价值，尤其是与资深工程师的一对一交流。这些对话往往比仪表盘更能激发出真正有价值的洞察，也更容易在全团队范围内扩散。
她表示，这套倾听巡回的习惯，也正是她推行「管理者先做 IC」这项制度的直接来源之一：正是在与团队成员的一轮轮交流里，她听到了不少关于「审批层级太多」「希望有更清晰的优先级」的真实声音，才决定从制度层面做出调整，而不是仅仅停留在口头上的鼓励自主性。
每个经理都要先做一段时间的 IC
Fiona Fung 在团队里推行了一项颇为独特的做法：每一位新晋管理者在正式承担管理职责之前，都要先以个人贡献者（IC）身份工作一段时间，此后也要持续保持部分 IC 工作。
这个想法来自她加入团队后做的一轮内部倾听。她注意到，如果一个管理者一上来就急着「打开管理工具箱、做管理该做的事」，反而容易造成过多的审批层级；而如果先花时间深入代码库和产品本身，往往能和团队建立起真正的信任关系。
这项原则某种程度上也是她自己职业生涯的翻版：她提到，当年从微软转到 Meta 出任管理岗位时，第一个季度她坚持先以工程师身份工作，就是为了亲身体验「作为一名 Meta 工程师去交付产品」是什么感觉。
到了 Anthropic 后，她延续了这个习惯。加入 Claude Code 团队的第一周，她原本准备走老套路，请每位工程师喝咖啡聊需求，后来却改成向 Claude 提问了解代码库。
她表示，自那之后每天做 PR，对她而言重要的不是修复了什么具体问题，而是这件事本身能让她始终保持「在场感」：「哪怕仪表盘和各种数据再完美，如果你作为一个领导者没有每天真正地使用、体验自己团队所构建的产品，你就会渐渐失去那种『触感』。」
她还提到一个细节，颇能说明这种「亲手上阵」对她本人的意义。
她说自己在 Meta 最后一次提交生产环境代码大约是在 2017 年，此后虽然一直坚持 dogfooding，却很少再真正动手写代码上线。很大程度上是因为她害怕自己不小心捅出篓子，或者因为流程、工具链早已变了样，反而浪费别人的时间去替她兜底。但加入 Claude Code 团队的第一周，她原本按老习惯准备挨个约工程师喝咖啡、了解代码库，后来却停下来想「不如直接问 Claude 吧」。
于是 Claude 成了她最好的「入职搭子」：她可以随时就代码库提问，Claude 不仅帮她生成自动化测试，还在她想额外做一轮人工测试时，帮她梳理出一套能覆盖各种边界情况的手动测试方案。正是这种确定性，让她重新找回了提交代码的信心，也让不少许久未写代码的朋友，如今纷纷告诉她「我又开始提交代码了，多亏了 Claude」。
技能会退化吗？
面对「工程师不再亲手写代码，编码能力会不会退化」的问题，Fiona Fung 的回答是：这是团队内部真实讨论过的话题。
她提到Boris Cherny 早期是亲手写代码的，虽然现在已经不这样做了，但正是那段经历让他对系统 architecture 有了深刻理解。
她认为，无论模型多强，「深入了解你所依赖的那一层」这件事本身依然重要，因为只有理解依赖关系，你才能真正意识到底层发生了变化，也才能更好地利用这些变化
「和 Agent 一起工作太孤独了」
访谈中一个格外真实的细节，是团队发现的一种新型「孤独感」。过去的工程协作是「N 个人一起搭一套系统」，其中有人做后端、有人做前端、有人做 iOS，彼此之间自然产生大量互动；而现在，一个人可能同时运行着十个并行工作的 Claude 实例独自推进项目，团队成员之间反而互动变少了。
Fiona Fung 坦承：「过了一段时间之后，我们发现这开始变成一种孤独的体验，因为大家都在和自己的 Agent 工作太多了。」
为此，团队最近开始组织「结对编程午餐」，也保留黑客马拉松这样的集体创作时段。
有意思的是，团队发现即便都在用 Claude Code 和 Cowork，每个人的工作流程也千差万别。真正坐下来看彼此如何工作时，大家反而能从中学到很多此前没意识到的技巧。这被形容为一种类似孩子「平行游戏」的状态：各自在做自己的项目，却因为并肩工作而彼此受益。
同样值得记录的，是关于「Flow 心流」的怀念。Fiona Fung 自己也做过十年工程师，她坦言过去那种「独自钻研一个棘手问题、最后攻克它」的心流体验和成就感，如今确实在变少。现在更多时候，人是在等待 Agent 把东西构建出来。她说，团队里其他工程师也提到过类似感受：以前最艰难、也最让人享受的那部分工作，正在被替代。她认为，大家从产品本身获得的成就感正在填补这部分缺失，但这确实是一种真实存在的转变，而非虚假的怀旧。
下一个被改变的角色：PM、设计与数据科学
除了工程师，Fiona Fung 认为 PM 是目前受 AI 冲击第二大的角色。因为 PM 不再受限于工程带宽，一旦有想法，很多时候可以自己动手实现。
她提到，Anthropic 的 PM 们已经开始「卷起袖子」，在工程师排期不上的时候自己动手把一些功能改动完成。她判断，接下来设计和数据科学会是下一批被显著改变的领域，团队需要投入更多精力，把这些环节的工作流程也自动化起来。
Lenny 在访谈中提到一位从事数据科学工作的朋友的经历颇具代表性：现在很多人会自己用 AI 做一版数据分析，再拿去给数据科学家「过目把关」，而这些分析往往一半时候是错的。数据科学家的工作因而变成了不断审核他人用 AI 生成的分析结果，而不是自己动手做分析。这与 Fiona Fung 所说的「验证」正是同一个趋势的不同侧面。
对于普通工程管理者，Fiona Fung 总结了这个时代的新常态：绝大多数代码提交都有 Claude 参与协助；工程师需要持续培养更强的产品感；角色边界正在双向模糊。
工程师变得越来越「产品导向」，而越来越多原本非工程背景的人也开始承担类似工程师的工作。
把 AI 能力带给身边的小生意主
访谈中一个格外温暖的段落，是 Fiona Fung 讲述她如何萌生做「Claude for Small Business」的念头。她出生在香港，幼年移民加拿大时不会说英语，是外婆放下一切陪她长大，但外婆同样不会英语，在异国他乡的生活颇为孤独。
直到有一年夏天，她们偶然发现了一家由讲粤语的老板娘开的毛线店，从此每周都去，那里成了外婆的「编织圈」，Fiona Fung 也是在那里学会了如今又重新流行起来的宏观编织（macramé）。
这段童年记忆，成为她后来关注小微企业的情感起点。真正的契机，是她自己用 Cowork 处理差旅报销。她一向不喜欢这类琐事，却发现 Cowork 处理得很流畅，由此想到：身边那些起早贪黑、常常利润微薄的小生意主朋友，如果能用上这样的工具会怎样？她随后帮几位朋友完成产品上手，过程中他们也帮团队找出了不少真实存在的 bug，可谓「双赢」。
她印象最深的一个例子，来自一位经营两家餐厅的朋友。
这位朋友的文档文件夹活像「厨房里那个什么都往里塞的抽屉」。她记得自己有菜单文件，却怎么也找不到。Fiona Fung 授权 Cowork 访问该文件夹后，很快帮她找到了菜单。更让她意外的是，这位朋友随后开始用一种她完全没预料到的方式使用产品：让 Cowork 分析同类菜系在当地的定价水平，以确保自己的价格「对本地人和游客都合理」，Cowork 给出的分析接近于一份市场调研报告。
「所以我每次都能学到新东西，而且他们也一直在给我很好的反馈。」
值得一提的是，这条产品线的诞生并非一次自上而下的战略决策。Fiona Fung 特别强调，「Claude for Small Business」的想法并非她一个人的功劳。在她带着几位小生意主朋友做产品体验的同时，团队内部也有一支专门和中小商户客户做深入沟通的小组，同样发现了类似的效率缺口，比如商户们总在问「这个插件支持吗」「那个插件支持吗」。
两条线索最终汇聚到了一起，才有了如今 Cowork 里那个专为小企业设计的功能开关。这些一线经验后来直接推动了「Claude for Small Business」的诞生。对于如何把这种能力更广泛地推广出去，她的建议很朴素：从分享一个真正改变过自己生活的 AI 使用案例开始，把它当作和身边人打开话题的方式，因为如果不这样做，AI 能力上的鸿沟只会越拉越大。
「隐性需求」是新产品的起点
Fiona Fung 还分享了 Anthropic 屡屡先人一步发现新机会的方法论：留意「隐性需求（latent demand）」
她提到，团队观察到不少并非专业程序员的人也在使用 Claude Code，这促使团队去思考如何为这类用户改善体验。这正是 Cowork 诞生的一条重要线索。
类似的观察方式也催生了「Claude for Small Business」：团队注意到用户不断追问「这个插件支持吗、那个插件支持吗」，于是干脆把这些能力打包整合进产品里，变成 Cowork 里的一个开关。
她将这套方法论总结为：「人们总会以你意料之外的方式使用你的产品，无论是好是坏。最好的应对方式，就是持续迭代、学习，并始终贴近反馈。」
下一步：更加异步化的工作方式
谈及工程工作方式的下一个前沿，Fiona Fung 认为团队正在朝更「异步（async）」的方向演进。
她把这和 Routines 联系起来：过去她需要同步地写一个 prompt、等它跑完，再决定下一步要不要异步地再起几个任务；现在 Routines 能够按她设定的节奏自动生成 prompt、派发给多个 Agent 去执行，等她第二天早上醒来时，成果已经以 PR 的形式摆在她面前，供她审阅、决定是否合入。
她把这种变化理解为管理者日常工作被系统性「模板化」的过程：过去她每天早上会思考「我该看哪些反馈渠道、该关注哪些人的进度」，现在这套判断本身也被写成了可以自动运行的流程。
用她的话说，这是「抽象层级又往上提了一级」。她也坦言，自己同样很好奇这条路径接下来会走向何方。她笑着对 Lenny 说：「要是能在一年后再回来聊一次这个问题就好了」，
恐惧、成长型思维，与「不被落下」
对于那些在这场变革中感到焦虑甚至被落下的人，Fiona Fung 给出的建议来自她自己的成长经历。
她认为成长型思维是应对变化最重要的心态，即要始终保持学习、始终愿意质疑「过去让你成功的方式，未必还能让你继续成功；而这个道理早在 AI 工具普及之前就已经被她验证过，尤其是在从微软转到 Meta 的头一年里体会最深。
她也谈到「恐惧」本身。她认为恐惧是一种进化本能，本无可厚非，但面对它的方式很关键：与其把自己代入「一切都在发生在我身上、我无能为力」的叙事，不如去问「这件事在我能控制的范围内，有哪些是我可以做的？
她分享了自己十几岁时的一段往事：她当年并未选择走计算机科学的路，而是一心想成为一名视觉艺术家。
她的第一台能接触到的电脑，是高中九年级时学校的打字课教室里的。为了补齐申请工程学院所需的理科课程，她拼命恶补，却又一度陷入「负担不起学费」的恐惧；直到高中里贴出一张国家银行招聘暑期柜员的传单，她抓住了这条「生命线」，靠着这份最低工资的兼职一路打工攒钱、支付学费，甚至在互联网泡沫破裂、企业普遍冻结实习招聘的那两年里，持续做了两年银行柜员。
她说，这是她当年在恐惧面前唯一能采取的、真正在自己掌控范围内的行动。
她还提到自己很喜欢的一句话：「你不敢去的那个山洞里，藏着你正在寻找的宝藏」，并把它和「做一些让自己感到害怕的事」联系在一起：当一个人在某个领域已经足够娴熟、达到某种效率巅峰时，恰恰是靠着去做那些让自己害怕的事情，才能继续成长。
用产品本身校准自己：Dogfooding 的分量
贯穿整场访谈，Dogfooding（尝自己的狗粮）几乎是 Fiona Fung 被身边同事提及最多的一个特质。
她解释，这是她保持对产品「脉搏」敏感度的方式：任何产品的诞生，背后都承载着一个「让某种体验变得更好」的愿景，而只有持续使用产品本身，才能真正贴近这个愿景是否被兑现。
她举了两个颇为生动的例子。她早已离开 Facebook Marketplace 团队多年后，有一次想卖掉自己的一台 MacBook Air，结果商品刚一挂出，就有人试图用一种她此前完全没识别过的新型骗术对她下手。这次经历让她再次印证「用户总会以意想不到的方式使用产品」这一规律。
另一个例子发生在她支持 VR 和 AR 团队期间：不知为何，她自己设置 VR 设备的方式总能复现出一类奇怪的「地板高度」问题，这个「意外的复现环境」反倒帮团队定位到了一个真实存在的 bug。
她的结论很朴素：不要把自己局限在指标仪表盘和演示文稿里。那些具体的、一个个「意外发现」的故事，往往比冷冰冰的数据更能告诉你产品到底出了什么问题、又该往哪里改进。
她也提到，这几乎是她加入过的每一个团队里都会被反馈的一个特质。无论是 VR、智能眼镜，还是 Instagram，新同事总会跟她说，很欣慰看到一位领导者真的在用自己团队做出来的东西，并且愿意给出真实的用户反馈。对她而言，这不只是一种工作习惯，更是领导者亲身体验团队所做工作的一种方式。
从 IBM 的 Vim 终端，到 Visual Studio 的第一次 IDE 体验，再到如今在 Anthropic 管理着一支人均代码产出 8 倍增长的团队，Fiona Fung 二十五年的工程师生涯，恰好跨越了软件行业几次最重要的范式转移。
但她在这场访谈里反复回到的，并不是工具本身有多强大，而是一系列更朴素的问题：当编码不再稀缺，什么才是真正稀缺的东西？答案或许是清晰的判断力、对产品真实的体感、愿意为结果负责的自主性，以及在快速变化面前持续学习的心态。这些恰恰是任何一次技术跃迁都不会替代掉的能力。
正如她所说，恐惧本身无可厚非，重要的是永远记得去问自己：「在我能控制的范围内，我可以做点什么？」
热门跟贴