Back to Details

prd

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

PRD (Product Requirements Document)

PRD（产品需求文档）

Expand a problem statement into a comprehensive PRD that bridges problem definition with implementation planning.
将问题陈述扩展为一份全面的PRD，衔接问题定义与实施规划。

Workflow

工作流

1. Check for PROBLEM.md

1. 检查是否存在PROBLEM.md

Look for 
PROBLEM.md
in the project root.
If found: Read it and use as the foundation for the PRD.
If not found: Ask the user:
"No PROBLEM.md found. Would you like me to:
  1. Create one first - Run 
    /problem-statement
    to define the problem clearly
  2. Proceed without it - I'll ask you to describe the problem directly"
If proceeding without PROBLEM.md, gather:
  • What problem are we solving?
  • Who is affected?
  • What does success look like?
在项目根目录查找
PROBLEM.md
文件。
若找到：读取该文件并将其作为PRD的基础。
若未找到：询问用户：
"未找到PROBLEM.md文件。请问您希望我：
  1. 先创建该文件 - 执行
    /problem-statement
    指令以清晰定义问题
  2. 不使用该文件继续 - 我会请您直接描述问题"
若不使用PROBLEM.md继续，需收集以下信息：
  • 我们要解决什么问题？
  • 哪些群体受影响？
  • 成功的标准是什么？

2. Gather Scope Information

2. 收集范围信息

Ask the user:
"What systems or repositories does this work touch?"
Also ask if not already clear from context:
  • Are there existing patterns or approaches we should follow?
  • Who are the stakeholders or reviewers?
  • Any hard constraints (timeline, technology, dependencies)?
询问用户：
"这项工作涉及哪些系统或代码仓库？"
若上下文未明确说明，还需询问：
  • 是否有我们应遵循的现有模式或方案？
  • 相关利益方或评审人员有哪些？
  • 是否存在硬性约束（如时间线、技术选型、依赖项）？

3. Generate PRD.md

3. 生成PRD.md

Create 
PRD.md
at project root using this structure:
markdown
undefined
在项目根目录使用以下结构创建
PRD.md
文件：
markdown
undefined

PRD: [Title from Problem Statement]

PRD：[来自问题陈述的标题]

Problem Statement

问题陈述

[Copy or summarize from PROBLEM.md - Problem, Context, Desired Outcome, Success Criteria]
[从PROBLEM.md中复制或总结 - 问题、背景、预期成果、成功标准]

Proposed Solution

拟议解决方案

Technical Approach

技术方案

High-level description of how to solve this. Focus on the "what" and "why", not implementation details.
对解决方案的高层描述，重点说明“做什么”和“为什么做”，而非具体实现细节。

Key Design Decisions

关键设计决策

Important choices and their rationale. Include alternatives considered if relevant.
重要的决策及其依据，若相关可包含曾考虑过的替代方案。

Scope

范围

Affected Systems

受影响系统

  • System/repo 1: What changes here
  • System/repo 2: What changes here
  • 系统/仓库1：此处的变更内容
  • 系统/仓库2：此处的变更内容

Dependencies

依赖项

External systems, services, or teams this work depends on.
这项工作依赖的外部系统、服务或团队。

Out of Scope

超出范围

[Carry forward from PROBLEM.md, expand if needed]
[沿用PROBLEM.md中的内容，如需可扩展]

Risks & Open Questions

风险与待解决问题

Risks

风险

  • Risk 1: Description and mitigation
  • Risk 2: Description and mitigation
  • 风险1：描述与缓解措施
  • 风险2：描述与缓解措施

Open Questions

待解决问题

  • Question that needs answering before/during implementation
  • Another unresolved question
  • 需在实施前/实施过程中解决的问题
  • 其他未解决问题

Success Criteria

成功标准

[Carry forward from PROBLEM.md]
Generated from PROBLEM.md on [date]
undefined
[沿用PROBLEM.md中的内容]
基于PROBLEM.md生成于[日期]
undefined

4. Open in Typora

4. 在Typora中打开

bash
open -a Typora PRD.md
bash
open -a Typora PRD.md

5. Offer Review

5. 提供评审服务

After opening:
"I've created PRD.md. Would you like me to:
  1. Review for gaps - Check for missing technical details, unclear scope, or unaddressed risks
  2. Done - Proceed with the PRD as-is"
If review requested, spawn a subagent using the Task tool with 
subagent_type: "Explore"
to analyze the codebase and validate the PRD:
Prompt: "Review PRD.md against the actual codebase. Check:
- Does the technical approach align with existing patterns?
- Are affected systems complete? Search for implicit dependencies.
- Do the APIs/endpoints mentioned actually exist? Verify response shapes.
- Are there existing implementations we should reference or follow?
- Are there vague areas that could cause scope creep?
- Are risks adequately identified?

Return structured findings: 🔴 Critical gaps, 🟡 Missing details, 🟢 Confirmed details."
After the subagent returns, present findings and offer options:
  1. Update PRD with findings
  2. Leave as-is for discussion
If user requests updates and needs clarification (e.g., exploring existing patterns), spawn additional Explore agents as needed.
打开文件后：
"我已创建PRD.md文件。请问您希望我：
  1. 检查遗漏内容 - 检查是否缺少技术细节、范围不明确或未提及风险
  2. 完成操作 - 保留当前PRD内容不变"
若用户请求评审，使用Task工具生成
subagent_type: "Explore"
类型的子代理，以分析代码库并验证PRD：
Prompt: "对照实际代码库评审PRD.md文件。检查以下内容：
- 技术方案是否与现有模式一致？
- 受影响系统列表是否完整？查找隐含依赖项。
- 提及的API/端点是否真实存在？验证响应格式。
- 是否有我们可参考或遵循的现有实现？
- 是否存在可能导致范围蔓延的模糊区域？
- 风险是否已充分识别？

返回结构化结果：🔴 关键遗漏，🟡 缺失细节，🟢 已确认细节。"
子代理返回结果后，展示发现的问题并提供选项：
  1. 根据发现的问题更新PRD
  2. 保持原样用于讨论
若用户请求更新并需要澄清（如探索现有模式），可根据需要生成更多Explore代理。

6. Offer Next Steps

6. 提供后续步骤选项

After review is complete (or if user chose "Done"):
"PRD is ready. Would you like me to:
  1. Create technical specs - Run 
    /specs
    to create detailed specifications
  2. Done - Proceed with the PRD as-is"
评审完成后（或用户选择“完成操作”后）：
"PRD已准备就绪。请问您希望我：
  1. 创建技术规格文档 - 执行
    /specs
    指令以创建详细的技术规格
  2. 完成操作 - 保留当前PRD内容不变"