企业官网建设流程全解析

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（最小可行产品 / 最简可用产品）
  用最小的功能集合快速验证市场与用户假设，获取真实反馈。

二、核心理念（为什么需要这些文档）

三、相互关系（典型流程视角）

常见流程顺序（可循环迭代）：

1. 产品发现阶段→ 输出PRD（高层目标、用户、成功指标、主功能）
2. 技术评审与架构设计→ 产出若干ADR（技术选型、关键决策）
3. 详细设计阶段→ 基于 PRD + ADR，编写Spec（API、数据模型、验收标准）
4. 开发与验证→ 实现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 周内上线

五、设计模式与最佳实践

1. 文档即代码：PRD/Spec/ADR 均放入 Git 仓库（/docs/prd/,/docs/spec/,/docs/adr/），通过 PR 评审变更。
2. 小而频繁的 ADR：避免巨型 ADR，建议每个独立决策一个文件。
3. 单一信息源（SSOT）：同一信息只在一个地方权威声明，其他地方链接引用。
4. 可执行的验收标准：PRD 每条需求必须配明确、可测试的 AC。
5. 可追溯性：需求 ID、Spec 文件、ADR、Issue 之间互相链接。
6. Living Document：文档随代码演进，定期 review，过时内容标记 Deprecated。
7. 明确 Owner：文档头部标注负责人（PM / Tech Lead / QA）。

六、使用场景

七、代码 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
• 保鲜机制：每次大版本发布前进行文档健康检查

十、常见误区与避坑指南

十一、快速上手 Checklist

• 写 PRD：明确目标、用户、成功指标、MVP 范围
• 在技术选型时立即记录 ADR（Proposed → Accepted）
• 编写 Spec：至少包含 API、数据模型、验收标准
• 实现 MVP：严格对齐 Spec，保持极简
• 上线并追踪 PRD 中定义的指标
• 根据数据迭代 PRD / Spec / ADR

以上内容可直接用于团队模板与培训，祝落地顺利！