Back to Details

replit-prd

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Replit PRD Generator

Replit PRD 生成器

Create comprehensive Product Requirements Documents optimized for Replit Agent to build complex applications.
创建针对Replit Agent优化的综合产品需求文档（PRD），用于构建复杂应用。

When to Use

适用场景

  • Building complex applications with multiple features
  • Need stakeholder alignment before development
  • Want one-shot autonomous builds (entire app from single prompt)
  • Require clear acceptance criteria and testing plans
  • Working on team projects that need documentation
  • 构建具备多个功能的复杂应用
  • 开发前需要对齐相关方需求
  • 希望实现一次性自主构建（通过单个提示词完成整个应用开发）
  • 需要明确的验收标准和测试计划
  • 开展需要文档支持的团队项目

PRD vs Simple Prompt

PRD 与简单提示词对比

AspectSimple PromptFull PRD
Features1-34+
Pages/Screens1-34+
User Roles1Multiple
Integrations0-1Multiple
Development Time< 1 hourHours to days
Iterations ExpectedMinimalMultiple phases
Rule of thumb: If you can describe it in 10 lines, use a prompt. If you need structure, use a PRD.
维度简单提示词完整PRD
功能数量1-3个4个及以上
页面/屏幕数量1-3个4个及以上
用户角色1种多种
第三方集成0-1个多个
开发时长少于1小时数小时至数天
预期迭代次数极少多阶段迭代
经验法则： 如果能用10行内容描述清楚，就用提示词；如果需要结构化文档，就用PRD。

PRD Template for Replit

Replit PRD 模板

markdown
undefined
markdown
undefined

[Product Name] - Product Requirements Document

[产品名称] - 产品需求文档

1. Executive Summary

1. 执行摘要

Product Name

产品名称

[Name]
[名称]

Version

版本

1.0.0
1.0.0

Last Updated

最后更新日期

[Date]
[日期]

One-Line Description

一句话描述

[What it is and who it's for in one sentence]
[产品定位及目标用户，一句话概括]

Problem Statement

问题陈述

[What problem does this solve? Why does it matter?]
[该产品解决什么问题？为什么这个问题很重要？]

Success Metrics

成功指标

  • [Metric 1: e.g., "User can complete core task in under 2 minutes"]
  • [Metric 2: e.g., "Zero critical bugs in core user flows"]
  • [Metric 3: e.g., "Page load time under 3 seconds"]
  • [指标1：例如，“用户可在2分钟内完成核心任务”]
  • [指标2：例如，“核心用户流程中无严重漏洞”]
  • [指标3：例如，“页面加载时间少于3秒”]

2. User Personas

2. 用户角色

Persona 1: [Name/Role]

角色1：[名称/角色]

  • Description: [Who they are]
  • Goals: [What they want to achieve]
  • Pain Points: [What frustrates them currently]
  • Tech Comfort: [Low/Medium/High]
  • 描述： [用户身份]
  • 目标： [用户希望达成的结果]
  • 痛点： [当前困扰用户的问题]
  • 技术熟练度： [低/中/高]

Persona 2: [Name/Role]

角色2：[名称/角色]

  • Description: [Who they are]
  • Goals: [What they want to achieve]
  • Pain Points: [What frustrates them currently]
  • Tech Comfort: [Low/Medium/High]
  • 描述： [用户身份]
  • 目标： [用户希望达成的结果]
  • 痛点： [当前困扰用户的问题]
  • 技术熟练度： [低/中/高]

3. Technical Specifications

3. 技术规格

Tech Stack

技术栈

LayerTechnologyRationale
Frontend[Framework][Why chosen]
Styling[Library][Why chosen]
Backend[Framework][Why chosen]
Database[System][Why chosen]
Auth[Provider][Why chosen]
HostingReplit DeploymentsDefault
层级技术选型选型理由
前端[框架][选型原因]
样式[库][选型原因]
后端[框架][选型原因]
数据库[系统][选型原因]
认证[服务商][选型原因]
部署Replit Deployments默认选项

Architecture Overview

架构概述

[Text diagram or description of system architecture]
[系统架构的文本示意图或描述]

Third-Party Integrations

第三方集成

ServicePurposeAPI TypeAuth Method
[Service][What for]REST/GraphQLAPI Key/OAuth
服务用途API类型认证方式
[服务名称][用途说明]REST/GraphQLAPI Key/OAuth

Environment Variables Required

所需环境变量

VariableDescriptionRequired
DATABASE_URLPostgreSQL connection stringYes
[VAR_NAME][Description]Yes/No
变量名描述是否必填
DATABASE_URLPostgreSQL连接字符串是
[变量名][描述]是/否

4. Data Model

4. 数据模型

Entity: [EntityName]

实体：[实体名称]

FieldTypeRequiredConstraintsDescription
idUUIDYesPrimary keyUnique identifier
[field][type]Yes/No[constraints][description]
字段类型是否必填约束条件描述
idUUID是主键唯一标识符
[字段名][类型]是/否[约束条件][描述]

Entity Relationships

实体关系

User (1) ----< (many) Posts
Post (1) ----< (many) Comments
User (1) ----< (many) Comments
用户 (1) ----< (多) 帖子
帖子 (1) ----< (多) 评论
用户 (1) ----< (多) 评论

Database Indexes

数据库索引

  • [table].[column] - For [use case]
  • [table].[column] - For [use case]
  • [表名].[列名] - 用于[使用场景]
  • [表名].[列名] - 用于[使用场景]

5. Feature Specifications

5. 功能规格

Feature 1: [Feature Name]

功能1：[功能名称]

Description

描述

[What this feature does]
[该功能的具体作用]

User Stories

用户故事

  • As a [role], I want to [action] so that [benefit]
  • As a [role], I want to [action] so that [benefit]
  • 作为[角色]，我希望[执行操作]，以便[获得收益]
  • 作为[角色]，我希望[执行操作]，以便[获得收益]

Functional Requirements

功能需求

IDRequirementPriority
F1.1[Specific requirement]Must Have
F1.2[Specific requirement]Must Have
F1.3[Specific requirement]Nice to Have
ID需求内容优先级
F1.1[具体需求]必须实现
F1.2[具体需求]必须实现
F1.3[具体需求]可选实现

UI Components

UI组件

  • [Component 1]: [Description and behavior]
  • [Component 2]: [Description and behavior]
  • [组件1]：[描述及行为]
  • [组件2]：[描述及行为]

API Endpoints

API接口

MethodEndpointRequest BodyResponseAuth
POST/api/[resource]{ field: type }{ field: type }Required
GET/api/[resource]/:id-{ field: type }Required
请求方法接口地址请求体响应体是否需要认证
POST/api/[资源路径]{ field: type }{ field: type }是
GET/api/[资源路径]/:id-{ field: type }是

Validation Rules

验证规则

  • [Field]: [Rule, e.g., "Email must be valid format"]
  • [Field]: [Rule, e.g., "Password minimum 8 characters"]
  • [字段]：[规则，例如“邮箱格式必须合法”]
  • [字段]：[规则，例如“密码至少8个字符”]

Error Handling

错误处理

Error ConditionError CodeUser MessageSystem Action
[Condition]400/401/etc[Friendly message][What happens]
错误场景错误码用户提示信息系统操作
[场景描述]400/401等[友好提示语][系统后续操作]

Feature 2: [Feature Name]

功能2：[功能名称]

[Repeat structure above]
[重复上述结构]

6. UI/UX Specifications

6. UI/UX 规格

Design System

设计系统

  • Primary Color: [Hex code]
  • Secondary Color: [Hex code]
  • Background: [Hex code]
  • Text: [Hex code]
  • Font Family: [Font name]
  • Border Radius: [Value, e.g., 8px]
  • 主色调： [十六进制色值]
  • 辅助色： [十六进制色值]
  • 背景色： [十六进制色值]
  • 文字颜色： [十六进制色值]
  • 字体： [字体名称]
  • 圆角： [数值，例如8px]

Page Layouts

页面布局

Page: [Page Name]

页面：[页面名称]

  • Route: /[path]
  • Layout: [Description]
  • Components:
    • [Component 1]
    • [Component 2]
  • State: [What state this page manages]
  • 路由： /[路径]
  • 布局： [描述]
  • 组件：
    • [组件1]
    • [组件2]
  • 状态管理： [该页面需要管理的状态]

Navigation Structure

导航结构

Home (/)
├── Dashboard (/dashboard)
├── [Section] (/[path])
│   ├── [Subsection] (/[path]/[subpath])
│   └── [Subsection] (/[path]/[subpath])
└── Settings (/settings)
首页 (/)
├── 控制台 (/dashboard)
├── [板块] (/[路径])
│   ├── [子板块] (/[路径]/[子路径])
│   └── [子板块] (/[路径]/[子路径])
└── 设置 (/settings)

Responsive Breakpoints

响应式断点

BreakpointWidthLayout Changes
Mobile< 640px[Changes]
Tablet640-1024px[Changes]
Desktop> 1024px[Default layout]
断点类型宽度布局变化
移动端< 640px[变化内容]
平板端640-1024px[变化内容]
桌面端> 1024px[默认布局]

7. User Flows

7. 用户流程

Flow 1: [Flow Name]

流程1：[流程名称]

Start → [Step 1] → [Step 2] → [Decision Point]
                                    ├── Yes → [Step 3a] → End
                                    └── No → [Step 3b] → End
Detailed Steps:
  1. User [action] on [page/component]
  2. System [response/validation]
  3. User sees [feedback/result]
  4. [Continue...]
开始 → [步骤1] → [步骤2] → [决策点]
                                    ├── 是 → [步骤3a] → 结束
                                    └── 否 → [步骤3b] → 结束
详细步骤：
  1. 用户在[页面/组件]上执行[操作]
  2. 系统做出[响应/验证]
  3. 用户看到[反馈/结果]
  4. [后续步骤...]

Flow 2: [Flow Name]

流程2：[流程名称]

[Repeat structure]
[重复上述结构]

8. Non-Functional Requirements

8. 非功能需求

Performance

性能

  • Page load time: < [X] seconds
  • API response time: < [X] ms
  • Support [X] concurrent users
  • 页面加载时间：< [X]秒
  • API响应时间：< [X]毫秒
  • 支持[X]个并发用户

Security

安全

  • Input sanitization on all forms
  • HTTPS only
  • SQL injection prevention (parameterized queries)
  • XSS prevention
  • CSRF tokens on forms
  • Rate limiting on auth endpoints
  • 所有表单输入均经过清洗
  • 仅支持HTTPS
  • 防止SQL注入（使用参数化查询）
  • 防止XSS攻击
  • 表单添加CSRF令牌
  • 认证接口添加频率限制

Accessibility

可访问性

  • Keyboard navigable
  • Screen reader compatible
  • Color contrast ratio 4.5:1 minimum
  • Focus indicators visible
  • 支持键盘导航
  • 兼容屏幕阅读器
  • 颜色对比度最低达到4.5:1
  • 焦点指示器可见

Browser Support

浏览器支持

  • Chrome (latest 2 versions)
  • Firefox (latest 2 versions)
  • Safari (latest 2 versions)
  • Edge (latest 2 versions)
  • Chrome（最新2个版本）
  • Firefox（最新2个版本）
  • Safari（最新2个版本）
  • Edge（最新2个版本）

9. Scope Boundaries

9. 范围边界

In Scope (MVP)

纳入范围（MVP版本）

  • [Feature/capability 1]
  • [Feature/capability 2]
  • [Feature/capability 3]
  • [功能/能力1]
  • [功能/能力2]
  • [功能/能力3]

Out of Scope (Future)

暂不纳入范围（未来版本）

  • [Feature/capability 1] - Reason: [why deferred]
  • [Feature/capability 2] - Reason: [why deferred]
  • [功能/能力1] - 原因：[延期理由]
  • [功能/能力2] - 原因：[延期理由]

Explicit Non-Goals

明确非目标

  • [Thing this product will NOT do]
  • [Thing this product will NOT do]
  • [本产品不会实现的功能]
  • [本产品不会实现的功能]

10. Acceptance Criteria

10. 验收标准

Feature 1: [Name]

功能1：[名称]

  • [Testable criterion 1]
  • [Testable criterion 2]
  • [Testable criterion 3]
  • [可测试的标准1]
  • [可测试的标准2]
  • [可测试的标准3]

Feature 2: [Name]

功能2：[名称]

  • [Testable criterion 1]
  • [Testable criterion 2]
  • [可测试的标准1]
  • [可测试的标准2]

Overall Application

整体应用

  • All pages load without errors
  • All forms validate correctly
  • All API endpoints return expected responses
  • Mobile layout is functional
  • No console errors in production
  • 所有页面加载无错误
  • 所有表单验证正常
  • 所有API接口返回预期响应
  • 移动端布局可用
  • 生产环境无控制台错误

11. Development Phases

11. 开发阶段

Phase 1: Foundation (Checkpoint 1)

阶段1：基础搭建（检查点1）

Goal: Basic structure and auth
  • Project setup with tech stack
  • Database schema and migrations
  • Authentication flow
  • Basic navigation/layout
目标： 完成基础结构和认证功能
  • 基于技术栈完成项目初始化
  • 数据库 schema 及迁移脚本
  • 认证流程
  • 基础导航/布局

Phase 2: Core Features (Checkpoint 2)

阶段2：核心功能开发（检查点2）

Goal: Primary functionality
  • [Core feature 1]
  • [Core feature 2]
目标： 实现核心功能
  • [核心功能1]
  • [核心功能2]

Phase 3: Polish (Checkpoint 3)

阶段3：优化完善（检查点3）

Goal: UX and edge cases
  • Error handling
  • Loading states
  • Responsive design
  • Form validations
目标： 优化用户体验及边缘场景
  • 错误处理
  • 加载状态
  • 响应式设计
  • 表单验证

Phase 4: Launch (Checkpoint 4)

阶段4：上线准备（检查点4）

Goal: Production ready
  • Final testing
  • Performance optimization
  • Security review
  • Documentation
目标： 达到生产环境就绪状态
  • 最终测试
  • 性能优化
  • 安全审查
  • 文档完善

12. Risks and Mitigations

12. 风险与应对措施

RiskImpactProbabilityMitigation
[Risk 1]High/Med/LowHigh/Med/Low[How to address]
[Risk 2]High/Med/LowHigh/Med/Low[How to address]
风险影响程度发生概率应对措施
[风险1]高/中/低高/中/低[解决方法]
[风险2]高/中/低高/中/低[解决方法]

13. Appendix

附录

Wireframes/Mockups

线框图/原型图

[Links or embedded images]
[链接或嵌入图片]

Reference Applications

参考应用

  • App name - Similar [feature/design]
  • App name - Similar [feature/design]
  • 应用名称 - 类似[功能/设计]
  • 应用名称 - 类似[功能/设计]

API Documentation Links

API文档链接

Glossary

术语表

TermDefinition
[Term][Definition]
undefined
术语定义
[术语][定义]
undefined

Procedure

操作流程

Step 1: Gather High-Level Requirements

步骤1：收集高层需求

Ask the user:
  1. What is the product and who is it for?
  2. What are the 3-5 most important features?
  3. Any specific tech requirements or preferences?
  4. Any reference apps or designs to emulate?
询问用户：
  1. 产品是什么？目标用户是谁？
  2. 3-5个最重要的功能是什么？
  3. 有没有特定的技术要求或偏好？
  4. 有没有需要参考的应用或设计？

Step 2: Define User Personas

步骤2：定义用户角色

For each user type:
  • Who are they?
  • What do they need to accomplish?
  • What's their technical skill level?
针对每种用户类型：
  • 用户身份是什么？
  • 用户需要完成什么任务？
  • 用户的技术熟练度如何？

Step 3: Detail Features

步骤3：细化功能

For each feature, extract:
  • User stories
  • UI components needed
  • Data required
  • API endpoints
  • Validation rules
  • Error scenarios
针对每个功能，梳理：
  • 用户故事
  • 所需UI组件
  • 所需数据
  • API接口
  • 验证规则
  • 错误场景

Step 4: Design Data Model

步骤4：设计数据模型

  • List all entities
  • Define all fields with types and constraints
  • Map relationships
  • Identify required indexes
  • 列出所有实体
  • 定义所有字段的类型和约束
  • 梳理实体关系
  • 确定所需索引

Step 5: Specify UI/UX

步骤5：明确UI/UX规格

  • Color palette
  • Page layouts
  • Navigation structure
  • Responsive behavior
  • Key interactions
  • 配色方案
  • 页面布局
  • 导航结构
  • 响应式行为
  • 关键交互

Step 6: Define User Flows

步骤6：定义用户流程

Document step-by-step:
  • Happy path
  • Error paths
  • Edge cases
详细记录：
  • 正常流程
  • 错误流程
  • 边缘场景

Step 7: Set Acceptance Criteria

步骤7：制定验收标准

Create testable checkboxes for:
  • Each feature
  • Overall functionality
  • Performance requirements
为以下内容创建可测试的检查项：
  • 每个功能
  • 整体功能
  • 性能要求

Step 8: Plan Development Phases

步骤8：规划开发阶段

Break into 3-4 phases with:
  • Clear goals
  • Specific deliverables
  • Checkpoint criteria
拆分为3-4个阶段，每个阶段包含：
  • 明确目标
  • 具体交付物
  • 检查点标准

Step 9: Present Draft PRD

步骤9：提交PRD草稿

undefined
undefined

PRD Draft: [Product Name]

PRD草稿：[产品名称]

Complexity: [Low/Medium/High] Estimated Phases: [Number] Primary Persona: [Name]
[Full PRD content]
复杂度： [低/中/高] 预计阶段数： [数量] 核心用户角色： [名称]
[完整PRD内容]

Usage Instructions

使用说明

  1. Copy entire PRD to Replit Agent
  2. Use Plan Mode first to review Agent's approach
  3. Approve plan and start Phase 1
  4. Create checkpoint after each phase
  5. Review and iterate before next phase
Ready to proceed?
undefined
  1. 将完整PRD复制到Replit Agent
  2. 先使用计划模式（Plan Mode）查看Agent的实现方案
  3. 批准方案后启动阶段1开发
  4. 每个阶段完成后创建检查点
  5. 进入下一阶段前进行评审和迭代
是否准备开始？
undefined

Step 10: Provide Iteration Guidance

步骤10：提供迭代指导

After PRD delivery:
  • How to use Plan Mode effectively
  • When to create checkpoints
  • How to handle deviations
交付PRD后：
  • 如何有效使用计划模式
  • 何时创建检查点
  • 如何处理偏离计划的情况

Output Format

输出格式

undefined
undefined

[Product Name] PRD

[产品名称] PRD

Quick Reference

快速参考

AttributeValue
Complexity[Low/Medium/High]
Features[Count]
Pages[Count]
API Endpoints[Count]
Phases[Count]
[Full PRD following template]
属性值
复杂度[低/中/高]
功能数量[数量]
页面数量[数量]
API接口数量[数量]
阶段数[数量]
[遵循模板的完整PRD]

Replit Agent Instructions

Replit Agent 操作指引

Mode: Start in Plan Mode
Phase 1 Prompt: "Review this PRD and create a development plan for Phase 1: [Phase 1 Goal]. Don't start building yet - just outline your approach."
Build Prompt (after plan approval): "Proceed with Phase 1 implementation. Create a checkpoint when complete."
Subsequent Phases: Repeat plan → build → checkpoint cycle for each phase.
undefined
模式： 从计划模式（Plan Mode）开始
阶段1提示词： "评审这份PRD，并为阶段1：[阶段1目标]制定开发计划。 暂不开始开发，仅概述实现方案。"
开发提示词（计划批准后）： "开始阶段1的开发。完成后创建检查点。"
后续阶段： 重复 计划→开发→检查点 的循环，直至所有阶段完成。
undefined

Rules

规则

  1. ALWAYS include acceptance criteria — Every feature needs testable conditions
  2. ALWAYS define data model — Schema before code
  3. ALWAYS specify error handling — Every feature's error scenarios
  4. ALWAYS break into phases — 3-4 phases with clear checkpoints
  5. NEVER leave fields vague — Every input has type, constraints, validation
  6. NEVER skip security requirements — Always include security section
  7. PREFER reference apps — Concrete examples over abstract descriptions
  1. 必须包含验收标准 —— 每个功能都需要可测试的条件
  2. 必须定义数据模型 —— 先有 schema 再写代码
  3. 必须明确错误处理 —— 每个功能都要覆盖错误场景
  4. 必须拆分开发阶段 —— 拆分为3-4个带明确检查点的阶段
  5. 字段描述不能模糊 —— 每个输入都要有类型、约束和验证规则
  6. 不能跳过安全需求 —— 必须包含安全章节
  7. 优先参考实际应用 —— 用具体案例替代抽象描述

Additional Resources

额外资源

See reference files:
  • references/prd-examples.md
     — Complete PRD examples for different app types
参考文件：
  • references/prd-examples.md
     —— 不同类型应用的完整PRD示例