Claude code 产品经理Cat Wu亲述：我是如何用AI彻底重构PM工作流的

Claude Code 产品经理Cat Wu刚写了一篇博客，详细剖析了AI如何重塑她的工作流，强烈推荐所有PM阅读，除了PM，我觉得AI时代人人都是产品经理，尤其是你想做出有影响力的产品时这篇文章更值得阅读。

以下是详细内容：

2024年10月，Claude Sonnet 3.5（新版）发布之后，我养成了一个习惯：每次有新模型出来，就让Claude Code（当时还是内部工具）给Excalidraw加一个表格工具。每次模型都能走得更远一些，但始终失败。

直到2025年6月Opus 4发布，Claude开始偶尔成功了。于是我们把这个演示录成视频，放进了Claude 4的发布活动。

再往后，Opus 4.6已经可以稳定地一次性完成Excalidraw的功能需求，我们开始在数千名专业开发者面前实时演示。

模型进步的速度，持续扩展着可能的边界。

传统产品管理的基本假设已经失效

传统产品管理的逻辑，建立在一个默认前提上：项目开始时的技术约束，到项目结束时基本不变。产品经理前期收集足够信息，做出自信的判断，然后按计划推进，一个周期往往长达数月。

指数级提升的模型打破了这个前提。你设计时绕开的约束，可能在项目进行到一半时就消失了。地面在你脚下持续抬升，团队必须围绕这个现实重新组织工作方式。新的产品管理节奏是：快速实验、持续交付、押注有效的方向。

我是怎么走到这里的

我职业生涯起步于Scale AI和Dagster的产品工程师，后来做过风险投资，期间仍然坚持用代码自动化工作中繁琐的部分——比如扫描X平台上的新公司公告，或者检测开源项目的增长势头。

2024年8月，我加入Anthropic，担任Research PM团队的产品经理，负责连接研究团队与真实用户，推动更好的模型落地。那年秋天Claude Code在内部开放后，我开始用它加速工作中手动操作的部分：构建Streamlit应用分析大规模用户反馈，跑评估帮助公司寻找新的可信基准。工具门槛低到我可以轻松越界探索，比如搭建强化学习环境来更好地理解模型训练。

这些项目耗费了我数百小时与Claude Code的交互，底层是Sonnet 3.5（新版），全程没有亲手写过一行代码。

我如何划分工作流

我最终在三款产品之间找到了自然的分工：Claude.ai、Claude Code和Cowork。

Claude.ai是我和Claude对话的地方，不需要它执行任何操作。我在这里打磨策略文档的思路，处理棘手的情况，快速获取答案。

Claude Code是我构建原型、跑评估、写脚本的地方，很多脚本本身也在调用Claude API。有代码产出的任务，我放在这里。

Cowork负责其他所有事情：清理收件箱、跟踪待办事项、制作PPT、搜索Slack里的决策历史、预订差旅。

我与其他公司产品经理的交流发现，他们也在摸索自己版本的这套分工。

Decagon产品总监Bihan Jiang分享道，Claude大幅提升了优质产品团队的上限，从想法到原型的距离大幅缩短，以前需要几周建设的东西，现在从Cowork拉取上下文、转到Claude Code，几小时内就能演示。能跑通真实用户验证的高质量想法数量显著增加。

Datadog高级产品经理Kai Xin Tai在构建AI SRE智能体时提到，每次新模型发布都意味着可能性边界的变化，产品经理的工作已经从前期锁定确定性，转变为加速发现。

模型能力的增长有多快

METR 2026年3月的研究数据显示，Opus 4.6在约一半情况下能完成人类需要近12小时才能完成的软件任务。而当我们最初构建Claude Code时，Sonnet 3.5（新版）是当时最强的模型，METR测量的结果是它能完成人类21分钟左右的任务。

16个月，约41倍的提升。

我们做出的四个转变

一、用短周期冲刺代替长线路线图

我们鼓励团队每个人——工程师、产品经理、设计师——开展边缘探索项目（side quest）。这是一种短期自主实验：花一个下午做个原型，测试一个你以为做不到的能力，或者就是看看把模型推得比预期更猛会发生什么。

Claude Code桌面版、AskUserQuestion工具、待办事项列表，都是这样诞生的。

二、用演示和评估替代文档

我们的团队基本上用原型优先取代了文档优先的思路。站会不是汇报进展，而是分享新想法的演示。内部用户试用，有真实参与感的功能得到打磨并更广泛分享。因为一个下午就能出原型，押错的代价很低。

实际案例：Noah把插件规范发给Claude Code，返回的原型已经接近可交付状态，直接锚定了团队最终交付的产品形态。

一个简单的技巧：写完规范文档之后，把它发给Claude Code，让它来构建。哪怕是粗糙的原型，也会彻底改变对话的质量。

此外，评估也能让抽象的产品功能变得具体。在多智能体协作功能的开发中，Conner手工构建了一套评估集，精准测量功能在哪些情况下有效、哪些情况下失效以及如何改进。能度量，才能改进。

三、用新模型重新审视已有功能

交付一个功能后，更好的模型出来了，这个功能可能会有质的提升。每次模型发布，都是重新审视已有功能的隐性信号。

捕捉这些时机最好的方式，就是自己成为日常活跃用户，刻意尝试你认为可能还做不到的事情。有时候它就成功了，这就是产品需要跟上的信号。

Claude Code with Chrome就是这样发生的。我们观察到用户在Claude Code里构建Web应用，然后手动切换到Chrome中的Claude来测试，反复复制粘贴指令。这个模式足够稳定，于是我们意识到这应该成为内置功能。

还有一个反直觉的原则：原型阶段要优先能力上限，不要过早削减token用量。很多人会提前控制成本，结果交付了能力大打折扣的功能。你应该先验证这个功能是否可行，成本的优化可以等到更便宜的模型跟上来之后再做。

四、做最简单的能跑通的方案

Anthropic在所有团队都有一条共同原则：做能解决问题的最简单方案。

如果你的产品巧妙地绕开了某个模型局限，那这个绕法在下个模型出来后就会变成多余的复杂度。实现越简单，新能力到来时就越容易替换。

我们最初在Claude Code里加入待办事项列表功能时，模型无法稳定地在完成任务后勾掉对应条目。于是我们加了系统提醒，每隔几条消息就推动智能体更新自己的待办列表。这个方案跑通了，但本质上是个临时补丁。下一个模型出来，这个行为直接就有了，提醒逻辑完全移除。我们反复见证这个模式：系统提示词和工具描述曾经被大量工程化来补偿模型局限，随着每个新模型的发布，这些工程化内容都在被削减——Opus 4.6上削减了20%。

最后说几句

很多产品经理习惯对完整的产品体验保持紧密控制，但AI产品要求你放手，才能跑快。这对我这个完美主义者来说是最难适应的转变。但产品经理的角色现在是识别少数几个真正不可妥协的点，其余的放手。

这些转变的综合效果是，产品团队可以大幅提速。当产品经理能在一个下午从想法走到可用的原型，想法和验证之间的距离几乎消失了。

在Anthropic，做出转变的不只是产品经理。数据科学、财务、市场、法务、设计团队都是自发地拿起这些工具的。整个组织以相同的速度运转，不再等待交接。

产品经理的工作，现在需要同时追踪两件事：AI如何改变你的工作方式，以及AI如何改变你的产品中什么是可能的。把这两件事做好，你就不会再对那个表格工具最终能跑通感到惊讶——因为你早就预判到了。

source：

https://claude.com/blog/product-management-on-the-ai-exponential