00 - 需求分析食谱

将模糊的产品想法转化为结构化、可执行的需求文档，是 AI 辅助编程的第一步。

适用场景

脑中有个想法，但还没有清晰的产品定义
需要快速产出用户故事或 PRD 初稿
想了解竞品的功能布局来辅助决策
评估一个需求在技术和资源上是否可行
项目范围模糊，需要明确做与不做的边界
确定 MVP 的最小功能集，避免过度设计

食谱 1：模糊想法 → 结构化需求

场景描述

你有一个产品想法，但只是口语化的描述（"我想做一个 XX"）。需要 AI 帮你整理成结构化需求文档，包括目标用户、核心功能、约束条件等。

核心模板

text

我有一个产品想法：{{一句话描述}}

目标用户是 {{目标用户群体}}，他们目前的痛点是 {{核心痛点}}。

请帮我整理成结构化需求，包含：
1. 问题定义 — 用户面临的具体问题
2. 目标用户画像 — 谁会用、什么场景、使用频率
3. 核心功能列表 — 按优先级排序（P0/P1/P2）
4. 非功能需求 — 性能、安全、兼容性
5. 约束条件 — 技术栈、时间、预算限制
6. 成功指标 — 如何衡量产品达标

背景补充：{{已有的想法、参考产品、技术偏好}}

输出格式：Markdown，功能列表用表格。

变量说明

变量	说明	示例
`{{一句话描述}}`	产品核心功能，不超过 30 字	`一个帮程序员管理代码片段的桌面工具`
`{{目标用户群体}}`	主要用户类型	`日常需要复用代码片段的全栈开发者`
`{{核心痛点}}`	用户为什么不满意	`代码片段散落各处，搜索困难、无语法高亮`
`{{已有的想法、参考产品、技术偏好}}`	可选补充信息	`参考 Ray.so，技术栈倾向 Electron + React`

好坏对比

text

❌ "我想做一个代码片段管理工具，帮我写需求文档。"
   → 没有目标用户、没有痛点、没有约束，AI 只能泛泛而谈

✅ "我有一个产品想法：帮程序员管理代码片段的桌面工具。
   目标用户是需要复用代码的全栈开发者，痛点是片段散落各处。
   请整理成结构化需求（问题定义/用户画像/功能列表/约束条件/成功指标）。
   约束：Electron + React，一人开发，两周出 MVP。"
   → 有用户、有痛点、有约束、有输出要求

实战案例

text

我有一个产品想法：根据 Git commit 记录自动生成工作日报的 CLI 工具。

目标用户是每天需要写日报的程序员，痛点是手动回忆今天干了什么，
经常漏写或描述不准确。

请整理成结构化需求，包含：问题定义、用户画像、核心功能列表（P0/P1/P2）、
非功能需求、约束条件、成功指标。
约束：Node.js CLI，调用 OpenAI API，一人开发，一周内完成。
功能列表用表格输出。

Claude 增强

使用 /spec Skill 可一键启动完整需求分析流程，自动输出 PRD 格式文档
用 @README.md 引用项目已有说明，让 Claude 基于已有上下文补充需求
搭配 先出方案不写代码 指令，避免 Claude 直接跳到实现

食谱 2：用户故事编写

场景描述

把功能需求转化为标准用户故事（User Story），含角色、动作、价值和验收标准。适合敏捷开发的需求拆解。

核心模板

text

请为以下功能编写用户故事：

功能描述：{{功能描述}}
产品背景：{{产品是什么、服务谁}}
相关约束：{{技术栈、业务规则等}}

要求：
1. 标准格式：作为 [角色]，我想要 [动作]，以便 [价值]
2. 每个故事附带 3-5 条验收标准（Given-When-Then 格式）
3. 标注故事点（1/2/3/5/8）和优先级（P0/P1/P2）
4. 复杂功能拆分为多个独立子故事
5. 标注故事之间的依赖关系

输出格式：每个故事一个区块，含标题、描述、验收标准、估算。

变量说明

变量	说明	示例
`{{功能描述}}`	要实现的功能	`用户通过邮箱注册并用密码登录`
`{{产品是什么、服务谁}}`	产品上下文	`在线教育平台，服务自学编程的学生`
`{{技术栈、业务规则等}}`	限制条件	`NextAuth.js，密码至少 8 位，需邮箱验证`

好坏对比

text

❌ "帮我写用户登录的用户故事。"
   → 缺少产品背景和约束，验收标准会很泛

✅ "请为以下功能编写用户故事：
   功能：用户通过邮箱注册并用密码登录
   背景：在线教育平台，面向自学编程的学生（18-35 岁）
   约束：NextAuth.js + Prisma，密码至少 8 位含大小写，需邮箱验证
   要求 Given-When-Then 验收标准，标注故事点和优先级。"
   → 有背景、有约束、有输出格式

实战案例

text

请为以下功能编写用户故事：

功能描述：购物车功能（添加商品、修改数量、删除、结算跳转）
产品背景：面向年轻女性的小型潮牌电商，移动端优先
相关约束：React Native，未登录用户也需支持购物车（localStorage），
         单个商品最大购买数 99，库存不足时前端拦截

要求：标准格式 + Given-When-Then 验收标准 + 故事点 + 优先级。
复杂功能拆分子故事，标注依赖关系。

Claude 增强

用 @src/types/ 引用现有类型定义，让用户故事与代码实体对齐
追加 请同时输出对应的 Gherkin 测试场景 可直接生成 BDD 测试骨架
多轮迭代：先生成故事，然后 请针对故事 3 追加异常场景的验收标准

食谱 3：竞品功能分析

场景描述

启动新项目前，快速了解市场已有产品，分析功能布局、优劣势和差异化机会。

核心模板

text

我正在做 {{你的产品描述}}，请对以下竞品进行分析：

竞品列表：
{{竞品1}}：{{一句话描述}}
{{竞品2}}：{{一句话描述}}
{{竞品3}}：{{一句话描述}}

分析维度：
1. 功能对比矩阵 — 核心功能逐个对比支持情况
2. 目标用户差异 — 各竞品瞄准什么用户群
3. 定价策略 — 免费/付费/订阅模式
4. 技术实现路线 — 技术栈或架构特点（如果可知）
5. 优劣势总结 — 每个竞品 2 优势 + 2 劣势
6. 差异化机会 — 我的产品可以在哪方面做出差异

输出格式：功能对比用表格，其余用列表，最后给总结性建议。

变量说明

变量	说明	示例
`{{你的产品描述}}`	你的产品定位	`面向独立开发者的项目管理工具`
`{{竞品N}}`	竞品名称	`Linear`
`{{一句话描述}}`	竞品定位	`面向产品团队的现代项目管理工具`

好坏对比

text

❌ "帮我分析一下市面上的项目管理工具。"
   → 没有自身定位，没有指定竞品，分析维度模糊

✅ "我在做面向独立开发者的轻量项目管理工具（CLI + Web），
   请分析竞品：Linear（团队项目管理）、GitHub Projects（看板）、
   Todoist（任务管理）。
   维度：功能对比矩阵/用户差异/定价/技术路线/优劣势/差异化机会。
   功能对比用表格。"
   → 有自身定位、有明确竞品、有分析框架

实战案例

text

我正在做面向技术写作者的 Markdown 编辑器（桌面端），
核心卖点是 AI 辅助写作 + Git 集成。请分析竞品：

Typora：所见即所得 Markdown 编辑器
Obsidian：本地文件知识管理工具
Notion：在线协作文档平台

维度：Markdown 支持/AI 功能/Git 集成/离线使用/插件生态。
功能对比用表格，最后给出差异化建议。

Claude 增强

Claude 知识有截止日期，最新竞品数据搭配 Web Search 工具更准确
追加 请基于分析写一段产品定位描述 可直接产出 README 文案
分析后可无缝衔接食谱 5（范围界定）和食谱 6（MVP 定义）

食谱 4：技术可行性评估

场景描述

正式开发前，从技术、资源、时间三个维度评估需求是否可行，避免在不可行的需求上浪费时间。

核心模板

text

请评估以下需求的可行性：

需求描述：{{需求描述}}
技术环境：{{现有技术栈和基础设施}}
团队情况：{{人员构成和技能水平}}
时间约束：{{期望的交付时间}}

评估维度：
1. 技术可行性 — 技术栈是否支持、需要引入什么、核心技术难点、
   是否有成熟开源方案
2. 资源可行性 — 预估工时（乐观/正常/悲观）、额外技能需求、
   外部依赖
3. 风险评估 — Top 3 风险（影响程度 + 缓解方案）
4. 结论 — 可行性评级（✅ 可行 / ⚠️ 有条件可行 / ❌ 不可行）
   及建议实施路径

输出格式：按维度分节，风险用表格。

变量说明

变量	说明	示例
`{{需求描述}}`	要评估的功能	`实现实时协作编辑，类似 Google Docs`
`{{现有技术栈和基础设施}}`	当前技术状态	`Next.js + PostgreSQL + Vercel，无 WebSocket`
`{{人员构成和技能水平}}`	团队能力	`1 名全栈，熟悉 React/Node.js，不熟悉 CRDT`
`{{期望的交付时间}}`	时间限制	`3 周内上线 beta 版`

好坏对比

text

❌ "实时协作编辑功能做得了吗？"
   → 没有上下文，AI 无法评估"你的"情况

✅ "请评估可行性：在现有文档编辑器加入实时协作编辑。
   技术：Next.js 14 + PostgreSQL + Vercel，无 WebSocket 基础设施。
   团队：1 人全栈，熟 React/Node.js，不熟 CRDT/OT。时间：3 周。
   请从技术/资源/风险三维度分析，给出评级和实施路径。"
   → 有具体环境、有团队能力、有时间约束

实战案例

text

请评估以下需求的可行性：

需求描述：为小程序商城接入微信支付（JSAPI 支付）
技术环境：Taro + Node.js (Express) + MySQL，已有小程序上线
团队情况：1 名前端开发者，有小程序经验，无支付开发经验
时间约束：2 周内完成支付闭环（下单→支付→回调→订单状态更新）

请从技术可行性、资源可行性、风险评估三个维度分析，
给出可行性评级和实施路径。风险用表格。

Claude 增强

用 @package.json 和 @tsconfig.json 引用项目配置，精确判断技术栈兼容性
追加 请列出需要调研的技术点和推荐学习资源 可直接得到学习路径
评估结果可无缝输入 /plan Skill，生成实施方案

食谱 5：需求范围界定

场景描述

需求有了雏形但边界不清——哪些做、不做、后续迭代做。明确范围，防止 scope creep。

核心模板

text

请帮我界定以下项目的需求范围：

项目描述：{{项目描述}}
目标版本：{{版本号或阶段}}
已知功能列表：
{{功能列表，每行一个}}

请输出：
1. 范围内（In Scope）— 必须实现的功能，按模块分组，
   标注 Must Have / Should Have / Nice to Have
2. 范围外（Out of Scope）— 不做的功能 + 排除理由
3. 待定（Parking Lot）— 需进一步讨论的功能 + 决策所需信息
4. 边界约束 — 技术边界、业务边界、用户边界
5. 变更规则 — 新增范围的条件和代价

输出格式：用表格，清晰可直接转为文档。

变量说明

变量	说明	示例
`{{项目描述}}`	一句话定位	`面向开发者的博客系统`
`{{版本号或阶段}}`	当前聚焦版本	`v1.0 公开发布版`
`{{功能列表，每行一个}}`	所有已收集需求	`文章 CRUD / 标签 / 评论 / RSS / 搜索 / 多语言`

好坏对比

text

❌ "这些功能哪些先做哪些后做？"
   → 没有版本目标和约束条件，排序缺少依据

✅ "请界定需求范围：
   项目：面向开发者的个人博客系统
   版本：v1.0（一人开发，4 周）
   功能：文章 CRUD / 标签 / 评论 / RSS / 全文搜索 / 多语言 / 暗黑模式 / SEO / 统计
   请划分 In Scope / Out of Scope / Parking Lot，标注优先级和理由。"
   → 有版本目标、有资源约束、有明确输出要求

实战案例

text

请帮我界定以下项目的需求范围：

项目描述：团队 OKR 管理工具（Web 端）
目标版本：v2.0（v1.0 基础上迭代，2 人开发，6 周）
v1.0 已有：OKR 创建/编辑、树状展示、周期管理
v2.0 需求列表：
- 对齐视图（团队 OKR 关联关系）
- 进度自动追踪（关联 Jira/Linear）
- 周报自动生成
- 权限管理（管理员/成员/观察者）
- 导出 PDF/Excel
- Slack 通知集成
- 移动端适配

请划分范围，Must Have 不超过 4 个，输出为表格。

Claude 增强

用 @docs/ 引用已有需求文档，让 Claude 基于已有规划做范围切分
追加 请将 In Scope 功能按开发顺序排列，标注依赖关系 可产出排期参考
范围确定后接 /plan Skill 生成详细技术方案

食谱 6：MVP 定义与迭代规划

场景描述

确认范围后，进一步收缩到最小可行产品。MVP 核心：用最少功能验证最关键假设，尽快获得用户反馈。

核心模板

text

请帮我定义以下产品的 MVP：

产品描述：{{产品描述}}
目标用户：{{目标用户}}
核心假设：{{要验证的最关键假设}}
资源限制：{{人力、时间、预算}}
功能候选列表：
{{功能列表}}

请输出：
1. 核心假设验证 — 最需要验证的 1-2 个假设及所需最少功能
2. MVP 功能集 — 必须有 / 可简化 / 坚决砍掉，标注预估工时
3. MVP 体验标准 — 用户完整路径、可人工替代的环节、最低性能标准
4. 验证计划 — 获客方式、关键指标（不超过 3 个）、评估周期
5. 迭代路线 — MVP 后第一个迭代加什么、pivot 信号

输出格式：功能集用表格（功能/状态/工时/理由），其余用列表。

变量说明

变量	说明	示例
`{{产品描述}}`	产品定位	`帮自由职业者追踪时间和生成发票的工具`
`{{目标用户}}`	首批用户画像	`月收入 1-5 万的自由设计师和开发者`
`{{要验证的最关键假设}}`	核心命题	`自由职业者愿意为自动时间追踪+发票生成付费`
`{{人力、时间、预算}}`	硬性约束	`1 人兼职开发，2 周上线，零预算`
`{{功能列表}}`	候选功能	`时间追踪/项目管理/发票生成/客户管理/报表`

好坏对比

text

❌ "帮我定义这个产品的 MVP，功能越少越好。"
   → "越少越好"不是标准，MVP 标准是能验证核心假设

✅ "请定义 MVP：帮自由职业者追踪时间和生成发票的工具。
   用户：月收入 1-5 万的自由设计师/开发者。
   假设：自由职业者愿意为自动时间追踪+发票生成付费。
   约束：1 人兼职，2 周上线，零预算。
   候选功能：时间追踪/项目管理/发票生成/客户管理/报表/多币种/团队协作。
   必须有的功能不超过 3 个。"
   → 有假设、有约束、有明确的功能上限

实战案例

text

请帮我定义以下产品的 MVP：

产品描述：AI 辅助背单词微信小程序，基于遗忘曲线智能安排复习
目标用户：准备考 CET-6 的大学生
核心假设：AI 个性化复习计划比固定计划的记忆效果更好
资源限制：1 人全栈，3 周，服务器 100 元/月

功能候选：单词库 / AI 生成例句 / 遗忘曲线复习 / 学习统计 /
打卡日历 / 单词本 / 听力模式 / 拼写测试 / 排行榜 / 错题本

必须有的功能不超过 4 个，给出验证计划和关键指标。

Claude 增强

用 /spec Skill 先生成完整 PRD，再用本食谱收缩为 MVP
追加 请为 MVP 功能集生成技术方案大纲 可直接衔接架构设计阶段
用 请对比两种 MVP 方案：A 侧重 X / B 侧重 Y 做方案对比决策

组合技巧

需求分析全流程串联

按顺序使用食谱，完成从想法到 MVP 的完整需求分析：

text

食谱 1（模糊想法→结构化需求）
  ↓ 输出需求文档
食谱 3（竞品分析）
  ↓ 补充差异化定位
食谱 2（用户故事编写）
  ↓ 拆分为可执行的故事
食谱 4（可行性评估）
  ↓ 确认技术可行
食谱 5（需求范围界定）
  ↓ 明确做与不做
食谱 6（MVP 定义）
  ↓ 收缩到最小可行集

多会话协作模式

对于重要项目，建议多会话隔离，每个会话上下文纯净：

text

会话 A（需求探索）：食谱 1-3，产出需求文档和竞品报告
会话 B（可行性评估）：基于会话 A 的文档，食谱 4 做技术评估
会话 C（范围与 MVP）：综合 A、B 输出，食谱 5-6 确定最终范围

通用增强后缀

在任意食谱模板末尾追加：请同时指出我可能遗漏的需求盲点 / 请标注哪些需求描述不够清晰 / 请用一段话总结，方便发给团队看。

00 - 需求分析食谱 ​

适用场景 ​

食谱 1：模糊想法 → 结构化需求 ​

场景描述 ​

核心模板 ​

变量说明 ​

好坏对比 ​

实战案例 ​

Claude 增强 ​

食谱 2：用户故事编写 ​

场景描述 ​

核心模板 ​

变量说明 ​

好坏对比 ​

实战案例 ​

Claude 增强 ​

食谱 3：竞品功能分析 ​

场景描述 ​

核心模板 ​

变量说明 ​

好坏对比 ​

实战案例 ​

Claude 增强 ​

食谱 4：技术可行性评估 ​

场景描述 ​

核心模板 ​

变量说明 ​

好坏对比 ​

实战案例 ​

Claude 增强 ​

食谱 5：需求范围界定 ​

场景描述 ​

核心模板 ​

变量说明 ​

好坏对比 ​

实战案例 ​

Claude 增强 ​

食谱 6：MVP 定义与迭代规划 ​

场景描述 ​

核心模板 ​

变量说明 ​

好坏对比 ​

实战案例 ​

Claude 增强 ​

组合技巧 ​

需求分析全流程串联 ​

多会话协作模式 ​

通用增强后缀 ​

相关资源 ​

00 - 需求分析食谱

适用场景

食谱 1：模糊想法 → 结构化需求

场景描述

核心模板

变量说明

好坏对比

实战案例

Claude 增强

食谱 2：用户故事编写

场景描述

核心模板

变量说明

好坏对比

实战案例

Claude 增强

食谱 3：竞品功能分析

场景描述

核心模板

变量说明

好坏对比

实战案例

Claude 增强

食谱 4：技术可行性评估

场景描述

核心模板

变量说明

好坏对比

实战案例

Claude 增强

食谱 5：需求范围界定

场景描述

核心模板

变量说明

好坏对比

实战案例

Claude 增强

食谱 6：MVP 定义与迭代规划

场景描述

核心模板

变量说明

好坏对比

实战案例

Claude 增强

组合技巧

需求分析全流程串联

多会话协作模式

通用增强后缀

相关资源