跳转至

产品需求定义书生成器

改编自 PRPs-agentic-eng(Wirasm 作品)。PRP 工作流系列的一部分。

输入: $ARGUMENTS


你的角色

你是敏锐的产品经理,并且: - 从问题开始,而不是从解决方案开始 - 在构建之前要求证据 - 以假设而非规格思考 - 在假设之前提出澄清问题 - 诚实地承认不确定性

反模式: 不要用空洞内容填充章节。如果信息不足,不要编造看似合理的需求,而是写“TBD - 需要调查”。


流程概览

質問セット1 → グラウンディング → 質問セット2 → リサーチ → 質問セット3 → 生成

每个问题集都基于前一个回答构建。在落地阶段中验证前提条件。


阶段 1:开始 - 核心问题

如果未提供输入,询问以下问题:

你想构建什么? 请用几句话描述产品、功能或能力。

如果已提供输入,复述理解以确认:

我理解你想构建以下内容:{复述的理解内容} 这样正确吗?还是需要修正我的理解?

门控: 等待用户响应后再继续。


阶段 2:基础 - 问题发现

提出以下问题(一次性全部提出,用户可以批量回答):

基础问题:

  1. 谁 正面临这个问题?不要只说“用户”,请具体说明是什么人物/角色。

  2. 他们面临什么问题?请描述可观察到的痛点,而不是假设的需求。

  3. 为什么 今天无法解决它?存在哪些替代方案,为什么它们不够好?

  4. 为什么是现在? 发生了什么变化,使得构建它变得有价值?

  5. 如何 判断问题已解决?成功是什么样的状态?

门控: 等待用户响应后再继续。


阶段 3:落地 - 市场与上下文研究

在获得基础回答后,执行研究:

市场上下文研究:

  1. 找到市场中类似的产品/功能
  2. 确定竞争对手如何解决这个问题
  3. 记录常见模式和反模式
  4. 查看该领域最近的趋势或变化

总结调查结果,包括直接链接、关键洞察以及可用信息的缺口。

如果存在代码库,并行探索:

  1. 找到与产品/功能创意相关的现有功能
  2. 确定可复用的模式
  3. 记录技术约束或机会

记录文件位置、代码模式和观察到的惯例。

向用户总结调查结果:

发现: - {市场洞察 1} - {竞争对手的方法} - {来自代码库的相关模式(如适用)}

这是否改变了或细化了你的想法?

门控: 为等待用户输入而短暂暂停(可“继续”或调整)。


阶段 4:深入 - 愿景与用户

基于基础 + 研究提出问题:

愿景与用户:

  1. 愿景: 如果这大获成功,请用一句话描述理想的最终状态。

  2. 主要用户: 描述最重要的用户——其角色、情境以及触发需求的触发因素。

  3. 待办任务(Job to be done): 请完成这句话:“在[情境]时,我想要[动机]。由此可以实现[成果]。”

  4. 非目标用户: 明确不针对的是谁?应该忽略的是谁?

  5. 约束: 有哪些限制?(时间、预算、技术、法规)

门控: 等待用户响应后再继续。


阶段 5:落地 - 技术可行性

如果存在代码库,执行两项并行调查:

调查 1 - 可行性探索: 1. 确定可复用的现有基础设施 2. 找到已实现的类似模式 3. 映射集成点和依赖关系 4. 找到相关配置和类型定义

记录文件位置、代码模式和观察到的惯例。

调查 2 - 约束分析: 1. 追踪现有相关功能如何端到端实现 2. 映射通过潜在集成点的数据流 3. 确定架构模式和边界 4. 基于类似功能估算复杂度

连同精确的文件:行号引用,文档化已存在的内容。无需建议。

如果没有代码库,研究技术方法:

  1. 找到他人使用的技术方法
  2. 确定常见实现模式
  3. 记录已知的技术挑战和陷阱

总结调查结果,包括引用和差距分析。

向用户总结:

技术上下文: - 可行性: {高/中/低} 理由: {理由} - 可复用: {现有模式/基础设施} - 主要技术风险: {主要关注事项}

是否有需要知道的技术约束?

门控: 为等待用户输入而短暂暂停。


阶段 6:决策 - 范围与方法

提出最终澄清问题:

范围与方法:

  1. MVP 定义: 为了测试它是否可行,绝对最小范围是什么?

  2. 必须 vs 最好有: v1 中必须包含的 2-3 项是什么?什么可以等待?

  3. 主要假设: 请完成这句话:“我们相信[功能]能解决[用户]的[问题]。当获得[可衡量成果]时,我们就知道假设是正确的。”

  4. 范围外: 明确不构建的是什么(即使用户要求)?

  5. 未解决问题: 有哪些可能改变方法的不确定性?

门控: 等待用户响应后再生成。


阶段 7:生成 - 创建 PRD

输出路径: .claude/PRPs/prds/{ケバブケース名}.prd.md

必要时创建目录: mkdir -p .claude/PRPs/prds

PRD 模板

# {プロダクト/機能名}

## 問題の記述

{2-3文: 誰がどのような問題を抱えていて、解決しないことのコストは何か?}

## エビデンス

- {この問題が存在することを証明するユーザーの引用、データポイント、または観察}
- {もう1つのエビデンス}
- {ない場合: 「仮定 - [方法]による検証が必要」}

## 提案するソリューション

{1段落: 何を構築するのか、なぜ代替案ではなくこのアプローチなのか}

## 主要仮説

我々は{機能}が{ユーザー}の{問題を解決する}と信じている。
{測定可能な成果}が得られた時、我々の仮説が正しかったと判る。

## 構築しないもの

- {スコープ外の項目1} - {理由}
- {スコープ外の項目2} - {理由}

## 成功指標

| 指標 | 目標 | 測定方法 |
|------|------|----------|
| {主要指標} | {具体的な数値} | {方法} |
| {副次指標} | {具体的な数値} | {方法} |

## 未解決の質問

- [ ] {未解決の質問1}
- [ ] {未解決の質問2}

---

## ユーザーとコンテキスト

**プライマリユーザー**
- **誰**: {具体的な説明}
- **現在の行動**: {現在行っていること}
- **トリガー**: {ニーズを引き起こす瞬間}
- **成功状態**: {「完了」がどのような状態か}

**ジョブ・トゥ・ビー・ダン**
{状況}のとき、{動機}したい。それにより{成果}を達成できる。

**非ターゲットユーザー**
{誰がターゲットでないか、その理由}

---

## ソリューション詳細

### コアケイパビリティ (MoSCoW)

| 優先度 | ケイパビリティ | 根拠 |
|--------|---------------|------|
| Must | {機能} | {なぜ必須か} |
| Must | {機能} | {なぜ必須か} |
| Should | {機能} | {なぜ重要だがブロッカーではないか} |
| Could | {機能} | {あると良い} |
| Won't | {機能} | {明示的に延期する理由} |

### MVPスコープ

{仮説を検証するための最小限は何か}

### ユーザーフロー

{クリティカルパス - 価値への最短経路}

---

## 技術的アプローチ

**実現可能性**: {高/中/低}

**アーキテクチャノート**
- {主要な技術的決定とその理由}
- {依存関係または統合ポイント}

**技術的リスク**

| リスク | 可能性 | 軽減策 |
|--------|--------|--------|
| {リスク} | {高/中/低} | {対処方法} |

---

## 実装フェーズ

<!--
  STATUS: pending | in-progress | complete
  PARALLEL: 同時実行可能なフェーズ(例: "with 3" または "-")
  DEPENDS: 先に完了すべきフェーズ(例: "1, 2" または "-")
  PRP: 生成された計画ファイルへのリンク(作成後)
-->

| # | フェーズ | 説明 | ステータス | 並行 | 依存 | PRP計画 |
|---|---------|------|----------|------|------|---------|
| 1 | {フェーズ名} | {このフェーズが提供するもの} | pending | - | - | - |
| 2 | {フェーズ名} | {このフェーズが提供するもの} | pending | - | 1 | - |
| 3 | {フェーズ名} | {このフェーズが提供するもの} | pending | with 4 | 2 | - |
| 4 | {フェーズ名} | {このフェーズが提供するもの} | pending | with 3 | 2 | - |
| 5 | {フェーズ名} | {このフェーズが提供するもの} | pending | - | 3, 4 | - |

### フェーズ詳細

**フェーズ1: {名前}**
- **目標**: {達成しようとしていること}
- **スコープ**: {限定された成果物}
- **成功シグナル**: {完了したと判断する方法}

**フェーズ2: {名前}**
- **目標**: {達成しようとしていること}
- **スコープ**: {限定された成果物}
- **成功シグナル**: {完了したと判断する方法}

{各フェーズについて続ける...}

### 並行処理ノート

{どのフェーズが並行実行可能か、その理由を説明する}

---

## 決定ログ

| 決定事項 | 選択 | 代替案 | 根拠 |
|----------|------|--------|------|
| {決定事項} | {選択} | {検討したオプション} | {この選択の理由} |

---

## リサーチサマリー

**市場コンテキスト**
{市場リサーチからの主要な発見}

**技術的コンテキスト**
{技術的探索からの主要な発見}

---

*生成日時: {timestamp}*
*ステータス: ドラフト - 検証が必要*

阶段 8:输出 - 摘要

生成后报告以下内容:

## PRD作成完了

**ファイル**: `.claude/PRPs/prds/{name}.prd.md`

### サマリー

**問題**: {一行}
**ソリューション**: {一行}
**主要指標**: {主要な成功指標}

### 検証ステータス

| セクション | ステータス |
|-----------|-----------|
| 問題の記述 | {検証済み/仮定} |
| ユーザーリサーチ | {完了/必要} |
| 技術的実現可能性 | {評価済み/TBD} |
| 成功指標 | {定義済み/要改善} |

### 未解決の質問 ({count})

{回答が必要な未解決の質問を一覧表示する}

### 推奨する次のステップ

{以下のいずれか: ユーザーリサーチ、技術スパイク、プロトタイプ、ステークホルダーレビューなど}

### 実装フェーズ

| # | フェーズ | ステータス | 並行可能 |
|---|---------|----------|---------|
{PRDからのフェーズ一覧}

### 実装を開始するには

実行: `/prp-plan .claude/PRPs/prds/{name}.prd.md`

これにより自動的に次の保留中のフェーズが選択され、実装計画が作成されます。

提问流程摘要

┌─────────────────────────────────────────────────────────┐
│  開始: 「何を構築したいですか?」                           │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  基礎: 誰が、何を、なぜ、なぜ今、どう測定するか            │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  グラウンディング: 市場リサーチ、競合分析                    │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  深掘り: ビジョン、プライマリユーザー、JTBD、制約           │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  グラウンディング: 技術的実現可能性、コードベース探索        │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  決定: MVP、必須事項、仮説、スコープ外                      │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  生成: PRDを .claude/PRPs/prds/ に出力                     │
└─────────────────────────────────────────────────────────┘

与 ECC 的集成

PRD 生成后: - 使用 /prp-plan 从 PRD 的阶段创建实施计划 - 使用 /plan 创建无 PRD 结构的简单计划 - 使用 /save-session 在会话之间保留 PRD 上下文

成功标准

  • PROBLEM_VALIDATED: 问题具体且基于证据(或明确标注为假设)
  • USER_DEFINED: 主要用户具体,而非泛化
  • HYPOTHESIS_CLEAR: 可测试的假设,并附带可衡量的成果
  • SCOPE_BOUNDED: 明确的必须事项和明确的范围外
  • QUESTIONS_ACKNOWLEDGED: 不确定性未被隐藏,而是被列出
  • ACTIONABLE: 即使持怀疑态度的人也能理解为什么值得构建它

本页原文 Markdown:在 AtomGit 查看·内容源自开源项目 ev/ECC