这两年很多产品经理用 AI 的方式，其实还停留在「聊天框外包」阶段：让 Codex、Claude Code 或 Cursor 帮忙写一版 PRD，整理一段会议纪要，生成几个用户故事。

这当然有用，但不够。产品经理真正累的地方，往往不是写 PRD 的那一刻，而是 PRD 前后那堆重复但不能省的工作：需求池要清洗，用户访谈要设计，访谈记录要拆解，机会点要归因，功能优先级要排序，指标看板要提前想清楚，最后还要把抽象方案变成团队能看懂的图。

如果每次都重新打开一个聊天框，从零解释背景、规则、输出格式，那 AI 只是一个临时实习生。真正值得沉淀的，是把这些高频流程变成 Agent 能反复调用的 Skill。

Prompt 适合解决一次对话，Skill 更适合沉淀一条工作流。产品经理应该很容易理解这件事，因为我们每天干的本来就是把混乱信息变成可执行流程。以前是给团队设计流程，现在也要开始给 Agent 设计流程。

我最近翻到一个比较适合 PM 看的 GitHub 仓库：phuryn/pm-skills。它不是那种泛泛的 prompt 合集，而是按产品工作流拆了很多 agentic skill，从 discovery 到 strategy、execution、launch、growth 都有。今天不做大而全盘点，只挑 7 个最适合产品经理先装的 Skill，按一条真实的 PM 工作流讲。

不是装了就变强，没这种好事。更准确地说，它们像是给你的产品流程装上 7 个半自动工位。你还是那个要判断、要拍板、要背锅的人，但很多重复整理、初稿生成、结构化分析，可以先让 Agent 跑一版。

1. analyze-feature-requests：先把需求池洗干净

第一个建议先看 analyze-feature-requests。它解决的是产品经理最常见的痛苦：需求池太脏。

客服丢一点，销售丢一点，老板开会随口说一点，用户访谈里又冒出来一点。每条都像是真的，每条也都像可以先放一放。PM 最后面对的不是「需求」，而是一锅信息浓汤。

以前我处理这种东西，最常做的动作就是手动打标签：体验类、增长类、留存类、商业化类。打着打着就开始怀疑人生，因为标签这东西很容易受当下情绪影响。今天觉得某个需求价值高，明天被线上 bug 折磨一下，又觉得所有体验问题都该排最高。

analyze-feature-requests 的价值，是让 Agent 先帮你做一版结构化清洗：主题是什么、影响哪些用户、背后可能是什么痛点、证据强不强、下一步要不要继续验证。注意，是先做一版，不是替你决定。产品经理最该警惕的不是 AI 做得不够多，而是 AI 做得太像真的。它整理出来的东西看起来很有条理，你就很容易懒得追问。

我的建议是，把它当成需求池的第一轮清洗机。它负责把脏水过滤一遍，你负责判断哪些真的是金子，哪些只是看起来闪。

2. interview-script：别把用户访谈做成自我说服

第二个是 interview-script。很多 PM 做用户访谈时，会犯一个很隐蔽的错误：问题问得太像在求认同。

「你觉得这个功能有用吗？」

「如果我们做了这个，你会不会用？」

「你现在是不是很需要一个更智能的工具？」

用户一般都很善良。他会说，嗯，有用，挺好的，可以试试。然后你回去写需求，兴奋得像捡到宝。上线以后没人用。

interview-script 的价值，是帮你把访谈问题设计得更像研究，而不是一场产品经理的自我安慰。它会提醒你围绕用户过去的行为、具体场景、替代方案、决策过程去问，而不是围绕你脑子里的功能幻觉去问。

我会把它放在所有用户访谈之前，尤其是做新功能、新方向、新人群的时候。产品经理不要高估自己的临场提问能力，现场太容易被用户的一句话带跑。提前让 Agent 搭一版访谈脚本，至少能保证问题一开始没有歪。

3. summarize-interview：访谈总结不是把原话贴进文档

第三个是 summarize-interview。访谈做完以后，真正折磨人的事才开始。一小时录音转写出来两万字，用户说了很多，但真正有价值的可能只有几句。更麻烦的是，用户说出来的需求，往往不是他真正的问题。

他说想要一个提醒功能，也许真正的问题是他记不住流程；他说想要导出 Excel，也许真正的问题是他需要给领导汇报；他说界面太复杂，也许真正的问题是他不知道下一步该点哪里。

summarize-interview 适合把访谈记录拆成痛点、动机、阻碍、现有替代方案、用户原话和潜在机会点。它的价值不只是写总结，写总结太简单了。它真正有用的地方，是让 PM 不要被用户的表层表达牵着走。

产品经理最值钱的能力不是把用户原话贴进文档，而是听懂用户没说出来的那半句。

4. opportunity-solution-tree：别从问题直接跳到方案

第四个是 opportunity-solution-tree。很多产品团队最大的问题，是从问题直接跳到方案。

用户流失了，那做个激励体系吧。转化低了，那改个按钮吧。新用户不会用，那加个新手引导吧。

不是说这些方案一定错，而是它们太快了。快到中间少了一层东西：机会点。

opportunity-solution-tree 的作用，是帮你把用户目标、机会点、解决方案和实验拆开。它会逼你先问：用户真正想完成什么？中间卡在哪里？有哪些机会点？每个机会点下面有哪些可能方案？哪个方案最值得先验证？

这对产品经理很重要，因为 PM 很容易被「做点什么」绑架。你一旦进了排期会，就会天然想把事情变成一个功能。可很多时候，真正该做的不是功能，而是改文案、改默认值、改流程顺序、改触达时机，甚至什么都别做，先观察。

机会树的价值，就是把你从「我要做功能」拉回「我要解决问题」。

5. prioritize-features：优先级排序需要一个可被挑战的初版

第五个是 prioritize-features。功能优先级，大概是所有 PM 都需要，但所有 PM 都不太愿意承认自己需要帮助的东西。

表面上看，优先级排序是一套理性方法：用户价值、商业价值、实现成本、风险、战略匹配、数据证据。听起来非常清爽。实际开会的时候，老板说这个很重要，销售说客户明天就要，研发说这个不可能这周做，运营说活动已经排好了。PM 坐在那里，像一个人肉路由器。

prioritize-features 的价值，不是替你拍板。真要拍板，还是人来。它更像是会前的冷静剂。

你把候选需求、业务目标、用户证据、资源约束丢进去，让 Agent 先按一套维度给出排序和理由。这样你进会议室的时候，不是拿着一堆「我觉得」，而是拿着一份可以被讨论、可以被挑战、可以被修改的初版判断。

产品经理很多时候缺的不是绝对正确，而是一个能让团队开始讨论的清晰版本。

6. metrics-dashboard：上线前就该想清楚怎么验证

第六个是 metrics-dashboard。这个我会放在功能上线前，而不是上线后。

很多团队有个毛病，功能上线以后才想怎么复盘。上线前文档写得热火朝天，目标也很漂亮：提升用户体验、增强用户粘性、提高转化效率。这些词我都写过，写完以后自己都不信。

metrics-dashboard 适合帮 PM 做一件很朴素的事：把一句漂亮目标变成能观察的指标。

比如你要做一个新手引导，到底看什么？新用户完成率？关键步骤转化？第二天留存？触发引导后的跳出率？用户是否更快到达 aha moment？

一旦开始拆指标，需求就会变得诚实。如果一个功能连观察指标都说不清，它可能根本还没有想清楚。

metrics-dashboard 不是帮你变成数据分析大师，它更像上线前的追问器。别只写「提升体验」，你到底准备怎么证明体验被提升了？

7. imini-api-integration-skill：把生图、生视频接进产品表达链路

前 6 个 Skill 主要解决产品思考链路：需求池清洗、访谈设计、访谈总结、机会树、优先级和指标看板。但产品经理还有一个现实问题：你写得再清楚，别人也不一定看得懂。

尤其是涉及新功能、新交互、新活动、新产品概念的时候，一张图经常比三页文字好用。所以第七个，我会放 imini-api-integration-skill。

这里多说几句，因为很多人可能还不知道 iMini AI 是什么。

iMini AI 是一个一站式 AI 生图、生视频聚合平台。你可以理解成，它把多种图像和视频模型放到一个入口里，比如 Nano Banana 系列、gpt-image-2、Kling、Seedance 等，不用你为了一个模型单独找接口、看文档、写请求。

如果只是普通使用，直接在 iMini 网站上生成图片和视频就够了。但对产品经理或者产品技术团队来说，更有价值的是把它接进 Agent 工作流，也就是这个 imini-api-integration-skill。

它不是简单告诉你「去调用某个接口」，而是让 Codex、Claude Code、Cursor 这类 Agent 理解 iMini 的模型选择、异步任务、轮询、结果提取和错误处理。换句话说，你不是让 AI 临时帮你写一段 API 调用，而是让它知道这套多模态生成能力应该怎么稳定接入。

安装方式很简单：

npx skills add imini-ai/imini-api-integration-skill

然后到这里获取 API Key：

https://imini.ai/api-keys

再把 key 放到环境变量里：

export IMINI_API_KEY="你的 key"

装好以后，你可以直接在 Codex 里说：

用 iMini 生成一张 16:9 的产品功能概念图，主题是 AI 会议纪要自动提取待办事项，风格要像干净的 SaaS 官网插图。

也可以更贴近 PM 文档场景：

用 iMini 生成一张适合放进 PRD 的功能流程示意图，重点表现用户上传录音、AI 转写、提取待办、同步日历这四步，画面简洁，不要太营销化。

如果你是偏技术的 PM，还可以让 Agent 直接生成接入代码：

帮我写一段 TypeScript，调用 iMini 生成产品原型图，要求包含 submit、poll、结果提取和错误处理。

这就是它和普通网页生图工具的区别。网页工具适合一次性出图，Skill 适合把出图、生视频能力放进你的 Agent 工作流里。

比如你前面用 pm-skills 整理完用户问题、机会树和功能优先级，最后让 iMini skill 生成一张功能示意图，放进方案评审。此时它不只是一个「画图工具」，而是产品表达链路的一部分。

我觉得这对产品经理挺重要。PM 的工作从来不是写文档，而是让一群人对一件还不存在的东西，形成足够接近的想象。文字能做到一部分，图能做到另一部分。如果 Agent 能把这两部分串起来，沟通成本会低很多。

Skill 不是收藏夹，是工作台

我不建议大家看到这里就一股脑全装。

Skill 不是越多越好。这件事我自己也踩过坑。看到一个仓库里几十个 skill，就觉得自己马上要变成赛博产品总监。结果装完发现，真正高频用的也就几条。很多 Skill 名字很酷，但和你的日常工作流对不上，最后只会变成 Agent 的噪音。

更合理的方式是先问自己一个问题：我每周重复做三次以上的 PM 工作是什么？

如果你每周都要整理需求池，先装 analyze-feature-requests；如果你经常做用户访谈，先看 interview-script 和 summarize-interview；如果你总卡在排期和优先级，prioritize-features 会更实用；如果你写了很多目标但复盘总是发虚，metrics-dashboard 值得放进上线前流程；如果你经常要把抽象方案讲给老板、研发、设计、销售听，那就把 iMini skill 接进来，让 Agent 帮你把方案表达成图或视频。

别把 Skill 当收藏夹，把它当工作台。

以前我们说产品经理要沉淀方法论。现在方法论不应该只停在脑子里、PPT 里、飞书文档里。它可以变成 Agent 能反复调用的流程。

你不是每次都重新解释自己怎么做需求分析，而是把需求分析方式封装成 Skill；你不是每次都重新告诉 AI 怎么写访谈问题，而是把访谈方法封装成 Skill；你也不是每次都让 AI 随便画一张图，而是把产品表达、模型选择、生成参数、结果保存这些动作放进稳定链路。

这才是 Skill 真正有意思的地方。不是让 AI 更聪明，而是让你的工作流不再每次从零开始。

最后把 7 个入口放在这里：

1. analyze-feature-requests
2. interview-script
3. summarize-interview
4. opportunity-solution-tree
5. prioritize-features
6. metrics-dashboard
7. imini-api-integration-skill

如果只想先试一个，我建议从 analyze-feature-requests 开始。需求池这东西太真实了，每个产品经理都逃不掉。

能不能从一堆混乱声音里，整理出一条可以往前走的产品路径，大概也是 PM 这份工作最难被替代的地方。Skill 可以帮你清场，但路怎么走，还得你来判断。