关于验证、质量、团队、规划和工程师孤独感今天听了个播客嘉宾是 Anthropic Claude Code 和 Cowork 团队的负责人 Fiona Fung。大部分人还在吵「AI 到底能不能写代码」「会不会取代工程师」这位大姐直接跳过这个问题讲的是这事之后的事。Fiona 做了 25 年工程师经历了好几轮「一切都变了」的时刻正因为在前面几轮活下来了她对这波 AI 的判断跟刚入行两年的小朋友完全是两个维度。因为内容很长也比较跳跃所以我理解后做了重新的组织播客里她上来就给了一个观点敲代码不再是瓶颈了。一个数据Anthropic 工程师平均每个季度交付的代码量是 2021 到 2025 年间的 8 倍图表走势是稳定、稳定、稳定然后一根直线往上冲。代码暴增只是表面真正让她觉得有意思的是另一件事提交代码的人变了。在 Claude Code 团队设计师在提交代码产品经理在提交代码几乎所有人都在 check in code。搁以前「写代码」是工程师的专属动作现在它变成了一种跨角色的基础能力跟发邮件一样稀松平常。Fiona 的原话问题变成了瓶颈转移到了哪里不仅更多人在提交代码而且来自不同学科吞吐量变得非常高。那我们怎么做验证怎么确认这些高速生成的东西是对的、质量是过关的这是一个很微妙的转向。过去工程团队的核心约束叫「工程带宽」写代码是贵的时间是稀缺的所以大家围着这个约束做大量规划保证有限的工程资源花在最值得的地方。现在这个约束消失了。代码可以很便宜、很快被生成出来。可约束没有真的消失它只是换了个位置它转移到了验证、审查、质量保障这些过去相对次要的环节上。拿她微软的经历一比就特别清楚Visual Studio 时代软件刻在 CD 上截止日是真正不可推迟的软件必须送去压盘、装盒、上架。工程时间极其金贵团队规划要做到极致。后来在线发布交付方式变了一次。到今天编码本身被 AI 大幅加速又变了一次。这三轮的模式其实一模一样旧的瓶颈被打穿新的瓶颈浮出水面。Lenny 在对话里讲了一个故事。他认识一个工程师过去听到功能需求第一反应是「太难了太复杂了做不了」。现在他的反应完全变了这完全可以做让 Claude Code 搞就行了。Fiona 也讲了一个类似的。她团队有个工程师本来不做移动端一个功能需要扩展到移动端。搁以前这事就卡住了因为他不是 Android 专家。现在有 Claude 做搭档不熟的技术领域也能推进。Fiona 说这确实抬高了每个人能做事情的上限。这句话很轻指向的东西很大。过去限制一个工程师产出的是技术复杂度这个东西你不会你就做不了现在限制产出的东西变了变成了你的判断力和雄心。理论上一大堆事都能做了关键是你选做什么你怎么验证做对了「写多快」不再是问题写得对不对才是。这就是 Fiona 看到的全貌代码量爆炸、角色边界模糊、能力上限被拉高三件事同时发生。听起来全是好消息对吧好消息的背面是一堆新问题质量谁来兜底AI 能帮你做任何事你怎么知道它做对了团队产出速度涨了 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 拿到明确的框架之后按规矩做验证这件事上表现特别好。只有一个前提这个规范文档得跟代码同步更新。写完扔一边不管那就是一份过期的废纸比没有还糟糕。第二招测试驱动开发圈内叫 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她说自己像一个编译器在生成可执行文件。原文链接分享一场Claude Code负责人的对话-36氪
分享一场Claude Code负责人的对话
关于验证、质量、团队、规划和工程师孤独感今天听了个播客嘉宾是 Anthropic Claude Code 和 Cowork 团队的负责人 Fiona Fung。大部分人还在吵「AI 到底能不能写代码」「会不会取代工程师」这位大姐直接跳过这个问题讲的是这事之后的事。Fiona 做了 25 年工程师经历了好几轮「一切都变了」的时刻正因为在前面几轮活下来了她对这波 AI 的判断跟刚入行两年的小朋友完全是两个维度。因为内容很长也比较跳跃所以我理解后做了重新的组织播客里她上来就给了一个观点敲代码不再是瓶颈了。一个数据Anthropic 工程师平均每个季度交付的代码量是 2021 到 2025 年间的 8 倍图表走势是稳定、稳定、稳定然后一根直线往上冲。代码暴增只是表面真正让她觉得有意思的是另一件事提交代码的人变了。在 Claude Code 团队设计师在提交代码产品经理在提交代码几乎所有人都在 check in code。搁以前「写代码」是工程师的专属动作现在它变成了一种跨角色的基础能力跟发邮件一样稀松平常。Fiona 的原话问题变成了瓶颈转移到了哪里不仅更多人在提交代码而且来自不同学科吞吐量变得非常高。那我们怎么做验证怎么确认这些高速生成的东西是对的、质量是过关的这是一个很微妙的转向。过去工程团队的核心约束叫「工程带宽」写代码是贵的时间是稀缺的所以大家围着这个约束做大量规划保证有限的工程资源花在最值得的地方。现在这个约束消失了。代码可以很便宜、很快被生成出来。可约束没有真的消失它只是换了个位置它转移到了验证、审查、质量保障这些过去相对次要的环节上。拿她微软的经历一比就特别清楚Visual Studio 时代软件刻在 CD 上截止日是真正不可推迟的软件必须送去压盘、装盒、上架。工程时间极其金贵团队规划要做到极致。后来在线发布交付方式变了一次。到今天编码本身被 AI 大幅加速又变了一次。这三轮的模式其实一模一样旧的瓶颈被打穿新的瓶颈浮出水面。Lenny 在对话里讲了一个故事。他认识一个工程师过去听到功能需求第一反应是「太难了太复杂了做不了」。现在他的反应完全变了这完全可以做让 Claude Code 搞就行了。Fiona 也讲了一个类似的。她团队有个工程师本来不做移动端一个功能需要扩展到移动端。搁以前这事就卡住了因为他不是 Android 专家。现在有 Claude 做搭档不熟的技术领域也能推进。Fiona 说这确实抬高了每个人能做事情的上限。这句话很轻指向的东西很大。过去限制一个工程师产出的是技术复杂度这个东西你不会你就做不了现在限制产出的东西变了变成了你的判断力和雄心。理论上一大堆事都能做了关键是你选做什么你怎么验证做对了「写多快」不再是问题写得对不对才是。这就是 Fiona 看到的全貌代码量爆炸、角色边界模糊、能力上限被拉高三件事同时发生。听起来全是好消息对吧好消息的背面是一堆新问题质量谁来兜底AI 能帮你做任何事你怎么知道它做对了团队产出速度涨了 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 拿到明确的框架之后按规矩做验证这件事上表现特别好。只有一个前提这个规范文档得跟代码同步更新。写完扔一边不管那就是一份过期的废纸比没有还糟糕。第二招测试驱动开发圈内叫 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她说自己像一个编译器在生成可执行文件。原文链接分享一场Claude Code负责人的对话-36氪
