Claude Code的产品经理，把她用AI重构工作流的方式全说了！
上周，Claude Code 的产品经理 Cat Wu 在 X 上罕见地摊了一次牌，详细拆解了 AI 究竟怎样重塑了她的日常工作流。这事儿挺有意思，信息量大，值得所有产品经理、甚至整个科技行业从业者好好琢磨一下。
她从自己的一个小实验讲起，挺有画面感的。
从 2024 年 10 月 Claude Sonnet 3.5 那会儿开始，Cat Wu 就养成了一个习惯：每次有新模型发布，她就让 Claude Code 去做同一件事——给一个叫 Excalidraw 的白板工具添加表格功能。起初，一次次尝试，一次次失败。一直到 2025 年 6 月 Opus 4 发布，Claude 才开始偶尔能勉勉强强成功。转折点来得很快，在 Opus 4.6 推出后，它已经能在数千名专业开发者面前，现场直播完成这个任务，而且几乎是一锤定音。
这个实验背后折射出的，是整个 AI 能力底层逻辑的指数级升级，而这种升级正在重新定义产品经理手里的每一个动作。
一、从工程师到 PM：一条独特的 AI 工具使用路径
Cat Wu 的背景比较特别，她本身是工程师出身，后来转去做 VC。但即便在投资人岗位上，她也停不下来编码的习惯——她会写脚本去扫 Twitter 找新公司，或者盯 GitHub 上哪些开源项目的热度突然飙升。说白了，她的骨子里还带着工程师的那股“动手解决一切”的劲儿。
2024年8月，她加入 Anthropic 担任研究型产品经理（Research PM），主要职责就是连接研究团队和真实用户，帮模型变得更好使。秋天的时候，Claude Code 开始内测，她就拿它来干各种“脏活累活”：用 Streamlit 搭应用分析用户反馈、跑评估测试模型能力，甚至自己搭强化学习环境来研究训练过程。这些项目加在一起，拢共几百小时的工作量，她愣是一行代码都没亲手写。全程都是靠跟 Claude Code 对话完成的。
这个经历让她产生了一个强烈的顿悟：在过去，一个 PM 脑子里冒出个想法，得先说服工程师排期，然后苦等两个星期，才能看到第一个粗糙的原型。可现在呢？下午她自己就能直接把它实现出来。想法到执行的壁垒，实际上已经被彻底打破了。
二、三个工具的分工协作：日常高效工作流
慢慢地，Cat Wu 摸索出了一套属于自己的工具使用系统。她发现核心不是琢磨“这是什么类型的任务”，而是要问自己“我要什么样的输出结果”。以下是她明确的三大分工：
- 例如写策略文档时思路卡壳，或者遇到棘手问题不知从何下手，就去跟 Claude 聊一聊。这种场景下是单纯的对话交流，不需要 AI 真正动手去做什么。
Claude.ai：想事情的时候用。
- 需要一个能跑的原型？用它。需要写一个脚本跑数据？也用它。只要你最终的输出是代码，就尽管扔给 Claude Code。
Claude Code：要做东西的时候用。
- 清邮件、管待办事项、做 PPT、翻 Slack 聊天记录回看当时某个决策的原因，甚至订机票酒店——这些通通交给 Cowork 来处理。
Cowork：处理琐碎杂务的时候用。
这套工作流并不是她个人独享的秘籍。Decagon 的产品总监 Bihan Jiang 也有类似的体验：“以前做一个能拿出来演示的东西，要几周时间，现在几小时就搞定了。我有一个习惯，在 Cowork 里把 Slack 聊天记录、代码库、文档都喂进去，等到它充分理解了背景，再切到 Claude Code，下午就能拿一个可以给用户看的版本出来。”
Datadog 的高级产品经理 Kai Xin Tai 也有同感，他觉得现在的产品管理有点像在做实验：“每一次新模型发布，我们不是被动接受，而是立刻测试它在哪些方面变强了、哪些地方还是短板，再快速调整产品方向。以前是‘先想清楚再干’，现在成了‘一边干一边发现’。”
三、AI时代 PM的工作方式：四个关键转变
Claude Code 的团队为了跟上模型自身快速进化的节奏，已经让各个角色之间的边界变得相当模糊。现在团队里，设计师可以写代码并发布功能，工程师可以参与产品决策，而产品经理则可以自己构建原型和跑评估。这种高效运转能成立的前提，是团队对战略目标有极其清晰的共识和优先级排序。那么，在这个背景下的 PM，到底在忙什么？核心是三项：
在快速变化中创造清晰度，推动团队思考更大的可能性，扫除一切阻挡发布的障碍。
转变 1：从长期路线图转到短周期实验
过去，一个 PM 的工作节奏通常是这样的：花两周时间调研、写一份 PRD、然后开评审会、将任务排进路线图，最后等着工程师去实现。整个流程跑下来，两三个月算短的。
但现在 Claude Code 团队的做法完全不同：他们鼓励所有人，包括工程师、PM、设计师，随时去做“side quest”。什么意思呢？就是如果你有了个想法，不要急着开会讨论，而是利用一个下午的时间自己动手试一下。你不妨去测测那个你认为“AI 肯定做不到”的功能，或者故意给模型出一些难题，看看它的能力到底到了哪一步。
Anthropic 目前几个最受欢迎、最具影响力的功能——比如桌面版 Claude Code、AskUserQuestion 工具、以及 todo lists——都不是在大会议室里规划出来的。它们全是靠这种“边做边玩”的方式偶然长出来的。
转变 2：从文档优先转到 Demo 优先
团队现在基本取消了传统的站会制度，取而代之的是“Demo 分享会”。谁有了新想法，就立刻做一个能跑的原型出来，直接让内部用户试用。如果大家真的在用，那就进一步打磨；要是没人理，那就算了。反正一个下午就能做出来，试错成本低到几乎可以忽略不计。
举一个实际案例：一位叫 Noah 的成员想做一个 plugins 功能，他没有先花大把时间打磨文档，而是写了一份规范，直接扔给了 Claude Code。Claude Code 返回的原型已经八九不离十了，团队拿着这个原型快速验证了用户体验，然后就直接基于它做出了最终版本。
Cat Wu 的建议很直接
转变 3：每次新模型发布后，把老功能重新审视一遍
这是一个非常有意思的现象：你上个月才发布的一个功能，这个月新模型一更新，它的能力突然就上了一个大台阶。所以，每一次模型迭代都值得把你已有功能全部重新过一遍底。
怎么才能发现这些深藏不露的机会？关键是要做一个重度用户，并时不时去“为难”一下 AI。让它做那些你觉得它“应该做不到”的事，有时候它真的就做到了。这个瞬间，就是产品设计应该跟进的信号。
Chrome 集成功能就是这么来的。团队发现，用户一边在用 Claude Code 开发 web 应用，一边还要手动切到浏览器里的 Claude 去测试，两边来回复制粘贴指令。这个过程虽然很麻烦，但用户确实在这么做。团队意识到：“用户已经自己拼凑出解决方案了，我们为什么不直接把这个做成产品功能？”
说到这里，Cat Wu 还特别提醒了一件事：在做这种新功能的时候，别一开始就想着怎么节省 token 成本。策略应该是先用足够多的 token 把能力做出来，先确认这个功能是可行的。等着后面更便宜的模型上场了，成本问题自然就迎刃而解了。
转变 4：保持简单实现，避免过度工程
Anthropic 内部有一个团队信条：
做有效的简单方案
有这么一个真实案例：Claude Code 刚推出 todo list 功能时，使用的是老版本模型。那个版本经常忘记勾选已完成的任务。因此，团队不得不加了一个“自动提醒”机制，每隔几条对话就提醒一下 AI：“别忘了更新 todo list 哦”。这招确实管用，但说白了，就是一个为弥补模型不足而打的补丁。
后来，新模型 Opus 4.6 发布了，它自己已经知道任务做完要打勾，根本不需要提醒了。团队二话不说，直接把那个提醒功能删了。类似的案例在不断上演：过去为了弥补模型能力不足，系统提示词和工具说明写得极其复杂。现在每一次新模型发布，这些“拐杖”就会扔掉一批。Opus 4.6 上线时，团队一次就删掉了 20% 的系统提示词。
四、最难的转变：PM 要学会“放手”
很多产品经理习惯了掌控产品的每一个细节，但这套逻辑在 AI 时代行不通了。Cat Wu 明确指出，用 AI 做产品，你必须学会“放手”。
她打了一个非常精彩的比方：“这就像冲浪，最重要的不是去控制浪，而是始终保持自己在浪头上。”对于一个完美主义者来说，这可能是最难适应的一点。但她发现，现在 PM 真正要做的工作是：
找出那少数几个绝对不能妥协的核心原则，对于其他大部分内容，快速迭代就好。
咱们做一个简单的对比就知道变化有多大：过去，一个 PM 从脑子里有想法，到真正拿出一个可用的原型，中间相隔好几周。现在，仅仅是一个下午就能搞出来。那句“要不我们试试……”和“来，试试这个东西……”之间，几乎没有了时间差。
写在最后：不只是PM，整个公司都在变快
在 Anthropic，不只是产品团队在用 AI 重构工作流程。数据科学团队、财务部门、市场团队、法务和设计团队，都各自摸索出了自己的用法。最终我们看到的结果就是：整个公司在以相同的步速奔跑，不再需要等着哪个部门来完成交接，效率的齿轮转动得越来越顺滑。
回到开头的那个 Excalidraw 表格工具的故事。从反复失败，到偶尔成功，再到现场演示一锤定音，这中间只用了不到一年的时间。Cat Wu 最后的总结精辟而有力：
