即刻App年轻人的同好社区
下载
推荐所有做产品的朋友都抽时间看一下 Claude Code 产品负责人 Cat Wu 的这次访谈。我还是非常有启发，毕竟，Claude Code 可能是今年最成功的 AI 产品之一。
访谈中，Cat Wu 分享了非常多我从没听过的产品认知，而且她还讲了 Anthropic 目前的产品发布流程，以及团队的结构。
一个感触是，我们确实应该主动求变。无论是团队的协同流程、结构，还是个人的工作习惯。
1
Cat 说，现在 Anthropic 的节奏，是把原来 6 个月的功能压缩到 1 个月，甚至 1 周、1 天上线。听起来确实很疯狂。
怎么做到的？可以从目标的定义、发布策略和流程说起。
他们对目标的定义非常清晰。Anthropic 的信条是，这个时代做一个谁都能用、但没人用得爽的功能，已经没有任何意义。
如果一个产品什么任务都能做一点，但每一个都做得很浅，那团队的方向就会特别模糊。方向一模糊，大家就得在十几个局部上分散精力，天天都觉得自己很忙，但每一件事都无法做精，做到极致。
Claude Code 团队的解法是把目标写的非常具体。比如，前段时间他们有个产品功能目标是这么写的：
帮助企业中的专业开发者减少权限弹窗，让他们在安全前提下尽可能做到零权限弹窗。
这里面每一个修饰词都在砍支路。用户不是所有人，是企业里的专业开发者。场景限定在保证安全的前提下。目标也不是减少一点。
能做的事情很多，要做的事情也很多。好 PM 最重要的能力之一，就是帮团队把目标定义到这种程度，一定要具体到一两类核心用户的几个典型任务，具体到一个可以被衡量的结果上。千万不要面面俱到。
目标定清楚之后，他们的第二个认知是要尽快把东西交到真实用户手里。
我们可以看到，Claude Code 几乎所有新功能一开始都以 Research Preview 形态上线，明确标注这是早期版本，随时会改，甚至可能下线。
这样做有两个好处。
一个是团队心理负担变小，不用一上来就搞得像 GA 那样一锤定音。另一个是可以在真实环境下快速收集反馈，再决定是做深还是砍掉。
大家想想，大公司里一个功能上线通常要开会、对齐、排期、做最终评审，摩擦力非常大。但 Claude Code 团队几乎把这些摩擦降到了零。大家可以快速从真实的用户那里收集反馈。
流程方面，他们也不是彻底放弃流程，而是保留了少数几个关键机制。
比如每周一起过指标，所有人都要对业务的关键数据、趋势和影响因素都有基本理解。再比如有一套团队原则文档，写清楚核心用户是谁、为什么是他们、愿意在什么地方做取舍。
2
Claude Code 团队还极度重视自动化。
他们的一个惯常思路是：盯住日常工作中每天都要重复做的事，选一件最烦的，用 AI 工具把它自动化到 100% 可以放心不管的程度。
关键词是 100%。
一个特别普遍的现象是，很多人把一个自动化做到 90% 或者 95% 成功率就停手了，觉得差不多够用。这根本不叫自动化，这叫半吊子工具。
为什么？因为剩下那 5% 的异常，反过来吃掉最多的注意力。
想象一个场景。搭了一个自动整理邮件的工作流，95% 的邮件能正确归类，5% 会分错。那 5% 会发生什么？每次打开邮箱都要把所有分类扫一眼确认没分错。哪怕只看一秒钟，这个动作已经占据了注意力。
结果就是理论上自动化了 95%，实际心力消耗可能只减少了 30%。花一堆时间搭的工作流，没真正解放出来。
那怎么做到 100%？Cat 有三条经验。
第一条，选对任务。
从每天真的在做、而且频率很高的事情下手，而不是那些听起来很酷、其实没那么刚需的活。
她自己试过用 Cowork 帮忙处理邮件，比如让 AI 帮她识别垃圾邮件、总结往来、生成回复草稿。结果搞了一阵发现，教模型怎么分类、怎么处理边界情况，比她自己点点归档还费时间，而且效果离完全不用管还差一截。
我知道，很多人经常被 X 上那些炫酷 workflow 带偏，去自动化一个月才做一两次的事情。即使你把这种自动化打磨到 100% 成功率，能省的时间也有限，还得多维护一个系统。
第二条，把整个工作都交给 AI，而不是让它只做某个局部。
举个例子，做大会的演讲 PPT。以前一份 20 页的演讲 PPT 手搓要花几个小时，AI 只能帮忙查一些资料。
但现在，她的做法是先把 Slack、Gmail、Calendar、Google Drive 全部接入 Cowork，然后把任务描述写清楚。
比如，这是演讲主题，这是产品营销同事的要点草稿，这是之前做过的一个不满意的旧版，这是公司的标准模板，请先给我一个大纲提案。
Cowork 花了大概一个小时，翻了 Twitter 上团队的产品发布记录，翻了 Claude Code 内部的 demo 频道，翻了发布间的公告，把一份 20 页的 PPT 搭了出来。第二天早上起床，只需要改风格、删字、选 demo。
她再三提醒，现在用 AI，关键点绝对不是某个酷炫的 Prompt，而是要给足上下文。
第三条，是别沉迷折腾工具本身。
现在大家很容易掉进一个坑。打开 X，一堆人在晒自己的 AI 工作流。屏幕上堆满了各种能力模块，接了一堆外部工具，配置看起来很复杂，像一个很厉害的系统。
但真正在用的人会发现，这种东西很容易变成另一个负担。
Cat 其实给了一个很简单的判断标准。
如果你做的这个东西，不能每天稳定帮你省下一点时间，那它就没什么价值。哪怕看起来再复杂，再高级，也只是个展示品。
真正有效的，反而是那种很朴素的东西。流程简单，能长期用，不需要频繁维护。可能没有那么炫，但每天都在帮你少做一小时重复工作。
3
PM 这个角色本身，正在被重新定义。Cat 观察到三个正在发生的现象：
第一个现象，角色边界在糊。
现象大致是这样的。PM 在做工程的事，工程师在做 PM 的事，设计师在做 PM 的同时还顺手写代码。
Claude Code 团队里几乎所有 PM 都当过工程师或者在产品里写过代码，设计师也全是前端工程师背景。一个工程师看到用户在 Twitter 上的反馈，一路自己改代码、写文案、交付，中间基本不经过 PM。
这跟很多大公司的情况完全相反。传统公司里角色分工很刚性，PM 写 PRD、工程师写代码、设计师画图，谁也别碰谁的地盘。Claude Code 团队反过来，大家都是混合体，没有明确的分工。
当然这种咬合在一起的状态能跑起来，前提是每个人都具备足够的产品品味。不然就变成一锅乱炖了。所以他们在招人时更在意的是：
1、你能不能端到端的把一个想法推到上线。
2、你有没有 Product Taste，而不是你曾经的职称是 Engineer / PM / Designer。
第二个现象，招聘逻辑跟着变了。
现在很多团队都会遇到一个选择。
是多招一些有产品感觉的工程师，让他们自己把很多 PM 的活一起做了，还是保持工程师规模不变，多招 PM，帮忙做筛选、对齐、推进。
表面上这是在调整团队结构，但本质上都是希望能够让团队中越来越多的人具备产品 Taste。因为真正决定效率和上限的，是这种能力的总量，而不是岗位比例。
Claude Code 走的是第一条路。
他们更偏好那种既能写代码，又能做产品判断的人。团队里的 PM 基本都有工程背景，设计师也能直接写前端。
这样一来，很多环节自然被压缩了。一个想法可以在一个人手里完成，从最初的构思，一路走到上线。中间少了大量沟通、对齐和反复确认的过程。
这也顺带解释了一个大家一直在问的问题。
PM 这个角色不会消失，但形态已经在变。单纯做协调、写文档、维护 roadmap 的空间在变小。更受欢迎的是那种有判断力、能动手、可以跨角色把事情推进到结果的人。
到了这个阶段，岗位名称本身已经不那么关键了。
第三个现象，人的软性能力越来越重要。因为 AI 越来越强，所以，大家不免说，那我们的价值是什么？Cat 的答案是：
1、理解真实世界里人和组织的关系网。谁是关键卡点、他们的偏好是什么、什么场合说什么话合适、哪些历史包袱不能碰。
这种社会智能、情境智能，目前的模型做不到。产品发布涉及的非结构化信息太多，这部分还是要人来做。沟通能力，以及让别人支持、信任我们的能力，会变得弥足珍贵。
2、承受和驾驭持续混沌。比如 Anthropic 很多时候的节奏是这样：周末冒出来一个 P0 的问题，然后周一上午升级成 P00，周一下午变 P000。这种环境里每个问题都焦虑就会崩溃。
Anthropic 特意招那种能在混乱里保持冷静和乐观的人，能看到问题的难度但不会被吓住，能接受暂时的粗糙。
3、看清什么事值得自己亲自做。任务爆炸的时候，残酷地优先级排序反而变得更值钱。承认自己做不了所有事，允许一些功能不够完美，只要不会伤到底层目标。
4
即便有些公司的招聘要求还很老套，但我也可以基本确定，他们已经不是一家 AI First 的公司。
在 Anthropic 看来，未来 PM 的核心技能有几个：
第一，学会看用户怎么滥用产品。
在任何一个 AI 产品里，都有一小批用户在做非常奇怪的事。写奇怪的 Prompt、拼脚本、绕开限制、把工具用出设计者没想到的花样。这些看起来是边角料的操作，其实是下一代功能最早的信号。
一个简单的例子。如果一部分用户一直在用复杂的 Prompt 让模型先列 To Do List 再逐条完成，这本身就说明他们需要一个原生的任务管理能力。
把它变成产品功能，用户就能得到更顺手的体验。不变，就只能一直看着用户在产品里打补丁。
最好的 PM 能从用户怎么在现有产品里打补丁里，看出下一代产品长什么样。
第二，学会把今天这个模型榨到极限。
Cat 特意说，这件事跟给超级 AGI 设计产品完全是两回事。给超级 AGI 设计产品非常简单。一个大输入框、什么都能干、模型自己判断、自己调用、自己完成。整个产品就是一个聊天窗。
难的是反过来。怎么用系统提示、工具设计、UI 引导，把用户行为限制在模型的优势区间里。怎么用流程、提示词、辅助工具（to-do list 就是一个典型例子）去弥补模型在记忆、坚持、验证上的弱点。
这件事的本质是知道模型哪强、哪弱，然后给用户铺一条路径。让用户在不知不觉中走到模型最擅长的地方去。
产品一旦能做到这一点，体验会立刻拉开和同行的差距。这也是为什么同样基于 Claude 的产品，有的跑得飞快，有的总显得笨笨的。差的不是模型，是有没有人在中间做这层铺垫。
第三，会和模型对话，不要只把它当黑盒。
大部分人用模型是这样的：给一个 Prompt，看一个结果，不满意就骂两句，或者改一改 Prompt 再试一次。这是把模型当成一个不会说话的黑盒。
Cat 的用法完全不一样。她会让模型自我反省。发现模型改了前端代码但没打开 UI 验证，她会让模型解释为什么没去点 UI。
是被系统提示误导了，还是 delegate 给 sub-agent 出了问题，然后反过来改 Harness（提示词、工具、工作流）。
这种对话的价值很大。因为模型其实能告诉 PM 哪里出了问题，只要 PM 肯问。大部分人之所以不会问，是因为从心态上就没把模型当成一个可以协作的对象。
把它当工具的人，永远在工具外面看。把它当协作者的人，能看到工具内部正在发生什么。
在新时代的 PM 工具箱里，和模型对话可能是最容易被忽视、但回报最高的一项技能。
第四，学会写 Eval。
Eval 听起来很工程师化，本质却很朴素：把一个模糊的目标变成一套可以自动化打分的测试。
好的 Eval 要能回答清楚三个问题：什么情况下算完成任务，差多少算不及格，新模型相比老模型到底好在哪里。
或者这么说吧，写 Eval 的真正意义，是在倒逼 PM 把产品目标想清楚。
因为一个写不出 Eval 的目标，大概率本身就是模糊的。
Cat 自己在某些不好衡量的功能上（比如 memory 那种没有明确对错的场景）会亲自下场设计 Eval，把产品目标直接写进自动化测试。
挺有启发的，大家可以去 Lenny 的频道找到这期播客。
访谈中，Cat Wu 分享了非常多我从没听过的产品认知，而且她还讲了 Anthropic 目前的产品发布流程，以及团队的结构。
一个感触是，我们确实应该主动求变。无论是团队的协同流程、结构，还是个人的工作习惯。
1
Cat 说，现在 Anthropic 的节奏，是把原来 6 个月的功能压缩到 1 个月，甚至 1 周、1 天上线。听起来确实很疯狂。
怎么做到的？可以从目标的定义、发布策略和流程说起。
他们对目标的定义非常清晰。Anthropic 的信条是，这个时代做一个谁都能用、但没人用得爽的功能，已经没有任何意义。
如果一个产品什么任务都能做一点，但每一个都做得很浅，那团队的方向就会特别模糊。方向一模糊，大家就得在十几个局部上分散精力，天天都觉得自己很忙，但每一件事都无法做精，做到极致。
Claude Code 团队的解法是把目标写的非常具体。比如，前段时间他们有个产品功能目标是这么写的：
帮助企业中的专业开发者减少权限弹窗，让他们在安全前提下尽可能做到零权限弹窗。
这里面每一个修饰词都在砍支路。用户不是所有人，是企业里的专业开发者。场景限定在保证安全的前提下。目标也不是减少一点。
能做的事情很多，要做的事情也很多。好 PM 最重要的能力之一，就是帮团队把目标定义到这种程度，一定要具体到一两类核心用户的几个典型任务，具体到一个可以被衡量的结果上。千万不要面面俱到。
目标定清楚之后，他们的第二个认知是要尽快把东西交到真实用户手里。
我们可以看到，Claude Code 几乎所有新功能一开始都以 Research Preview 形态上线，明确标注这是早期版本，随时会改，甚至可能下线。
这样做有两个好处。
一个是团队心理负担变小，不用一上来就搞得像 GA 那样一锤定音。另一个是可以在真实环境下快速收集反馈，再决定是做深还是砍掉。
大家想想，大公司里一个功能上线通常要开会、对齐、排期、做最终评审，摩擦力非常大。但 Claude Code 团队几乎把这些摩擦降到了零。大家可以快速从真实的用户那里收集反馈。
流程方面，他们也不是彻底放弃流程，而是保留了少数几个关键机制。
比如每周一起过指标，所有人都要对业务的关键数据、趋势和影响因素都有基本理解。再比如有一套团队原则文档，写清楚核心用户是谁、为什么是他们、愿意在什么地方做取舍。
2
Claude Code 团队还极度重视自动化。
他们的一个惯常思路是：盯住日常工作中每天都要重复做的事，选一件最烦的，用 AI 工具把它自动化到 100% 可以放心不管的程度。
关键词是 100%。
一个特别普遍的现象是，很多人把一个自动化做到 90% 或者 95% 成功率就停手了，觉得差不多够用。这根本不叫自动化，这叫半吊子工具。
为什么？因为剩下那 5% 的异常，反过来吃掉最多的注意力。
想象一个场景。搭了一个自动整理邮件的工作流，95% 的邮件能正确归类，5% 会分错。那 5% 会发生什么？每次打开邮箱都要把所有分类扫一眼确认没分错。哪怕只看一秒钟，这个动作已经占据了注意力。
结果就是理论上自动化了 95%，实际心力消耗可能只减少了 30%。花一堆时间搭的工作流，没真正解放出来。
那怎么做到 100%？Cat 有三条经验。
第一条，选对任务。
从每天真的在做、而且频率很高的事情下手，而不是那些听起来很酷、其实没那么刚需的活。
她自己试过用 Cowork 帮忙处理邮件，比如让 AI 帮她识别垃圾邮件、总结往来、生成回复草稿。结果搞了一阵发现，教模型怎么分类、怎么处理边界情况，比她自己点点归档还费时间，而且效果离完全不用管还差一截。
我知道，很多人经常被 X 上那些炫酷 workflow 带偏，去自动化一个月才做一两次的事情。即使你把这种自动化打磨到 100% 成功率，能省的时间也有限，还得多维护一个系统。
第二条，把整个工作都交给 AI，而不是让它只做某个局部。
举个例子，做大会的演讲 PPT。以前一份 20 页的演讲 PPT 手搓要花几个小时，AI 只能帮忙查一些资料。
但现在，她的做法是先把 Slack、Gmail、Calendar、Google Drive 全部接入 Cowork，然后把任务描述写清楚。
比如，这是演讲主题，这是产品营销同事的要点草稿，这是之前做过的一个不满意的旧版，这是公司的标准模板，请先给我一个大纲提案。
Cowork 花了大概一个小时，翻了 Twitter 上团队的产品发布记录，翻了 Claude Code 内部的 demo 频道，翻了发布间的公告，把一份 20 页的 PPT 搭了出来。第二天早上起床，只需要改风格、删字、选 demo。
她再三提醒，现在用 AI，关键点绝对不是某个酷炫的 Prompt，而是要给足上下文。
第三条，是别沉迷折腾工具本身。
现在大家很容易掉进一个坑。打开 X，一堆人在晒自己的 AI 工作流。屏幕上堆满了各种能力模块，接了一堆外部工具，配置看起来很复杂，像一个很厉害的系统。
但真正在用的人会发现，这种东西很容易变成另一个负担。
Cat 其实给了一个很简单的判断标准。
如果你做的这个东西，不能每天稳定帮你省下一点时间，那它就没什么价值。哪怕看起来再复杂，再高级，也只是个展示品。
真正有效的，反而是那种很朴素的东西。流程简单，能长期用，不需要频繁维护。可能没有那么炫，但每天都在帮你少做一小时重复工作。
3
PM 这个角色本身，正在被重新定义。Cat 观察到三个正在发生的现象：
第一个现象，角色边界在糊。
现象大致是这样的。PM 在做工程的事，工程师在做 PM 的事，设计师在做 PM 的同时还顺手写代码。
Claude Code 团队里几乎所有 PM 都当过工程师或者在产品里写过代码，设计师也全是前端工程师背景。一个工程师看到用户在 Twitter 上的反馈，一路自己改代码、写文案、交付，中间基本不经过 PM。
这跟很多大公司的情况完全相反。传统公司里角色分工很刚性，PM 写 PRD、工程师写代码、设计师画图，谁也别碰谁的地盘。Claude Code 团队反过来，大家都是混合体，没有明确的分工。
当然这种咬合在一起的状态能跑起来，前提是每个人都具备足够的产品品味。不然就变成一锅乱炖了。所以他们在招人时更在意的是：
1、你能不能端到端的把一个想法推到上线。
2、你有没有 Product Taste，而不是你曾经的职称是 Engineer / PM / Designer。
第二个现象，招聘逻辑跟着变了。
现在很多团队都会遇到一个选择。
是多招一些有产品感觉的工程师，让他们自己把很多 PM 的活一起做了，还是保持工程师规模不变，多招 PM，帮忙做筛选、对齐、推进。
表面上这是在调整团队结构，但本质上都是希望能够让团队中越来越多的人具备产品 Taste。因为真正决定效率和上限的，是这种能力的总量，而不是岗位比例。
Claude Code 走的是第一条路。
他们更偏好那种既能写代码，又能做产品判断的人。团队里的 PM 基本都有工程背景，设计师也能直接写前端。
这样一来，很多环节自然被压缩了。一个想法可以在一个人手里完成，从最初的构思，一路走到上线。中间少了大量沟通、对齐和反复确认的过程。
这也顺带解释了一个大家一直在问的问题。
PM 这个角色不会消失，但形态已经在变。单纯做协调、写文档、维护 roadmap 的空间在变小。更受欢迎的是那种有判断力、能动手、可以跨角色把事情推进到结果的人。
到了这个阶段，岗位名称本身已经不那么关键了。
第三个现象，人的软性能力越来越重要。因为 AI 越来越强，所以，大家不免说，那我们的价值是什么？Cat 的答案是：
1、理解真实世界里人和组织的关系网。谁是关键卡点、他们的偏好是什么、什么场合说什么话合适、哪些历史包袱不能碰。
这种社会智能、情境智能，目前的模型做不到。产品发布涉及的非结构化信息太多，这部分还是要人来做。沟通能力，以及让别人支持、信任我们的能力，会变得弥足珍贵。
2、承受和驾驭持续混沌。比如 Anthropic 很多时候的节奏是这样：周末冒出来一个 P0 的问题，然后周一上午升级成 P00，周一下午变 P000。这种环境里每个问题都焦虑就会崩溃。
Anthropic 特意招那种能在混乱里保持冷静和乐观的人，能看到问题的难度但不会被吓住，能接受暂时的粗糙。
3、看清什么事值得自己亲自做。任务爆炸的时候，残酷地优先级排序反而变得更值钱。承认自己做不了所有事，允许一些功能不够完美，只要不会伤到底层目标。
4
即便有些公司的招聘要求还很老套，但我也可以基本确定，他们已经不是一家 AI First 的公司。
在 Anthropic 看来，未来 PM 的核心技能有几个：
第一，学会看用户怎么滥用产品。
在任何一个 AI 产品里，都有一小批用户在做非常奇怪的事。写奇怪的 Prompt、拼脚本、绕开限制、把工具用出设计者没想到的花样。这些看起来是边角料的操作，其实是下一代功能最早的信号。
一个简单的例子。如果一部分用户一直在用复杂的 Prompt 让模型先列 To Do List 再逐条完成，这本身就说明他们需要一个原生的任务管理能力。
把它变成产品功能，用户就能得到更顺手的体验。不变，就只能一直看着用户在产品里打补丁。
最好的 PM 能从用户怎么在现有产品里打补丁里，看出下一代产品长什么样。
第二，学会把今天这个模型榨到极限。
Cat 特意说，这件事跟给超级 AGI 设计产品完全是两回事。给超级 AGI 设计产品非常简单。一个大输入框、什么都能干、模型自己判断、自己调用、自己完成。整个产品就是一个聊天窗。
难的是反过来。怎么用系统提示、工具设计、UI 引导，把用户行为限制在模型的优势区间里。怎么用流程、提示词、辅助工具（to-do list 就是一个典型例子）去弥补模型在记忆、坚持、验证上的弱点。
这件事的本质是知道模型哪强、哪弱，然后给用户铺一条路径。让用户在不知不觉中走到模型最擅长的地方去。
产品一旦能做到这一点，体验会立刻拉开和同行的差距。这也是为什么同样基于 Claude 的产品，有的跑得飞快，有的总显得笨笨的。差的不是模型，是有没有人在中间做这层铺垫。
第三，会和模型对话，不要只把它当黑盒。
大部分人用模型是这样的：给一个 Prompt，看一个结果，不满意就骂两句，或者改一改 Prompt 再试一次。这是把模型当成一个不会说话的黑盒。
Cat 的用法完全不一样。她会让模型自我反省。发现模型改了前端代码但没打开 UI 验证，她会让模型解释为什么没去点 UI。
是被系统提示误导了，还是 delegate 给 sub-agent 出了问题，然后反过来改 Harness（提示词、工具、工作流）。
这种对话的价值很大。因为模型其实能告诉 PM 哪里出了问题，只要 PM 肯问。大部分人之所以不会问，是因为从心态上就没把模型当成一个可以协作的对象。
把它当工具的人，永远在工具外面看。把它当协作者的人，能看到工具内部正在发生什么。
在新时代的 PM 工具箱里，和模型对话可能是最容易被忽视、但回报最高的一项技能。
第四，学会写 Eval。
Eval 听起来很工程师化，本质却很朴素：把一个模糊的目标变成一套可以自动化打分的测试。
好的 Eval 要能回答清楚三个问题：什么情况下算完成任务，差多少算不及格，新模型相比老模型到底好在哪里。
或者这么说吧，写 Eval 的真正意义，是在倒逼 PM 把产品目标想清楚。
因为一个写不出 Eval 的目标，大概率本身就是模糊的。
Cat 自己在某些不好衡量的功能上（比如 memory 那种没有明确对错的场景）会亲自下场设计 Eval，把产品目标直接写进自动化测试。
挺有启发的，大家可以去 Lenny 的频道找到这期播客。
165 13119
来自圈子
产品经理的日常
205616人已经加入