指数级 AI 时代的产品管理
指数级 AI 时代的产品管理
作者: Cat Wu，Anthropic Claude Code 产品负责人
自 2024 年 10 月 Claude Sonnet 3.5 (new) 发布以来，我养成了一个习惯：每次新模型发布，就用 Claude Code（当时还是内部工具）测试让它给 Excalidraw 添加表格功能。每次新模型，Claude 都能前进一小步，但始终失败。
然后，2025 年 6 月 Opus 4 发布，Claude 开始偶尔成功了——成功次数足够多，我们把这次练习做成了 预录 demo，在 Claude 4 发布会上展示最新模型能做到什么。
不到一年后，Opus 4.6 已经能可靠地一次性完成 Excalidraw 功能请求，可靠到我们敢在数千名专业开发者面前现场演示。
模型进步的速度不断扩展着可能性的边界。传统产品管理的底层假设是：项目开始时技术能做什么，项目结束时大概还是那些。产品经理会在前期收集足够信息，对未来做出有信心的押注，然后按计划执行数月。
指数级进化的模型打破了这个假设。 你设计时围绕的限制可能在项目中途消失。你脚下的土地正在上升，团队需要围绕这个现实重新组织。新的产品管理节奏是：快速实验、持续交付、在有效的地方加倍投入。
作为 Anthropic 的产品经理，我最常被问到的问题之一就是：我们的角色正在如何变化？以下是我学到的东西。
我与 Claude Code 的产品管理之旅
我的职业生涯始于 Scale AI 和 Dagster 等初创公司的产品工程师，后来成为风险投资人——在那个角色里我仍然写代码，用来自动化工作中繁琐的部分，比如扫描 X 平台上的新公司公告，或检测开源项目何时开始获得关注。
2024 年 8 月，我加入 Anthropic，成为 Research PM 团队的产品经理，这个团队连接我们的研究团队和真实客户，以交付更好的模型。那年秋天 Claude Code 在内部可用时，我用它加速工作中偏手动的部分，包括构建 Streamlit 应用来分析大规模用户反馈，运行 evals 帮助公司找到可信的新基准测试。低门槛的构建也意味着我可以探索远超常规角色的领域，比如创建 RL 环境来更好理解训练。
这些项目花了数百小时的 Claude Code 提示，但没有一行代码是手写的。
设计新的产品管理工作流
像 Claude Code 和 Cowork 这样的工具正在模糊产品开发生命周期中不同角色的界限。Claude Code 不是唯一支撑我工作流的工具。随着时间推移，我在三个产品间形成了自然的分工：聊天协作者（Claude.ai）、Agent 编码工具（Claude Code）、知识工作工具（Cowork）。
| 工具 | 用途 |
|---|---|
| Claude.ai | 把 Claude 当作思维伙伴对话，不需要它采取行动。讨论策略文档、处理棘手情况、获取快速答案 |
| Claude Code | 构建原型、evals 和脚本，很多会调用 Claude API。输出是代码时使用 |
| Cowork | 做其他所有事：清空收件箱、跟踪和执行待办清单、创建幻灯片、搜索 Slack 理解决策历史、预订出差 |
我与行业各地的产品经理交流过，他们找到了自己版本的这种工作流：
“Claude 提高了优秀产品团队能构建的上限，大大缩短了从想法到原型的距离。以前要花几周构建才能给客户看到的东西，现在我从 Claude Cowork 开始，拉取 Slack、代码库和文档的上下文，然后转到 Claude Code，几小时就能做出可 demo 的东西。优秀的产品团队一直在用真实客户测试想法，这个直觉没变。变的是我们能把这个循环跑在多少高质量想法上。” — Bihan Jiang，Decagon 产品总监
“对我来说，AI 原生世界的 PM 既要有创意又要学术。每个新模型发布都会改变可能性，在构建 Datadog 的 Bits AI SRE agent 时，我们通过真实生产事故的离线评估来研究它的优势和失败模式。我们还设计紧密的反馈循环，优化 UX 来暴露 agent 的困难点，把这些洞察转化为产品改进。从这个意义上说，PM 的手艺已经从’前期定义确定性’转变为’加速发现’。” — Kai Xin Tai，Datadog 高级产品经理
作为今天的产品经理，最令人兴奋的事情之一是这些工作流在不断演进，给我们更多杠杆。
拥抱 AI 指数级增长
METR 研究发现，Opus 4.6 大约有一半的时候能完成人类需要近 12 小时的软件任务。当我们刚开始构建 Claude Code 时，Sonnet 3.5 (new) 是前沿模型，METR 测量它能完成人类大约 21 分钟的任务。16 个月内大约 41 倍的跃升。
Claude Code 团队已经进化以跟上模型改进的速度。我们的角色正在融合：设计师交付代码，工程师做产品决策，产品经理构建原型和 evals。这之所以可行，是因为清晰的策略和目标让每个人都能自主优先排序。产品经理的工作是在快速模型进步创造的模糊中带来清晰，推动团队对可能性想得更大，清理更快交付的路径。
以下是我们拥抱的四个转变：
1. 用短冲刺规划
传统产品经理思维把探索当作路线图锁定前发生的事情。你做研究，写 PRD，然后交给工程团队构建。
我们不再用长期路线图，而是鼓励团队每个人（工程师、产品经理、设计师）去接"支线任务"。支线任务是你跑在正式路线图之外的短期自主实验——花一下午原型一个想法，测试一个你以为遥不可及的能力，或者只是看看把模型推到极限会发生什么。
Anthropic 一些最受欢迎的功能——Claude Code Desktop、AskUserQuestion tool、todo lists——都是这样诞生的。
2. 鼓励 demo 和 eval，而不是文档
我们的团队很大程度上用"原型优先"思维取代了"文档优先"思维。不再举办传统站会，而是分享新想法的 demo。内部用户试用，真正有参与感的会被打磨并更广泛分享。因为你可以一下午原型一个想法，获得真实用户反馈，然后迭代或放弃，我们避免了在没人想要的功能上浪费工程时间。
Evals 也扮演类似角色。我们不再猜测模型能否可靠执行某个行为，而是构建 eval 来测量。这把抽象的产品辩论变成具体的实验。
3. 给团队无限 token（先学习，后优化成本）
当模型能力快速变化时，最稀缺的资源是学习速度，而不是 token 成本。
在 Claude Code，我们鼓励团队使用最强大的模型（目前是 Opus 4.6），即使它更贵。我们有个工程师一个月用了超过 5000 万 token——大约 2500 美元——但他的产出远超这个成本。给团队慷慨的 token 访问权限让他们能学习什么可行、什么不可行。当某个工作流被验证后，我们再优化成本，也许用更便宜的模型或缓存。
先验证功能是否可能，再考虑成本优化。
4. 做简单的事
在 Anthropic，我们有一个贯穿每个团队的指导原则：做有效的简单事。
如果你的产品巧妙地绕过了某个模型限制，当下一个模型发布时，那个绕过就成了不必要的复杂性。这就是为什么"做简单的事"很重要：实现越简单，新能力到来时越容易替换。
当我们首次在 Claude Code 发布 todo list 时，模型不能可靠地在完成任务后打勾。所以我们每隔几条消息添加系统提醒，定期推动 agent 更新自己的 todo list。这有效，但这是个 hack。下一个模型，这个行为自然就有了，我们完全移除了提醒。我们反复看到这个模式：我们的系统提示和工具描述曾经重度工程化以补偿模型限制，我们每个模型都在削减提示，包括 Opus 4.6 减少了 20%。
展望未来
许多产品经理习惯对完整产品体验有紧密控制，但 AI 推动你放手以快速行动。构建 AI 产品感觉像冲浪，最重要的是留在浪上。作为完美主义者，这是我最难适应的转变，但产品经理的角色现在是识别少数真正不可妥协的事情，其他的放手。
这些转变的净效果是产品团队可以显著更快。当产品经理能在一下午从想法走到可工作的原型，“如果我们试试……“和"来，试试这个"之间的差距几乎消失了。
在 Anthropic，产品经理不是唯一用 Claude 改变工作流的人。我们的数据科学、财务、营销、法务和设计团队都自己学会了这些工具。整个组织以相同速度前进，不再等待交接。
PM 角色现在是同时追踪两件事：AI 如何改变你的工作方式，以及它如何改变你产品中的可能性。 做好这一点，你就不会在表格工具终于工作时感到惊讶——你是预见它到来的人。