> For the complete documentation index, see [llms.txt](https://book.likun.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://book.likun.ai/00-intro/05aipm-gong-ju-xiang.md). # 5. AI PM 的工具箱：以产出倒逼工具，让 AI 把你变成超级人类 > 欲善其工，必先利其器。工具是人能力的延伸，工具可以让人发挥远超过自身的价值。 *** 前四节，我们分别探讨了**信息革命的宏观坐标**、**模型即产品的范式跃迁**、**产品 Agent 化的形态变化** 与 **有战斗力的 AI PM 的能力模型**。这些讨论回答的是\*「是什么」*与*「为什么」\*。 本节要回答的是最具体的一个问题——**在 AI 时代，一个产品经理每天到底应该用什么工具**。 *** ## 一、重新理解工具：AI 不是小弟，是延伸 ### 思想转化：你 + AI = 超级人类 对于一个 AI 产品经理来说，第一个重要的工具一定是 AI。但更重要的，是**从思想上完成一次彻底的转化**。 很多人总是想「驾驭 AI」——把 AI 当作自己的小弟，安排 AI 做自己不想做的琐碎小事情。这背后的潜台词是：*我才是主角，AI 是工具，AI 在帮我提效*。 但这种认知在大部分场景下，并没有承认一个根本事实：**AI 是远强于你的超级物种**。AI 能做你不会做的事情，能在你完全不熟悉的领域里给出专业级别的产出，能把你的能力*延展*到你原本无法触达的边界。 {% hint style="info" %} **核心观点** 不是 AI 帮你完成你的工作，让你变得更快； 而是**你 + AI = 超级人类**，你借助 AI 完成了你单独无法完成的事情。 **你 + AI ≠ 更快的你。** {% endhint %} **图 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 的形式。 {% hint style="info" %} **核心观点** 「两图一表」的**本质**是一种高质量的 Prompt， 或者说——你内心**真实的想法、评价标准**，能够快速让 AI 理解你。 图和表只是中间载体。一旦 AI 理解了，**这些载体的价值就完成了使命**。 {% endhint %} ### 工具选择：任意趁手都行 在这个环节，**任意的画图工具、表格工具、原型绘制工具都可以**。不必纠结「哪个最专业」——这一层的工具差异，远远小于你思考清晰度的差异。 **表 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 的，所以里面肯定需要用到很多模型能力——不管是**语音和图像的生成**，还是**多模态的理解**。 {% hint style="info" %} **核心观点** **每个 AI 产品经理，都必须有自己的大模型 API Key。** 它和你手中的电脑一样重要。 甚至有很多人自己直接**买了 GPU 显卡，自己部署自己的模型**——这是更高级的要求了。 {% endhint %} **工具卡：常见组合速查（仅供参考）** * **协同伙伴：** `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 更有说服力**。 ### 合规底线：企业业务请用内部服务 最后一个不能忽略的提醒： {% hint style="info" %} **核心观点** **为了合规，如果是企业业务，请使用公司内部服务。** 公开的云服务（即便是大厂的）也意味着**数据离开企业边界**，对于涉及客户数据、内部知识库、未公开战略的项目，必须走**内部部署 + 内部评审**的合规路径。 速度很重要，但**合规是不能违反的底线**。 {% endhint %} *** ## 六、结语：工具会变，工具观不会变 工具是手段，产出是目的；而比工具与产出都更基础的，是**你看待工具的思想**。 让我们用一张总图收束本节——**从思想转化**到**三类产出**，再到**每类产出对应的工具集合**，形成一个自上而下的工具决策框架。 **图 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。 {% hint style="info" %} **核心观点** **AI PM 的工具箱新原则：** * 最重要的工具是 AI 本身——它是远强于你的超级物种； * 最重要的工作产出是**图表与原型** / **产品 demo** / **线上服务**； * 最重要的工具观是——**以产出倒逼工具，始终相信「最好的工具是下一个工具」**。 工具会变，工具观不会变。 {% endhint %} *** {% hint style="warning" %} **思考题** **用今天这一节，做一次自我盘点。** **思想前提：** 过去一周，你和 AI 的协作方式更像「驾驭小弟」还是「借力延伸」？你最近一次让 AI 做的事，**是不是你自己原本完全做不到的**？ **产出一：** 你最近一次提的需求，有没有把「两图一表」准备齐？如果你只交付了文字 PRD，AI 与协作方真的能复现你脑海里的样子吗？ **产出二：** 你手上有几个可用的大模型 API Key？最近一次提需求之前，**你自己有没有先用 Cursor / Claude Code 跑过一个 demo**？ **产出三：** 你最近一个想法，**有没有变成一个人人可访问的 URL**？如果没有，是工具的问题，还是你「不敢上线」的问题？ **找出你工具箱里最薄弱的一环——明天就补上它。** {% endhint %} *** ## 第零章 · 章末小结 ### AI 时代产品经理的「新起点」 第零章结束了，**AI 时代带给人类真正的改变，才刚刚开始**。 这五节讲述的，是*一个人类文明新的起点下，一个古老的职业突破桎梏，站到人类创新之巅的故事*。 我们终将让世人见证—— > **产品经理这个族群，如何创造璀璨。** *—— 第零章 · 完 ——* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://book.likun.ai/00-intro/05aipm-gong-ju-xiang.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.