夜雨聆风
最 AI 化的产品团队,是怎么把软件做出来的
如果你想知道 AI 真正进入软件团队之后，公司内部会发生什么，这期 Lenny’s Podcast 很值得看。
嘉宾是 Fiona Fung。
她现在在 Anthropic 领导 Claude Code 和 Cowork 背后的团队。更早之前，她在微软做过 Visual Studio 和 TypeScript，在 Meta 从零开始做过 Facebook Marketplace，也参与过 Meta 智能眼镜和 AR 眼镜项目，在 Instagram 领导过基础设施、增长、诚信和安全团队。
她做工程和工程管理已经超过 25 年。
所以这期对话有意思的地方，不是又多了几个 AI 工具技巧，而是一个真正站在软件生产一线的人，在回答一个更底层的问题。
当代码不再是瓶颈，产品团队到底该怎么工作？
Lenny 在开头提到一个数字，Anthropic 工程师现在平均每个季度交付的代码量，是 2021 到 2025 年期间的 8 倍。
这个数字听起来很夸张，但 Fiona 的判断更重要。
她说，编码不再是瓶颈。
过去软件团队最稀缺的是工程时间。因为代码要人写，软件还要刻成 CD 发出去，所以计划、排期、取舍都围绕一个现实展开，工程资源太贵了。
但现在，Claude Code 和 Cowork 团队里，不只是工程师在提交代码，设计师、产品经理也开始提交代码。更多人能构建，更多功能能被快速做出来，吞吐量突然被拉高。
问题也随之改变。
以前的问题是，谁来写。
现在的问题是，谁来验证。
Fiona 回忆自己职业早期在 IBM 做 DB2 操作系统服务团队。那时她用 Vim，没有真正意义上的 IDE。后来到了微软，才第一次接触 Visual Studio。
她一开始甚至不知道 Visual Studio 是什么。因为她来自 Unix 环境，听到这个名字时，还以为是不是一个更好的绘图软件。
后来 Visual Studio 成了她职业生涯前 11 年最重要的产品。
也正是在那里，她第一次感受到工具对工程工作的巨大改变。IDE、断点、多线程调试，这些在当时都是阶跃式的变化。
但她也说，今天这轮变化更彻底。
以前 IDE 让工程师写得更好。今天 AI 让更多人都变成了 builder。
这也解释了为什么她现在管理团队的方式发生了变化。
她给 Claude Code 开了一个远程会话，让它接入所有代码库、Slack 频道和团队指标。每个月，她会和自己支持的人一起打开这个 Claude Code 会话，回顾过去一段时间。
不是只问这个人发了什么功能。
而是问，这些功能在市场上表现怎么样？用户反馈怎么样？有没有造成新的 bug？有没有从事故和问题里看到某些主题？
过去，这些工作需要大量人工整理。你要看 PR、看反馈、看指标、看事故复盘，然后才能拼出一个人或一个团队真实的输出图景。
现在 Claude 可以把这些线索放在一起，帮助管理者和团队成员展开更具体的对话。
这就从「管理交付」变成了「管理影响」。
Fiona 说，她经常提醒团队，犯错没关系，关键是不断犯新的错误。
如果目标是零错误，那可能意味着你行动太慢，或者太谨慎。
但高速行动的前提，是你必须有更强的验证系统。
在 Claude Code 团队里，反馈渠道非常重要。
Fiona 以前早上喝完咖啡，会自己去看反馈频道，看看用户在抱怨什么，看看有没有自己能帮忙的地方。
后来他们推出了 routines，也就是例程。
现在她可以设置一个例程，让 Claude 每天早上自动查看反馈渠道，总结用户反馈主题，甚至生成一些可供审核的 PR。
这件事听起来像自动化，但它实际改变的是管理节奏。
以前管理者先获得信息，再决定要不要推动修复。
现在，一部分信息整理和初步行动可以在你醒来之前发生。
代码审查也是一样。
Fiona 说，想想去年他们甚至还没有 Claude code review，这件事本身就很不可思议。以前真正的瓶颈是人工 reviewer，尤其是需要深厚专业知识的地方。
但 AI 审查不是简单地让 Claude 看代码。
关键是，你要把「什么是好」定义清楚。
她举了一个例子，如果团队有内容设计规范，有某些尺度和标准，就应该把这些规范放进代码仓库里，并且让规范和代码一起更新。
当「好」的定义被写下来，Claude code review 才能根据这些标准去验证。
Fiona 把这看成测试驱动开发的一个演进。
TDD 的原则很好，先写测试，确保测试失败，再写代码让测试通过。但很多工程师会觉得这像「先吃西兰花」，总有一点痛苦。
现在不同的是，你可以让 Claude 先帮你写测试，帮你构造失败用例，再一起修复。
很多过去正确但昂贵的工程原则，因为模型能承担更多执行成本，反而变得更容易落地。
Lenny 问她，现在该招聘什么样的人。
Fiona 的答案很清楚，主要是两类。
一类是有产品意识的创意型 builder。
这类人会对一个产品想法很兴奋，会自己动手做出来，会看反馈，会迭代，会在意体验是不是令人愉悦。
另一类是能处理复杂部分的资深系统专家。
因为模型已经很强，但很多地方仍然需要验证。越是底层、复杂、分布式、系统性的部分，越需要深厚专业知识。
她反复强调一个原则，信任，但要验证。
这也是 AI 原生团队的一个核心矛盾。
一方面，AI 拉高了每个人的能力上限。一个不是移动端专家的工程师，也可以和 Claude 合作，把功能扩展到移动端。
另一方面，能力上限被拉高之后，人更容易进入陌生领域。越是这样，越需要有人知道底层是什么，知道哪些东西不能只看表面结果。
所以 AI 时代不是不需要专家。
它更需要两种能力同时存在。
有人负责大胆建造，有人负责深度校验。
对很多团队来说，AI 最大的变化不是效率，而是野心。
Lenny 提到，他和一位 10X 工程师聊天，对方说以前听到一个功能想法时，第一反应可能是这个太难了、太复杂了。
现在他的反应变成了，这完全可以做，我让 Claude Code 来处理。
Fiona 很认同。
她说，这像是突破了任何人的能力上限。理论上，更多东西都变得可能。于是问题不再是你能不能写，而是你敢不敢想，你想把什么东西做出来。
但不是每个人都会自然适应。
她观察到，那些适应得最好的人，通常有很强的成长型思维。
成长型思维不是一句漂亮话，而是要承认一件很难受的事，过去让你成功的方法，可能不再适用。
这对很多资深的人尤其困难。
因为你会本能地想，我明明就是靠这套方法走到今天的，现在你要我改变它？
Fiona 说，很多挫败感背后其实是恐惧。面对让你害怕的东西，她的建议是靠近它，然后问自己，我能做什么？什么是在我控制之内的？
她讲了自己的一个故事。
她高中时原本想做视觉艺术家，后来喜欢上编程，是因为她发现编程也能把想法变成现实。但她担心自己负担不起工程学院学费。后来看到加拿大国家银行招聘高中实习柜员，她虽然最讨厌会计，还是去做了这个暑期和周末工作，靠它攒学费。
这件事给她留下的经验是，当你面对不确定和恐惧时，不要只停在情绪里，去找那个你能控制的小动作。
这套心法，也适用于今天很多人面对 AI 的焦虑。
Fiona 对小企业采用 AI 特别感兴趣。
她出生在香港，后来在加拿大长大。小时候，她和奶奶都不会说英语。奶奶搬来照顾她，在异国他乡很孤独。后来她们发现了一家会说粤语的小毛线店，奶奶在那里找到了自己的编织小组。
这让 Fiona 对小企业有一种很深的感情。
她说，小企业常常不只是卖东西，它们也创造社区。
后来她用 Cowork 处理自己的商务报销，发现自己讨厌的发票、票据、报销流程都被自动化了。她马上想到，那些小企业主朋友每天也在做这些没人喜欢的繁琐工作。
于是她开始帮朋友试用。
一个朋友经营两家餐厅，有一个像杂物抽屉一样的文件夹，里面什么文档都有。Claude 接入目录后，帮她找到了菜单。后来她又让 Claude 看自己餐厅的菜系和价格，比较本地人和游客是否都能接受，结果几乎像做了一次市场分析。
Fiona 从这些场景里看到一个问题。
如果只让已经懂 AI 的人越来越强，差距会越来越大。
她希望更多人能把自己身边的小企业、家人、朋友带进来，给他们看具体用例，而不是抽象地说 AI 很重要。
她说，AI 只是工具，也许是黑暗里的一束光。知识就是力量。如果我们不主动分享，差距会扩大。
Anthropic 怎么发现机会？
Fiona 没有神秘化这件事。她说自己不了解其他实验室怎么做，但在 Claude Code 团队，他们很关注 latent demand，也就是潜在需求。
比如，有很多不一定是程序员的人也在用 Claude Code。那团队就会问，能不能改善这些人的体验？
客户总会用你没想到的方式使用产品。好的产品团队要做的是持续观察反馈，发现那些正在涌现的用例，然后提出假设，把它做得更流畅。
这也是她反复强调 dogfooding 的原因。
她在 Visual Studio 团队时，用 VS 编辑器来开发 VS 编辑器，团队成员都是重度用户，所以反馈很快。后来做 Facebook Marketplace，她有一次在上面卖自己的 MacBook Air，刚挂上去就遇到诈骗，这让她发现了一种自己没意识到的用户风险。
她还讲到在智利调研 Facebook Marketplace 的经历。
当时 Marketplace 在拉美某个地区表现不好，他们做了很多分析。后来她带着几个人去智利，买了一批安卓手机，打开后发现当地 LTE 网络速度比美国慢很多，Marketplace 的信息流根本加载得不好。
数据能告诉你表现不好。
但只有真的走到用户环境里，你才知道为什么不好。
她引用了 Jeff Bezos 的一个观点，如果数据和轶事冲突，要相信轶事。
更准确地说，不是反数据，而是不要被仪表盘骗过。指标告诉你哪里有问题，具体的用户经历告诉你问题长什么样。
工程工作的下一个前沿是什么？
Fiona 认为是异步。
过去你同步地写 prompt，或者启动几个异步 agent。现在 routines 把抽象层又抬高了一层，你可以写一个例程，让它自动生成 prompt，自动启动不同 agent。
比如每天早上定时看反馈，如果发现 bug，就启动修复。你醒来之后，看到的是总结和一批等待审核的 PR。
这会带来新的管理方式。
管理者可以把自己每天、每周重复做的判断写成 routines，让 Claude 先做一轮检查。项目进展如何？哪些反馈集中出现？谁可能卡住？哪些问题可以先修？
但这里也有一个边界。
Fiona 说，高自主性必须配套高责任感。
Claude Code 和 Cowork 团队很重视 agency，也就是自主性。每个人看到问题，都可以提出解决方案，都可以动手。但同时你也要回答，你到底在解决什么问题？你的假设是什么？谁为结果负责？
这也是她对「刷 token」风潮的警惕。
一开始很多人会关注代码行数、PR 数、token 用量、工具使用量。但她提醒，如果你只衡量行动本身，很容易忘记真正的目标。
不要为了追求进展而放弃行动。
她更关心的是，我们到底想解决什么问题？什么指标能说明这个问题真的被解决了？
她举了 Facebook Marketplace 早期的例子。
当时他们按地区扩张，最初关注卖家数量。但后来发现，一个地区卖家数量不多，用户却能找到想要的东西。原因是那里有一些很强的卖家。
如果继续只看卖家数量，就会错过真正的产品目标。
所以指标也要不断被审视。过去合理的指标，在新的环境下可能会失效。
关于质量，Fiona 提了一个很实用的框架。
她把问题分成 bad 和 sad。
bad 是非常严重、不可恢复的错误。比如 CLI 崩溃，导致用户丢工作。
sad 是可恢复但令人沮丧的体验。比如屏幕闪烁，用户还能继续用，但感受很差。
这个区分看似简单，但对团队很有用。
因为当你面对很多不同产品界面时，单看性能、可靠性、加载时间这些仪表盘，很难判断一个数字到底意味着什么。团队需要一个体验框架，判断什么是不可接受的坏体验，什么是会不断累积、最终也可能变坏的沮丧体验。
在 AI 让代码速度暴涨之后，质量管理不能只靠更多人工 review。
更重要的是主动监控、测试、评估、反馈闭环。
团队要知道什么是成功，也要让 agent 能够自己发现并修复一部分问题。
他们甚至讨论过追踪用户爆粗口的情况。因为脏话本身可能是一种非常直接的用户挫败信号。
这听起来有点好笑，但背后仍然是同一个原则。
质量不只是正确性，也是体验。
Anthropic 还有一个很特别的管理原则，经理要先从 IC 做起。
Fiona 说，环境变化太快，以前有效的方法今天可能不适用，今天适用的方法明天也可能要变。
所以新经理加入时，不应该马上掏出一套「管理工具箱」，开始管理别人。更好的方式是先深入代码库、产品和团队实际工作，理解作为团队成员是什么感觉。
她自己从 Meta 到 Anthropic 时，也先做过短暂的 IC。
这不只是为了交几个 PR。
重点是让自己继续使用产品，继续理解产品。她说，如果领导者不是每天全身心投入产品，只看指标和仪表盘，就会慢慢失去对产品的感知。
Claude Code 也让很多做了多年管理的人重新有能力发布代码。
Fiona 说，她上一次在 Meta 发布生产软件大概是 2017 年。后来她已经很久没发代码了，因为担心自己搞砸，造成 bug，浪费别人的时间。
但在 Anthropic 的第一周，她开始用 Claude 了解代码库，问问题，让 Claude 帮她做自动化测试，也让它帮她设计手动测试方案。
这让她重新相信，自己可以再次发货。
不少当了很久经理的人也告诉她，多亏 Claude，他们又能写代码了。
但她也担心技能退化。
她认为，工程师仍然要理解架构和变更，仍然要往下双击自己依赖的那一层。也许有一天这不再重要，但在今天，理解底层仍然是验证的基础。
与此同时，团队也发现了另一个问题，和 agent 工作久了会变孤独。
所以 Claude Code 团队开始做结对编程午餐。大家坐在一起，各自用 Claude Code 工作，同时观察彼此的 flow。
每个人使用 Claude Code 的方式都不同，光是看别人怎么工作，就能学到很多。
AI 让一个人能做更多事，但团队仍然需要共同体感。
Lenny 问，在这个新世界里，什么东西正在消失？
Fiona 说，很多工程师怀念过去那种 flow。遇到难题，放一段音乐，沉进去，最后突然想通，代码终于跑起来。
这种乐趣现在少了一些。
新的乐趣更多来自产品本身，但难题的质感变了。
另一个变大的问题是上下文切换。
当你同时启动 20 个 agent，就会有源源不断的检查、审核和接续工作。你必须记住每个 agent 在做什么，自己当时为什么启动它。
有趣的是，AI 同时让上下文切换变容易，也让上下文切换变频繁。
容易是因为 agent 可以提醒你上下文，不需要你重新理解整个代码库。频繁是因为你能同时推动太多异步任务。
Fiona 说，她现在反而需要重新安排专注时间，用来追上自己启动的那些异步工作。
这可能是下一阶段 AI 工作流真正要解决的问题。
不是怎么让 agent 更多，而是怎么让人不被 agent 拖碎。
除了工程师，产品经理和数据科学也在发生变化。
Fiona 说，PM 不再只是有想法后等待工程资源。Claude Code 团队里的 PM 也会卷起袖子，直接改进一些功能。
工程师越来越有产品意识，PM 也越来越像 builder。
角色边界正在模糊。
数据科学也是类似。Lenny 提到一个数据科学朋友说，现在很多人用 AI 做出一些并不可靠的分析，再拿给数据科学家确认。于是数据科学家的工作变成了整天审核 AI 生成的数据分析。
这再次回到验证。
当更多非专业角色开始动手做专业工作，组织必须建立一种机制，让每个人都能对结果有足够信心。
Fiona 对未来仍有很多未解问题。
比如，还需不需要独立的 iOS 和 Android 组织？可能仍然需要专家，但不一定需要过去那种大型移动组织。
全自动 review 能走多远？这取决于我们能不能定义什么是「好」。
角色边界模糊后，如何确保不同背景的人同样高效？这仍然没有完全答案。
还有工程教育。
如果新一代工程师从一开始就不需要亲手写太多代码，他们还要不要理解内存、基础设施、架构这些底层知识？
Fiona 觉得也许软件工程会更接近研究员或学徒制。她不确定答案，但她在意一件事，怎样把上一代工程师积累的人生经验传给下一代 builder。
抽象层会继续上移。
从二进制到汇编，从高级语言到框架，现在也许到自然语言和 agent。但每次抽象上移，真正重要的能力也会变化。
下一代工程师要学的，可能不只是怎么写代码，而是怎么提出有价值的问题，怎么判断体验是否有效，怎么知道自己构建的东西不是一堆垃圾。
最后，Fiona 说，让她夜里睡不着的，不是具体产品问题，也不是工程问题，而是团队文化。
因为产品和工程问题还能看仪表盘，能做假设，能验证。
文化更像一个活的生命体。
它不是贴在墙上的海报，而是团队每天如何相处，如何支持彼此，如何讨论分歧，如何在临近终点线时回头看看别人需不需要帮助。
Claude Code 和 Cowork 团队正在高速增长。她担心的是，在增长中，团队是否还能保持健康、开放、诚实的辩论，是否还能承认哪里不顺。
她最害怕的场景是，问一个处在关键位置的人最近怎么样，对方说一切都好。
她说，那就像那个房间着火、猫还端着咖啡说一切都好的梗图。
这正是她的噩梦。
所以她要求团队，尤其是经理们，要经常坦诚地谈论正在发生什么，也谈论进展不顺的地方。
只有能说出问题，团队才有机会一起解决问题。
这期最后还有一个非常实用的建议。
Fiona 说，Claude Code 和 Cowork 团队文化里很重要的一点，是明确允许终止那些不再有用的流程。
她建议大家回头看自己团队里那些讨厌、繁琐、成本高、依赖人工的流程，先挑一个问，它今天还有存在的意义吗？
她自己刚加入 Claude Code 时，也想过做一个轻量级的六个月路线图。这个练习确实帮助团队对齐目标。
但三个月后她发现，变化太快了，大家几乎不再回头看那份计划。
于是她把规划方式改成 JIT planning，也就是即时规划。
现在他们尽量做一个月计划，而且非常轻量，甚至不是正式文档，只是一个小表格，列出下个月最重要的事。每周快速确认一次，这些优先级是否仍然成立。
他们每六个月仍然会聚在一起讨论大的主题，但具体项目保持短周期和高适应性。
这可能也是整期对话最值得带走的东西。
AI 原生团队不是把旧流程加速一遍。
它会逼你重新问，哪些流程还有效，哪些指标还有效，哪些角色边界还有效，哪些质量标准还有效，哪些管理动作还有效。
代码变快之后，真正稀缺的东西变了。
不是写代码的人。
而是能提出好问题的人，能定义好体验的人，能验证结果的人，能在混乱里保持学习的人，能在高速增长中守住文化的人。
这也是为什么 Fiona 反复说，不要只是追逐行动本身。
先问清楚，你到底想解决什么问题。
然后再让 AI 帮你把它做出来。