上周有个 PM 朋友跟我抱怨：手上有 20 个需求想法，开发资源只够做 3 个，老板拍板选了 A，但他心里清楚 B 才是用户真正需要的。

“要是能快速把每个想法都做出来看看反应就好了，“他说，“但我只是个 PM，不会写代码。”

这句话我以前也说过。

但现在我不这么想了。

AI 指数级进步打破传统假设

Anthropic 的产品经理 Cat Wu 分享过一个有趣的观察：她用每个新版本的 Claude 测试同一个任务——给 Excalidraw 添加表格工具。

• Sonnet 3.5（2024年10月）：能做一点，但会失败
• Opus 4（2025年6月）：偶尔成功
• Opus 4.6（2026年）：可以稳定地一次性完成

16 个月内，约 41 倍的速度提升。

这种指数级进步打破了传统产品管理的核心假设：项目开始时技术上可能的事情，在项目结束时大致还是那些事情。

传统 PM 工作流是这样的：写需求文档 → 排期 → 等开发 → 看到成果 → 发现不对 → 改需求 → 继续等。

这很正常，大家都这么干。但问题在于，当技术能力在项目周期内发生数量级变化时，这个模式就失效了。你在上升的地板上盖房子，传统的长期规划模式已经不适用了。

新工作流：三个工具，三种场景

Cat Wu 描述了她自然形成的工作流分工。这个分工的关键在于：每个工具都有明确的场景边界，边界不重叠，配合起来覆盖了 PM 工作的完整光谱。

Claude.ai — 思想伙伴

用在没有需要它执行行动的时候。讨论策略、处理棘手情况、快速获取答案。

当你需要 bounce 想法、验证假设、或者只是需要一个可以对话的思考伙伴时，Claude.ai 是最合适的选择。它不需要调用工具，只需要和你对话。

Claude Code — 原型构建器

用在你需要代码作为输出的时候。构建原型、运行 evals、编写脚本。

这是 PM 工作流中最革命性的变化。以前你需要等待开发资源，现在你可以在一个下午把想法变成可交互的原型。

不是那种画出来的 Figma 原型——那是”死的”，点按钮只是跳到下一页，逻辑是假的，数据是假的。用 Claude Code 做出来的原型是”活的”——它是真的 HTML，真的能跑，真的能展示交互逻辑。

更重要的是，它本来就是代码。如果老板说”这个想法不错，我们做吧”，开发拿到的是一个已经搭建好的起点，而不是从零开始。

这种工作方式正是 Vibe 编程 的核心——AI 即笔，思维即刃。你不需要懂实现细节，只需要清楚表达你的想法。

Cowork — 知识工作助手

其他一切：收件箱清零、待办事项跟踪、创建幻灯片、搜索 Slack 理解决策历史、预订工作旅行。

这些事情占据了大量时间，但不需要创造性思考。Cowork 专门处理这些。

这三个工具的组合，让 PM 能够在 AI 工具生态 中高效工作，而不需要成为技术专家。

四个核心转变

短冲刺规划代替长期路线图

传统 PM 思维把探索当作路线图锁定之前的事情。你做完研究，写完 PRD，然后交给工程团队。

取而代之的是，鼓励团队里的每个人都做”支线任务”（side quests）——一个下午的实验，测试一个你认为超出能力范围的功能，或者只是看看当你把模型推得比预期更远时会发生什么。

Anthropic 的一些最受欢迎功能——Claude Code 桌面版、AskUserQuestion 工具、待办事项列表——就是这样出现的。

演示和评估代替文档优先

团队已经基本用”原型优先”思维取代了”文档优先”思维。不再举办传统的站会，而是分享新想法的演示。内部用户试用，真正有参与度的会被进一步打磨并更广泛地分享。

因为你可以一个下午就做出原型，错误的赌注成本很低。

当 Noah 分享他的 Claude Code 插件规范时，返回的原型已经接近生产就绪。那个原型成了团队最终交付的东西的锚点，因为它使团队能够快速验证 UX。

提示：写完规范后，把它发给 Claude Code，看看它是否能构建出来。即使是一个粗略的原型也会改变对话。

除了演示，评估（evals）也可以帮助让抽象的产品感觉更具体。对于 agent teams 功能，Conner 手工制作了一组评估来理解什么时候 agent 团队工作良好，什么时候不工作，以及需要修复什么。测量功能是否有效使改进它变得更容易。

用新模型重新审视已有功能

现在，你发布了一个功能，然后一个更好的模型出来了，你的功能可能会显著改善。每个模型发布都是一个隐含的提示，让你重新审视你已经构建的东西。

捕捉这些时刻的最佳方法是成为每日活跃用户，并故意要求它做你认为可能太难的事情。有时它奏效了，这就是产品需要迎头赶上的信号。

Claude Code with Chrome 就是这样发生的。团队注意到用户用 Claude Code 构建 Web 应用，然后手动切换到 Chrome 中的 Claude 来测试它。用户手动提示并在两个工具之间复制粘贴指令。它工作得足够好，团队意识到这应该是一个内置功能。

如果用户正在拼凑一些东西，那是你可以构建到产品中的脚手架。

做简单的事

在 Anthropic，每个团队都有一个指导原则：做有效的简单事情。

如果你的产品巧妙地绕过了模型限制，当下一个模型发布时，变通方法就变成了不必要的复杂性。这就是为什么”做简单的事”很重要：你的实现越简单，当新能力到来时就越容易交换进去。

当首次在 Claude Code 中发布待办事项列表时，模型不会可靠地在完成项目时勾选它们。所以每隔几条消息添加系统提醒，会定期推动代理更新自己的待办事项列表。它奏效了，但这只是一个 hack。随着下一个模型，这个行为免费来了，团队完全删除了提醒。

这个模式反复出现：系统提示和工具描述曾经经过大量工程设计以补偿模型限制，团队能够随着每个模型减少提示，包括 Opus 4.6 的 20% 减少。

你不需要学编程

重点来了：你不需要会写代码，你只需要会描述清楚你想要什么。

这本身就是 PM 的核心能力。

你不需要懂 React 的细节，不需要知道 Tailwind 的类名怎么拼，你只需要说：“我要一个登录页，有手机号输入框、验证码按钮、下一步按钮，黑色主色调。”

AI 会帮你搞定剩下的一切。

一个真实的例子

上周我想做一个”录音转写 App”的原型。以前我可能要写两页 PRD，跟开发对齐半天，然后等一周才能看到东西。

这次我只做了一件事：打开 Claude Code，说：

“帮我做一个移动端录音页。顶部是标题，中间是一个大的录音按钮，下面是最近录音列表。录音按钮按下后变成停止按钮，列表里显示录音时长和日期。”

10 分钟后，我拿到了一个能跑的页面。

我发现列表样式不太对，又补了一句：“把列表项改成卡片样式，左边是标题和时间，右边有个播放按钮。”

5 分钟后，样式改好了。

整个过程中，我没有写一行代码，我只在做 PM 最擅长的事情——描述需求，然后调整。

最后我把这个原型发到群里，大家直接在手机上打开试了试，反馈马上就来了。

这不是画图，这是做东西。

决策成本降低的意义

当你能把想法在 1 小时内变成可触摸的东西，你就不再需要跟老板、跟开发、跟任何人”争夺资源”了。你可以说：“老板，这个想法我已经做出来了，你来看看。”

决策成本从”做出来要两周”降到了”试试只要一小时”，游戏规则就变了。

那个”窗口期”问题

我知道有人在想什么：“AI 都能直接写代码了，那还要 PM 做原型干嘛？直接让 AI 做产品不就行了？”

理论上是对的。长期来看，AI 确实可能直接从需求描述生成产品。

但问题是，我们不在那个未来。我们还在传统团队里，还需要跟开发、跟设计、跟老板协作。这个过渡期可能是一两年，也可能是三五年。

在这个窗口期里，能用 AI 快速做原型的 PM，比只会写 PRD 的 PM，有巨大优势。

你不需要等三五年。你只需要比你的同事快一步就够了。

如何开始

如果你有点心动，我建议你从这三步开始：

选一个 AI 编程工具

Claude Code、Cursor、Bolt，都行。选一个你觉得界面顺手的。

找一个周末

不需要辞职，不需要全职，给自己一个完整的下午，跟着文档跑通第一个示例。

挑一个小需求

不是你工作里最重要的那个，找一个你想做但一直没有资源的。试着把它做出来。

做完这三步，你会发现自己打开了新世界的大门。

写在最后

这篇文章不是在说”所有 PM 都应该转行做工程师”。

PRD 还是需要的，沟通还是重要的，开发团队的价值也不会消失。

但如果你是个 PM，而且你有过”等开发资源等到绝望”的时刻，那你应该知道我在说什么。

AI 时代来了。有些人还在用它写邮件，有些人已经开始用它做产品了。

你是哪一个？