原文：Product management on the AI exponential 作者：Cat Wu，Anthropic Claude Code 产品负责人
Cat Wu 有一个持续了将近一年的习惯：每当有新模型发布，她就让 Claude Code 尝试给 Excalidraw 添加一个表格工具。
每次，Claude 都能走得更远一些，但总是失败。
直到 Opus 4（2025 年 6 月）发布，Claude 开始偶尔成功——成功率足以让团队把它做成 Claude 4 发布会的预录演示。
不到一年后，Opus 4.6 已经可以在数千名开发者面前实时、可靠地一键完成这个任务。
这个小故事说明了一个根本性的变化：AI 模型的能力在指数级增长，而传统的产品管理方法是建立在”项目开始和结束时技术能力大体相同”这个假设之上的。 这个假设正在被打破。
一、Cat Wu 的产品经理之路
Cat 的职业轨迹很有代表性：
- 在 Scale AI 和 Dagster 做产品工程师（startup 早期）
- 转型为风险投资人，同时用代码自动化繁复工作（扫描 X 上的新公司公告、检测开源项目势头）
- 2024 年 8 月加入 Anthropic，担任 Research PM，负责连接研究团队与真实用户
关键转折点：内部 Claude Code 开放后，她用它构建了大量工具：
- Streamlit 应用，用于分析大规模用户反馈
- Eval 框架，帮助公司寻找新的可信基准
- RL 训练环境，用于理解模型训练（这已经远超她的 PM 职责）
这些项目花了数百小时与 Claude Code 对话，但她没有亲手写一行代码。
二、全新的三工具工作流
Claude Code 发展期间，Cat 逐渐形成了一套自然的三工具分工体系：
| 工具 | 用途 | 核心场景 |
|---|---|---|
| Claude.ai | 思维伙伴，不需要执行动作 | 策略文档构思、棘手情况处理、快速问答 |
| Claude Code | 输出是代码时使用 | 原型构建、Eval 脚本、调用 Claude API 的各类工具 |
| Cowork | 其他所有知识工作 | 清理收件箱、任务跟踪、制作 PPT、搜索 Slack 历史、出差预订 |
这种分工的核心逻辑：不是”有 AI 没 AI”的问题，而是不同任务场景匹配最合适的工具。
Decagon 产品总监 Bihan Jiang 的评价很有代表性：
“Claude 提高了优秀产品团队能构建的上限，并大幅缩短了从想法到原型的距离。以前让客户看到实物要几周，现在我会先在 Claude Cowork 里拉入 Slack、代码库、文档的上下文，再进入 Claude Code，两小时内就能有可演示的东西。“
三、拥抱 AI 指数：四个关键转变
METR 的研究数据很有说服力：从 Sonnet 3.5 (new) 到 Opus 4.6，AI 完成软件任务的时间从人类的 21 分钟延伸到近 12 小时——16 个月内能力提升约 41 倍。
在这种速度下，Claude Code 团队做出了四个关键调整：
转变一：用”短冲刺”代替长期路线图
传统做法：先研究，写 PRD，锁定路线图，交付给工程团队执行。
新做法：鼓励所有人（工程师、PM、设计师）承接**“Side Quest”（旁路探索）**：
- 不在官方路线图之内
- 时间短：一个下午就能完成的实验
- 目标灵活：原型验证、测试某个以为超出能力范围的功能，或者只是”推更狠一点看看会发生什么”
效果：Claude Code 的桌面版、AskUserQuestion 工具、Todo 列表这些热门功能，都是从 Side Quest 里长出来的。
转变二：用演示和 Eval 替代文档
传统做法：文档驱动，写规范，团队评审，再开发。
新做法：原型优先。
- 不开站会，改为分享新想法的Demo
- 内部用户试用，有真实参与度的演示才会被打磨后广泛分享
- 因为一个下午就能出原型，错误代价极低
一个具体案例：当 Noah 把 Plugins 规范发给 Claude Code 时，返回的原型已经接近生产可用，直接成为团队最终交付版本的锚点。
实操建议：写完规格文档后，把它发给 Claude Code，让它尝试构建出来。哪怕是粗糙原型，也会彻底改变后续讨论的质量。
Eval 同样作为让抽象功能变得具体的手段：Agent Teams（多个 Claude Code 实例协同工作）功能开发期间，团队手工制作了一套 Eval，精确测量”什么情况下 Agent Teams 好用、什么时候不好用、该修什么”。
转变三：用新模型重新审视已有功能
传统做法：功能上线即完成。
新做法：每次新模型发布都是隐式信号，提示你回头看已有产品。
捕捉这些时机的最佳方法：成为日活用户，并刻意尝试你认为”可能太难”的操作。
Claude Code + Chrome 集成就是这样出现的：团队注意到用户在用 Claude Code 构建 Web 应用后，会手动切换到 Chrome 里的 Claude 来测试，在两个工具之间手动拷贝粘贴。这个”用户自己搭的脚手架”明确告诉团队：这应该是内置功能。
原则：原型阶段永远优先验证能力，不要过早削减 token 成本。能力天花板确认之后，再用更便宜的模型把成本降下来。
转变四：做简单的事
Anthropic 全团队贯彻的一条准则：做有效的简单事情（Do the simple thing that works）。
为什么重要：如果你的产品聪明地绕过了某个模型限制，下一代模型一出，那个绕法就变成了不必要的复杂度。
一个真实案例：Claude Code 最初上线 Todo 列表时，模型不会可靠地勾掉已完成项。于是团队加了系统提醒，每隔几条消息就 nudge 一下 Agent。这个方案有效，但是个 hack。
下一个模型出来，这个行为开箱即得，团队把提醒全删了。
这个模式在 Claude Code 里反复出现：系统提示和工具描述曾经为补偿模型局限而被过度工程化，每代新模型之后都在精简——包括 Opus 4.6 上减少了 20% 的 prompting。
四、展望：放手，才能快速移动
Cat 自认是个完美主义者，而 AI 时代 PM 最难适应的转变恰恰是：放手。
AI 推着你用不完美来换速度。新的 PM 职责变成了：
- 识别真正不可妥协的核心需求（少数几个）
- 其他的，放手
这种转变的复合效应：当 PM 能在一个下午从想法到可用原型，“我们假设……”和”你来试试”之间的距离几乎消失。
更重要的是，这不只是 PM 的转变。Anthropic 的数据科学、财务、市场、法务、设计团队都自发采用了这些工具。整个组织以同样的速度运转，而不是在等待流转交接。
PM 的新职责：同时追踪两件事——AI 如何改变你的工作方式，以及 AI 如何改变你产品中可能的边界。做好这两件事，你就不会在”桌格工具终于可用了”的时候感到惊讶。你是那个提前看到它来临的人。
核心要点总结
| # | 传统 PM | AI 时代 PM |
|---|---|---|
| 1 | 长期路线图，锁定再执行 | 短冲刺 + Side Quest 旁路探索 |
| 2 | 文档驱动，规范先行 | 演示驱动 + Eval 量化 |
| 3 | 功能上线即完成 | 每次新模型都是重审信号 |
| 4 | 绕过限制的巧妙工程 | 做简单的事，让模型能力填补空缺 |
| 5 | 掌控完整体验 | 识别不可妥协项，其余放手 |
本文整理自 Anthropic Claude Code 产品负责人 Cat Wu 于 2026 年 3 月 19 日发布的文章。