原文：Product management on the AI exponential 作者：Cat Wu（Anthropic，Claude Code 产品负责人） 译文说明：技术与管理向本地化，保留专名（Claude Code、Cowork、METR 等），便于对照原文。
自 2024 年 10 月 Claude Sonnet 3.5（new） 起，作者养成一个习惯：每出新模型，就用当时的 Claude Code（当时还是内部工具）让模型给 Excalidraw 加一个「表格工具」。每个版本都会多推进一点，但一直做不成。
到 2025 年 6 月 Opus 4 发布，Claude 开始偶尔能成功，团队甚至把这段做成了 Claude 4 发布会的预录 demo，展示最新模型已经能做到什么。
不到一年后，Opus 4.6 已经能足够稳定地一次搞定（one-shot）这类 Excalidraw 需求，团队敢在成千上万专业开发者面前现场演示。
模型进步的速度，不断把「可能」的边界往外推。传统产品管理假设：项目开始时技术上能做什么，结束时也差不多还是那些。PM 会在前期尽量把信息收齐，对未来下注，再按数月计划执行。
指数级变强的模型会打破这个假设。 你当初围绕的约束，可能做到一半就消失了。你是在一块不断抬升的地基上盖楼，团队必须按这个现实重组节奏。新的产品节拍是：快速实验、持续交付、对有效路径加倍投入。
作者在 Anthropic 做 PM，被问得最多的是：我们的角色到底怎么变。下面是她的总结。
我与 Claude Code 同行的产品之路
职业早期，作者在 Scale AI、Dagster 等公司做 product engineer，后来做过风投；做 VC 时仍会写代码，把繁琐工作自动化，例如扫 X 上的新公司动态、判断开源项目是否在起势。
2024 年 8 月加入 Anthropic，在 Research PM 团队，连接研究与真实客户，推动更好的模型交付。那年秋天 Claude Code 对内开放后，她用它加速工作中偏手工的部分：搭 Streamlit 分析大规模用户反馈、跑 eval 帮公司找更可信的新 benchmark；低门槛也让她能探索职责之外的事，例如搭 RL 环境 以理解训练。
这些项目花了数百小时与 Claude Code（Sonnet 3.5 new） 对话，但没有一行手写代码。
设计一套新的产品管理工作流
Claude Code、Cowork 等工具，正在模糊产品生命周期里各角色的边界。
作者自己的工作流逐渐稳定为三款产品分工：
产品 | 用途 |
Claude.ai | 与 Claude 对话、碰撞思路，不需要它直接替你执行。写战略文档、处理棘手情境、快速问答。 |
Claude Code | 做原型、eval、脚本，很多会调 Claude API；产出是代码时用它。 |
Cowork | 其余知识工作：清空收件箱、跟进待办、做幻灯片、在 Slack 里搜决策历史、订差旅等。 |
行业里其他 PM 也有类似组合。文中引述：
Bihan Jiang（Decagon，产品总监）：「Claude 抬高了优秀产品团队能交付的上限，也极大缩短了从想法到原型的距离。过去要把东西摆到客户面前可能要几周；现在我会先在 Claude Cowork 里拉齐 Slack、代码库、文档上下文，再进 Claude Code，几小时内就有可 demo 的东西。好团队一向会用真实用户验证想法，这点没变；变的是我们能经得起完整验证循环的高质量想法多了多少。」
Kai Xin Tai（Datadog，高级产品经理）：「在 AI-native 世界里做 PM，既像创作又像做研究。每次新模型都会改写可能性边界；我们做 Datadog Bits AI SRE agent 时，会在真实生产事故上做离线 eval，研究模型强项与失效模式，并设计紧凑反馈回路，在 UI 上暴露 agent 吃力的环节，再反哺产品。可以说，手艺从事先定义确定性转向了加速发现。」
主动拥抱「AI 指数曲线」
文中引用 METR 研究：《Task-Completion Time Horizons of Frontier AI Models》（2026 年 3 月）。大约一半情况下，Opus 4.6 能完成人类需要近 12 小时 才能做完的软件类任务。
团队刚开始做 Claude Code 时，前沿模型是 Sonnet 3.5（new），METR 测到它大致对应人类约 21 分钟 量级的任务——约 16 个月里，能力量级跃升约 41 倍（原文表述为 roughly 41x jump）。
Claude Code 团队也在随模型进化而变：设计写代码、工程做产品决策、产品做原型和 eval。能跑通，是因为清晰的战略与目标让每个人能自主排序。PM 的工作，是在模型快速进步带来的模糊里建立清晰度，推动团队把「可能」想更大，并扫清更快 ship 路上的障碍。
作者总结了 四个转变：
图源：Claude 官方博文插图 fig1-claude-code-pm-playbook-on-the-ai-exponential，概括短周期、demo/eval、随模型迭代重做、做简单有效之事四条主线。
1. 用短周期规划（Plan in short sprints）
传统思路里，探索发生在路线图锁死之前：调研、写 PRD、交给工程开做。
团队更鼓励** side quest（支线任务）**：在正式路线图之外，短平快的自驱实验——一下午做个原型、测一个原以为够不着的 capability、或故意把模型推到比预期更狠。Anthropic 一些受欢迎的功能——Claude Code Desktop、AskUserQuestion 工具、待办列表——都来自这类探索。
2. 用 demo 和 eval 代替「文档优先」（Encourage demos and evals over docs）
团队 largely 用 prototype-first 替代 documentation-first。不再依赖传统站会，而是分享新想法的 demo；内部用户试用，真正有 engagement 的再打磨、再扩散。下午能出原型，押错成本就低。
例如有人把 plugins 的 spec 丢给 Claude Code，回来的原型已接近可上线，团队能很快验证 UX，最终交付也围绕这个原型对齐。
小技巧：写完 spec，先丢给 Claude Code 看能不能做出来；哪怕粗糙原型，也会改变讨论方式。
除 demo 外，eval 能把抽象功能变具体。例如 agent teams（多实例 Claude Code 协同）场景里，同事手搓了一套 eval，弄清何时好用、何时不行、该修什么。能量化，才容易迭代。
3. 新模型发布后回头重做（Revisit features with new models）
功能上线后，更好的模型一来，同一功能可以好一大截。每次发版都是在提醒：把已经做过的东西再拿出来试一遍。
最好的捕捉方式是自己天天用，并故意让它做你觉得太难的事——有时突然能成，就说明产品该跟上。
Claude Code with Chrome 就是这样来的：用户用 Claude Code 做 web app，再手动切到 Chrome 里的 Claude 去测，两边复制粘贴提示。团队发现这种「用户自己搭脚手架」的行为足够普遍，就应做成一等公民功能。
做原型时，先为能力优化，别过早抠 token。常见错误是过早砍成本，结果 ship 出去的东西弱很多。成本可以等便宜模型追上来再压；先要确认这件事在能力上是否成立。
4. 做简单有效的事（Do the simple thing）
Anthropic 跨团队有一条原则：做简单且有效的事（the simple thing that works）。
若产品巧妙绕开了模型短板，下个模型一强，这些 workaround 就变成多余复杂度。实现越简单，越容易换上新能力。
例如早期 Claude Code 待办列表：模型不能稳定勾选已完成项，团队就加系统提醒，隔几条消息催 agent 更新待办——能用，但是 hack。新模型一来，行为自然变好，提醒就删掉了。类似地，系统提示与工具说明曾为了补模型短板写得很重；随模型迭代不断瘦身，Opus 4.6 上提示词还砍了约 20%。
向前看（Looking forward）
很多 PM 习惯强控制端到端体验，但做 AI 产品往往要放手才能快。作者说像冲浪：关键是留在浪上。作为 perfectionist，这是她最难适应的一点；现在的角色是：抓住少数真正不可妥协的点，其余放手。
这些转变叠加的结果是：团队整体快很多。PM 从「要是我们试试…」到「来，你试试这个」，间隔几乎消失。
在 Anthropic，不只 PM：数据科学、财务、市场、法务、设计等团队也自发用起来，全公司同速前进，而不是卡在交接上。
今天的 PM 要同时盯两件事：AI 如何改变你的工作方式，以及 AI 如何改变产品里「能做到什么」。两件事都盯住了，当「表格工具终于稳定能加进 Excalidraw」时，你不会意外——你早就预见到了。
致谢（译注）
原文致谢：本文由 Cat Wu（Anthropic，Claude Code 产品负责人）撰写；感谢 Bihan Jiang、Kai Xin Tai 对本文的贡献。原文页脚可见作者社交链接。