5. AI PM 的工具箱：以产出倒逼工具，让 AI 把你变成超级人类

欲善其工，必先利其器。工具是人能力的延伸，工具可以让人发挥远超过自身的价值。

前四节，我们分别探讨了信息革命的宏观坐标、模型即产品的范式跃迁、产品 Agent 化的形态变化 与 有战斗力的 AI PM 的能力模型。这些讨论回答的是*「是什么」与「为什么」*。

本节要回答的是最具体的一个问题——在 AI 时代，一个产品经理每天到底应该用什么工具。

一、重新理解工具：AI 不是小弟，是延伸

思想转化：你 + AI = 超级人类

对于一个 AI 产品经理来说，第一个重要的工具一定是 AI。但更重要的，是从思想上完成一次彻底的转化。

很多人总是想「驾驭 AI」——把 AI 当作自己的小弟，安排 AI 做自己不想做的琐碎小事情。这背后的潜台词是：我才是主角，AI 是工具，AI 在帮我提效。

但这种认知在大部分场景下，并没有承认一个根本事实：AI 是远强于你的超级物种。AI 能做你不会做的事情，能在你完全不熟悉的领域里给出专业级别的产出，能把你的能力延展到你原本无法触达的边界。

核心观点

不是 AI 帮你完成你的工作，让你变得更快；

而是你 + AI = 超级人类，你借助 AI 完成了你单独无法完成的事情。

你 + AI ≠ 更快的你。

图 1：两种工具观的根本差异

   ┌──────────────────────┐         ┌──────────────────────┐
   │   小弟视角（错误）    │         │   延伸视角（正确）    │
   ├──────────────────────┤         ├──────────────────────┤
   │ 你 + AI = 更快的你    │   思想   │ 你 + AI = 超级人类    │
   │                      │  ──────▶ │                      │
   │ • 我是主角，AI 是工具 │   转化   │ • AI 是远强于你的     │
   │ • AI 帮我做琐碎的事    │         │   超级物种            │
   │ • AI 能力 ≤ 我的能力   │         │ • AI 做你不会做的事    │
   │ • 收益线性：节省时间   │         │ • AI 能力 > 你的能力   │
   │                      │         │ • 收益指数：能力延展   │
   ├──────────────────────┤         ├──────────────────────┤
   │ 天花板：你自己的能力上限│         │ 天花板：AI 能力的边界  │
   └──────────────────────┘         └──────────────────────┘

为什么这一节迟迟没有写

这一小节迟迟没有动笔，是因为工具的迭代更新速度太快了。而且，大部分人都有自己的工具偏好。如果你给出一个工具的「唯一正确性」答案，肯定会有很多人从很多角度去反驳，而且他们的反驳都是有道理的。

所以阅读这一节，请始终记住一个原则：

最好的工具是下一个工具。
当前讲的工具，都是狭义上、当前可能有一定参考意义的工具。

二、以产出倒逼工具：三个产出，三套工具箱

为什么要从产出出发

工具的种类太多，列表式的工具盘点很容易迷失在细节里。所有的工具都是服务于你的产出的，所以我们需要从产出来倒逼工具——先想清楚要交付什么，再决定用什么。

对一个 AI 产品经理来说，每天工作的核心产出可以收拢为三类：

产出一：能讲明白需求的图表和原型（沟通载体）；
产出二：一个可以实际使用的产品 demo（验证载体）；
产出三：人人可体验可反馈的线上服务（迭代载体）。

这三类产出，分别对应三套工具箱。后续整节内容，都会沿着这条主线展开。

图 2：AI PM 工具箱全景图

   从沟通  ──▶  验证  ──▶  上线
   ▲
   │  ┌──────────────────────────────────────────────────┐
   │  │ 产出一：图表 & 原型                                 │
   │  │   两图一表：原型草图 | 流程/状态图 | 数据表           │
   │  │   工具示例：Excalidraw | Figma | Mermaid |          │
   │  │            飞书文档 | Notion | 任意表格工具          │
   │  └──────────────────────────────────────────────────┘
   │
   │  ┌──────────────────────────────────────────────────┐
   │  │ 产出二：产品 demo                                  │
   │  │   24h 协同伙伴 + 模型 API：让想法在小时级别变成可体验产品 │
   │  │   工具示例：Codex | Cursor | Claude Code |         │
   │  │            OpenAI/Claude/Gemini API Key | 自部署 GPU │
   │  └──────────────────────────────────────────────────┘
   │
   │  ┌──────────────────────────────────────────────────┐
   │  │ 产出三：线上服务                                    │
   │  │   一键部署 + 持续反馈：从本地 demo 升级为人人可访问的服务  │
   │  │   工具示例：Vercel | Cloudflare | Render |         │
   │  │            Hugging Face Spaces | 公司内部云平台      │
   │  └──────────────────────────────────────────────────┘
   ▼

三、产出一：能讲明白需求的图表和原型

从「补齐 corner case」到「面向 AI 的表达」

在 AI 时代，我们依然需要一个能讲明白需求的文档和原型。但是大部分产品经理可以从以前的很多 corner case、边界值定义里面释放出来。

想得全，其实是一种补齐的能力，但补齐不是产品最有价值的地方——当面对的是一个能自己推理、能自己泛化的大模型时，PM 的价值不在于把每一个分支都写满，而在于把核心意图、核心约束、核心评价标准说清楚。

产品经理未来需要构建面向 AI 的需求和原型表达能力。我把第一个工具集合，称之为**「两图一表」**。

图 3：「两图一表」的结构与本质

   ┌──────────────┐   ┌──────────────┐   ┌──────────────┐
   │ 图一          │   │ 图二          │   │ 一表          │
   │ 原型草图      │   │ 流程/状态图    │   │ 数据表        │
   │              │   │              │   │              │
   │ 快速草绘      │   │ 讲明白数据流转 │   │ 当前需求的     │
   │ 突出模块和序   │   │ 讲明白业务模式 │   │ 分析数据       │
   │ 表达"心中构想" │   │ pipeline      │   │ 转化率/漏斗    │
   │              │   │ 状态边界       │   │ 让 AI 理解业务  │
   │ Axure/Figma  │   │ Mermaid       │   │ Excel/Numbers │
   │ /Sketch      │   │ /draw.io      │   │ /Notion       │
   │              │   │ /飞书文档      │   │ /数据看板      │
   └──────┬───────┘   └──────┬───────┘   └──────┬───────┘
          │                  │                  │
          └──────────────┐   │   ┌──────────────┘
                         ▼   ▼   ▼
                    ┌──────────────────┐
                    │     本质：        │
                    │   高质量的 Prompt  │
                    └──────────────────┘

两图一表，分别讲什么

图一指的是：快速草绘原型图——非常简单但是能表达明白你心中构想的原型图，重点突出模块和序。不需要像素级精致，不需要交互完整，只需要让看的人（包括 AI）一眼明白「哪里有什么、先后是什么」。

图二指的是：流程图或者状态图——能讲明白数据流转的 pipeline、业务的模式。这一类图回答的是「事情怎么跑起来」的问题，是从静态结构到动态行为的桥梁。

一表指的是：数据表——产品需要提供当前需求的分析数据、转化率等等，让 AI 可以快速理解业务现状和问题、业务中面临的漏斗关系等等。没有数据的需求文档，对 AI 而言是「无脚本的演员」，它不知道要往哪里发力。

两图一表的本质：高质量的 Prompt

但是这些都是中间过程，是当下产品经理能快速和 AI 交互的 prompt 的形式。

核心观点

「两图一表」的本质是一种高质量的 Prompt，

或者说——你内心真实的想法、评价标准，能够快速让 AI 理解你。

图和表只是中间载体。一旦 AI 理解了，这些载体的价值就完成了使命。

工具选择：任意趁手都行

在这个环节，任意的画图工具、表格工具、原型绘制工具都可以。不必纠结「哪个最专业」——这一层的工具差异，远远小于你思考清晰度的差异。

表 1：「两图一表」常见工具速查（仅为参考，并非唯一正确）

产物类型

典型工具

使用场景

成本

原型草图

Axure / Figma / Sketch

头脑风暴、与 AI 描述心中构想、跨职能初稿沟通、需求评审

免费 / 中

流程图 / 状态图

Mermaid / draw.io / 飞书文档

描述业务 pipeline、状态机、Agent 编排

免费 / 低

数据表 / 看板

Excel / Numbers / Notion / 内部 BI

漏斗、转化率、对照实验、效果评测

免费 / 中

四、产出二：一个可以实际使用的产品 demo

你需要一个 24h 在线的协同伙伴

第二类产出，是一个可以实际使用的产品 demo。这一层，你需要的不再是画图工具，而是生产工具。

具体来说，你需要一个强大的 24h 在线的协同合作伙伴，它能让你的想法快速变成产品，可以随时修改和体验。强力推荐三类工具任选其一：Codex、Cursor、Claude Code。

它们的共同特征是：

自然语言驱动，不需要你写每一行代码；
多文件、多步骤的工程能力；
与 IDE 或 Terminal 深度集成，所见即所得。

借助它们，从想法到现实，可以在小时级别完成。然后快速迭代——所有后续的环节是**「需求即生产」**：一边提需求，一边就在生产。

图 4：「需求即生产」的循环

              产生想法
              （业务/用户洞察）
                  │
                  ▼
   立即体验  ◀───────────▶  描述给 AI
   （自己+小范围）           （自然语言 prompt）
              ▲                    │
              │  需求即生产           ▼
              │  Need = Build      小时级产出
              │                    （可运行的 demo）
              └─────────◀──────────┘

除了协同伙伴，还需要 API Key

除了工具伙伴，你还需要自己准备几个效果不错的大模型 API Key。

所有的事情不能终止于纸上谈兵。我们使用 AI 构建的产品也是 AI 的，所以里面肯定需要用到很多模型能力——不管是语音和图像的生成，还是多模态的理解。

核心观点

每个 AI 产品经理，都必须有自己的大模型 API Key。

它和你手中的电脑一样重要。

甚至有很多人自己直接买了 GPU 显卡，自己部署自己的模型——这是更高级的要求了。

工具卡：常见组合速查（仅供参考）

协同伙伴： Cursor（IDE 集成）/ Claude Code（Terminal 原生）/ Codex（CLI 与 IDE）
对话与推理： Claude Sonnet/Opus / GPT 系列 / Gemini / DeepSeek / 国内大模型 API
多模态： GPT-4o/4.1 / Gemini / Qwen-VL（图像、语音、视频理解）
生成模型： DALL·E / Midjourney API / Stable Diffusion / Suno（音频）
自部署进阶： vLLM / Ollama / LM Studio + 自购 GPU（如 RTX 4090 / H100）

工具是能力的物理载体

这里讲的「产品 demo」，正是**第四节「动手实现能力」**的工具落点。能力是肌肉，工具是器械——没有 Cursor 这一类协同伙伴，「动手实现」的门槛会高得让大部分 PM 望而却步；但有了它们，门槛被显著降低，动手与否，完全取决于你的意愿。

五、产出三：线上服务，你的 demo 人人可体验可反馈

第三步：很多 PM 还没涉及

从第三步开始，就是很多产品经理现在还没有涉及到的领域——你需要拥有一个云服务平台的权限，把你的想法发布出去。

想法要及时地分享，吸收大家的反馈，然后不断地迭代。
如果生产出来的产品只是在你自己的电脑上，不能快速地去分享、部署、变成人人可以访问的服务，那么效率就会很慢。
要快速发布、快速上线、快速让大家去体验。

图 5：从本地 demo 到线上服务的链路

   ┌─────────┐         ┌─────────┐         ┌─────────┐         ┌─────────┐
   │ 本地 demo│ ──────▶ │ 一键部署 │ ──────▶ │ 线上服务 │ ──────▶ │ 收集反馈 │
   │ 只在你   │         │ 推送到云 │         │ 人人可   │         │ 真实用户 │
   │ 电脑跑   │         │         │         │ 访问     │         │ 行为     │
   └─────────┘         └─────────┘         └─────────┘         ────┬────┘
        ▲              Vercel/             URL/                   │
        │              Cloudflare/         小程序/                埋点+反馈
        │              Render/             App                   +评测
        │              内部平台                                    │
        └──────────────────── 驱动新一轮迭代 ◀──────────────────┘

   ⚠ 合规提醒：如果是企业业务，请使用公司内部服务，避免数据外流引发的合规风险

为什么「上线」是 PM 的能力分水岭

线上服务这一步，看似是工程师/运维的活，但在 AI 时代，它正在成为PM 个人能力的一道分水岭。

原因有三：

1. 反馈速度决定产品速度。 demo 在你电脑上时，反馈来源只有你一个人；demo 在线上时，反馈来源是所有体验过它的人。反馈量级的差异，直接决定迭代速度的差异。

2. 真实环境暴露真实问题。 模型在本地 demo 中表现良好，不代表在真实流量、真实用户输入分布下也表现良好。很多 corner case 只会在线上出现。

3. PM 的「叙事能力」需要载体。 你向高管、向跨部门讲产品方向时，一个可以现场打开的 URL，比一沓 PPT 更有说服力。

合规底线：企业业务请用内部服务

最后一个不能忽略的提醒：

核心观点

为了合规，如果是企业业务，请使用公司内部服务。

公开的云服务（即便是大厂的）也意味着数据离开企业边界，对于涉及客户数据、内部知识库、未公开战略的项目，必须走内部部署 + 内部评审的合规路径。

速度很重要，但合规是不能违反的底线。

六、结语：工具会变，工具观不会变

工具是手段，产出是目的；而比工具与产出都更基础的，是你看待工具的思想。

让我们用一张总图收束本节——从思想转化到三类产出，再到每类产出对应的工具集合，形成一个自上而下的工具决策框架。

图 6：AI PM 工具决策框架

   ┌──────────────────────────────────────────────────────┐
   │ 思想前提：你 + AI = 超级人类（AI 是延伸，不是小弟）        │
   └────────┬─────────────────┬─────────────────┬────────┘
            │                 │                 │
   ┌────────▼────────┐ ┌──────▼────────┐ ┌─────▼────────┐
   │ 产出一：图表&原型 │ │ 产出二：产品demo│ │ 产出三：线上服务│
   └────────┬────────┘ └──────┬────────┘ └─────┬────────┘
            │                 │                 │
   ┌────────▼────────┐ ┌──────▼────────┐ ┌─────▼────────┐
   │ 两图一表          │ │ 24h 协同+API   │ │ 一键部署平台   │
   │                 │ │                 │ │                │
   │ Axure/Figma/    │ │ Cursor/Codex/   │ │ Vercel/        │
   │ Sketch          │ │ Claude Code     │ │ Cloudflare     │
   │ Mermaid/        │ │ Claude/GPT/     │ │ Render/        │
   │ 飞书文档         │ │ Gemini API      │ │ HF Spaces      │
   │                 │ │ Key/自部署      │ │ 或：公司内部     │
   └────────┬────────┘ └──────┬────────┘ └─────┬────────┘
            │                 │                 │
            └─────────────────┼─────────────────┘
                              ▼
   ┌──────────────────────────────────────────────────────┐
   │ 底层原则：最好的工具是下一个工具                          │
   │           ——以产出倒逼工具，不被工具绑架                  │
   └──────────────────────────────────────────────────────┘

这一节列出的所有具体工具，都极有可能在你读到这本书的几个月后被新的工具取代。但有三件事，几乎不会随版本号迭代：

把 AI 当作能力延伸，而不是当作小弟；
从产出倒逼工具，而不是被工具绑架；
亲自把想法跑成线上服务，而不是停留在 PPT。

核心观点

AI PM 的工具箱新原则：

最重要的工具是 AI 本身——它是远强于你的超级物种；
最重要的工作产出是图表与原型 / 产品 demo / 线上服务；
最重要的工具观是——以产出倒逼工具，始终相信「最好的工具是下一个工具」。

工具会变，工具观不会变。

思考题

用今天这一节，做一次自我盘点。

思想前提： 过去一周，你和 AI 的协作方式更像「驾驭小弟」还是「借力延伸」？你最近一次让 AI 做的事，是不是你自己原本完全做不到的？

产出一： 你最近一次提的需求，有没有把「两图一表」准备齐？如果你只交付了文字 PRD，AI 与协作方真的能复现你脑海里的样子吗？

产出二： 你手上有几个可用的大模型 API Key？最近一次提需求之前，你自己有没有先用 Cursor / Claude Code 跑过一个 demo？

产出三： 你最近一个想法，有没有变成一个人人可访问的 URL？如果没有，是工具的问题，还是你「不敢上线」的问题？

找出你工具箱里最薄弱的一环——明天就补上它。

第零章 · 章末小结

AI 时代产品经理的「新起点」

第零章结束了，AI 时代带给人类真正的改变，才刚刚开始。

这五节讲述的，是一个人类文明新的起点下，一个古老的职业突破桎梏，站到人类创新之巅的故事。

我们终将让世人见证——

产品经理这个族群，如何创造璀璨。

—— 第零章 · 完 ——

上一页4. AI PM 的能力模型：一个有战斗力的 AI PM 长什么样下一页第一章：先学会衡量——评测体系的建立

最后更新于 3个月前

这有帮助吗？