Anthropic 负责人：最 AI 化的产品团队如何工作丨Lenny's Podcast

用户4242

6月22日修改

🔗 原文链接： https://mp.weixin.qq.com/s?__biz=Mz...

原创 Capihom Capihom 晚点再听LaterCast2026年6月21日 23:10 北京

我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。 全文约 3900 字，如果你现在没有时间，试试转成播客稍后再听​

"编码已经不再是瓶颈，判断力才是。”

“最 AI 化的团队，拼的不是会不会用工具，而是谁更敢重新设计工作。” ​

“AI 把产能放大之后，人的主动性和验收能力变得更贵了。”​

Fiona Fung 现在带着 Anthropic 里 Claude Code 和 Cowork 背后的工程、产品团队，也就是 Boris Cherny 和 Cat Wu 所在的组织。她在微软做过 Visual Studio 和 TypeScript，在 Facebook 从零启动 Marketplace，后来又参与 Meta 智能眼镜、Orion AR 眼镜，并在 Instagram 带过基础设施、增长、诚信和安全团队。Lenny 找她来聊的，不只是一款编码工具有多快，而是一个已经被 AI 深度改造的产品团队，今天到底怎样做计划、招人、验收、协作和保持质量。​

这份履历让她的判断有分量。Fiona 见过从 Unix、Vim 到 IDE 的开发工具变化，也带过 500 人规模的 Meta 组织。如今她站在 Claude Code 和 Cowork 的一线，能同时看到工程师、PM、设计师、数据科学家和小企业用户怎么被 AI 改变。读这期对话，最有价值的地方不在工具清单，而在一支先进团队怎样把“能做更多”翻译成更可靠的组织习惯。​

代码暴涨 8 倍后，瓶颈换了地方

这期对话的起点，是 Anthropic 刚公布的一张图：工程师平均每个季度提交的代码量，已经达到 2021 到 2025 年基线的 8 倍。Fiona 的判断很直接，Claude Code 和 Cowork 把过去最稀缺的手工编码时间释放出来，团队不再围着“能不能写完”转，开始围着“该不该做、能不能验、上线后会发生什么”转。 当代码产能突然变得很便宜，产品团队的稀缺资源就从手速变成判断力和验证能力。​

"编码已经不再是瓶颈。"

她拿自己熟悉的软件工程历史作对照：早年做盒装软件时，计划周期长、改动成本高，工程师会把大量精力放在前期规划上。今天 Claude Code 团队面对的场景完全不同，代码可以迅速铺开，需求也可以更快试探。 团队的工作重心因此前移到假设和后移到验收，中间那段“写出来”的阻力被大幅削薄。 Fiona 说工程师不再只问“这个需求什么时候排得上”，还会问“有没有更大的解法”“这个假设能不能用更快的方式验证”。AI 把很多低层执行变成可并行的选项，团队反而更需要清楚选择哪一条线。​

产品经理和设计师也开始提交代码

Fiona 观察到的变化，不只发生在工程师身上。Claude Code 团队里，设计师、PM 也会 check in 代码。她提到一个移动端功能，当时团队需要补一个 Android 体验，负责的人并不是移动工程专家，却可以借助 Claude 完成过去需要跨团队排期的部分工作。工作边界变薄以后，跨职能成员能更快把想法落到真实界面里，后续再由工程体系保证质量。​

"不只是工程师，设计师和 PM 也在提交代码。"

这会带来一个新考题：更多人能产出代码，代码评审和验证就会变得更重要。Lenny 问到软件工程未来的管理方式，Fiona 的回答集中在“verification”。一支高产团队需要知道哪些检查必须自动化，哪些场景需要人工看，哪些质量信号能够提前暴露风险。 AI 没有取消工程纪律，它把工程纪律推到了更多角色面前。 她还把这条线延伸到数据科学和设计：当业务同学能先让 AI 做一份分析，数据科学家的角色会变成复核、纠偏和建立可信流程；当设计师能生成更接近可运行的界面，工程系统也要让他们安全落地。​

Lenny 还提到一个数据科学朋友的变化：同事会先把 AI 做出的分析拿来，请数据科学家确认是否正确。工作的入口从“帮我做分析”变成“帮我判断这份分析能不能信”。这类变化会出现在更多岗位里，PM、设计、数据、工程都要学会给 AI 产物设验收线。​

招人更看主动性和系统深度

当 Lenny 问什么样的人在 AI 原生团队里适应得最好，Fiona 没有先谈提示词技巧。她强调的是主动性、好奇心和学习速度。她从 IBM、微软、Meta 一路走到 Anthropic，亲身经历过从 Vim 到 IDE、从盒装软件到移动互联网、再到 agentic coding 的多轮变化。能继续往前走的人，往往愿意承认过去让自己成功的方法，到了新阶段可能要被重写。​

"表现最好的人，主动性最强。"

她还提到两类人会更突出：一类是有创造力、能快速把想法做出来的 builder；另一类是对复杂系统有深理解的人。AI 抬高了可执行范围，但系统设计、质量判断和长期维护仍要靠人的经验。 越是工具能写很多代码，团队越需要知道哪些代码会在真实系统里站得住。 Fiona 还把恐惧拆得很具体：有人会觉得变化发生在自己身上，所有东西都失控。她给出的动作是靠近它，问“我还能做什么”“什么在我控制范围内”。这个动作不靠口号推进，而是把焦虑拆成一次能开始的尝试。​

Cowork 来自非程序员的真实用法

Fiona 讲 Cowork 时，用了一个很产品经理的观察：团队一直盯着 latent demand。Claude Code 最初是给编码场景做的，但 Anthropic 发现很多不写代码的人也在借它处理工作。于是 Cowork 的方向逐渐清晰：把那批非程序员已经摸索出的真实用法，变成更顺手的产品体验。产品洞察来自用户绕开原本定位的行为：他们已经在拿 Claude Code 做知识工作，团队要做的是把那条小路铺平。​

"很多非程序员也在使用 Claude Code。"

她还举了小企业的例子。Fiona 很关心普通小店、社区型生意如何用 AI 改善日常工作，因为那里面有大量具体而琐碎的任务：看反馈、整理主题、生成计划、跟进顾客。她还提到一个朋友用 Claude 生成棚屋建造计划，拿给她看成果。 Cowork 的想象力不在“人人都要变成工程师”，它更像一套把重复劳动交给 agent、把注意力放回判断和关系的工作入口。​

Routine 把工作推进到异步模式

Fiona 说，自己过去每天早上会手动看反馈频道、整理主题、生成 prompts。Routines 出现后，她可以让系统持续观察一个反馈 channel，第二天醒来就看到总结，甚至让 agent 帮自己生成后续 prompt 和 PR。工作流从“我坐在电脑前发起一次任务”，变成“任务在后台持续推进，我回来接收结果”。​

这也是 Cowork 名字背后的含义：它不只是一个聊天窗口，而是能替人守住某条工作线。Fiona 说过去她会自己写 prompt、自己追反馈；现在 routine 可以先把材料准备好，等她回到电脑前，讨论已经有了初稿。管理者的早晨因此不再从翻信息开始，而是从审阅 agent 整理出的工作包开始。​

"我们正在更多转向异步。"

异步 agent 也带来新的负担。Fiona 提到上下文切换压力正在升高；Lenny 则形容，如果同时跑 20 个 agents，人需要不断检查、记住每条线在做什么。Fiona 自己也开始重新给日程留出 focus time，用来追上那些已经启动的异步工作。 AI 帮人开启更多任务，人也要重新设计接收、复盘和合并任务的时间。 她不把这看成单纯的个人效率技巧，而是产品体验的一部分：工具应该帮助用户降低切换负担，让人更容易知道每个 agent 到了哪一步。​

ROI 要从 token 狂欢回到产出

Lenny 提到最近的氛围变化：从“token maxing”，也就是尽量多用、先看看能做什么，转向追问花了多少钱、获得了什么。Fiona 承认工程生产力很难衡量。代码行数、提交量、处理速度都能看趋势，但一支 AI 原生团队不能只盯着更大的数字，还要问业务假设是否被验证、质量是否稳定、用户体验是否变好。​

"我们到底得到了什么？ROI 是多少？"

Anthropic 的特殊之处在于内部用自家模型和工具，token 成本的感受和普通公司不同。可 Fiona 依然把 ROI 当成团队讨论的一部分。原因很简单：即使成本暂时低，组织也需要知道新工作方式是否改善了结果。 花更多 token 不难，难的是把 token 变成更少返工、更快反馈、更高质量和更清晰的产品判断。 Boris 过去在 Meta 做过工程生产力相关工作，Lenny 也追问代码提交量之外还该看什么。Fiona 的回答更像一个组合：趋势数据要看，体验质量要看，团队是否更敢做大事也要看。​

这也给普通团队一个现实提醒：先别急着证明 AI 一定省多少钱，先挑一个能量化的流程，看从需求到上线、从反馈到修复的周期有没有缩短，再看质量和用户反馈是否同步改善。​

质量管理先分清 Bad 和 Sad

在质量管理上，Fiona 给团队引入了一个很轻的框架：Bad 和 Sad。Bad 是不可恢复的严重错误，Sad 是可恢复但让人痛苦的小挫折。单个 Sad 也许还能忍，很多 Sad 叠在一起，就会变成 Bad。这个框架适合多产品界面，因为单看加载时间、可靠性数字，很难判断用户真实感受已经坏到什么程度。​

"很多 Sad 叠起来，会走向 Bad。"

这套分法对 AI 产品尤其现实。Agent 可能完成了任务，却在权限、等待、解释、重试、上下文丢失上制造小摩擦。仪表盘会记录很多技术指标，用户记住的是一次次被打断。 高产团队不能只庆祝吞吐量，还要尽早发现那些会侵蚀信任的小失败。 Fiona 强调要更早发现质量信号，因为高吞吐会把缺陷放大得更快。一天内多出很多 PR，也会让小问题更容易成片扩散。​

团队文化要补上人的连接

Fiona 很清楚 AI 原生团队会失去一些旧体验。Claude Code 团队发现，大家越来越多和自己的 agent 一起工作，时间久了会有孤独感。于是他们最近开始办 pair-wise programming lunch，让人重新坐在一起写、看、讨论。AI 把个体能力放大以后，团队还要主动设计新的同步场景。​

"只和 agent 工作久了，会变得孤独。"

她对管理者也有很强的要求：在 Anthropic，所有 manager 都从 IC 开始。Fiona 会亲自 dogfood 产品，用自己的时间检查体验、做 polish、守住质量线。她还把半年路线图缩短成 JIT monthly planning，每周快速确认本月优先级是否还成立。 速度越快，管理者越不能只当流程主持人；他们必须下场使用产品，持续校准方向。 她甚至还在想怎么自动化那张月度优先级表，不希望更新表格变成团队税。计划本身也要接受 AI 原生团队的效率审视。​

半年路线图在她刚加入 Claude Code 时还像一个合理做法，三个月后团队已经很少回头看那份文档，因为市场、模型和用户行为都在快速变。JIT 月度计划更轻，团队每周只确认本月优先级是否仍然成立，再把注意力放回真实反馈。​

写在最后

Fiona 给焦虑者的建议很朴素：靠近它，然后问自己还能做什么，什么在自己控制范围内。AI 原生团队不会等每个人准备好才前进。先把一个真实任务交给 Claude Code，认真验收一次结果，再把流程里最耗人的一步自动化掉，改变就会从口号变成肌肉记忆。​

内容来源："Building the most AI-pilled engineering team in the world"丨Lenny's Podcast​

原视频：https://www.youtube.com/watch?v=Ybrl4FYM57c

Anthropic 负责人：最 AI 化的产品团队如何工作丨Lenny's Podcast​

Anthropic 负责人：最 AI 化的产品团队如何工作丨Lenny's Podcast