Back to Details

writing-prds

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Writing PRDs

撰写PRD

Scope

范围

Covers
  • Turning a product idea into a decision-ready PRD with unambiguous scope, requirements, and success metrics
  • Optionally producing a PR/FAQ (press release + FAQ) to force customer-centric narrative first
  • For AI features: adding a Prompt Set + Eval Spec so “requirements” are testable and continuously checkable
When to use
  • “Write a PRD / product spec / requirements doc for this feature.”
  • “Turn these messy notes into a PRD we can align on.”
  • “Create a PR/FAQ and then a PRD.”
  • “This is an AI feature; I need evals + prompts to define behavior.”
When NOT to use
  • You’re still choosing what strategy/market to pursue (do product vision / strategy first)
  • You need discovery from scratch (research plan, problem validation) more than requirements
  • You need a detailed engineering design doc (APIs, schemas, low-level architecture)
  • You’re prioritizing among many initiatives (do roadmap prioritization first)
涵盖内容
  • 将产品想法转化为一份可用于决策的PRD，包含明确的范围、需求和成功指标
  • 可选生成PR/FAQ（新闻稿+常见问题），优先构建以客户为中心的叙事
  • 针对AI功能：添加Prompt Set + Eval Spec，让“需求”可测试且能持续验证
适用场景
  • “为这个功能撰写PRD/产品规格/需求文档。”
  • “把这些零散的笔记整理成一份我们可以对齐的PRD。”
  • “先创建PR/FAQ，再写PRD。”
  • “这是一个AI功能；我需要评估指标和提示词来定义其行为。”
不适用场景
  • 你仍在选择要追求的战略/市场（先做产品愿景/战略）
  • 相比需求，你更需要从零开始的探索（研究计划、问题验证）
  • 你需要详细的工程设计文档（API、schema、底层架构）
  • 你需要在多个项目中进行优先级排序（先做路线图优先级排序）

Inputs

输入信息

Minimum required
  • Product + target user/customer segment
  • Problem statement + why now (what changed, what’s broken, or what opportunity exists)
  • Goal(s) + non-goal(s) + key constraints (timeline, policy/legal, platform, dependencies)
  • Success metric(s) + 2–5 guardrails (quality, safety, cost, latency, trust)
If it’s an AI feature (additionally)
  • What the model/system should do vs must never do (policy + safety)
  • Concrete examples of desired and undesired outputs
  • How correctness will be evaluated (offline tests, human review, online metrics)
Missing-info strategy
  • Ask up to 5 questions from references/INTAKE.md.
  • If answers are still missing, proceed with clearly labeled assumptions and provide 2–3 options (scope, metric, rollout).
最低必填项
  • 产品+目标用户/客户群体
  • 问题陈述+为什么是现在（发生了什么变化、哪里出了问题，或者存在什么机会）
  • 目标+非目标+关键约束（时间线、政策/法律、平台、依赖项）
  • 成功指标+2–5个护栏指标（质量、安全、成本、延迟、信任）
如果是AI功能（额外要求）
  • 模型/系统应该做什么和绝对不能做什么（政策+安全）
  • 期望和非期望输出的具体示例
  • 如何评估正确性（离线测试、人工审核、线上指标）
缺失信息处理策略
  • 从references/INTAKE.md中提出最多5个问题。
  • 如果仍缺少答案，继续推进并明确标注假设，同时提供2–3个选项（范围、指标、上线计划）。

Outputs (deliverables)

输出成果（交付物）

Produce a PRD Pack in Markdown (in-chat; or as files if the user requests):
  1. Context snapshot (what decision we’re making, constraints, stakeholders)
  2. Artifact selection (PR/FAQ vs PRD vs AI add-ons)
  3. PR/FAQ (optional) — customer narrative + FAQs
  4. PRD — goals/non-goals, requirements (R1…Rn), UX flows, metrics, rollout
  5. AI Prompt Set (if AI) — versioned prompts + examples + guardrails
  6. AI Eval Spec (if AI) — acceptance tests + judge prompts + pass/fail criteria
  7. Risks / Open questions / Next steps (always included)
Templates: references/TEMPLATES.md
生成一份Markdown格式的PRD包（在对话中；或根据用户请求生成文件）：
  1. 上下文快照（我们要做的决策、约束、相关利益方）
  2. 产出物选择（PR/FAQ vs PRD vs AI附加组件）
  3. PR/FAQ（可选）——客户叙事+常见问题
  4. PRD——目标/非目标、需求（R1…Rn）、用户流程、指标、上线计划
  5. AI Prompt Set（如果是AI功能）——带版本的提示词+示例+护栏指标
  6. AI Eval Spec（如果是AI功能）——验收测试+评审提示词+通过/失败标准
  7. 风险/未解决问题/下一步行动（始终包含）
模板：references/TEMPLATES.md

Workflow (8 steps)

工作流程（8个步骤）

1) Decide the artifact set (don’t over-document)

1) 确定产出物集合（不要过度文档化）

  • Inputs: User request + constraints.
  • Actions: Choose: PR/FAQ only, PRD only, PR/FAQ → PRD, or PRD + AI add-ons (Prompt Set + Eval Spec).
  • Outputs: Artifact selection + rationale.
  • Checks: The artifacts match the decision being made and the audience.
  • 输入： 用户请求+约束条件。
  • 行动： 选择：仅PR/FAQ、仅PRD、PR/FAQ→PRD，或PRD+AI附加组件（Prompt Set + Eval Spec）。
  • 输出： 产出物选择+理由。
  • 检查： 产出物与要做的决策和受众匹配。

2) Intake + clarify decision and success

2) 收集并明确决策与成功标准

  • Inputs: references/INTAKE.md.
  • Actions: Ask up to 5 questions; confirm decision owner, timeline, constraints, and success metrics/guardrails.
  • Outputs: Context snapshot.
  • Checks: You can state “what we’re deciding” and “how we’ll measure success” in 1–2 sentences.
  • 输入： references/INTAKE.md。
  • 行动： 提出最多5个问题；确认决策负责人、时间线、约束条件以及成功指标/护栏指标。
  • 输出： 上下文快照。
  • 检查： 你可以用1–2句话说明“我们要做什么决策”和“我们如何衡量成功”。

3) Write the customer narrative first (PR/FAQ or PRD narrative)

3) 先撰写客户叙事（PR/FAQ或PRD叙事部分）

  • Inputs: Context snapshot.
  • Actions: Draft a customer-centric narrative (problem → solution → why now). If using PR/FAQ, draft the press release headline/summary and top FAQs.
  • Outputs: Narrative section (and PR/FAQ if selected).
  • Checks: A stakeholder can restate the customer benefit and urgency without jargon.
  • 输入： 上下文快照。
  • 行动： 起草以客户为中心的叙事（问题→解决方案→为什么是现在）。如果使用PR/FAQ，起草新闻稿标题/摘要和核心常见问题。
  • 输出： 叙事部分（以及选中的PR/FAQ）。
  • 检查： 相关利益方可以不用行话复述客户价值和紧迫性。

4) Lock scope boundaries (goals, non-goals, out of scope)

4) 锁定范围边界（目标、非目标、超出范围内容）

  • Inputs: Narrative + constraints.
  • Actions: Define goals, non-goals, and explicit exclusions; call out dependencies and assumptions.
  • Outputs: Scope section(s) in the PRD.
  • Checks: “What we are NOT doing” is as clear as what we are doing.
  • 输入： 叙事+约束条件。
  • 行动： 定义目标、非目标和明确的排除项；标注依赖项和假设。
  • 输出： PRD中的范围部分。
  • 检查： “我们不做什么”和“我们做什么”一样清晰。

5) Convert scope into testable requirements (R1…Rn)

5) 将范围转化为可测试的需求（R1…Rn）

  • Inputs: Goals + user journeys.
  • Actions: Write numbered requirements with acceptance criteria, edge cases, and non-functional needs (privacy, latency, reliability). Mark “must/should/could”.
  • Outputs: Requirements table/list.
  • Checks: An engineer or QA can turn requirements into test cases without asking you to interpret intent.
  • 输入： 目标+用户旅程。
  • 行动： 撰写带验收标准、边缘案例和非功能性需求（隐私、延迟、可靠性）的编号需求。标注“必须/应该/可以”。
  • 输出： 需求表格/列表。
  • 检查： 工程师或QA无需询问意图，就能将需求转化为测试用例。

6) Define UX flows + instrumentation plan

6) 定义用户流程+埋点计划

  • Inputs: Requirements + current product surfaces/events.
  • Actions: Describe key user flows/states; specify success metrics, guardrails, and event/data needs (what to log, where, who owns).
  • Outputs: UX/flows section + metrics & instrumentation section.
  • Checks: Every goal has at least one measurable metric and a realistic data source.
  • 输入： 需求+现有产品界面/事件。
  • 行动： 描述关键用户流程/状态；明确成功指标、护栏指标以及事件/数据需求（要记录什么、在哪里记录、负责人是谁）。
  • 输出： 用户流程部分+指标与埋点部分。
  • 检查： 每个目标至少有一个可衡量的指标和真实的数据来源。

7) If AI feature: ship prompts + evals as “living requirements”

7) 如果是AI功能：将提示词+评估规范作为“活需求”交付

  • Inputs: Requirements + examples.
  • Actions: Create a versioned Prompt Set and an Eval Spec (judge prompts + test set + pass thresholds). Include red-team/failure modes.
  • Outputs: Prompt Set + Eval Spec drafts.
  • Checks: The eval suite can fail when behavior regresses and pass when requirements are met.
  • 输入： 需求+示例。
  • 行动： 创建带版本的Prompt Set和Eval Spec（评审提示词+测试集+通过阈值）。包含红队测试/失败场景。
  • 输出： Prompt Set + Eval Spec草稿。
  • 检查： 当行为退化时评估套件会失败，当需求满足时会通过。

8) Quality gate + finalize for circulation

8) 质量把关+定稿分发

  • Inputs: Full draft pack.
  • Actions: Run references/CHECKLISTS.md and score with references/RUBRIC.md. Add Risks/Open questions/Next steps.
  • Outputs: Final PRD Pack (shareable as-is).
  • Checks: Decisions, owners, metrics, and open questions are explicit.
  • 输入： 完整的草稿包。
  • 行动： 使用references/CHECKLISTS.md检查，并通过references/RUBRIC.md评分。添加风险/未解决问题/下一步行动。
  • 输出： 最终PRD包（可直接分享）。
  • 检查： 决策、负责人、指标和未解决问题都明确清晰。

Quality gate (required)

质量把关（必填）

  • Use references/CHECKLISTS.md and references/RUBRIC.md.
  • Always include: Risks, Open questions, Next steps.
  • 使用references/CHECKLISTS.md和references/RUBRIC.md。
  • 必须包含：风险、未解决问题、下一步行动。

Examples

示例

Example 1 (B2B SaaS feature): “Write a PR/FAQ + PRD for ‘Saved views’ in our analytics dashboard for admins.”
Expected: PR/FAQ narrative, a scoped PRD with R1…Rn, metrics/guardrails, and a rollout plan.
Example 2 (AI feature): “Write a PRD + Prompt Set + Eval Spec for an ‘AI email reply’ assistant with brand tone constraints.”
Expected: requirements that include safety/brand constraints, a prompt set with examples, and an eval spec with judge prompts + pass/fail thresholds.
Boundary example: “Write a PRD for ‘make onboarding better’ (no product context).”
Response: ask the minimum intake questions; if context remains missing, produce 2–3 scoped options + assumptions and recommend discovery before committing to requirements.
示例1（B2B SaaS功能）： “为我们的分析仪表板中面向管理员的‘保存视图’功能撰写PR/FAQ + PRD。”
预期产出：PR/FAQ叙事、带R1…Rn的限定范围PRD、指标/护栏指标，以及上线计划。
示例2（AI功能）： “为带有品牌调性约束的‘AI邮件回复助手’撰写PRD + Prompt Set + Eval Spec。”
预期产出：包含安全/品牌约束的需求、带示例的提示词集，以及带评审提示词+通过/失败阈值的评估规范。
边界示例： “为‘优化新用户引导’撰写PRD（无产品上下文）。”
回应：提出最低要求的收集问题；如果仍缺少上下文，生成2–3个限定范围的选项+假设，并建议在确定需求前先进行探索研究。