产品经理技能专题：用 Product Design 与 Superpowers 完成需求澄清、方案取舍和执行交付

产品经理使用 AI，最容易掉进两个坑：要么让它直接写 PRD，拿到一篇看似完整、实际没有决策的长文；要么让它直接出原型或拆开发任务，结果范围、用户问题和验收标准全靠开发猜。

更可靠的方式是让不同技能承担不同角色：有人负责把模糊想法问清楚，有人负责检查已有流程，有人负责探索方向，有人负责把已经确认的决定写成可执行计划。本文介绍的是当前会话真实可用的 Product Design 与 Superpowers 技能，不是“产品经理会用 AI”的概念清单。

本文以一个通用但真实常见的任务为主线：“用户总说找不到已保存内容，我们要不要在移动端增加‘已保存’入口？” 最终不是交付一份漂亮 PRD，而是交付一套能让团队决定“做不做、做哪种、怎么验证”的任务包。

最终成果包含：

• 一份问题与需求澄清记录；
• 一份基于现有流程证据的审计结论；
• 三种可比较的方案方向及取舍；
• 一份可交给设计、开发或 AI Agent 的执行计划；
• 一份验收标准、风险边界和停止条件。

文中“已保存入口”是脱敏示例，不表示某个具体产品已经发现、开发或验证过该问题。请用你自己的研究记录、埋点、客服反馈、截图或可访问页面替换它；没有证据时就写“待验证”。

先分清五项技能：谁做什么，谁不该越界

技能获取与安装

这些链接是获取页或源码页，不等于授权 Agent 直接安装。安装插件、运行 npx、写入项目配置或覆盖既有技能前，都应先取得项目负责人的确认。

最值得记住的一点是：product-design:index 是路由器，本身不完成审计；superpowers:brainstorming 是澄清过程，不是替你编造事实；writing-plans 是实施计划，不是先做后补文档。

任务起点：先把一句抱怨变成可判断的问题

原始输入常常只有一句：“用户找不到保存的内容，做个入口吧。”在调用任何生成或规划技能前，先填写下面的需求卡。

原始诉求：用户反馈找不到已保存内容。
目标用户：移动端、每周会保存多条内容的登录用户。
用户任务：从任意页面找到、查看、取消保存一条内容。
已知证据：客服工单 12 条 / 埋点数据 / 访谈摘录 / 当前页面截图（逐项替换为真实材料）。
未知项：用户是真的找不到入口，还是保存状态不可信、列表加载慢、或根本没有再次查看需求？
业务目标：减少与“找不到保存内容”相关的求助；不把首页改成收藏中心。
硬约束：不改变现有收藏数据；不增加登录步骤；移动端和桌面端都要可达。
不在范围：重做个人中心、修改推荐算法、声称已经提升留存。

验收： 需求方能回答“谁在什么场景下、要完成什么、证据是什么、哪些还不知道、绝对不能动什么”。回答不出来，说明还没到写 PRD 的时候。

第一步：用 Superpowers Brainstorming 澄清需求，而不是逼 AI 猜

superpowers:brainstorming 的关键不是输出得快，而是按问题逐轮确认目标、范围、约束和成功标准。原技能的完整工作流还要求写入设计文档并 Git commit；那是代码项目的流程要求。若你的项目没有明确授权，不要让 Agent 擅自创建长期文档、提交或改动文件。产品经理可以先使用它的澄清结构，得到一个可确认的决策草案。

可复制提示词

请使用 superpowers:brainstorming 帮我澄清一个产品问题。

原始诉求：用户反馈找不到已保存内容，希望增加入口。
已有事实：[粘贴真实工单、数据、截图或访谈摘要]
未知项：[粘贴未知项]
硬约束：不改收藏数据模型；不增加登录步骤；移动端与桌面端都可达。

请一次只问一个会改变方案的问题，优先确认：
1. 目标用户和触发场景；
2. 当前证据和证据缺口；
3. 目标、非目标与成功标准；
4. 业务/技术/合规约束；
5. 谁能确认最终取舍。

在信息足够后，输出：问题定义、假设、待验证风险、2-3 个方案方向和需要我确认的决策。
禁止：虚构用户研究、把假设写成事实、创建文件、Git commit、开始开发或选择方案。

这一步的输出应该长什么样

不要接受“用户需要一个收藏入口”这种答案。更好的问题定义是：“对于已登录且存在至少一条保存记录的移动端用户，在阅读完成后 7 天内，能否在不返回首页的情况下找到保存列表并重新打开任一内容？”

这句话同时限定了人群、前提、时机和可观察行为。它还暴露了一个关键事实：如果用户没有保存记录，空状态与入口位置是两个不同问题。

验收与停止条件

• 至少列出一个已知证据和一个未知项；
• 成功标准是可观察行为或指标定义，不是“体验更好”；
• 方案尚未得到业务/设计/技术确认时，停止在决策草案，不进入实施计划；
• 若对方要求“直接做”，仍要在任务记录中标记未确认假设。

第二步：用 Product Design Audit 验证现有路径

当你已经知道要审查什么，再用 product-design:audit 查看现有体验。它要求取得本轮真实截图，逐步记录用户看到什么、能做什么、哪里卡住，以及截图无法确认的限制。

输入材料

• 移动端：从内容页、账户入口到“已保存”列表的真实截图；
• 桌面端：同一路径的截图；
• 明确任务：“找到一条已保存内容并再次打开”；
• 当前组件、品牌和登录约束。

可复制提示词

请使用 product-design:audit 审查“找到已保存内容并再次打开”的当前路径。

用户：已登录、至少保存过一条内容的移动端用户。
步骤：内容详情页 → 账户入口 → 已保存列表 → 打开一条内容。
证据：只使用我本轮提供或你本轮捕获的真实截图。
约束：不改收藏数据，不增加新登录步骤；桌面端必须有等价路径。

对每一步输出：用户目标、截图中可确认的优点、P0/P1/P2 问题、可见的无障碍风险、截图无法判断的测试项、最小改动建议和验收方法。
禁止：修改页面、生成假截图、把审美偏好写成 P1、宣称完整无障碍合规。

产品经理怎样读审计结果

重点不是“卡片间距是否 16px”，而是路径是否连续。例如：如果内容页的收藏状态不可见、账户入口不易发现、保存列表没有空状态区分，用户的“找不到”可能来自三个不同节点。把它们拆开，才能决定是优化反馈、入口，还是列表信息结构。

验收

每个 P1 都必须有“位置 + 用户影响 + 截图依据 + 最小修改 + 验收”；截图无法证明的事项（如屏幕阅读器朗读、真实加载速度、埋点归因）必须进入待测清单，不能写成已通过。

第三步：用 Product Design Ideate 比较方向，而不是只换配色

审计显示问题后，product-design:ideate 可用于探索不同的层级或交互模型。它的真实工作流会生成恰好三个独立方向，并等待人工选择。产品经理在这里的职责不是挑“最漂亮的一张”，而是说明每种方向解决哪个问题、付出什么代价。

先准备完整 brief

对象：移动端“已保存内容”的发现与回访路径。
已证实问题：[粘贴 audit 中的 P1/P2]
目标：让已有保存记录的用户从内容页或账户入口快速到达列表。
必须保留：现有收藏动作、内容卡片、账户体系和品牌 token。
差异要求：三个方向必须在入口位置、信息层级或交互模型上不同。
不允许：新增营销模块、伪造保存数量、重新设计整站、改变业务规则。

可复制提示词

请使用 product-design:ideate，根据以下 brief 生成三个独立方向。

[粘贴完整 brief]

每个方向必须先用文字写清：
- 用户从哪里进入、要走几步；
- 对有保存记录和无记录用户分别怎样处理；
- 对移动端和桌面端的结构影响；
- 解决哪个已证实问题；
- 风险、成本和不适用情况。

如需生成视觉参考，它只能是方向草图，不得带真实品牌文案、用户数据、伪造测试结果或“已上线”状态。生成后停止，等待我选择一个方向。

方案取舍表

验收： 选择记录必须写下“为什么选它”和“为什么不选另外两个”。没有取舍理由，说明只是视觉投票。

第四步：用 Superpowers Writing Plans 交给执行者

superpowers:writing-plans 适用于方案已经确认之后。它要求计划包含精确路径、修改文件、测试和验证；其默认代码工作流还会涉及 TDD 和频繁提交。产品经理不能把它当成“自动开工”按钮：先确认范围，再让它把执行步骤写清楚；是否建文件、跑测试或 commit，取决于项目规则和授权。

可复制提示词

请使用 superpowers:writing-plans 为已确认方案编写执行计划，暂不修改任何文件。

已选方案：[粘贴方向名称和取舍]
目标行为：已登录且有保存记录的用户，能从 [入口] 到达保存列表并打开一条内容。
范围：仅 [页面/组件/路由]；桌面端和移动端都要覆盖。
非目标：不改数据模型、不改登录、不改推荐算法、不增加新依赖。
现有事实：[粘贴仓库路径、组件、设计系统、测试命令]
验收：列出默认、空、加载、失败、收藏取消、键盘焦点和响应式状态。

请输出：
1. 需要先读取的文件和原因；
2. 按依赖排序的最小任务；
3. 每个任务的输入、修改范围、验证命令、预期结果；
4. 风险和回退点；
5. 不确定时必须停下询问的条件。

禁止：在没有授权时创建文档、执行命令、写代码、安装依赖或 Git commit；不要把未运行的命令写成已验证。

一份合格计划必须包含的状态

最终交付：复制给你的执行 Agent

任务：为 [产品/页面] 完成“已保存内容”发现与回访体验的最小改进。

已确认问题：[粘贴 audit 的 P1/P2 与截图编号]
目标用户与任务：[粘贴需求卡]
已选方案及取舍：[粘贴方向选择]
必须保留：[现有数据、登录、设计 token、组件]
不在范围：[非目标]

执行前：先读取 [具体文件/设计系统/测试脚本]，发现事实与任务不一致时停止并报告。
实施要求：覆盖默认、有数据、空、加载、失败、取消保存、移动端和键盘状态；不增加依赖、不改后端数据结构、不做无关重构。
验证要求：实际运行相关测试和桌面/移动端检查，记录命令、退出码、关键结果和真实截图；未执行项必须写“未执行”。
验收：用户能通过 [入口] 到达已保存列表并再次打开内容；P1 逐项关闭或说明原因；没有横向溢出，主要操作焦点可见。
停止条件：需要改变数据模型、登录、全局导航、品牌规范或出现真实用户数据/权限风险时，先请求确认。

常见失败方式

1. 让 AI 直接写 PRD。 没有用户、证据、约束和成功标准的 PRD 只是在放大猜测。
2. 把 audit 的截图观察等同于用户研究。 截图能证明界面状态，不能证明真实动机、转化率或无障碍合规。
3. 让 ideate 用三张相似的图替代方案比较。 三种方向必须在入口、层级或交互模型上不同，并写出取舍。
4. 未确认方案就 writing-plans。 计划越精细，越容易把错误决策高效地做出来。
5. 忽略 Agent 的权限边界。 需求澄清不授权安装依赖、改数据、提交 Git 或上线。

完成前检查

• [ ] 每一项技能都有明确职责、输入、提示词、输出和验收。
• [ ] product-design:index 被说明为路由，而不是产出技能。
• [ ] 已知事实、假设和待验证项没有混写。
• [ ] 方案选择包含取舍，不以“更好看”作为理由。
• [ ] 执行计划只在范围确认后才开始。
• [ ] 最终任务块包含验证证据、停止条件和未执行项说明。

产品经理需要的不是一台替自己写文档的机器，而是一条能把模糊诉求逐步变成可验证决策的工作流。技能组合的价值，就在于让每一步都知道该问什么、该交什么，以及何时不该继续。