阶段 2：PRD - 生成产品需求文档

PRD 阶段是 Agent App Factory 流水线的第二个阶段，负责将 input/idea.md 转化为完整的、面向 MVP（最小可行产品）的产品需求文档。这个阶段将明确目标用户、核心功能、MVP 范围和非目标，为后续的 UI 设计和技术架构提供清晰的指引。

学完你能做什么

将 input/idea.md 转化为符合标准模板的 artifacts/prd/prd.md 文档
理解 PRD Agent 的职责边界（只定义需求，不涉及技术实现）
掌握 MoSCoW 功能优先级框架，确保 MVP 聚焦核心价值
能够编写高质量的用户故事和可验证的验收标准
知道哪些内容应该在 PRD 中，哪些应该在后续阶段

你现在的困境

你可能有一个清晰的产品想法（Bootstrap 阶段已完成），但在转化为需求文档时遇到困难：

"不知道应该包含哪些功能，担心遗漏或过度设计"
"功能很多，但不知道哪些是 MVP 必需的"
"用户故事写得不清楚，开发团队无法理解"
"不小心把技术实现细节混入需求，导致范围蔓延"

这种不清晰的 PRD 会导致后续 UI 设计和代码开发缺乏明确指引，最终生成的应用可能偏离你的预期或包含不必要的复杂度。

什么时候用这一招

当 Bootstrap 阶段完成，并且满足以下条件时：

已完成 idea.md 结构化（Bootstrap 阶段输出）
还没开始 UI 设计或技术架构（这些在后续阶段）
希望明确 MVP 范围（避免功能过度设计）
需要为开发和设计提供清晰指引（用户故事、验收标准）

🎒 开始前的准备

前置条件

在开始 PRD 阶段前，请确保：

✅ 已完成项目初始化
✅ 已了解 7 阶段流水线概览
✅ 已完成 Bootstrap 阶段，生成了 input/idea.md
✅ 已安装并配置好 AI 助手（推荐 Claude Code）

核心思路

什么是 PRD 阶段？

PRD（Product Requirements Document，产品需求文档）阶段的核心职责是定义要做什么，而不是怎么做。

不是技术文档

PRD Agent 不是架构师或 UI 设计师，它不会替你决定：

❌ 使用什么技术栈（React vs Vue，Express vs Koa）
❌ 数据库如何设计（表结构、索引）
❌ UI 布局和交互细节（按钮位置、颜色方案）

它的任务是：

✅ 定义目标用户和他们的痛点
✅ 列出核心功能和优先级
✅ 明确 MVP 范围和非目标
✅ 提供可测试的用户故事和验收标准

为什么要 PRD？

想象一下，你告诉施工队："我想建个房子"

❌ 没有图纸：施工队只能猜测，可能建成你完全不想住的房子
✅ 有详细图纸：明确房间数量、功能布局、材料要求，施工队按图施工

PRD 阶段就是把"我想建个房子"变成"三室两厅、主卧朝南、开放式厨房"的详细图纸。

MoSCoW 功能优先级框架

PRD 阶段使用 MoSCoW 框架对功能进行分类，确保 MVP 聚焦在核心价值上：

分类	定义	判断标准	示例
Must Have	MVP 绝对不能缺少的功能	没有它产品无法交付核心价值	记账应用：添加支出记录、查看支出列表
Should Have	重要但非阻塞的功能	用户会明显感受到缺失，但可以暂时用变通方案	记账应用：导出报表、分类统计
Could Have	锦上添花的功能	不影响核心体验，用户不会特别注意到缺失	记账应用：预算提醒、多币种支持
Won't Have	明确排除的功能	与核心价值无关或技术复杂度高	记账应用：社交分享、投资建议

MVP 核心

Must Have 功能应该控制在 5-7 个以内，确保 MVP 聚焦核心价值，避免范围蔓延。

跟我操作

第 1 步：确认 Bootstrap 阶段已完成

在开始 PRD 阶段前，确保 input/idea.md 已存在且内容符合标准。

bash

# 检查 idea.md 是否存在
cat input/idea.md

你应该看到：包含简要描述、问题、目标用户、核心价值、假设、非目标等章节的结构化文档。

如果 idea.md 不符合标准

返回 Bootstrap 阶段重新生成，或者手动编辑补充信息。

第 2 步：启动流水线到 PRD 阶段

在 Factory 项目目录中执行：

bash

# 如果流水线已经启动，继续到 PRD 阶段
factory run prd

# 或从头启动流水线
factory run

CLI 会显示当前状态和可用阶段，并生成 PRD Agent 的助手指令。

第 3 步：AI 助手读取 PRD Agent 定义

AI 助手（如 Claude Code）会自动读取 agents/prd.agent.md，了解其职责和约束。

PRD Agent 职责

PRD Agent 只能：

读取 input/idea.md
写入 artifacts/prd/prd.md
使用 skills/prd/skill.md 中的思维框架和决策原则

它不能：

讨论任何技术实现细节或 UI 设计
读取其他文件（包括 upstream 产物）
写入其他目录

第 4 步：加载 skills/prd/skill.md

PRD Agent 会加载 skills/prd/skill.md，获取以下指导：

思维框架：

目标用户：谁会使用？背景、角色、痛点是什么？
核心问题：产品要解决什么根本问题？
核心价值：为什么这个方案有价值？和竞品相比优势在哪里？
成功指标：如何衡量成功？

MoSCoW 功能优先级：

Must Have（必须有）：MVP 绝对不能缺少的功能
Should Have（应该有）：重要但非阻塞的功能
Could Have（可以有）：锦上添花的功能
Won't Have（不会有）：明确排除的功能

用户故事编写指南：

作为 [角色/用户类型]
我想要 [功能/操作]
以便 [业务价值/目标]

PRD 文档结构要求（8 个章节）：

概述
目标用户画像
核心价值主张
功能需求（MoSCoW 分类）
用户流程
非目标（Won't Have）
成功指标
假设和风险

第 5 步：生成 PRD 文档

AI 助手会根据 input/idea.md 的内容，使用技能中的思维框架和决策原则，生成完整的 PRD 文档。

PRD Agent 会做什么：

阅读 input/idea.md，提炼关键元素（目标用户、问题、核心价值等）
按照 MoSCoW 框架对功能进行分类
为 Must Have 功能编写用户故事和验收标准
列出非目标，防止范围蔓延
给出可量化的成功指标
将整理好的文档写入 artifacts/prd/prd.md

关键约束

PRD Agent 禁止讨论技术实现细节或 UI 设计。如果发现这些内容，PRD Agent 会拒绝写入。

第 6 步：确认 prd.md 内容

PRD Agent 完成后，会生成 artifacts/prd/prd.md。你需要仔细检查：

检查点 ✅：

目标用户是否具体？
- ✅ 有具体画像（年龄/职业/技术能力/使用场景/痛点）
- ❌ 模糊："所有人"或"需要记账的人"
核心问题是否清晰？
- ✅ 描述了用户在现实场景下遇到的难题
- ❌ 空泛："用户体验不好"
核心价值是否可量化？
- ✅ 有具体收益（节省 80% 时间、提升 50% 效率）
- ❌ 空泛："提升效率"、"更好的体验"
Must Have 功能是否聚焦？
- ✅ 不超过 5-7 个核心功能
- ❌ 功能过多或包含次要功能
每个 Must Have 功能是否有用户故事？
- ✅ 使用标准格式（作为...我想要...以便...）
- ❌ 缺失用户故事或格式不正确
验收标准是否可验证？
- ✅ 有具体可验证的标准（可以输入金额、显示在列表中）
- ❌ 模糊（"用户友好"、"体验流畅"）
Should Have和Won't Have是否明确列出？
- ✅ Should Have 标注为"未来迭代"并说明原因
- ✅ Won't Have 说明为什么排除
- ❌ 缺失或太少
成功指标是否可量化？
- ✅ 有具体数值（用户留存率 > 30%、任务完成时间 < 30 秒）
- ❌ 模糊（"用户喜欢"、"体验好"）
假设是否可验证？
- ✅ 可通过用户调研验证
- ❌ 主观判断（"用户会喜欢"）
是否包含技术实现细节或 UI 设计？
- ✅ 无技术细节和 UI 描述
- ❌ 包含技术栈选择、数据库设计、UI 布局等

第 7 步：选择继续、重试或暂停

确认无误后，CLI 会显示选项：

bash

请选择操作：
[1] 继续（进入 UI 阶段）
[2] 重试（重新生成 prd.md）
[3] 暂停（稍后继续）

建议先在代码编辑器中查看

在 AI 助手中确认前，先用代码编辑器打开 artifacts/prd/prd.md，逐字检查。一旦进入 UI 阶段，修改成本会更高。

踩坑提醒

坑 1：Must Have 功能过多

错误示例：

Must Have:
1. 添加支出记录
2. 查看支出列表
3. 导出报表
4. 分类统计
5. 预算提醒
6. 多币种支持
7. 社交分享
8. 投资建议

后果：MVP 范围过大，开发周期长，风险高。

建议：控制在 5-7 个核心功能：

Must Have:
1. 添加支出记录
2. 查看支出列表
3. 选择支出类别

Should Have（未来迭代）:
4. 导出报表
5. 分类统计

Won't Have（明确排除）:
6. 社交分享（与核心价值无关）
7. 投资建议（需要专业资质，技术复杂度高）

坑 2：用户故事缺失或格式不正确

错误示例：

功能：添加支出记录
描述：用户可以添加支出记录

后果：开发团队不清楚要为谁做、解决什么问题。

建议：使用标准格式：

功能：添加支出记录
用户故事：作为一个预算意识强的用户
我想要记录每一笔支出
以便了解我的消费去向和控制预算

验收标准：
- 可以输入支出金额和描述
- 可以选择支出类别
- 记录立即显示在支出列表中
- 显示当前日期和时间

坑 3：验收标准不可验证

错误示例：

验收标准：
- 用户界面友好
- 操作流畅
- 体验良好

后果：无法测试，开发团队不知道什么算"友好"、"流畅"、"良好"。

建议：写具体可验证的标准：

验收标准：
- 可以输入支出金额和描述
- 可以从 10 个预设类别中选择
- 记录在 1 秒内显示在支出列表中
- 自动记录当前日期和时间

坑 4：目标用户描述太泛

错误示例：

目标用户：所有需要记账的人

后果：后续 UI 设计和技术架构无法明确方向。

建议：明确画像：

主要用户群体：
- 角色：18-30 岁刚工作的年轻人
- 年龄：18-30 岁
- 技术能力：中级，熟悉智能手机应用
- 使用场景：日常消费后立即记录，月底查看统计
- 痛点：月底发现超支，但不知道钱花在哪，没有预算控制

坑 5：非目标缺失或太少

错误示例：

非目标：无

后果：后续 PRD 和 Code 阶段可能过度设计，增加技术复杂度。

建议：至少列出 3 项：

非目标 (Out of Scope)：
- 社交分享功能（MVP 聚焦个人记账）
- 财务建议和投资分析（需要专业资质，超出核心价值）
- 与第三方金融系统集成（技术复杂度高，MVP 不需要）
- 复杂的数据分析和报表（Should Have，未来迭代）

坑 6：包含技术实现细节

错误示例：

功能：添加支出记录
技术实现：使用 React Hook Form 管理表单，API 端点 POST /api/expenses

后果：PRD Agent 会拒绝这些内容（只定义需求，不涉及技术实现）。

建议：只说"做什么"，不说"怎么做"：

功能：添加支出记录
用户故事：作为一个预算意识强的用户
我想要记录每一笔支出
以便了解我的消费去向和控制预算

验收标准：
- 可以输入支出金额和描述
- 可以选择支出类别
- 记录立即显示在支出列表中
- 显示当前日期和时间

坑 7：成功指标不可量化

错误示例：

成功指标：
- 用户喜欢我们的应用
- 体验流畅
- 用户留存高

后果：无法衡量产品是否成功。

建议：写可量化的指标：

成功指标：
产品目标：
- 第一个月获得 100 个活跃用户
- 用户每周至少使用 3 次
- 核心功能（添加支出记录）使用率 > 80%

关键指标 (KPIs)：
- 用户留存率：7 日留存 > 30%，30 日留存 > 15%
- 核心功能使用率：添加支出记录使用率 > 80%
- 任务完成时间：添加一次支出 < 30 秒

验证方法：
- 通过后端日志记录用户行为
- 使用 A/B 测试验证用户留存
- 通过用户反馈问卷收集满意度

坑 8：假设不可验证

错误示例：

假设：用户会喜欢我们的设计

后果：无法通过用户调研验证，MVP 可能失败。

建议：写可验证的假设：

假设：
市场假设：
- 年轻人（18-30 岁）存在"不知道钱花在哪"的痛点
- 现有记账应用过于复杂，年轻人需要更简单的解决方案

用户行为假设：
- 用户愿意在每次消费后花费 2 分钟记录支出，如果能帮助控制预算
- 用户更喜欢极简的 UI，不需要复杂的图表和分析

技术可行性假设：
- 移动端应用可以实现快速的 3 步记账流程
- 离线存储可以满足基本需求

本课小结

PRD 阶段的核心是定义需求，而非实现：

输入：结构化的 input/idea.md（Bootstrap 阶段输出）
过程：AI 助手使用 skills/prd/skill.md 的思维框架和 MoSCoW 优先级框架
输出：完整的 artifacts/prd/prd.md 文档
验证：检查用户是否明确、价值是否可量化、功能是否聚焦、是否包含技术细节

关键原则

❌ 不做什么：不讨论技术实现、不设计 UI 布局、不决定数据库结构
✅ 只做什么：定义目标用户、列出核心功能、明确 MVP 范围、提供可测试的用户故事

下一课预告

下一课我们学习 阶段 3：UI - 设计界面与原型。
你会学到：
如何根据 PRD 设计 UI 结构
如何使用 ui-ux-pro-max 技能生成设计系统
如何生成可预览的 HTML 原型
UI 阶段的输出文件和退出条件

附录：源码参考

点击展开查看源码位置

更新时间：2026-01-29

功能	文件路径	行号
PRD Agent 定义	`agents/prd.agent.md`	1-33
PRD Skill	`skills/prd/skill.md`	1-325
流水线定义（PRD 阶段）	`pipeline.yaml`	20-33
调度器定义	`agents/orchestrator.checkpoint.md`	1-100+

关键约束：

禁止技术实现细节：prd.agent.md:23
禁止 UI 设计描述：prd.agent.md:23
必须包含目标用户：pipeline.yaml:29
必须定义 MVP 范围：pipeline.yaml:30
必须列出非目标：pipeline.yaml:31
输出文件必须保存到 artifacts/prd/prd.md：prd.agent.md:13

退出条件（pipeline.yaml:28-32）：

PRD 包含目标用户
PRD 定义 MVP 范围
PRD 列出非目标（Out of Scope）
PRD 不包含任何技术实现细节

Skill 内容框架：

思维框架：目标用户、核心问题、核心价值、成功指标
MoSCoW 功能优先级框架：Must Have、Should Have、Could Have、Won't Have
用户故事编写指南：标准格式和示例
PRD 文档结构要求：8 个必需章节
决策原则：以用户为中心、关注 MVP、非目标明确、可测试性
质量检查清单：用户和问题、功能范围、用户故事、文档完整性、禁止项检查
不要做 (NEVER)：7 条明确禁止的行为

PRD 文档必需章节：

概述（产品概述、背景和目标）
目标用户画像（主要用户群体、次要用户群体）
核心价值主张（解决的问题、我们的方案、差异化优势）
功能需求（Must Have、Should Have、Could Have）
用户流程（主流程描述）
非目标（Won't Have）
成功指标（产品目标、关键指标、验证方法）
假设和风险（市场假设、用户行为假设、技术可行性假设、风险表）

阶段 2：PRD - 生成产品需求文档 ​

学完你能做什么 ​

你现在的困境 ​

什么时候用这一招 ​

🎒 开始前的准备 ​

核心思路 ​

什么是 PRD 阶段？ ​

为什么要 PRD？ ​

MoSCoW 功能优先级框架 ​

跟我操作 ​

第 1 步：确认 Bootstrap 阶段已完成 ​

第 2 步：启动流水线到 PRD 阶段 ​

第 3 步：AI 助手读取 PRD Agent 定义 ​

第 4 步：加载 skills/prd/skill.md ​

第 5 步：生成 PRD 文档 ​

第 6 步：确认 prd.md 内容 ​

第 7 步：选择继续、重试或暂停 ​

踩坑提醒 ​

坑 1：Must Have 功能过多 ​

坑 2：用户故事缺失或格式不正确 ​

坑 3：验收标准不可验证 ​

坑 4：目标用户描述太泛 ​

坑 5：非目标缺失或太少 ​

坑 6：包含技术实现细节 ​

坑 7：成功指标不可量化 ​

坑 8：假设不可验证 ​

本课小结 ​

下一课预告 ​

附录：源码参考 ​

阶段 2：PRD - 生成产品需求文档

学完你能做什么

你现在的困境

什么时候用这一招

🎒 开始前的准备

核心思路

什么是 PRD 阶段？

为什么要 PRD？

MoSCoW 功能优先级框架

跟我操作

第 1 步：确认 Bootstrap 阶段已完成

第 2 步：启动流水线到 PRD 阶段

第 3 步：AI 助手读取 PRD Agent 定义

第 4 步：加载 skills/prd/skill.md

第 5 步：生成 PRD 文档

第 6 步：确认 prd.md 内容

第 7 步：选择继续、重试或暂停

踩坑提醒

坑 1：Must Have 功能过多

坑 2：用户故事缺失或格式不正确

坑 3：验收标准不可验证

坑 4：目标用户描述太泛

坑 5：非目标缺失或太少

坑 6：包含技术实现细节

坑 7：成功指标不可量化

坑 8：假设不可验证

本课小结

下一课预告

附录：源码参考