这是我对 Lenny Rachitsky 与 Cat Wu 对谈的主题整理和个人理解，不是逐字稿。Cat Wu 在 Anthropic 负责 Claude Code 与 Cowork 的产品工作。
原始访谈：How Anthropic’s product team moves faster than anyone else（2026-04-23）。
工程变快之后，PM 的价值去了哪里
AI 让原型、代码和交付速度显著提高，但这并没有让产品工作消失。当“怎么做”越来越便宜，“为什么做”、“为谁做”和“现在应该做什么”反而更重要。
优秀 PM 的重心会继续向产品判断、长期方向和跨职能协同偏移。不是跟在工程师后面管进度，而是帮团队更快地选对问题、消除发布障碍，并对最终体验负责。
先构建“现在还不完全成立”的产品
访谈中一个很有价值的观点是：不要等到模型具备所有能力才开始做产品。先搭建原型，让它在真实任务里失败，才能知道究竟是模型能力、产品交互，还是验证机制在阻碍它。
当新模型跨过能力门槛时，已经理解问题边界的团队，可以快速判断哪些临时脚手架应该移除，哪些新体验终于可以成立。
速度不是催促，而是减少阻力
快速发布不应依靠长期加班，更可持续的方式是缩短反馈链路：让提出想法的人有能力做出原型，让决策者及时看到真实效果，让一个小改动不需要经过过多的流程和交接。
“Just do things” 在这里不是鼓励鲁莽，而是提醒自己：理解约束之后，尽快做一个可验证的行动，再从错误中更新判断。
评估 AI 产品：从“感觉不错”到可复现
AI 产品最有用的反馈，往往不是一句“效果不好”，而是一个可以重现的任务：用户给了什么上下文，期望什么，模型在哪一步偏离，什么结果才算成功。
对 PM 来说，这意味着需要会设计评估、理解边缘案例，也要亲自长期使用产品。数据可以告诉我们哪里出了问题，但很多细微的交互别扭，只有在反复使用时才能感受到。
我留下的行动清单
- 找出每周重复出现的低价值工作，逐个交给 AI，但不把 95% 的可靠性当作完成。
- 做真正会每天使用的工具，用高频使用暴露产品问题。
- 对每个 AI 功能先定义成功标准，再开始调整提示词或交互。
- 少追求工具的复杂定制，把时间放在真正要完成的任务上。
- 当交付速度提高时，主动把更多精力投入方向选择、产品品质和用户理解。