Created time
Apr 3, 2026 09:11 AM
category
library
date
Mar 19, 2026
status
Published
icon
password
slug
why-anthropic-pm-doesnt-write-long-term-roadmap
summary
本文探讨了在快速发展的AI环境中，Anthropic的产品经理如何调整工作方式，通过短期实验和快速原型设计替代传统的长期路线图，以适应技术的指数级演进。
tags
产品经理
Claude
type
post
原文链接：https://claude.com/blog/product-management-on-the-ai-exponential 发布时间：2026年3月19日
自2024年10月 Claude Sonnet 3.5（新版） 上线以来，我养成了一个习惯：每当新模型发布，就让 Claude Code（当时还是内部工具）给 Excalidraw 添加一个表格工具。每次它都能比上一次走得更远，但最终仍会失败。
不到一年后，Opus 4.6 已经能极为稳定地一次性完成 Excalidraw 的功能请求——稳定到我们敢在数千名专业开发者面前进行现场演示。
模型的进步速度，正在不断重新定义"可能"的边界。
传统产品管理的思路建立在一个假设之上：项目开始时的技术水平，到结束时不会有太大变化。于是 PM 提前收集信息，预判未来，制定几个月的执行计划。
但指数级演进的模型打破了这个假设。你在设计阶段考虑的技术限制，可能到项目中期就已经消失了。脚下的土地正在不断上升，团队必须围绕这一现实重新调整节奏。新的产品管理方式是：快速实验、持续交付，并在有效的方向上加倍投入。
作为 Anthropic 的产品经理，我被问得最多的问题就是：我们的角色发生了哪些变化？以下是我的亲身体会。
我与 Claude Code 的产品管理之路
我的职业生涯起步于 Scale AI 和 Dagster 等初创公司，担任产品工程师。后来我转行做风险投资，那时依然会写代码来处理重复性工作——比如扫描 X 平台上的新公司公告，或监测开源项目的热度趋势。
2024年8月，我加入 Anthropic 担任研究 PM，负责连接研究团队与真实客户，推动模型持续改进。那年秋天 Claude Code 在内部开放使用后，我开始用它加速工作中繁琐的部分：构建 Streamlit 应用来分析大规模用户反馈、运行评估（evals）寻找公司可以信赖的新基准，甚至探索职责之外的领域——比如搭建强化学习（RL）环境，更深入地理解训练机制。
这些项目累计消耗了数百小时的提示词工作，全部由 Sonnet 3.5（新版）驱动的 Claude Code 完成。而我自己，一行代码都没有亲手写过。
重新设计产品管理工作流
Claude Code 和 Cowork 这样的工具，正在模糊产品开发各角色之间的界限。
Claude Code 只是我工作流的一部分。随着时间推移，我逐渐习惯在三款产品之间分配工作：聊天协作工具（Claude.ai）、智能体编程工具（Claude Code）和知识工作工具（Cowork）。
- Claude.ai：用来思维碰撞。讨论战略文档、处理棘手问题、获取快速答案——不需要实际执行任何动作。
- Claude Code：用来构建原型、评估脚本。只要输出是代码，我就用它。
- Cowork：处理其余一切——清空收件箱、跟踪和执行待办事项、制作幻灯片、搜索 Slack 了解决策历史、预订出差行程。
和我聊过的同行 PM 也有类似的工作流：
"Claude 提高了优秀产品团队的产出上限，大幅缩短了从想法到原型的距离。以前，把东西呈现在客户面前需要数周的开发。现在，我先在 Claude Cowork 中整合 Slack、代码库和文档的背景信息，然后进入 Claude Code，几小时内就能做出可演示的东西。优秀的产品团队始终在用真实客户测试想法——这个直觉没变。改变的是，我们现在能把更多高质量的想法推入测试循环。"
—— Bihan Jiang，Decagon 产品总监
"对我来说，在 AI 原生世界做 PM，既是创意工作，也是学术工作。每个新模型的发布都在刷新可能性的边界。在构建 Datadog 的 Bits AI 运维助手时，我们通过真实生产事故进行离线评估，研究它的优势和失败模式，同时设计紧密的反馈循环，把用户体验中发现的智能体不足转化为产品改进。从这个意义上说，PM 的核心技能已经从'提前确定答案'转向了'加速探索发现'。"
—— Kai Xin Tai，Datadog 高级产品经理
如今做产品经理最令人兴奋的一点在于：这些工作流还在不断进化，给了我们越来越强的杠杆。
拥抱 AI 的指数级演进
METR. (2026, March). Task-Completion Time Horizons of Frontier AI Models. https://metr.org/time-horizons/
METR 研究发现，Opus 4.6 已经能在约一半的情况下，完成人类需要近 12 小时才能完成的软件任务。而在我们刚开始构建 Claude Code 时，Sonnet 3.5（新版）还是最前沿的模型，当时 METR 测得它能完成人类约 21 分钟的任务。16 个月内，能力提升了约 41 倍。
Claude Code 团队本身也在随模型进步而进化。我们的角色正在融合：设计师写代码，工程师做产品决策，产品经理构建原型和评估。这一切之所以可行，是因为清晰的战略和目标让每个人都能自主判断优先级。PM 的工作，是在快速进步带来的模糊中创造清晰度——推动团队想象更大的可能性，同时为更快的交付扫清障碍。
以下是我们主动拥抱的四个转变：
以短冲刺替代长路线图
传统 PM 思维认为，探索应该在路线图锁定之前完成——先调研，再写 PRD，然后交给工程团队执行。
我们的做法不同。我们鼓励团队中的每个人（工程师、PM、设计师）去执行"支线任务"——路线图之外的短期自主实验。你可以花一个下午做原型，测试你认为无法实现的能力，或者把模型推向极限看看会发生什么。
用演示和评估代替文档
我们团队很大程度上以"原型优先"取代了"文档优先"。我们不再举行传统站会，而是分享新想法的演示。内部用户试用后，真正受欢迎的想法会被打磨并广泛传播。由于一个下午就能做出原型，押错注的代价极低。
以 Noah 分享 插件 规范为例——Claude Code 生成的原型已经接近生产级别，直接成为团队最终交付的基础，因为它帮助大家快速验证了用户体验。
小贴士：写完规范后，扔给 Claude Code 试试能不能做出来。哪怕是粗糙的原型，也能彻底改变讨论的走向。
除了演示，评估（evals）同样能让抽象的产品变得具体。在开发 智能体团队 功能时（允许用户协调多个 Claude Code 实例协作），Conner 亲手制作了一套评估方案，帮助团队清楚地看到：这个功能在什么情况下表现好，在什么情况下表现差，以及需要优先修复什么。衡量功能是否有效，会让改进变得更有方向感。
用新模型重新审视已有功能
如今的常态是：你刚发布一个功能，更强的模型就出来了——而你的功能本可以做得更好。每次模型迭代，都在隐隐提醒你：回头看看已经构建的东西。
捕捉这些时机的最好方式，是成为产品的日常活跃用户，故意让它做一些你觉得太难的事。如果它成功了，说明产品需要跟上了。
带 Chrome 功能的 Claude Code 就是这样诞生的。我们发现用户用 Claude Code 构建网页应用，然后手动切换到 Chrome 里的 Claude 进行测试，在两个工具之间来回复制粘贴指令。这个模式很有效——这恰恰说明它应该成为内置功能。如果用户在自己拼凑某个工作流，那就是你可以内置到产品里的信号。
在为这些想法制作原型时，务必先优化能力：用比你认为需要的更多的 Token，不要过早削减成本。等更便宜的模型追上来，随时可以降本。但首先，你得知道这个功能到底行不行。
做简单且有效的事
在 Anthropic，我们每个团队都遵循同一个原则：做简单且有效的事。
如果你的产品巧妙地绕过了某个模型限制，那么当下一个模型发布时，这个绕过方案就变成了多余的复杂性。实现越简单，新能力出现时就越容易替换。
我们最初推出待办事项列表时，模型无法可靠地在完成任务后自动勾选。于是我们加了系统提醒，每隔几条消息就提醒智能体更新列表——虽然有效，但只是权宜之计。下一个模型发布后，这个行为自然就实现了，我们把那段提醒彻底删掉了。
这种模式一再重演：以前为了弥补模型限制，系统提示词和工具描述经过了大量工程雕琢。现在随着每个模型的进步，我们都在精简提示词——Opus 4.6 甚至让提示词缩减了 20%。
展望未来
很多产品经理习惯于完全掌控产品体验，但 AI 迫使你学会放手，才能跑得更快。构建 AI 产品就像冲浪——最重要的是始终留在浪头上。 作为一个完美主义者，这是我最难适应的转变。但 PM 现在的角色，是识别出少数几个真正不可妥协的点，然后对其余部分放手。
这些转变带来的最终结果是：产品团队可以大幅提速。当 PM 能在一个下午从想法变成可运行的原型时，"如果我们尝试一下……"和"给，试试这个"之间的距离几乎消失了。
今天的 PM 角色需要同时追踪两件事：AI 如何改变你的工作方式，以及 AI 如何改变你产品的可能性边界。 把这两件事都做好，当表格工具最终成功的那一刻，你不会感到惊讶——因为你就是那个早就预见到这一切的人。