Back to Details

write-prd

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Write PRD

撰写PRD

Create a new Product Requirements Document in the project's PRD directory.
在项目的PRD目录中创建新产品需求文档。

Step 1: Find the PRD Directory and Next Number

步骤1：查找PRD目录并确定下一个编号

Look for an existing PRD directory in the project. Common locations: 
docs/prds/
, 
prds/
, 
docs/prd/
, 
prd/
. If none exists, ask the user where PRDs should live.
List existing PRD files and determine the next sequence number. Files follow the pattern 
NNNN-slug.md
(e.g., 
0019-user-onboarding.md
). The next file would be 
0020-<slug>.md
. If no PRDs exist yet, start at 
0001
.
在项目中查找现有的PRD目录。常见位置：
docs/prds/
、
prds/
、
docs/prd/
、
prd/
。如果不存在，询问用户PRD应存放的位置。
列出现有的PRD文件并确定下一个序号。文件遵循
NNNN-slug.md
的命名格式（例如：
0019-user-onboarding.md
）。下一个文件应为
0020-<slug>.md
。如果还没有任何PRD，则从
0001
开始。

Step 2: Gather Context

步骤2：收集背景信息

Before writing, you need to understand:
  1. What feature or change is this for? — Get a short description from the user if not already provided.
  2. Business context — Why does this matter? What problem does it solve? Who asked for it? If the user hasn't provided this, ask directly: "What's the business reason for this? What problem are we solving and for whom?"
  3. Success criteria — How will we know this worked? Ask if not obvious: "How should we measure success? What changes for the user?"
Do not proceed without a clear business justification. A PRD without business context is just a feature spec.
撰写之前，你需要了解：
  1. 这是针对什么功能或变更的？ —— 如果用户尚未提供，请获取简短描述。
  2. 业务背景 —— 这为什么重要？它解决了什么问题？谁提出的需求？如果用户未提供，直接询问：“这项需求的业务原因是什么？我们要为谁解决什么问题？”
  3. 成功标准 —— 我们如何判断它是否成功？如果不明确，请询问：“我们应该如何衡量成功？用户会有哪些变化？”
在没有明确业务依据的情况下不要继续。缺乏业务背景的PRD只是一份功能规格说明。

Step 3: Generate the Filename

步骤3：生成文件名

Combine the next sequence number with 2-4 kebab-case keywords from the feature description:
  • 0020-fix-social-sharing.md
  • 0021-add-team-billing.md
  • 0022-migrate-auth-to-oauth2.md
Confirm the filename with the user before writing.
将下一个序号与功能描述中的2-4个短横线分隔式（kebab-case）关键词组合：
  • 0020-fix-social-sharing.md
  • 0021-add-team-billing.md
  • 0022-migrate-auth-to-oauth2.md
撰写前请与用户确认文件名。

Step 4: Write the PRD

步骤4：撰写PRD

Use the template structure from the references. The PRD should be:
  • Problem-first — Lead with why, not what
  • Measurable — Every goal has a success metric
  • Scoped — Explicit about what's in and what's out
  • User-centered — Written from the user's perspective, not the developer's
  • Implementation-free — Describe what, not how (no architecture, no code)
Consult 
references/prd-best-practices.md
for good and bad examples. Consult 
references/prd-template.md
for the document structure.
使用参考资料中的模板结构。PRD应满足：
  • 以问题为导向 —— 先说明原因，再说明内容
  • 可衡量 —— 每个目标都有成功指标
  • 明确范围 —— 清晰界定包含和排除的内容
  • 以用户为中心 —— 从用户视角撰写，而非开发者视角
  • 无实现细节 —— 描述要做什么，而非怎么做（不涉及架构、代码）
参考
references/prd-best-practices.md
中的正反示例。 参考
references/prd-template.md
获取文档结构。

Step 5: Review and Refine

步骤5：审核与优化

After writing the first draft, review it against the quality checklist in the references:
  • Does every requirement have a clear "why"?
  • Are success metrics specific and measurable?
  • Is scope clearly bounded (in/out)?
  • Are edge cases and error states considered?
  • Are dependencies and risks called out?
Present the draft to the user for feedback before finalizing.
完成初稿后，对照参考资料中的质量检查表进行审核：
  • 每个需求是否都有明确的“原因”？
  • 成功指标是否具体且可衡量？
  • 范围是否清晰界定（包含/排除）？
  • 是否考虑了边缘情况和错误状态？
  • 是否明确了依赖关系和风险？
定稿前将初稿提交给用户以获取反馈。