Cat Wu 和 Boris Cherny 搭档，把产品功能的交付周期从半年压到了一天。她面试了几百个 PM 候选人，发现大多数人还在用 6-12 个月路线图的思维——但 Anthropic 的节奏是一周甚至一天发布一个功能。这期播客最有价值的不是"怎么做快"，而是 Cat 对 PM 角色根本性变化的思考：当代码变得几乎免费，决定"写什么"和"为谁写"才是真正值钱的能力。
Boris 是 Claude Code 的创造者和技术负责人。Cat 用 "80% mind-meld" 形容他们的关系。Boris 擅长方向感——三个月后、六个月后产品应该长什么样，那个最 AGI pilled 的版本是什么。Cat 的角色是把愿景翻译成执行路径：从现在到那个愿景之间，每一步怎么走。
剩下的 20% 是各自特别在意的事情——谁更在意谁就推。这种模糊分工看起来不太正统，但正因为模糊，才能快。
Cat 面试了几百人，发现大多数人对 AI PM 角色的理解方向不对。
AI 出现之前技术变化很慢，PM 做 6-12 个月的规划，代码写起来很贵，核心工作是协调各团队的路线图。但现在模型能力快速提升，很多功能的交付时间从 6 个月变成 1 个月，有时候 1 周，甚至 1 天。PM 不应该花精力对齐多季度路线图，而应该想：怎么最快把东西推出去？
最好的 AI 产品 PM，能缩短从「有这个想法」到「产品到了用户手里」的时间，并且能定义出产品必须在哪些任务上开箱即用。
— Cat Wu
第一，设定清晰目标。大语言模型能力太通用，用户是谁、解决什么问题全都模糊。好的 PM 能把这些定死：核心用户是企业开发者，这个功能解决权限提示疲劳感。目标一旦清楚，就排除了大量方案。
第二，Research Preview 机制。几乎所有功能都先以研究预览形式发布——明确告诉用户这是早期产品、在收集反馈、可能不会永远支持。一两周就能出货。
第三，"evergreen launch room"。工程师觉得功能准备好了，发到这个频道里，文档和市场团队直接跳进来，第二天就完成对外宣传。搭建这套发布流水线，就是 PM 该干的事。
第一，每周做严格的 metrics readout，整个团队一起看数据，确保每个人都深度理解业务。
第二，维护一份 team principles——谁是核心用户、为什么是他们、愿意做什么取舍。让团队每个人能自己做决策，不等 PM 拍板。
PRD 对特别模糊的功能和需要大量基础设施的长期项目还是会写。但大部分功能不需要。
Cat 的回答很直接：他们已经快了好几个季度了，新模型不是核心原因。更大的原因是流程和团队期望——每个人都觉得自己有权力也有责任把想法在一周内变成现实。
2026 年 3 月底，Claude Code 完整源代码通过 npm 包泄露。原因是人为错误——有人用 Claude 写了一个关于包发布流程更新的 PR，经过两层审查但还是漏了。Cat 定性为流程失败，涉事员工仍在公司。
PM 写代码，工程师做产品决策，设计师提交 PR。Anthropic 选的路是大量招有产品品味的工程师——很多工程师能独立完成从看到 Twitter 反馈到周末发布的全流程，几乎不需要 PM 参与。
当代码变得越来越便宜，真正变得更有价值的是决定写什么。什么是正确的 UX？什么是让用户最愉悦的体验方式？
— Cat Wu
Product taste 仍然是一种非常稀缺的技能，任何能强有力地展示这种能力的人，我们基本都会录用。
— Cat Wu
每个人都能看到终极未来：模型极其聪明，一个输入框搞定一切。但为那个终极版本做产品太容易了。难的是搞清楚当前模型的能力边界在哪，怎么在边界内榨出最大价值。
做到恰好正确程度的 AGI 信仰非常难。太 AGI pilled 会让你忽略眼前用户的痛点，太保守又会在下一次模型升级时措手不及。
— Cat Wu
Cat 的做法：花 30% 时间故意把产品推到极限，搞清楚模型为什么在某些任务上犯错。培养方式：大量使用模型并让它自省、找到 5 个信任的 taste evaluator、写 10 个好 eval。
很多产品功能是模型的「拐杖」。早期 Claude Code 做大规模重构时会遗漏 call sites，团队加了 TODO list 强制模型逐一完成。Opus 4 之后模型自然使用 TODO list，不再需要提醒。每次新模型发布，团队通读整个 system prompt：「模型还需要这个提醒吗？」
我们做的很多修改，是删掉不再需要的功能。给产品加功能，本质上是给模型加拐杖。
— Cat Wu
更激进的策略：提前构建当前还不完全 work 的产品，等模型追上来。Code Review 试了好几代模型，直到 Opus 4.5/4.6 才达到可靠水平。
核心构建单元是单个任务的成功率。模型变强 → 单任务成功率上升 → 多任务并行 → 50-100 个 Agent 同时工作。这条路线从单兵作战走向 Agent 矩阵。
关键挑战：如何让用户知道哪些任务需要关注？如何确保 agent 自我验证？这已经不是本地机器能承载的了。
找到重复性工作交给 AI，但必须推到 100% 可靠。大多数人到 90-95% 就放弃了，而 95% 可靠的自动化你根本不敢依赖。
如果一个自动化不能 100% 可靠地工作，它就不是自动化。最后 5-10% 确实更费时间，但我鼓励大家投入精力去教会 Claude 你的偏好。
— Cat Wu
另一个反直觉建议：别做「设置狂魔」。有些人花太多时间添加 skills 和 MCP，反而忘了核心目标——发布产品。构建你每天真正使用的应用，不是一次性原型。
Just do things. 我觉得工作是假的。如果你理解约束条件，就能推导出该做什么，然后快速执行、从错误中学习。做错了就道歉、修正。
— Cat Wu
Cat 认为每个人都应该在某个时候加入初创公司——没有流程的环境会迫使你学会这种思维方式。
Cat 讲"一天出一个功能""让工程师自主发布"，但 Anthropic 是那家把"安全"写在名片上的公司。一周内两次信息外泄，Cat 的解释都是"人为失误，已加防护"。对速度文化本身是否加剧了这类风险，没有反思。
Cat 对封堵第三方工具的解释在经济逻辑上成立——$200/月的订阅用户通过 Agent 框架可能消耗数千美元算力。但 Anthropic 在自己的 Cowork 推出类似功能之后才封堵第三方通道。"先复制热门功能到封闭 harness，再把开源锁在门外"——这个批评没有正面回应。
Cat 给出的最高效模式是工程师端到端完成全流程，"几乎不需要 PM"。如果这是真的，PM 的价值在哪？她说 product taste，但始终停留在抽象层面。更深的悖论：如果模型足够强，一个文本框就够了，她所做的产品工作本质上是过渡性的。一个产品负责人承认自己的工作有保质期——这种坦率不常见。
📚 《How Asia Works》— 什么政策能造就持久的经济体
📚 《The Technology Trap》— 技术革命对工人的影响
🚗 最爱产品：Waymo — 每天坐两次通勤
🧗 AGI 之后的退休计划：搬到法国枫丹白露，每天攀岩