夜雨聆风
我给自己造了一套 PM AI 工具链
一个 AI 产品经理是怎么用 Claude Code 插件把自己从重复劳动里解放出来的——这是这个系列的第一篇，讲设计思路和全景，后面每篇会拆一个具体场景。
上周四下午开产品会，老板说了一句话：”数据导出做一下，应该不复杂。”
我点点头，打开电脑，回到工位。
然后我敲了这一行命令：
/pm:feature-flow 数据导出
Claude 问我：”你想对数据导出做什么？”给了五个选项：头脑风暴、需求拆解、写 PRD、评估复杂度、或者你有更具体的问题。
我选了头脑风暴。
它开始问我一连串问题：谁在什么场景下需要导出数据？导出的目的是汇报还是做分析？导出之后在哪儿用——发邮件、导进 Excel、还是对接其他系统？数据量大概是什么级别？
二十分钟后，我从一个模糊的”做数据导出”，变成了三个拆解清晰的子功能，每个都有使用场景、用户角色、边界说明。
然后我直接说”帮我生成这三个子功能的 PRD”，大概又过了十分钟，三份结构完整的 PRD 出来了。
这件事本来在以前需要我自己先查一圈现有功能、想半天用户场景、找一个 PRD 模板、填一下再修改——大概要两个小时。
我不是在炫耀效率。我只是想说，这套工具是我真的在用的，不是演示 Demo。
为什么不直接用 ChatGPT
这是最多人会问我的问题。
我也用过。用了挺长一段时间。
ChatGPT 最让我头疼的问题不是它回答得不好，是它没有记忆。
每次开一个新对话，我都要重新解释一遍：我在做的是什么产品、我们的技术栈大概是什么、我们的用户主要是谁、公司规模多少、B 端还是 C 端。不解释，它给的东西就太通用了，用处不大。解释完，这个对话用完了就散了，下次再来还是从头开始。
有一段时间我想了个办法，把这些背景信息存成一段固定的”系统提示词”，每次手动粘贴进去。用了一周，嫌麻烦，放弃了。
更深的问题是：ChatGPT 帮你”做事”，但它不懂你这个 PM 的思维方式。
它不知道你碰到一个需求时，你的第一反应应该是先问”谁在用”而不是直接想功能点。它不知道写 PRD 的时候，”业务规则”这个模块比”界面说明”更重要。它不知道评估客户需求的时候，要先区分”客户说的”和”客户想要的”。
这些是 PM 的方法论，不是通用知识。
Cursor 不是我的工作场景
另一个常见的问题是 Cursor。
Cursor 很好用，我有时候也会用，但它解决的不是我的问题。
Cursor 是为写代码优化的。它的上下文是代码仓库，它的思维方式是”帮你写这段逻辑”。
我的工作上下文是什么？
是一堆 PRD 文档、一个需求池、几十条客户反馈、上周的产品会纪要、还有老板在飞书里随手发过来的一句话需求。
我需要的不是代码补全，是帮我理清楚这些信息之间的关系，再帮我做判断和产出。
这两个场景差得很远。
Claude Code 给了我一个不一样的思路
Claude Code 本来是开发工具，我一开始也没想到会用它做 PM 的工作。
真正让我想到这件事，是因为 Claude Code 有一套插件机制：Agent、Command、Skill 三层架构。
Skill 是最底层的，可以理解为一个”专项知识包”——比如”如何写一份好的 PRD”、”如何设计用户研究方案”、”如何识别需求里的隐藏复杂度”。
Command 是可以直接调用的命令——比如 /pm:feature-flow、/pm:bug-investigate。
Agent 是更上层的协调者，可以在不同 Command 之间调度。
这三层加起来，意味着你可以做一件事：把你作为 PM 的方法论，固化到插件里。
不是让 AI 帮你做事。是把你的专业方法论教给 AI，让它按你的思路做事。
这是一个完全不同的思路。
我给自己造了什么
我搭建的这套 PM 插件，目前包含六个主要命令：
/pm:feature-flow，功能全流程的总入口。从模糊想法到可执行 PRD，一个命令覆盖”想清楚→拆清楚→写清楚”全过程。这是用得最频繁的一个，也是今天讲的那个数据导出故事的主角。
/pm:user-research，用户研究助手。大多数小团队没有专职用研，这个命令帮我设计访谈提纲、问卷、用户画像，以及可用性测试方案。不是银弹，但有它之前我很少会主动做用研，现在至少会去做。
/pm:evaluate-client-request，客户需求评估。B 端 PM 的日常痛苦：客户说”这个功能很简单”，但其实背后有一堆你还没发现的复杂度。这个命令帮我系统识别隐藏复杂度，也帮我想清楚怎么跟客户回复。
/pm:bug-investigate，Bug 业务调研。Bug 来了，我最怕的不是 Bug 本身，是不知道影响范围。以前要等开发查完才知道”这个问题大不大”，现在我可以先从业务逻辑层面做初步调研，生成一份业务影响报告和验收清单，不需要看代码。
/pm:plan-iteration，迭代排期规划。Sprint Planning 拍脑袋，排完发现工作量超了，或者有两个功能强耦合忘了放一起——这些是常见的坑。这个命令帮我做合理性检查，识别排期里的风险点。
/pm:verify-feature，功能验收闭环。PRD 写完就进了文件夹，等功能开发完了再捞出来对一遍，往往发现有几个逻辑点没对上。这个命令帮我做验收，对照 PRD 逐项过，生成”符合/偏差/未覆盖”的清单。
六个命令，覆盖了我日常工作里最容易卡壳的六个节点。
设计这套工具的时候，我想了几件事
第一，PM 的文档不能有代码语言。
我见过很多”AI 生成的 PRD”，里面出现了”调用 getUser() 接口”、”写入 MySQL 的 orders 表”这种描述。这对 PM 没用，反而会让你的文档显得像是开发草稿。
我在设计 Skill 的时候，专门规定了一条：所有产出都用业务语言。不出现代码路径、函数名、表结构。用”用户下单后，系统记录订单状态”而不是”调用 createOrder() 写入数据库”。
这是写给人看的文档，不是写给机器执行的脚本。
第二，宁可多问一句，不替用户做决定。
这是我踩坑最多的地方。
早期版本的插件，AI 会直接帮你”推断意图”——你说”帮我写数据导出的 PRD”，它就直接开始写了，写完给你看。
问题是，这个推断往往是错的。
“数据导出”是什么？是单条记录导出，还是批量导出？是 Excel 还是 CSV？是实时导出还是异步任务？这些问题不问清楚，写出来的 PRD 方向就跑偏了。
后来我改了设计：所有命令都必须先确认意图，不猜测，不跳过。就算多一个交互步骤，也比给你一份方向错了的文档要好。
第三，苏格拉底式提问，而不是直接给答案。
这是最有意思的一个设计决策。
传统的 AI 使用方式是”你问，它答”。你说”帮我列一下数据导出的用户场景”，它给你一个列表。
但这会让你变懒。你看完列表，点点头，觉得好像差不多，然后直接用了。有没有什么重要的场景被漏掉了？不知道，反正 AI 帮我想了。
我想要的是相反的效果——AI 来问我，逼我自己想清楚。
“谁在用这个功能？””他们在什么情况下会触发导出？””导出之后拿来干什么？”
这些问题我都知道答案，但如果不被追问，我不一定会系统地想一遍。被追问之后，我的思路反而更清楚了。
产出是我自己的，AI 只是帮我把思路逼出来。
第四，插件之间要能协同。
用户研究发现了新的痛点 → 用功能全流程拆解成需求 → 用迭代规划排进下一个 Sprint → 客户来问”这个什么时候做”时用需求评估生成回应话术。
这是一条链，不是六个孤立的工具。我在设计的时候，让每个命令的产出格式尽量保持一致，这样上一个命令的输出可以直接喂给下一个命令。
我觉得大多数 PM 都还没想清楚一件事
“用 AI 提效”这件事，大多数人的做法是：遇到一个任务，让 AI 帮你做。
这当然也有用，但上限有限。
因为你每次都在从零开始，每次都在用通用的 AI，每次都要重新解释背景。AI 不知道你的思维框架，不知道你的输出标准，不知道你的用户是谁。
更有价值的做法，是把你作为 PM 的方法论本身沉淀下来，变成可以反复调用的东西。
这不只是”保存了一个好用的 Prompt”。是你在想一个更根本的问题：我作为产品经理，我的核心方法论是什么？如果要教一个新人或者教一个 AI，我会怎么描述我的思考方式？
这个问题本身就很有价值，跟 AI 无关。
接下来这个系列会讲什么
这篇是开篇，说的是整体思路和全景。
后续六篇，每篇聚焦一个具体场景：
-
第 2 篇：功能全流程——”数据导出”这个需求是怎么从一句话变成三份 PRD 的，把过程完整复现一遍
-
第 3 篇：用户研究——小团队没有用研，PM 怎么用 AI 做一场”还说得过去”的用研
-
第 4 篇：客户需求评估——客户说”这个很简单”，我怎么系统地拆穿这句话
-
第 5 篇：Bug 调研——线上出了 Bug，PM 在等开发之前能做什么
-
第 6 篇：迭代排期——Sprint Planning 怎么用 AI 做合理性检查
-
第 7 篇：功能验收——PRD 写完到功能上线，怎么做闭环
每篇会有完整的操作过程，包括我实际用的命令、AI 的真实输出、以及我觉得好用或者不好用的地方。
不是功能介绍，是真实使用记录。
如果你也在用 Claude Code，或者对这类 PM 工具链感兴趣，可以关注一下后续更新。
（这个系列背后对应的是我在 Claude Code 里搭的一套 PM 插件。如果后续有需要，我会考虑整理出来分享。）
关于作者
Derek，AI 产品经理，目前专注于用 AI 工具提升产品团队的工作效率，核心理念始终是一个：不是让 AI 替代 PM，而是把 PM 的方法论固化到 AI 插件里，让 AI 成为你的方法论执行引擎。
公众号关注后回复「PM插件」获取工具链介绍
感谢你读到这里。如果这个系列对你有启发，欢迎转发给同样在探索 AI + PM 工作方式的朋友