Back to Details

prd-writer

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Product Requirements Document (PRD)

产品需求文档（PRD）

Overview

概述

Design comprehensive, production-grade Product Requirements Documents (PRDs) that bridge the gap between business vision and technical execution. This skill works for modern software systems, ensuring that requirements are clearly defined.
设计全面、可用于生产环境的产品需求文档（PRDs），打通业务愿景与技术落地之间的鸿沟。该技能适用于现代软件系统，确保需求定义清晰明确。

When to Use

使用场景

Use this skill when:
  • Starting a new product or feature development cycle
  • Translating a vague idea into a concrete technical specification
  • Defining requirements for AI-powered features
  • Stakeholders need a unified "source of truth" for project scope
  • User asks to "write a PRD", "document requirements", or "plan a feature"
在以下场景中使用该技能：
  • 启动新产品或新功能的开发周期时
  • 将模糊的想法转化为具体的技术规格说明时
  • 为AI驱动功能定义需求时
  • 利益相关者需要一个统一的项目范围「唯一可信来源」时
  • 用户提出「撰写PRD」「记录需求」或「规划功能」等请求时

Operational Workflow

操作流程

Phase 1: Discovery (The Interview)

阶段1：发现（访谈环节）

Before writing a single line of the PRD, you MUST interrogate the user to fill knowledge gaps. Do not assume context.
Ask about:
  • The Core Problem: Why are we building this now?
  • Success Metrics: How do we know it worked?
  • Constraints: Budget, tech stack, or deadline?
在撰写PRD的任何内容之前，你必须询问用户以填补信息空白，切勿假设上下文。
需询问的内容：
  • 核心问题：我们现在开发这个的原因是什么？
  • 成功指标：如何判断项目成功？
  • 约束条件：预算、技术栈或截止日期有哪些限制？

Phase 2: Analysis & Scoping

阶段2：分析与范围界定

Synthesize the user's input. Identify dependencies and hidden complexities.
  • Map out the User Flow.
  • Define Non-Goals to protect the timeline.
整合用户输入，识别依赖关系和潜在的复杂性。
  • 梳理用户流程。
  • 定义非目标以保障项目进度。

Phase 3: Technical Drafting

阶段3：技术撰写

Generate the document using the Strict PRD Schema below.
使用下方的严格PRD架构生成文档。

PRD Quality Standards

PRD质量标准

Requirements Quality

需求质量

Use concrete, measurable criteria. Avoid "fast", "easy", or "intuitive".
diff
undefined
使用具体、可衡量的标准，避免使用「快速」「易用」或「直观」这类模糊表述。
diff
undefined

Vague (BAD)

模糊表述（错误示例）

  • The search should be fast and return relevant results.
  • The UI must look modern and be easy to use.
  • 搜索功能应快速且返回相关结果。
  • UI必须看起来现代化且易于使用。

Concrete (GOOD)

具体表述（正确示例）

  • The search must return results within 200ms for a 10k record dataset.
  • The search algorithm must achieve >= 85% Precision@10 in benchmark evals.
  • The UI must follow the project's design system and achieve 100% Lighthouse Accessibility score.

---
  • 针对1万条记录的数据集，搜索必须在200ms内返回结果。
  • 搜索算法在基准测试中必须达到≥85%的Precision@10。
  • UI必须遵循项目设计系统，并达到100%的Lighthouse可访问性评分。

---

Strict PRD Schema

严格PRD架构

You MUST follow this exact structure for the output:
输出内容必须遵循以下精确结构：

1. Executive Summary

1. 执行摘要

  • Problem Statement: 1-2 sentences on the pain point.
  • Proposed Solution: 1-2 sentences on the fix.
  • Success Criteria: 3-5 measurable KPIs.
  • 问题陈述：1-2句话描述痛点。
  • 解决方案提议：1-2句话描述修复方案。
  • 成功标准：3-5个可衡量的KPI。

2. User Experience & Functionality

2. 用户体验与功能

  • User Personas: Who is this for?
  • User Stories: 
    As a [user], I want to [action] so that [benefit].
  • Acceptance Criteria: Bulleted list of "Done" definitions for each story.
  • Non-Goals: What are we NOT building?
  • 用户画像：该功能面向哪些用户？
  • 用户故事：
    作为[用户角色]，我希望[执行操作]，以便[获得收益]。
  • 验收标准：每个用户故事对应的「完成」定义列表（项目符号形式）。
  • 非目标：我们不会开发哪些内容？

3. AI System Requirements (If Applicable)

3. AI系统需求（如适用）

  • Tool Requirements: What tools and APIs are needed?
  • Evaluation Strategy: How to measure output quality and accuracy.
  • 工具需求：需要哪些工具和API？
  • 评估策略：如何衡量输出质量与准确性。

4. Technical Specifications

4. 技术规格说明

  • Architecture Overview: Data flow and component interaction.
  • Integration Points: APIs, DBs, and Auth.
  • Security & Privacy: Data handling and compliance.
  • 架构概述：数据流与组件交互方式。
  • 集成点：API、数据库与认证机制。
  • 安全与隐私：数据处理方式与合规要求。

5. Risks & Roadmap

5. 风险与路线图

  • Phased Rollout: MVP -> v1.1 -> v2.0.
  • Technical Risks: Latency, cost, or dependency failures.
  • 分阶段推出：MVP -> v1.1 -> v2.0。
  • 技术风险：延迟、成本或依赖项故障等问题。

Implementation Guidelines

实施指南

DO (Always)

必须遵守的规则

  • Define Testing: For AI systems, specify how to test and validate output quality.
  • Iterate: Present a draft and ask for feedback on specific sections.
  • 定义测试方式：对于AI系统，明确说明如何测试和验证输出质量。
  • 迭代优化：提交草稿并针对特定部分征求反馈。

DON'T (Avoid)

需要避免的行为

  • Skip Discovery: Never write a PRD without asking at least 2 clarifying questions first.
  • Hallucinate Constraints: If the user didn't specify a tech stack, ask or label it as 
    TBD
    .
  • 跳过发现环节：在撰写PRD之前，至少要提出2个澄清问题，切勿直接开始撰写。
  • 虚构约束条件：如果用户未指定技术栈，请询问用户或标记为
    TBD
    。

Example: Domain Retrieval Feature

示例：领域检索功能

1. Executive Summary

1. 执行摘要

Problem: Users struggle to find specific information across large domain knowledge sources. Solution: A retrieval feature that provides direct answers with source citations. Success:
  • Reduce search time by 50%.
  • Citation accuracy >= 95%.
问题：用户难以在大型领域知识源中找到特定信息。 解决方案：提供带来源引用的直接回答的检索功能。 成功标准：
  • 将搜索时间减少50%。
  • 引用准确率≥95%。

2. User Stories

2. 用户故事

  • Story: As a domain user, I want to ask natural language questions so I don't have to guess exact keywords.
  • AC:
    • Supports multi-turn clarification.
    • Returns code blocks with "Copy" button.
  • 故事：作为领域用户，我希望能用自然语言提问，这样就不用猜测精确关键词。
  • 验收标准：
    • 支持多轮澄清对话。
    • 返回带有「复制」按钮的代码块。

3. System Architecture

3. 系统架构

  • Capabilities Required: content indexing, query parsing, source retrieval, and citation rendering.
  • 所需能力：内容索引、查询解析、来源检索和引用渲染。

4. Evaluation

4. 评估方式

  • Benchmark: Test with 50 common domain questions.
  • Pass Rate: 90% must match expected citations.
  • 基准测试：使用50个常见领域问题进行测试。
  • 通过率：90%的结果必须与预期引用匹配。