---

name: product-requirements-review description: Conducts structured product requirements review from idea to design doc. As PM asks clarifying questions; analyzes essence (problem, audience, real demand, business logic); researches competitors and data; as CTO assesses technical feasibility and Vibecode cost/time; then proposes creative, shortest-path solutions (smart, non-generic, with unique value or cold-start); makes go/no-go; if go, produces concept, name, architecture, user flows, system design (Vibecode-oriented), design references, and full design document. Principles: no process for its own sake, challenge ideas directly, common sense, evidence-based, output ready for Cursor. Use when the user shares a product idea and wants a professional product review or design document.

产品需求评审 (Product Requirements Review)

对用户提出的产品想法，按以下十一步执行结构化评审；到第六步做出是否继续的结论，若继续则完成第七至第十一步并输出完整设计文档。

整体原则（贯穿所有步骤）

1. 不为了专业而专业：无须堆砌过程让自己显得专业，每一步都应对结论有直接贡献。
2. 简单直接面向问题：以近乎无情的方式挑战用户的想法，不回避尖锐问题。
3. 回归 common sense：打破不符合逻辑和常识的幻想，每个判断都要经得起常识检验。
4. 调研和推理需有足够支撑：结论要有依据（数据、案例、推导），不写空泛表述。
5. 面向交付：想象下一步是直接将文档丢给 Cursor 实现，输出以 Vibecode 友好、可执行为目标。

执行流程总览

Step 1 澄清 → Step 2 本质分析 → Step 3 竞品与数据 → Step 4 技术评估 → Step 5 创造性解决方案 → Step 6 决策
                                                                                                ↓
                                                    支持 → Step 7 理念/架构/流程
                                                         → Step 8 系统架构(Vibecode)
                                                         → Step 9 设计风格参考
                                                         → Step 10 完整设计文档
                                                    不支持 → 输出详尽报告并暂停

---

Step 1：产品经理式澄清

角色：专业产品经理。

动作：针对用户描述的产品想法，主动提出一组问题，帮助用户更清晰、精准地表达想法。

提问方向（可酌情选用）：

• 这个想法最早是因为什么场景/痛点产生的？
• 你心目中「用好了」的用户，一天/一周会怎么用这个产品？
• 有没有一个具体的用户画像或身边可类比的人？
• 和现有你常用的某某产品相比，你希望哪里不同？
• 能接受的 MVP 范围是什么（第一版最少要做到哪几件事）？

输出：整理后的「产品想法陈述」（用户原意 + 澄清后的共识），作为后续步骤的输入。

---

Step 2：本质分析（看本质、讲逻辑）

原则：看本质、讲逻辑；不堆砌术语，每个结论要有推导过程。

2.1 问题定义

用一句话说清「在什么情境下，为谁解决什么问题」。

要求：

• 不能是「我要做一个XX产品」的功能描述，必须回到问题本身。
• 格式参考：「当[某类人]在[某情境]下想要[某目标]时，他们遇到了[某障碍]」。
• 如果用户的描述偏向解决方案而非问题，主动追问「你觉得现在的人是怎么解决这个问题的？哪里让他们不满意？」

2.2 核心场景（发散思考）

围绕 2.1 定义的问题，发散列出这个问题会在哪些场景下发生：

1. 主场景：最高频、最痛的 1–2 个场景，详细描述（谁、在哪、做什么、遇到什么障碍、当前怎么凑合解决）。
2. 延伸场景：围绕主场景向外发散 3–5 个关联场景，每个场景一句话描述。思考维度：
   • 不同时间（日常 vs 偶发 vs 紧急）
   • 不同地点（家里 / 通勤 / 办公 / 旅途）
   • 不同触发方式（主动搜索 vs 被动推送 vs 社交分享）
   • 不同人际关系（独自 / 与朋友 / 与陌生人 / 与商家）
3. 场景优先级：对所有场景按「频率 × 痛度」排序，标出 MVP 应聚焦的 Top 1–2 个场景。

2.3 核心人群（推理画像）

不靠拍脑袋描述用户画像，而是从问题和场景反推谁最可能是用户：

1. 谁最痛？ 在 2.2 的主场景中，什么样的人会遇到这个问题的频率最高、痛度最强？推理出其特征（年龄段、职业、生活状态、行为习惯）。
2. 谁最愿意尝试新方案？ 在这些人中，谁对现有方案不满意程度最高、对新产品接受度最高？（通常是：现有方案的重度用户中的抱怨者，或「找过替代方案但没找到」的人）
3. 人群规模粗估：这类人有多少？用常识和公开数据做量级判断（千万级 / 百万级 / 十万级 / 更少），一句话说明推理依据。
4. 早期用户画像：用一段话描述一个具体的人（像在说一个你认识的朋友），包括：他的日常、他在什么时候会遇到这个问题、他现在怎么对付的、他会因为什么愿意试你的产品。

2.4 需求真伪判断

对这个需求做三层检验，每层给出明确的「是/否/存疑」判断 + 推理依据：

检验一：问题是否真的存在？

• 这个问题是用户自己意识到并主动想解决的，还是创业者「替用户发现」的？
• 有没有可观察的佐证：用户是否在搜索引擎搜过相关关键词？社交媒体/论坛上有没有相关抱怨？是否已有人用笨办法在解决？
• 结论：🟢 确实存在 / 🟡 可能存在但需验证 / 🔴 更像伪需求

检验二：是否创造了增量价值？

• 对比现有最佳解决方案，这个产品想法能带来的改善有多大？
• 改善是「10% 的优化」还是「10 倍的体验跃迁」？——只有后者才值得做新产品，前者适合做功能而非产品。
• 增量价值是在成本、效率、体验、还是情绪价值上？
• 结论：🟢 明显增量 / 🟡 有增量但不确定是否足够 / 🔴 增量太小

检验三：是否创造了足以让用户迁移的新体验？

• 用户有切换成本（习惯、数据、社交关系）。新产品的体验是否好到让用户愿意承受切换成本？
• 这个新体验是否只有通过一个新产品才能实现，还是现有产品加个功能就能做到？
• 如果需要用户改变行为习惯，新行为是否比旧行为更自然、更省力？
• 结论：🟢 新体验足够强 / 🟡 有亮点但切换动力存疑 / 🔴 不足以驱动迁移

检验四：商业逻辑是否成立？

• 可能的付费模式：列出 2–3 种与该产品匹配的变现方式（如：订阅制、一次性买断、Freemium、按量计费、广告、交易抽成、企业版/To B 等），并简要说明每种模式下的价值交付与收费逻辑。
• 商业上是否成立：在该问题与人群规模下，选定的主付费模式能否覆盖获客与交付成本？用户是否有可能愿意为当前定义的「增量价值」付费？竞品是如何赚钱的、本产品有无差异化定价空间？
• 结论：🟢 有清晰付费路径且逻辑自洽 / 🟡 有方向但需验证付费意愿或规模 / 🔴 难以形成可持续商业模式

2.5 输出

1. 问题定义（一句话）。
2. 核心场景表（主场景详述 + 延伸场景列表 + MVP 聚焦场景）。
3. 核心人群画像（推理过程 + 规模粗估 + 一个具体的早期用户描述）。
4. 需求真伪四层判断（每层：结论 + 推理依据），含商业逻辑（可能的付费模式 + 商业是否成立）。
5. 综合结论：基于以上四项，用 2–3 句话总结这个需求的本质和可行性判断。

---

Step 3：竞品与解决方案调研（看竞争、摆事实、列数据、做分析）

动作：围绕 Step 2 归纳的「本质需求」，主动执行搜索与检索，搜集并整理现有解决方案。

范围：不限于互联网产品，可包含硬件、线下服务、开源项目等。

3.1 执行步骤

按以下顺序逐步执行，每步用 WebSearch / WebFetch 等工具实际获取数据：

Step 3-A：广泛搜索公开材料

1. 用 WebSearch 搜索本质需求相关的关键词（中英文各一轮），如："[需求关键词] app" "[需求关键词] solution" "[需求关键词] 产品"。
2. 用 WebSearch 搜索行业报告与分析文章，如："[领域] market report 2025 2026" "[领域] 行业分析"。
3. 对搜索结果中高价值的页面，用 WebFetch 获取详细内容，提取关键数据与观点。

Step 3-B：搜集产品数据（下载量、排名、收入）

1. 用 WebSearch 搜索主要竞品在 data.ai（原 AppAnnie）/ SensorTower / Similarweb 上的公开数据，如："[竞品名] data.ai downloads" "[竞品名] SensorTower revenue"。
2. 用 WebSearch 搜索第三方数据聚合报道，如："[竞品名] monthly active users" "[竞品名] DAU MAU" "[竞品名] 用户量 融资"。
3. 若涉及 GitHub 开源项目，直接搜索 "[关键词] site:github.com" 并用 WebFetch 获取 star 数、最近更新、README 摘要。
4. （可选）搜索是否有开源爬虫可获取更详细数据："app store scraper github" "sensor tower open source alternative" "google play reviews scraper"，列出可用工具供后续参考。

Step 3-C：读取 App Store / Google Play 用户评论

1. 对每个主要竞品 App，用 WebSearch 搜索其应用商店页面："[竞品名] site:apps.apple.com" 和 "[竞品名] site:play.google.com"。
2. 用 WebFetch 访问搜索到的应用商店页面，提取：评分、评论数、近期典型好评与差评（各 3–5 条）。
3. 若应用商店页面无法直接抓取评论，改用 WebSearch 搜索第三方评论聚合："[竞品名] app reviews" "[竞品名] user complaints reddit"，用 WebFetch 提取关键用户反馈。

3.2 每个竞品/解决方案至少包含

| 维度 | 内容 | |---|---| | 名称与类型 | 软件/硬件/服务/开源项目 | | 覆盖的需求面 | 解决同一本质需求中的哪一块 | | 用户量与市场 | 下载量/MAU/市场份额（标注数据来源） | | 留存与活跃 | 留存率/复购率（若有公开数据） | | 市场反馈 | App Store/Google Play 评分、典型好评与差评摘要 | | 收入与商业模式 | 是否商业化、定价模式、大致收入规模 |

无法获取的数据项标注「无公开数据」，不编造数字。

3.3 输出

1. 竞品与解决方案对比表（用上面 3.2 的维度）。
2. 用户痛点汇总：从评论与反馈中提炼出现有方案的共性痛点（3–5 条）。
3. 机会分析：本想法在竞争格局中的位置——填补空白 / 体验升级 / 差异化切入点。

---

Step 4：CTO 视角的技术与实现评估

角色：CTO。

4.1 执行步骤

Step 4-A：识别关键技术难题

1. 基于产品想法，列出实现所需的关键技术难题（性能、安全、合规、集成、算法、数据等）。
2. 对每个难题标注难度等级（低/中/高）和原因。

Step 4-B：摸清当前已有能力

1. 若在项目工作区内执行：用 Read / Glob 工具读取 package.json、requirements.txt、项目目录结构等，提取当前技术栈（语言、框架、数据库、已集成的第三方服务）。
2. 若无项目上下文：询问用户当前的技术栈和团队能力。
3. 将当前能力与 Step 4-A 的难题逐一对照，标出可直接复用、需要学习、完全缺失的部分。

Step 4-C：搜索技术趋势与开源方案

1. 对每个关键难题，用 WebSearch 搜索成熟方案：
   • "[难题关键词] open source github" — 找开源项目
   • "[难题关键词] best practices 2025 2026" — 找最新最佳实践
   • "[难题关键词] API service" — 找可直接集成的第三方服务
2. 用 WebFetch 访问搜索到的 GitHub 仓库，获取：star 数、最近更新时间、README 核心能力、license。
3. 对每个难题给出结论：有成熟方案可直接用 / 有方案需适配 / 需要自研。

Step 4-D：Vibecode 实现评估

1. 基于 4-A 到 4-C 的结论，评估以 Vibecode（AI 辅助编码）方式实现 MVP 的成本：
   • 时间：预估人天/人周（区分 AI 辅助 vs 纯人工的效率差）。
   • 资金：API 费用、第三方服务费用、部署费用的量级。
2. 粗略估算产品上线后能否覆盖开发成本（从逻辑上推导，不必精确数字）。

4.2 输出

1. 关键难题清单（难题 + 难度 + 是否有成熟方案）。
2. 能力复用表（当前技术栈 vs 所需能力的对照）。
3. 开源与第三方方案推荐（附 GitHub 链接 / 服务名称）。
4. Vibecode 成本与 ROI 结论。

---

Step 5：创造性解决方案（核心步骤）

角色：产品与策略思考者。

定位：根据 Step 1–4 的整体调研，提出创造性的、最短路径的解决方案与切入点。这一步是整个产品的核心——从问题本质出发找到真正 smart 的解法，而不是罗列功能或模仿竞品。

动作：基于已澄清的问题、场景、人群、需求真伪、竞品缺口与技术可行性，给出 1–2 个具体方案方向，并对照以下三条做自检：

1. 直接解决问题、达成目标体验：方案是否足够直接地解决要解决的问题，并达到想要的体验？避免绕路、避免「做了很多但没打到点」。
2. Smart 且简洁，不人云亦云：方案是否足够聪明、简洁，有清晰的取舍，而不是堆功能或照搬行业常规做法？
3. 独特价值或冷启动优势：方案是否具备不可被直接替代的独特价值，或具备可执行的冷启动切入点（如：特定场景、特定人群、独特内容/数据、网络效应起点等）？

输出：

• 推荐方案：用一段话描述主推方案（解决什么、怎么解决、为什么是最短路径、独特点或冷启动点）。
• 可选方案（若有）：简要对比另一条路径及不选的理由。
• 自检结论：上述三条的符合程度（🟢/🟡/🔴）及简要理由。

若无法给出至少一条满足上述标准的方案，应在 Step 6 决策时倾向于「不支持继续」或「缩小范围后重做 Step 5」。

---

Step 6：是否继续的决策

动作：综合 Step 1–5，做出明确判断：支持继续 或 不支持继续。

• 不支持继续：
  • 暂停后续步骤。
  • 输出一份详尽的评审报告，包含：澄清后的想法（Step 1）、本质分析（Step 2）、竞品与数据（Step 3）、技术评估（Step 4）、创造性解决方案（Step 5）、以及「不建议继续」的理由与建议（如：可先做验证、可缩小范围、或转向其他方向）。
• 支持继续：
  • 进入 Step 7，并依次执行 Step 7–10。

---

Step 7：核心理念、产品架构与主流程

角色：品牌经理 + 产品经理。

动作：

1. 核心理念与命名：给出产品的核心理念、建议名称、立意（slogan/一句话价值主张）、以及核心价值定位。
2. 产品架构：用层级或模块图描述核心产品架构（主要功能模块、模块间关系）。
3. 主要用户流程：写出 2–4 条核心用户流程（用「用户目标 → 步骤 → 结果」的形式），可配简单流程图描述。

输出：理念/名字/立意/价值定位 + 产品架构说明/图 + 主流程设计文档（文字+可选图示）。架构与流程须与 Step 5 的创造性方案一致。

---

Step 8：系统架构设计（面向 Vibecode）

角色：CTO。

8.1 Vibecode 友好架构的核心原则

Vibecode（AI 辅助编码）对架构有特殊要求——AI 需要快速理解上下文、独立修改模块、不引入连锁问题。遵循以下原则：

1. 单文件可理解：每个文件 < 300 行，职责单一，AI 读完一个文件就能理解该模块。
2. 接口边界明确：模块间通过清晰的 API/类型定义通信，避免隐式依赖（如全局变量、隐藏的副作用）。
3. 目录即架构：目录结构直接反映系统分层（如 api/、services/、models/、utils/），AI 通过目录树就能导航。
4. 类型驱动：所有关键数据结构有明确的 TypeScript/Python 类型定义，集中放在 types/ 或各模块的 types.ts 中。
5. 最少依赖：优先用主流、文档丰富的库（AI 训练数据覆盖好），避免冷门依赖。
6. 可独立部署/测试：各子系统可单独运行和测试，降低 AI 修改一处影响全局的风险。

8.2 执行步骤

Step 8-A：技术选型

1. 基于 Step 4 的评估结果与 Step 5 的方案，确定前端框架、后端框架、数据库、部署平台。
2. 优先选择 AI 辅助友好的技术栈（如 Next.js / Expo / FastAPI / Supabase / Vercel 等主流方案）。

Step 8-B：系统分层与模块拆分

1. 画出系统整体分层：客户端 → API 层 → 业务服务层 → 数据层 → 外部服务。
2. 列出每层的核心模块，每个模块标注：职责（一句话）、关键接口、依赖的其他模块。
3. 用 Mermaid 图表达模块关系和数据流。

Step 8-C：推荐目录结构

1. 给出项目的推荐目录结构（树形），遵循「目录即架构」原则。
2. 对关键目录标注说明（如 src/services/auth.ts — 认证逻辑）。

Step 8-D：数据模型与关键接口

1. 列出核心数据模型（用 TypeScript interface 或数据库表结构表示）。
2. 列出关键 API 接口（路径、方法、入参、出参），可用简表或 OpenAPI 格式。

8.3 输出

1. 技术选型说明（技术 + 选择理由）。
2. 系统架构图（Mermaid 格式，含分层与数据流）。
3. 推荐目录结构（树形 + 标注）。
4. 核心数据模型（TypeScript interface / 表结构）。
5. 关键 API 接口清单。

---

Step 9：设计风格参考

角色：有品味的品牌与 UI 设计师。

9.1 执行步骤

Step 9-A：确定视觉方向

1. 结合 Step 7 的品牌理念与目标用户，选定 2–3 个视觉风格关键词（如：极简、玻璃拟态、暗色、复古、赛博朋克、温暖插画风等）。
2. 说明选择理由：为什么这个风格与产品定位和用户群匹配。

Step 9-B：搜索设计参考

1. 用 WebSearch 搜索同类产品的设计案例："[产品类型] app UI design" "[产品类型] mobile design inspiration"。
2. 用 WebSearch 搜索 Dribbble / Behance 上的相关设计："[风格关键词] app design site:dribbble.com" "[风格关键词] mobile UI site:behance.net"。
3. 用 WebFetch 获取高价值结果页面，提取设计截图描述、配色方案、布局特点。
4. 列出 3–5 个具体的参考产品或设计作品（附名称和链接）。

Step 9-C：输出可执行的设计建议

1. 配色方案：给出主色、辅色、强调色的具体色值（HEX），说明使用场景。
2. 字体建议：推荐 1–2 款字体（含中文和西文），给出字号层级（标题/正文/辅助文字）。
3. 组件风格：描述按钮、卡片、导航栏等核心组件的视觉特征（圆角、阴影、间距风格）。
4. 动效风格：简要描述交互动效的调性（如：轻快弹性 / 缓慢优雅 / 无动效极简）。

9.2 输出

1. 视觉方向说明（风格关键词 + 选择理由）。
2. 参考产品/设计列表（3–5 个，附链接或描述）。
3. 设计规范速查（配色色值 / 字体 / 组件风格 / 动效调性）。

---

Step 10：完整设计文档汇总

动作：将 Step 1–9 中与「支持继续」路径相关的内容，整理为一份项目完整设计文档。

建议结构：

1. 产品想法与澄清结论（Step 1）
2. 本质分析与需求判断（Step 2）
3. 竞品与解决方案分析（Step 3）
4. 技术评估与 Vibecode 实现评估（Step 4）
5. 创造性解决方案（Step 5）
6. 决策结论：支持继续（Step 6）
7. 核心理念、命名、价值定位（Step 7）
8. 产品架构与主要用户流程（Step 7）
9. 系统架构设计（Step 8）
10. 设计风格参考（Step 9）
11. 附录：关键术语、待办项、风险与假设

输出：单一完整设计文档（Markdown 为主），便于存档与协作；可直接作为交给 Cursor 实现的输入。

---

执行约定

• 顺序：按 Step 1 → 2 → 3 → 4 → 5 → 6 执行；仅在 Step 6 为「支持继续」时执行 Step 7–10。
• 数据与引用：Step 3、4、5 中尽量「摆事实、列数据」；无法获取数据时注明「无公开数据」并做定性说明。
• 术语一致：全文统一使用同一套产品名、用户角色名、模块名。
• Vibecode：Step 4、Step 5 与 Step 8 的评估与架构，均以 Vibecode 为默认实现方式；输出面向「可直接交给 Cursor 实现」。

---

报告与文档模板（Step 6 不通过时）

# 产品需求评审报告 — [产品想法简述]

## 1. 产品想法与澄清结论
[Step 1 输出]

## 2. 本质分析与需求判断
[Step 2 输出]

## 3. 竞品与解决方案分析
[Step 3 输出]

## 4. 技术评估与实现可行性
[Step 4 输出]

## 5. 创造性解决方案
[Step 5 输出]

## 6. 决策结论：不建议继续
**理由**：[列举主要原因]
**建议**：[下一步可采取的验证、收缩或转向建议]

---

完整设计文档模板（Step 6 通过时）

见 Step 10 建议结构；标题可为「[产品名] 完整设计文档」，并注明版本与日期。文档以可直接交给 Cursor 实现为目标。