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 模型的能力每 16 个月提升 41 倍（METR 数据）。你上个月还在担心“这个功能 AI 做不了”，这个月模型一更新，它就能做了。传统 PM 的工作方式是：花三个月做规划，然后按计划执行。但现在的问题是，你规划时的技术限制，可能两个月后就不存在了。

她说自己最大的转变是：从“制定完美计划”变成了“快速试错，抓住机会”。下面是她的具体做法。

一、从工程师到 PM：我的 AI 工具使用之路

Cat Wu 的背景挺特别：工程师出身，后来做了 VC，但在投资岗位上她还是闲不住，写代码自动化那些重复劳动——比如写个脚本扫 Twitter 找新公司，或者监测 GitHub 上哪些开源项目突然火了。

2024年8月，她加入Anthropic担任研究PM，负责连接研究团队和真实用户，帮助模型变得更好。秋天 Claude Code 内测时，她拿它来干各种活儿：做 Streamlit 应用分析用户反馈、跑评估测试模型能力、甚至搭强化学习环境研究训练过程。这些项目加起来几百小时工作量，但她一行代码都没手写，全是跟 Claude Code 对话完成的。

这个经历让她意识到一件事：以前 PM 有个想法，得先说服工程师排期，等两周才能看到原型。现在她自己下午就能做出来，门槛彻底降了。

二、3个工具的分工协作：我的日常工作流

慢慢地，Cat Wu 摸索出了一套工具使用习惯。她发现不用想“这是什么任务”，而是想“我要什么输出”：

Claude.ai：想事情的时候用

比如写策略文档没思路，就去跟 Claude 聊聊；遇到棘手问题不知道怎么处理，也去聊聊。就是纯对话，不需要 AI 动手做什么。

Claude Code：要做东西的时候用

需要一个能跑的原型？用它。要写个脚本跑数据？用它。反正只要最后输出是代码，就扔给 Claude Code。

Cowork：处理杂事的时候用

清邮件、管理待办、做 PPT、翻 Slack 历史记录找当时为什么这么决策、订机票酒店——这些都交给 Cowork。

这套工作流不是她一个人这么用。Decagon 的产品总监 Bihan Jiang 说：“以前做个能演示的东西要几周，现在几小时就行。我在 Cowork 里把 Slack 聊天记录、代码库、文档都扔进去，让它理解背景，然后切到 Claude Code，下午就能拿出可以给用户看的版本。”

Datadog 的高级 PM Kai Xin Tai 也有类似体会：“现在做 PM 有点像做实验。每次新模型出来，我们就测它哪些地方变强了、哪些还不行，然后快速调整产品。以前是「先想清楚再做」，现在是「边做边发现」。”

三、AI 时代 PM的工作方式转变

Claude Code 团队为了跟上模型快速进化的节奏，已经让角色边界变得模糊：设计师写代码发布功能，工程师做产品决策，产品经理构建原型和评估。这能运转的前提是清晰的战略和目标，让每个人都能自主优先级排序。PM 的工作变成了：在快速变化中创造清晰度，推动团队思考更大的可能性，扫清发布障碍。

Cat Wu 说，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 的建议：以后写完需求文档，先别发给团队，发给 Claude Code 试试它能不能做出来。哪怕是个粗糙的原型，也比一堆文字更能说明问题。

另一个技巧是做评估测试（evals）。比如 Agent teams 这个功能（让多个 Claude Code 协同工作），团队成员 Conner 专门做了一套测试：什么场景下有效、什么时候会出问题、该怎么改进。有了数据支撑，抽象的功能就变得具体了。

转变 3：每次新模型出来后，把老功能重新过一遍

这个现象很有意思：你上个月发布了一个功能，这个月新模型出来，你的功能突然变强了。所以每次模型更新，都值得把已有功能重新审视一遍。

怎么发现这些机会？做重度用户，故意为难 AI。让它做你觉得“应该做不到”的事，有时候它真的做到了，那就是产品该跟进的信号。

Chrome 集成功能就是这么来的。团队发现用户在用 Claude Code 做 web 应用，然后手动切到浏览器里的 Claude 去测试，两边来回复制粘贴指令。这个流程虽然麻烦，但用户真的在这么干。团队一看：用户都自己拼出解决方案了，我们为什么不直接做成产品功能？

Cat Wu 提醒：做这种新功能时，别一上来就想着省 token 成本。先用足够多的 token 把能力做出来，确认功能可行。等后面便宜的模型能力上来了，成本自然就降下来了。

转变 4：保持简单实现，避免过度工程

Anthropic 有个团队信条：做有效的简单方案（do the simple thing that works）。

在现如今，有时候你特别费劲去绕过的模型限制，下个月新模型一出，那个限制可能就没了。你的“巧妙设计”反而变成了累赘。所以实现越简单，以后升级越容易。

举个真实例子：Claude Code 刚推出 todo list 功能时，用的是老版本模型，它经常忘记勾选已完成的任务。所以团队加了个“自动提醒”机制，每隔几条对话就提醒一下 AI：别忘了更新 todo list 哦。这招管用，但说白了就是个补丁。

后来新模型 Opus 4.6 发布了，它自己就知道完成任务要打勾，不用提醒了。团队直接把那个提醒功能删了。类似的情况反复出现：以前为了弥补模型能力不足，系统提示词和工具说明写得特别复杂。现在每次新模型出来，那些“拐杖”都能扔掉一批。Opus 4.6 一次就删掉了 20% 的提示词。

四、最难的转变：PM要学会“放手”

很多 PM 习惯了掌控产品的每个细节。但 Cat Wu 说，用 AI 做产品，你得学会放手。

她的比喻是：这就像冲浪，最重要的不是控制浪，而是保持在浪头上。 作为完美主义者，这之前是她最难适应的。但她发现，现在 PM 的工作是：找出少数几个绝对不能妥协的点，其他的快速迭代就行。

举个对比：以前 PM 从有想法到做出原型，中间隔着好几周。现在一个下午就能做出来。“要不我们试试……”和“来，试试这个”之间，几乎没有时间差了。

写在最后：不只是PM，整个公司都在变快

在 Anthropic，不只是产品团队在用 AI 重构工作流程。数据科学、财务、市场、法务、设计团队都自己摸索出了用法。结果就是：整个公司以同样的速度在跑，不用等着别的部门交接了。

Cat Wu 说，PM 现在要盯两条线：AI 怎么改变你的工作方式，AI 怎么改变你产品的可能性。

回到文章开头那个 Excalidraw 表格工具的故事。从反复失败到偶尔成功，再到现场演示一次搞定，这个过程只用了不到一年。

Cat Wu 的总结是：在 AI 能力指数增长的时代，产品管理不再是“制定完美计划然后执行”，而是“快速试错，拥抱变化”。模型能力每天都在变强，与其追求完美规划，不如保持快速的迭代。