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

在项目中查找现有的PRD目录。常见位置：

docs/prds/

、

prds/

、

docs/prd/

、

prd/

。如果不存在，询问用户PRD应存放的位置。

列出现有的PRD文件并确定下一个序号。文件遵循

NNNN-slug.md

的命名格式（例如：

0019-user-onboarding.md

）。下一个文件应为

0020-<slug>.md

。如果还没有任何PRD，则从

开始。

Step 2: Gather Context

步骤2：收集背景信息

Before writing, you need to understand:

What feature or change is this for? — Get a short description from the user if not already provided.
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?"
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.

撰写之前，你需要了解：

这是针对什么功能或变更的？ —— 如果用户尚未提供，请获取简短描述。
业务背景 —— 这为什么重要？它解决了什么问题？谁提出的需求？如果用户未提供，直接询问：“这项需求的业务原因是什么？我们要为谁解决什么问题？”
成功标准 —— 我们如何判断它是否成功？如果不明确，请询问：“我们应该如何衡量成功？用户会有哪些变化？”

在没有明确业务依据的情况下不要继续。缺乏业务背景的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.

完成初稿后，对照参考资料中的质量检查表进行审核：

每个需求是否都有明确的“原因”？
成功指标是否具体且可衡量？
范围是否清晰界定（包含/排除）？
是否考虑了边缘情况和错误状态？
是否明确了依赖关系和风险？

定稿前将初稿提交给用户以获取反馈。