最近我收听了一期播客，主角是负责 Anthropic 旗下 Claude Code 和 Cowork 团队的 Fiona Fung。
当众人还在围绕「AI 到底能不能写代码」「是否会抢走工程师饭碗」争论不休时，她早已越过这个阶段，直接聊起了更核心的问题。
Fiona 拥有 25 年工程师经验，历经多次「天翻地覆」的转折；正因她挺过了前几波浪潮，她对这轮 AI 变革的洞察，与仅工作两年的新人相比，处于完全不同的维度。
由于原对话信息量大且跳跃性强，我做了归纳和重组；Fiona 一开场就抛出一个论断：编码本身已不再是限制因素。
她给出一个数据：
Anthropic 工程师的季度人均代码交付量，从 2021 年到 2025 年期间增长了 8 倍，图表曲线从平稳期陡然直线上扬。
代码激增只是表象，真正令她兴奋的是另一现象：提交代码的人群变了。
在 Claude Code 团队，设计师在 check in 代码，产品经理在 check in 代码，几乎每位成员都在进行代码提交。
过去，「写程序」是工程师的专属领域，如今它已演化为一种跨职能的基础技能，就和发送邮件一样日常。
Fiona 的原话：
核心问题转变为，瓶颈转移到了哪里？不仅更多人、更多元学科背景的人在提交代码，而且产出量极高。那我们如何验证？怎么确保这些高速生成的内容是准确的、品质过硬？
这是一种微妙的转向。
以往工程团队的掣肘，叫「工程带宽」；写代码成本高、时间稀缺，因此大家围绕这个限制做大量规划，只为将有限的工程资源用在刀刃上。
如今这个限制消融了。代码可以低廉、快速地自动生成。
但制约并未真的消失，只是挪了个地方，移到了验证、审核、质量保障等过去相对边缘的环节上。
拿她微软的经历一对比就特别通透：
Visual Studio 时代，软件刻录在 CD 上，截止日是铁定的：软件必须按时送去压盘、装盒、上架。工程时间极度昂贵，团队规划要缜密到分钟。
后来过渡到在线发布，交付模式变了一次。到今天，编码本身被 AI 大幅提效，又变了一次。
这三轮变化的模式如出一辙：旧瓶颈被打通，新瓶颈浮现。
Lenny 在对话中讲了个故事。他认识一位工程师，过去面对功能需求，本能反应是「太难、太复杂、干不了」。
现在他的态度彻底反转：这完全可以做，让 Claude Code 搞定就行。
Fiona 也举了个类似例子。她团队里一名工程师，原本不做移动端，一个功能需要扩展到移动端。过去这就搁浅了，因为他不精通 Android。如今有 Claude 作搭档，不熟悉的技术领域也能推进。
Fiona 说：这实质上拉高了每个人能成事的边界。
这话说得轻巧，指向却很深远。
过去束缚工程师产出的是技术复杂度：这东西你不会，就束手无策；现在束缚变了，变成你的判断力和志向。
按理说一大片区域都成了可行动范围，关键在于：
你选择做什么，你如何验证做得对；‘写多快’不再是问题；写得对不对，才是。
这就是 Fiona 观察到的全景：代码量爆炸、角色界限消融、能力天花板被抬高，三件事同步发生。
听起来全是利好，没错吧？
利好的背面是一连串新挑战：质量谁背书？AI 能帮你干任何事，你怎么知道它干对了？团队产出飙了 8 倍，过去那套管理套路、质量框架、规划节律还能否奏效？
Fiona 在 Anthropic 的日常，就是在解答这些疑问。
......
她做的首个变更是在所有仓库中部署了一个 Claude Code 远程会话。
该实例能访问团队的全部代码库、Slack 频道、指标看板；说白了，她获得了一种全局视野，随时能掌握每个人的进展和状态。
搁过去，她的早晨是这样度过的：
端杯咖啡，打开各种反馈渠道，逐条翻阅用户反馈和内部同事的意见。有空的话顺带处理几个事项。
现在整个流程被重构了。
大约一两个月前，Claude Code 推出了 Routines，她的工作流被彻底刷新。
Fiona 亲自描述：「以前我得自己写 prompt，现在有了 Routines，就像有个智能助手帮我生成 prompt，甚至直接生成 PR。
例如：我设定一个 Routine，让它每天清晨盯住反馈频道，自动提炼主题。等我醒来，一份反馈摘要已经生成，旁边还躺着几个待审的 PR。」
Lenny 追问她：那你作为管理者，过去看到问题会派人去修，现在是 Claude 已把修复方案做好，你只需审核是否合并？
Fiona 说没错，还不止；如果验证体系足够牢固，甚至可以给 Agent 更多自主权，让它直接操作执行。
你察觉到了吗，这里有一次微妙的角色演变。
曾经是你自己起草指令，坐等结果；后来变成你一次性发出多条指令，不用干等，回头一并收取。
现在更进一步：你设定一个固定流程，这个流程自己帮你写指令，再分派给不同的 AI 助手去干活；你的角色从「亲手操刀」，变成了「事后把关」，再往前走一步，就成了「构建系统的人」。
Fiona 也并不讳言：
以前她得专门腾出大块时间写代码，现在她得专门留出大块时间，去消化所有 AI 助手异步完成的工作。
说得直白点，过去脑子累在编码上，现在累在来回切换、逐一验收上，这是一种全新的上下文切换负担。
......
管理者的工作流被重塑了，效率拉满了；紧跟着一个问题就浮现了：东西是产出快了，质量谁兜底？
Fiona 在这块讲了几招，有的很硬，有的奇招迭出。
先说硬的，第一招，自动化代码审查。她说：回想一下，去年我们连 Claude Code 自动审代码的功能都还没有，过去，人类审查者是个巨大瓶颈。
当然，需要深领域知识的地方，还得靠人。许多可以固化为标准的检查项，现在完全交给 Claude 就行。
她的建议很具体：
如果你对「什么叫好」有明确定义，不管是设计规范、代码风格、还是架构原则，直接写下来，放进代码仓库，做成一个规则文件。
Claude 拿到清晰框架后，在按规矩做验证这件事上表现尤为出色。
但有一个前提：这个规范文档必须与代码同步迭代。写完就抛之脑后，那就是一份过期的废纸，比没有还糟糕。
第二招，测试驱动开发，俗称 TDD。简言之，先写测试用例、再写代码。先把你想达成的标准定好，再动手干活。
她在 Claude Code 上修复的第一个 bug，就让 AI 帮她走这套流程：先写测试，确保测试不通过，然后修复代码让测试通过。
她自己的原话：
TDD 在 2000 年代特别盛行，理论很扎实。但我当时有点抵触，感觉自己像被按着头先吃西兰花，而我只想做出产品、发布出去。
现在测试生成被自动化了，过去那些正确但让人提不起劲的做法，突然又焕发生机了。
这个比喻我中意；西兰花健康却不好吃，测试重要但写起来烦。现在 AI 帮你把西兰花嚼碎了，你只管享用成品。
第三招，是她自己琢磨出的一个判断框架，叫 Bad vs Sad。英文不必记，你理解内涵就行。
Bad，指那种不可逆的严重错误；比如：你正操作着，命令行直接崩溃，写的内容全丢了。这就是 Bad。
Sad，是有点糟心但你还能恢复的问题，如界面闪烁一下，有些烦，但没丢数据，继续干活无妨。
每个产品各异，每个团队得自行界定：在你这儿，什么算 Bad，什么算 Sad。
这里有个很关键的洞察：Sad 积攒多了，会质变成 Bad。
Fiona 说：过去我们有太多监控面板，很难退一步看大局；因此，与其紧盯着大量原始性能数据，不如先有一个判断框架，帮你辨别什么是真糟糕的体验、什么是不适但可容忍的。
确保你在解决真正的 Bad，同时紧盯 Sad 的趋势，别让它恶化。
最后一招有些另类；去年九月，团队一名工程师提议：我们应该追踪用户爆粗口的频率。
Fiona 说好主意。听起来很荒唐对吧？这个指标后来真成了团队监测用户情绪的一种方式。脏话频率上升了，说明产品在某个点让人抓狂。
它代替不了正经的性能指标，但提供了一个完全不同的视角：用户在用你产品的时候，是愉悦的，还是在骂骂咧咧？
质量框架有了，检测的手段也齐了；那谁来执行？什么样的人能在这种高速下存活，还活得风生水起？
......
Fiona 现在招募两类人。
第一类，她称之为 dreamers。即，有产品感知的创造型人才。
这种人脑中有了想法，自己就动手干起来，干完紧盯反馈，不好就调，一直打磨到体验过关为止；整个产品从构思到落地，她一个人从头扛到尾。
第二类，深度系统专家。
她刚加入 Claude Code 时发现，团队有很不错的通才产品人，却缺少一种人：真正精通底层系统和分布式架构的工程师；模型再强，很多地方还得靠人理解底层到底在运转什么，才能做出靠谱的判断。
光有人手还不够。她反复强调一个配对概念：高自主性，搭高担当感。
原词是 agency 和 accountability，你不必死记，记住意思就行：
团队里每个人都可以带着自己的想法去解决问题，这叫高自主性；但前提是你得回答两个问题：你要解决什么？你的假设是什么？你不能只有冲劲，却不给交代。
说白了，你可以放开手脚干，结果你必须认。
然后她有一项做法，我觉得挺硬核的：所有新来的管理者，必须先回归一线写代码，扎进代码库里，至少一个季度，为的是让你保持对产品的手感。
她的逻辑很简单：
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 引了一句话：你最怕进的那个洞穴里，就藏着你一直在找的宝藏；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
