【技术教程】PRD / ADR / Spec / MVP 使用教程-程序员充电站

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.1info:title:示例认证服务 APIversion:1.0.0paths:/signup:post:summary:用户注册requestBody:required:truecontent:application/json:schema:type:objectrequired:[email,password]properties:email:{type:string,format:email}password:{type:string,minLength:8}responses:'201':{description:注册成功}'400':{description:参数错误或用户已存在}/login:post:summary:用户登录（返回 JWT）requestBody:required:truecontent:application/json:schema:type:objectrequired:[email,password]properties:email:{type:string,format:email}password:{type:string}responses:'200':description:登录成功content:application/json:schema:type:objectproperties: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.pyfromfastapiimportFastAPI,HTTPExceptionfrompydanticimportBaseModel,EmailStrimporthashlibimportjwtimporttimefromtypingimportDict app=FastAPI()SECRET="please_change_this_in_production"classSignupReq(BaseModel):email:EmailStr password:strclassLoginReq(BaseModel):email:EmailStr password:str# MVP 阶段：内存存储（实际项目请换数据库）users:Dict[str,str]={}defhash_pw(pw:str)->str:returnhashlib.sha256(pw.encode()).hexdigest()@app.post("/signup",status_code=201)defsignup(req:SignupReq):ifreq.emailinusers:raiseHTTPException(400,"user exists")users[req.email]=hash_pw(req.password)return{"message":"created"}@app.post("/login")deflogin(req:LoginReq):stored=users.get(req.email)ifnotstoredorstored!=hash_pw(req.password):raiseHTTPException(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 做得太简单或太完整	无法有效验证假设	紧扣核心假设，只做必须的功能