AI时代产品经理生存指南：当地面每天都在变化，你如何站稳脚跟？

TL;DR

“我们花了 16 个月，把一个‘总是失败’的功能，变成了敢在数千名开发者面前现场演示的产品。这不是因为我们变聪明了，而是因为地面在我们脚下升起。” —— Cat Wu，Anthropic 产品经理

引子：一个重复了几个月的“失败实验”

2024 年 10 月的某个下午，Anthropic 的产品经理 Cat Wu 做了一件看起来有点傻的事：

她让 Claude Code 给 Excalidraw 添加一个表格工具。

失败了。

第二天，新模型发布，她又试了一次。

还是失败。

第三次、第四次、第五次……她就这样重复了好几个月，每次新模型发布，都做同一个实验。

这不是执着，这是一种新的产品直觉：在 AI 时代，“不可能”的保质期只有几个月。

2025 年 6 月，Opus 4 发布。Claude 开始偶尔成功了。

不到一年后，2026 年 3 月，Opus 4.6 已经能一次性可靠完成这个功能。Anthropic 敢在数千名专业开发者面前现场演示，不需要预录视频，不需要彩排，因为它就是能做到。

从“总是失败”到“偶尔成功”到“一次搞定”，只用了 16 个月。

这个故事听起来像是 AI 能力的进步，但它真正揭示的，是产品经理这个职业正在经历的一场地震。

第一部分：传统产品管理的基本假设正在崩塌

那个曾经坚如磐石的假设

传统产品管理建立在一个看似理所当然的假设之上：

项目开始时的技术可行性，与项目结束时的技术可行性，大致相同。

这个假设塑造了整个产品管理的工作流程：

1. 调研阶段（2-4 周）：访谈用户，分析竞品，评估技术可行性

2. 规划阶段（1-2 周）：撰写 PRD，确定优先级，锁定路线图

3. 开发阶段（2-6 个月）：工程师按照 PRD 实现功能

4. 测试与发布（2-4 周）：QA 测试，修复 bug，灰度上线

整个周期：3-8 个月。

这套流程的核心逻辑是：在项目初期收集足够的信息，对未来做出有把握的预测，然后按计划执行。

就像建造一座桥梁：你先设计图纸，然后严格按图施工。钢材的强度不会在施工过程中突然翻倍，混凝土的性能也不会在浇筑时突然改变。

但 AI 打破了这个假设。

当地面每天都在变化

想象你在建造一座桥梁，但在施工过程中：

• 第一个月：钢材强度翻倍

• 第二个月：混凝土可以自我修复

• 第三个月：重力突然减半

你的设计图纸还有意义吗？

这就是 AI 时代产品经理面临的现实。

METR（Model Evaluation and Threat Research）的研究数据揭示了这种变化的速度：

• 2024 年 10 月，Sonnet 3.5（新版）：能完成人类需要 21 分钟的软件任务

• 2026 年 3 月，Opus 4.6：能完成人类需要近 12 小时的软件任务

16 个月，能力提升了约 41 倍。

这意味着什么？

你在项目启动时认为“技术上不可行”的功能，可能在项目进行到一半时就变得轻而易举。

你当初为了绕过技术限制而精心设计的复杂方案，可能在下个模型发布后就变成了不必要的累赘。

你脚下的地面在不断变化，而且变化的速度还在加快。

传统的产品管理方法论，正在失效。

第二部分：一个 Anthropic 产品经理的工作日常

Cat Wu 的职业生涯并不是从产品经理开始的。

她曾是 Scale AI 和 Dagster 等创业公司的产品工程师，后来成为风险投资家。即使在做投资时，她仍然写代码来自动化工作中繁琐的部分——扫描 Twitter 寻找新公司的公告，检测开源项目何时获得发展势头。

她是那种“手痒就要写代码”的人。

2024 年 8 月，她加入 Anthropic，担任研究产品经理。这个团队的职责是连接研究团队和实际客户，交付更优质的模型。

同年秋季，公司内部开始使用 Claude Code。Cat Wu 用它加速了工作中一些繁琐的操作：

• 构建 Streamlit 应用分析大规模用户反馈

• 运行评估程序帮助公司找到新的可靠基准

• 创建强化学习环境来更好地理解训练过程

这些项目耗费了数百小时的时间，但没有一行代码是她手工编写的。

三个工具，三种工作模式

随着时间推移，Cat Wu 自然而然地将工作分配给了三个产品：

1. Claude.ai：思想交流的伙伴

用途：

• 探讨战略文档的撰写思路

• 讨论如何处理棘手的情况

• 快速获得问题的解答

关键特征： 不需要它采取行动，只需要它动脑。

典型场景：

“我正在写一份关于模型评估的战略文档，但不确定应该从用户视角还是技术视角切入。我把两种思路都发给 Claude.ai，它会帮我分析各自的优劣，甚至提出第三种我没想到的角度。“

2. Claude Code：代码输出的引擎

用途：

• 构建原型

• 编写评估脚本

• 创建数据分析工具

关键特征： 当输出是代码时，用它。

典型场景：

“我需要分析 10 万条用户反馈，找出最常见的痛点。我告诉 Claude Code 我的需求，它会构建一个 Streamlit 应用，包含数据清洗、情感分析、主题聚类和可视化。整个过程可能需要几个小时的来回调试，但我不需要写一行代码。”

3. Cowork：知识工作的助手

用途：

• 清空收件箱

• 跟踪和处理待办事项

• 创建幻灯片

• 搜索 Slack 历史了解决策背景

• 预订工作旅行

关键特征： 其他所有杂事。

典型场景：

“我需要准备一个关于模型性能的汇报，但相关讨论散落在过去三个月的 Slack 消息、会议记录和内部文档中。我让 Cowork 帮我搜索和整理，它会把所有相关信息汇总成一份结构化的简报。”

这种工作方式的深层意义

Cat Wu 的工作流程不是个例。她与业内众多产品经理交流过，大家都找到了各自版本的类似工作流程。

Decagon 产品总监 Bihan Jiang 说：

“Claude 提高了优秀产品团队的开发上限，并大幅缩短了从想法到原型之间的距离。过去，要将实际产品推向客户需要数周时间。现在，我只需在 Claude Cowork 中，从 Slack、代码库和文档中提取上下文信息，然后转到 Claude Code，几个小时就能做出可演示的产品。”

Datadog 高级产品经理 Kai Xin Tai 说：

“在人工智能原生时代担任产品经理既充满创意又需要学术钻研。每个新模型的发布都会改变我们所能实现的边界。在构建 Datadog 的 Bits AI SRE 代理时，我们会通过对真实生产环境中的事故进行离线评估，来研究其优势和失效模式。产品经理的工作重心已经从预先设定确定性转变为加速探索。”

这些产品经理的共同点是：他们不再只是“管理”产品，而是“构建”产品。

AI 工具模糊了产品经理、工程师和设计师之间的界限。在 Anthropic 的 Claude Code 团队：

• 设计师发布代码

• 工程师做产品决策

• 产品经理构建原型和评估

这不是混乱，而是一种新的协作模式。

第三部分：四个核心转变——如何在变化的地面上站稳脚跟

转变 1：从长期路线图到“支线任务”

传统思维：探索在路线图之前

传统产品管理把探索视为一个阶段：

探索阶段 → 锁定路线图 → 执行阶段

你做调研，写 PRD，然后把它交给工程团队去构建。探索结束了，执行开始了。

这种思维假设：你可以在开始之前就知道所有答案。

AI 时代思维：探索永不停止

在 Anthropic，团队鼓励每个人（工程师、产品经理、设计师）承担“支线任务”（side quests）。

什么是支线任务？

一个短期的自主实验，在你的官方路线图之外运行——花一个下午原型化一个想法，测试一个你以为遥不可及的能力，或者就是看看当你把模型推得比预期更远时会发生什么。

支线任务的特征：

• 时间短：一个下午到几天

• 自主性：不需要审批，自己决定做什么

• 探索性：测试“不可能”的边界

• 低成本：失败了也不影响主线任务

真实案例：三个“意外”诞生的热门功能

1. Claude Code 桌面版

最初，Claude Code 只是一个 Web 应用。某个工程师在支线任务中尝试把它做成桌面应用，发现体验好得出乎意料。团队决定正式投入资源，现在桌面版是最受欢迎的使用方式之一。

1. AskUserQuestion 工具

产品经理在使用 Claude Code 时发现，有时候 Claude 需要向用户确认一些选择，但没有好的交互方式。他花了一个下午设计了一个结构化的问答工具，让 Claude 可以向用户展示选项。这个工具现在是 Agent SDK 的核心功能之一。

1. Todo 列表

工程师发现 Claude 在处理复杂任务时容易“迷路”，忘记自己要做什么。他尝试让 Claude 维护一个 todo 列表，效果显著。这个功能现在是 Claude Code 的标配。

这些功能的共同点：都不在原始路线图上，都是支线任务的产物。

为什么支线任务如此重要？

因为在 AI 时代，最大的风险不是做错了什么，而是错过了什么。

模型能力的提升速度太快，你不可能在季度规划会议上预测到所有可能性。

支线任务是一种分布式探索机制：

• 每个团队成员都在探索边界

• 有人发现新可能性时，整个团队都能看到

• 好的想法会自然浮现，不需要自上而下的决策

这是一种适应快速变化的组织结构。

转变 2：从文档优先到原型优先

传统流程：文档是真理

在传统产品管理中，PRD（产品需求文档）是真理的来源：

1. 产品经理写 PRD

2. 工程师根据 PRD 估算工作量

3. 设计师根据 PRD 设计界面

4. 所有人在 PRD 上达成共识

5. 开始开发

PRD 是合同，是承诺，是协调的基础。

AI 时代流程：原型是真理

在 Anthropic 的 Claude Code 团队，文档仍然存在，但它不再是中心。

新的流程：

1. 产品经理写一个简单的规格说明

2. 把规格说明发给 Claude Code，让它构建原型

3. 团队基于原型讨论和迭代

4. 好的原型直接演化成产品

原型是真理，是讨论的基础，是快速验证的工具。

真实案例：插件系统的诞生

Noah（Claude Code 团队成员）写了一个关于插件系统的规格说明。这个规格描述了插件应该如何工作，但没有详细的实现细节。

他把这个规格发给 Claude Code。

几个小时后，Claude Code 返回了一个接近生产就绪的原型。这个原型包括：

• 插件的加载机制

• 插件与主程序的通信协议

• 一个示例插件

• 基本的错误处理

团队基于这个原型进行讨论：

• “这个加载机制太复杂了，我们简化一下”

• “通信协议很好，但需要加上权限控制”

• “示例插件很有启发性，我们可以做一个插件市场”

这个原型锚定了最终产品的形态。

如果没有原型，团队可能会在抽象的讨论中花费数周时间。有了原型，所有人都在讨论具体的东西，效率提升了一个数量级。

Pro-tip：规格说明的新用法

传统用法： 规格说明是给人看的，用于协调团队。

AI 时代用法： 规格说明也是给 AI 看的，用于快速生成原型。

实践建议：

写完规格说明后，立刻把它发给 Claude Code，看它能构建出什么。

• 如果它能构建出接近可用的原型 → 你的规格足够清晰

• 如果它构建的东西完全跑偏 → 你的规格有歧义，需要澄清

• 如果它根本做不出来 → 可能这个功能超出了当前的技术边界

这是一种新的“规格验证”方法。

转变 3：每次新模型发布，重新审视老功能

新模型 = 新可能性

在传统软件开发中，功能发布后就“完成”了。你可能会修复 bug，做一些小的改进，但核心功能不会有本质变化。

在 AI 时代，功能永远不会“完成”。

每次新模型发布，你的功能都可能变得更好——如果你愿意重新审视它。

真实案例：Claude Code with Chrome

背景：

Claude Code 是一个编码工具，用户用它来构建 Web 应用。

团队注意到一个模式：

1. 用户在 Claude Code 中开发 Web 应用

2. 用户切换到浏览器中的 Claude，让它测试应用

3. 用户在两个工具之间复制粘贴指令和反馈

用户在“手动拼凑”一个工作流。

团队的反应：

这不应该是手动的。如果用户在 hack 某个东西，那就是我们该做的脚手架。

解决方案：

Claude Code with Chrome——Claude Code 可以直接在 Chrome 中测试它构建的 Web 应用，无需用户手动切换和复制粘贴。

关键洞察：

这个功能之所以可能，是因为新模型有了更好的“工具使用”能力。在旧模型上，这个功能可能需要大量的工程来协调两个工具。在新模型上，它几乎是自然而然的。

如果团队没有重新审视用户的使用模式，这个功能可能永远不会诞生。

如何发现这些机会？

最好的方法：成为日常活跃用户。

Cat Wu 说：

“最好的方式是成为日常活跃用户，并故意让它做你认为可能太难的事。有时它能做到，那就是产品需要跟上的信号。”

实践建议：

1. 每天使用自己的产品：不是测试，是真的用它完成工作

2. 故意测试边界：尝试你以为做不到的事

3. 记录“惊喜时刻”：当 AI 做到了你没想到的事，记下来

4. 观察用户的 hack：用户在手动拼凑的工作流，就是你该自动化的

每次新模型发布，重复这个过程。

重要原则：能力优先，成本其次

在原型化这些想法时，Cat Wu 强调：

“始终优先优化能力。使用比你认为需要的更多的 token。过早削减 token 成本是一个常见错误，会导致发布的功能能力大打折扣。你总是可以在更便宜的模型赶上来后降低成本，但首先你需要知道这个功能是否可能。”

这是一个反直觉的建议。

在传统软件开发中，我们被训练成“优化一切”。但在 AI 时代，过早优化会让你错过真正的可能性。

先证明它能做到，再考虑成本。

转变 4：做简单的事

Anthropic 的指导原则

在 Anthropic，有一个贯穿所有团队的指导原则：

做简单有效的事。

这不是说“做容易的事”，而是说“用最简单的方式解决问题”。

为什么“简单”如此重要？

因为你今天为了绕过模型限制而做的“聪明设计”，明天可能就是不必要的复杂度。

真实案例：Todo 列表的演化

第一版（Hack）：

当 Claude Code 首次推出 todo 列表功能时，模型有个问题：它不会可靠地勾选已完成的任务。

团队的解决方案：

添加“系统提醒”——每隔几条消息，自动插入一个提示，提醒 Claude 更新它的 todo 列表。

这个方案能用，但它是个 hack：

• 增加了系统复杂度

• 消耗了额外的 token

• 在对话中插入了“噪音”

下一个模型发布后：

模型自己就会勾选任务了。

团队的反应：

删掉所有提醒代码。

这种模式反复出现：

• 系统提示词曾经需要大量工程来弥补模型缺陷

• 工具描述曾经需要精心设计来引导模型行为

• 每次新模型发布，都能删掉一些这样的“拐杖”

Opus 4.6 发布时，团队删掉了 20% 的提示词。

简单的深层含义

“做简单的事”不仅仅是关于代码的简洁性，它是一种战略选择：

1. 简单的实现更容易升级

当新模型发布时，简单的实现可以直接受益，复杂的实现可能需要重构。

1. 简单的实现更容易理解

团队成员可以快速理解和修改，不需要深入研究复杂的逻辑。

1. 简单的实现更容易维护

Bug 更少，调试更容易，技术债务更少。

1. 简单的实现更容易解释

向用户、向团队、向投资人解释产品时，简单的实现更容易讲清楚。

如何识别“不必要的复杂度”？

问自己三个问题：

1. 我是在绕过模型的限制吗？

   • 如果是，这个限制可能在下个模型中消失

2. 这个复杂度是为了解决当前的问题，还是为了解决未来可能的问题？

   • 如果是后者，可能是过度设计

3. 如果我有一个更强大的模型，我还会这样设计吗？

   • 如果不会，那就简化它

实践建议：

每次新模型发布后，做一次“简化审查”：

• 哪些 workaround 可以删掉？

• 哪些提示词可以简化？

• 哪些复杂的逻辑可以用更简单的方式实现？

把简化当成一种持续的实践，而不是一次性的优化。

第四部分：产品经理角色的本质转变

从控制到冲浪

Cat Wu 说了一句很有洞察力的话：

“很多产品经理习惯了对产品体验的完全控制，但 AI 要求你放手才能快速前进。在 AI 时代做产品，感觉就像冲浪，最重要的是留在浪上。”

这是一个深刻的比喻。

传统产品管理：建造者的心态

传统产品经理就像建筑师：

• 设计每一个细节

• 控制每一个体验

• 确保一切按计划进行

你是建造者，产品是你的作品。

AI 时代产品管理：冲浪者的心态

AI 时代的产品经理更像冲浪者：

• 你不能控制浪，但你可以选择在哪里冲浪

• 你不能改变浪的方向，但你可以调整自己的姿态

• 最重要的不是完美的技术，而是保持在浪上

你是冲浪者，AI 是浪，产品是你冲浪的轨迹。

这对完美主义者意味着什么？

Cat Wu 坦承：

“作为一个完美主义者，这是我最难适应的转变。”

完美主义者的本能是：

• 控制每一个细节

• 确保一切都是最优的

• 在发布前打磨到完美

但在 AI 时代，这种本能可能是致命的：

• 当你在打磨细节时，模型已经进化了

• 当你在追求完美时，竞争对手已经发布了

• 当你在控制一切时，你错过了新的可能性

新的心态是：

• 识别少数几个“绝对不能妥协”的点

• 其他的，放手

• 快速发布，快速迭代，快速学习

这不是降低标准，而是重新定义什么是“好”。

在快速变化的环境中，“好”不是“完美”，而是“快速学习和适应”。

产品经理的新角色定义

Cat Wu 给出了一个新的角色定义：

“产品经理的工作现在是同时追踪两件事：AI 如何改变你的工作方式，以及 AI 如何改变你产品的可能性。做好这两件事，你就不会在表格工具终于能用时感到惊讶。因为你早就看到它来了。”

让我们拆解这个定义：

1. 追踪 AI 如何改变你的工作方式

这是向内看：

• 你如何使用 AI 工具完成工作？

• 哪些任务可以自动化？

• 哪些工作流可以优化？

• 你的时间分配如何改变？

实践建议：

每周花 30 分钟反思：

• 这周我用 AI 做了什么？

• 哪些任务比我预期的更容易？

• 哪些任务仍然很难？

• 我的工作方式有什么变化？

记录这些变化，它们是洞察的来源。

2. 追踪 AI 如何改变你产品的可能性

这是向外看：

• 新模型能做什么？

• 用户在 hack 什么工作流？

• 竞争对手在做什么？

• 行业的边界在哪里？

实践建议：

每次新模型发布后：

• 花一天时间测试它

• 尝试你以为做不到的事

• 重新审视你的产品路线图

• 问自己：“如果我今天重新设计这个功能，我会怎么做？”

3. 看到它来了

这是最关键的：

不是在事情发生后反应，而是在事情发生前预见。

Cat Wu 能在表格工具“终于能用”之前就看到它来了，因为：

• 她每次新模型发布都测试

• 她追踪模型能力的演化

• 她理解能力提升的趋势

• 她知道什么时候该重新尝试

这不是预测未来，而是理解趋势。

第五部分：组织层面的转变

不只是产品经理在改变

Cat Wu 指出：

“在 Anthropic，产品经理不是唯一用 Claude 改变工作流程的人。我们的数据科学、财务、营销、法律和设计团队都自发地采用了这些工具。整个组织以相同的速度前进，而不是等待交接。”

这是一个关键洞察。

传统组织：串行的工作流

在传统组织中，工作是串行的：

1. 产品经理写需求

2. 设计师设计界面

3. 工程师实现功能

4. QA 测试

5. 市场营销推广

每个环节都在等待上一个环节完成。

AI 原生组织：并行的工作流

在 AI 原生组织中，工作是并行的：

• 产品经理可以自己构建原型

• 设计师可以自己发布代码

• 工程师可以自己做产品决策

• 市场营销可以自己分析数据

每个人都有更大的自主权，团队可以更快地前进。

这需要什么条件？

1. 清晰的战略和目标

当每个人都有更大的自主权时，清晰的战略和目标变得更加重要。

没有清晰的方向，自主权会导致混乱。

1. 高度的信任

你需要信任团队成员会做出正确的决策，即使他们不是传统意义上的“专家”。

没有信任，自主权会导致微观管理。

1. 快速的反馈循环

当每个人都在快速实验时，你需要快速的反馈循环来识别什么有效，什么无效。

没有反馈，自主权会导致资源浪费。

1. 共享的工具和语言

当整个组织都使用相同的 AI 工具时，协作变得更容易。

没有共享的工具，自主权会导致孤岛。

第六部分：给产品经理的实践建议

基于 Cat Wu 和其他 AI 时代产品经理的经验，这里有一些具体的实践建议：

1. 建立你的“三工具工作流”

找到你的：

• 思考工具：用于探讨想法、分析问题（如 Claude.ai）

• 执行工具：用于构建原型、生成代码（如 Claude Code）

• 协调工具：用于管理任务、搜索信息（如 Cowork）

不要试图用一个工具做所有事情。

不同的任务需要不同的工具，清晰的分工会提高效率。

2. 每周做一个“支线任务”

规则：

• 时间：2-4 小时

• 目标：测试一个“不可能”的想法

• 输出：原型或学习

不要担心失败。

支线任务的目的是探索边界，大部分会失败，但偶尔的成功会带来巨大的价值。

3. 每次新模型发布，做三件事

第一天：测试

• 花一天时间测试新模型

• 尝试你以为做不到的事

• 记录“惊喜时刻”

第一周：重新审视

• 重新审视你的产品路线图

• 哪些功能突然变得可行了？

• 哪些 workaround 可以删掉了？

第一月：简化

• 做一次“简化审查”

• 删掉不必要的复杂度

• 更新你的最佳实践

4. 建立“原型优先”的文化

改变会议的结构：

• 少开“讨论会议”，多开“演示会议”

• 鼓励每个人带原型来，而不是带文档来

• 基于具体的东西讨论，而不是抽象的概念

改变决策的流程：

• 不要在没有原型的情况下做重大决策

• 如果一个想法值得讨论，它就值得原型化

• 原型可以很粗糙，但必须是可交互的

5. 成为日常活跃用户

不要只是“测试”你的产品，要“使用”它。

• 用它完成真实的工作

• 故意推它到极限

• 记录你的挫折和惊喜

最好的产品洞察来自真实使用，而不是测试用例。

6. 追踪两条曲线

能力曲线：

• 模型能做什么？

• 能力如何演化？

• 下一个突破可能在哪里？

用户曲线：

• 用户在做什么？

• 他们在 hack 什么工作流？

• 他们的需求如何演化？

当两条曲线交汇时，就是产品机会。

7. 培养“冲浪者心态”

接受你无法控制一切：

• 模型会改变

• 用户会变化

• 竞争会加剧

专注于你能控制的：

• 你的学习速度

• 你的适应能力

• 你的团队文化

记住：最重要的是留在浪上。

结语：地面在升起，你准备好了吗？

回到文章开头的故事。

Cat Wu 花了 16 个月，把一个“总是失败”的功能，变成了敢在数千名开发者面前现场演示的产品。

但这不是她变聪明了，而是地面在她脚下升起。

模型能力的指数级提升，正在改变产品管理的基本假设。

传统产品管理假设：技术可行性是稳定的。

AI 时代的现实：技术可行性每天都在变化。

这种变化不是挑战，而是机会。

对于那些能够适应的产品经理来说，这是一个黄金时代：

• 你可以在一个下午构建出过去需要几周的原型

• 你可以测试过去不敢想象的想法

• 你可以以前所未有的速度学习和迭代

但这需要新的心态：

• 从控制到冲浪

• 从完美到快速

• 从计划到探索

• 从复杂到简单

Cat Wu 的建议是：

“产品经理的工作现在是同时追踪两件事：AI 如何改变你的工作方式，以及 AI 如何改变你产品的可能性。做好这两件事，你就不会在表格工具终于能用时感到惊讶。因为你早就看到它来了。”

地面在升起。

问题不是它会不会升起，而是：当它升起时，你是站在上面，还是被甩在后面？

选择权在你。

延伸阅读

• Anthropic 官方博客：https://www.anthropic.com/blog

• Claude Code 文档：https://code.claude.com/docs

• METR 模型评估报告：https://metr.org/time-horizons

• Cat Wu 的 Twitter：https://x.com/_catwu

• Cat Wu 的 LinkedIn：https://www.linkedin.com/in/cat-wu/

关于作者

本文基于 Anthropic 产品经理 Cat Wu 的文章《Product management on the AI exponential》改编。Cat Wu 是 Claude Code 的产品负责人，曾在 Scale AI、Dagster 等创业公司担任产品工程师，后成为风险投资家。她的职业生涯横跨工程、产品和投资，对 AI 如何改变产品管理有深刻的洞察。

如果这篇文章对你有启发，欢迎分享给更多的产品经理朋友。

在 AI 时代，我们都在学习如何在变化的地面上站稳脚跟。