PRD / ADR / Spec / MVP 全面中文教程
本文是一份结构清晰、可直接复制使用的完整教程，涵盖 PRD、ADR、Spec、MVP 的全称、核心理念、相互关系、使用场景、模板、最佳实践以及真实案例与代码示例。内容模块化，便于快速查阅与落地。
一、名词与全称（快速速览）
-
PRD：Product Requirement Document（产品需求文档）
面向产品管理与业务，回答“要做什么、为什么做、做给谁、如何衡量成功”。 -
ADR：Architecture Decision Record（架构决策记录）
面向工程技术，记录“重要架构/技术决策、备选方案、权衡与最终结果”。 -
Spec：Specification（规范/规格说明书）
可细分为：- Functional Spec（功能规范）
- Technical Spec（技术规范）
- API Spec（接口规范，如 OpenAPI/Swagger）
回答“如何实现、接口怎么调用、数据结构、协议与行为细节”。
-
MVP：Minimum Viable Product（最小可行产品 / 最简可用产品）
用最小的功能集合快速验证市场与用户假设，获取真实反馈。
二、核心理念（为什么需要这些文档）
| 文档 | 核心价值 | 解决的主要问题 |
|---|---|---|
| PRD | 统一产品方向、对齐所有利益相关者、明确验收标准与成功指标 | 避免团队“各做各的”、需求反复变更 |
| Spec | 将抽象需求转化为可执行、可测试、可实现的工程蓝图 | 消除实现歧义、减少前后端沟通成本 |
| ADR | 将重要技术决策保存为组织知识，便于未来审计、重构、新人理解 | 决策理由丢失、“为什么当年这么做”无人知晓 |
| MVP | 以最小成本、最短时间验证核心假设，降低失败风险 | 花大代价做了一个没人用的完整产品 |
三、相互关系（典型流程视角）
常见流程顺序（可循环迭代）：
- 产品发现阶段 → 输出 PRD（高层目标、用户、成功指标、主功能）
- 技术评审与架构设计 → 产出若干 ADR（技术选型、关键决策）
- 详细设计阶段 → 基于 PRD + ADR，编写 Spec（API、数据模型、验收标准）
- 开发与验证 → 实现 MVP → 上线收集反馈 → 迭代（回到 PRD / 补充 ADR / 更新 Spec）
可视化关系图：
PRD（为什么做 / 目标 / 成功指标）
│
├─→ ADR（技术选型与权衡，在设计/实现中产生）
│
└─→ Spec（怎么做 / 接口 / 数据 / 行为细节）
│
└─→ MVP（最小实现，用于验证 PRD 中的假设）
四、典型模板（可直接复制使用）
1. PRD 模板（简洁实用版）
# <功能/产品名称> PRD
**作者**：XXX
**日期**：YYYY-MM-DD
**版本**：v1.0
### 一、背景与问题
- 当前用户痛点 / 业务机会 / 数据支撑
### 二、目标与成功指标
- **目标**：一句话描述要达成的业务/用户价值
- **关键指标**（建议可量化）：
- 7天留存提升 ≥ 10%
- 日活跃用户 ≥ 1000
- 转化率提升 ≥ 2%
### 三、用户画像与场景
- 目标用户 Persona
- 核心用户故事（As a ... I want ... So that ...）
### 四、主要功能（按优先级排序）
- **功能1**：描述 + 验收标准（AC）
- **功能2**：...
### 五、非功能性需求
- 性能、可用性、安全、隐私、合规等
### 六、MVP 范围与发布计划
- **MVP 包含**：A、B、C
- **MVP 不包含**：X、Y、Z（延后）
- 时间线：XX 周完成
### 七、风险与缓解措施
### 附录
- 流程图 / 原型链接 / 竞品分析
2. ADR 模板（推荐放在代码仓库 docs/adr/）
文件命名：YYYY-MM-DD-title.md
# ADR 0001: 选择认证方案
- **Date**: 2025-12-17
- **Status**: Proposed | Accepted | Deprecated | Superseded
- **Deciders**: Tech Lead / 架构组
### Context（背景）
- 项目需要支持 Web、App、第三方接入的统一认证
### Decision（决策）
- 采用 OAuth2（Authorization Code + PKCE）作为主流程，内部服务间使用 JWT 传递上下文
### Alternatives Considered（备选方案）
1. 纯 JWT：实现简单，但难以支持第三方授权和权限撤销
2. Session + Cookie：传统但不适合移动端和微服务
### Consequences（后果）
- **优点**：标准、安全、可扩展
- **缺点**：初期实现成本较高，需要引入授权服务器
- **缓解**：先实现简化版，后续迭代支持完整 scope
### References
- 相关 Issue / PR 链接
3. Spec 示例（以 OpenAPI YAML 为例）
openapi: 3.0.1
info:
title: 示例认证服务 API
version: 1.0.0
paths:
/signup:
post:
summary: 用户注册
requestBody:
required: true
content:
application/json:
schema:
type: object
required: [email, password]
properties:
email: { type: string, format: email }
password: { type: string, minLength: 8 }
responses:
'201': { description: 注册成功 }
'400': { description: 参数错误或用户已存在 }
/login:
post:
summary: 用户登录（返回 JWT）
requestBody:
required: true
content:
application/json:
schema:
type: object
required: [email, password]
properties:
email: { type: string, format: email }
password: { type: string }
responses:
'200':
description: 登录成功
content:
application/json:
schema:
type: object
properties:
access_token: { type: string }
'401': { description: 账号或密码错误 }
4. MVP 定义模板
### MVP 定义：XX 功能验证
**核心假设**：用户愿意为 XX 功能付费 / 用户会频繁使用 XX
**包含功能**（最小集合）：
- A
- B
- C
**明确不包含**：
- X（复杂权限系统）
- Y（多语言支持）
**成功标准**：
- 30 天内注册用户 ≥ 5000
- 付费转化率 ≥ 2%
**时间箱**：6 周内上线
五、设计模式与最佳实践
- 文档即代码：PRD/Spec/ADR 均放入 Git 仓库（
/docs/prd/,/docs/spec/,/docs/adr/），通过 PR 评审变更。 - 小而频繁的 ADR：避免巨型 ADR，建议每个独立决策一个文件。
- 单一信息源（SSOT）：同一信息只在一个地方权威声明，其他地方链接引用。
- 可执行的验收标准：PRD 每条需求必须配明确、可测试的 AC。
- 可追溯性：需求 ID、Spec 文件、ADR、Issue 之间互相链接。
- Living Document：文档随代码演进，定期 review，过时内容标记 Deprecated。
- 明确 Owner：文档头部标注负责人（PM / Tech Lead / QA）。
六、使用场景
| 文档 | 主要使用者 | 典型使用时机 |
|---|---|---|
| PRD | 产品经理、业务方、设计、开发、运营 | 立项、需求评审、对齐会议 |
| Spec | 前后端开发、QA、DevOps | 开发前详细设计、联调、测试用例编写 |
| ADR | 架构师、Tech Lead、后端开发 | 技术选型评审、未来重构回顾 |
| MVP | 产品 + 开发团队 | 早期验证假设、内部试点、A/B 测试 |
七、代码 Demo（Spec → 实现 → MVP）
基于上述 OpenAPI Spec，实现一个最简认证服务（Python + FastAPI）
# app.py
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel, EmailStr
import hashlib
import jwt
import time
from typing import Dict
app = FastAPI()
SECRET = "please_change_this_in_production"
class SignupReq(BaseModel):
email: EmailStr
password: str
class LoginReq(BaseModel):
email: EmailStr
password: str
# MVP 阶段：内存存储（实际项目请换数据库）
users: Dict[str, str] = {}
def hash_pw(pw: str) -> str:
return hashlib.sha256(pw.encode()).hexdigest()
@app.post("/signup", status_code=201)
def signup(req: SignupReq):
if req.email in users:
raise HTTPException(400, "user exists")
users[req.email] = hash_pw(req.password)
return {"message": "created"}
@app.post("/login")
def login(req: LoginReq):
stored = users.get(req.email)
if not stored or stored != hash_pw(req.password):
raise HTTPException(401, "invalid credentials")
token = jwt.encode(
{"sub": req.email, "iat": int(time.time())},
SECRET,
algorithm="HS256"
)
return {"access_token": token}
这就是一个典型 MVP：功能极简、能验证“用户是否愿意注册并登录”，完全对齐 Spec。
八、真实案例分析：短文本社交功能
场景：移动端社交 App 计划新增“发布短文本 + 评论”功能，验证用户互动黏性。
1. PRD 关键内容
- 目标：提升日活跃与用户互动时长
- 成功指标：7 天内日活 ≥ 1000，平均每用户日发帖 ≥ 0.1
- MVP 范围：发帖（≤280字）、时间线查看、评论（纯文本）
2. 产生的 ADR（示例）
- ADR-0001：认证方案选用 JWT（原因：快速实现，MVP 阶段无需复杂 OAuth）
- ADR-0002：存储选用 MongoDB（原因：schema 灵活，适合快速迭代）
3. Spec 关键内容
- API：
POST /posts,GET /timeline,POST /posts/{id}/comments - 数据模型：Post、Comment 字段定义，分页规则，280 字限制
4. MVP 实现与验证
- 仅实现上述 3 个接口 + 简单前端页面
- 上线 2 周后收集数据：
- 若 KPI 未达标 → 回到 PRD 分析（是功能不吸引人？还是 UX 问题？）
- 若达标 → 规划后续迭代（添加@、图片、点赞等）
关系总结：
- PRD 决定“做什么”和 MVP 边界
- ADR 解释“为什么选当前技术路线”
- Spec 将 PRD + ADR 转化为可编码的契约
- MVP 是最终交付物，用于验证 PRD 中的假设
九、文档管理与协作实践
- 存储路径：代码仓库中统一管理
/docs/prd//docs/spec//docs/adr/
- 变更流程：所有文档变更走 PR + Owner 审批
- 链接机制：相互引用（如 PRD 中写 “详见 ADR-0002” 并附链接）
- 自动化校验：OpenAPI 文件可在 CI 中 lint + 生成 stub
- 保鲜机制：每次大版本发布前进行文档健康检查
十、常见误区与避坑指南
| 误区 | 后果 | 建议 |
|---|---|---|
| 把所有细节塞进 PRD | PRD 臃肿、难以维护 | PRD 只写“为什么”和“成功标准”，细节交给 Spec |
| 不写 ADR，决策散落在聊天记录 | 后期无人知晓决策理由 | 关键选型必须写 ADR 并入库 |
| Spec 与代码不同步 | 接口频繁返工 | 用 contract test / OpenAPI 生成代码 |
| MVP 做得太简单或太完整 | 无法有效验证假设 | 紧扣核心假设，只做必须的功能 |
十一、快速上手 Checklist
- 写 PRD：明确目标、用户、成功指标、MVP 范围
- 在技术选型时立即记录 ADR（Proposed → Accepted）
- 编写 Spec：至少包含 API、数据模型、验收标准
- 实现 MVP：严格对齐 Spec，保持极简
- 上线并追踪 PRD 中定义的指标
- 根据数据迭代 PRD / Spec / ADR
以上内容可直接用于团队模板与培训，祝落地顺利！
扫一扫
3895
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
