📄 PRD 文档标准模板

📋 示例：文档元数据

{
  "prd_id": "PRD-20260313-001",
  "title": "电商平台用户中心产品需求文档",
  "version": "1.0.0",
  "status": "评审中",
  "created_date": "2026-03-13",
  "last_updated": "2026-03-13",
  "author": "张三（高级产品经理）",
  "stakeholders": [
    "李四（技术负责人）",
    "王五（UX 设计师）",
    "赵六（运营负责人）",
    "钱七（客服主管）"
  ],
  "approvers": [
    "周八（产品副总裁）",
    "吴九（CTO)"
  ],
  "tags": ["电商", "用户中心", "CRM", "2026Q1"]
}

📋 示例：执行摘要

本产品是一个面向中小企业的智能化电商用户中心解决方案，旨在帮助企业提升客户管理效率和用户满意度。 通过整合用户数据、优化服务流程、提供个性化推荐，我们预计可将客户留存率提升 30%， 客服响应时间缩短 50%。产品将服务于 1000+ 中小企业，覆盖电商、零售、服务业等多个行业， 预计在上线后 12 个月内实现 10 万 + 活跃用户。

📋 示例：问题陈述

现状：目前中小企业在用户管理方面普遍使用分散的工具和手工流程， 导致数据孤岛严重、客户信息不完整、服务响应慢。

痛点：

• 客户数据分散在多个系统中，无法形成统一视图
• 客服响应时间长，平均需要 24 小时
• 缺乏个性化服务能力，客户体验差
• 营销转化率低，复购率不足 20%

影响：客户流失率高（年流失率 40%+），口碑传播受限，增长乏力。

机会：通过一体化用户中心，整合数据、优化流程、智能服务，可显著提升客户满意度和商业价值。

📋 示例：产品愿景

成为中小企业首选的智能化用户管理平台，让每一家企业都能像大公司一样专业地服务客户。 通过 AI 驱动的数据洞察和自动化流程，帮助用户实现：

• 客户数据 100% 整合，形成完整的 360°视图
• 客服响应时间缩短至 2 小时内
• 个性化推荐转化率提升至行业平均水平的 2 倍
• 客户年留存率提升至 80%+

标准格式：
作为 [用户角色]，我想要 [功能/特性]，以便 [实现价值/解决问题]

示例：
作为 注册用户，我想要 通过手机号验证码快速登录，以便 无需记住密码即可访问我的账户

作为 购物者，我想要 查看订单实时物流信息，以便 了解包裹何时送达

作为 消费者，我想要 一键申请退货退款，以便 在不满意时快速处理

Gherkin 格式示例（Given-When-Then）

用户故事： 作为用户，我想要通过手机号验证码登录，以便快速访问账户

验收标准：

Scenario 1: 正常登录流程
  Given 用户已注册且手机号有效
  When 用户输入手机号并请求验证码
  Then 系统发送 6 位数字验证码到手机
  And 验证码 5 分钟内有效
  
Scenario 2: 验证码验证成功
  Given 用户已收到有效验证码
  When 用户输入正确的验证码
  Then 系统验证通过并跳转到首页
  And 自动登录用户账户
  
Scenario 3: 验证码错误
  Given 用户输入错误的验证码
  When 用户提交验证
  Then 系统提示"验证码错误，请重新输入"
  And 允许用户重新尝试（剩余次数显示）
  
Scenario 4: 验证码过期
  Given 验证码已超过 5 分钟有效期
  When 用户尝试使用该验证码
  Then 系统提示"验证码已过期"
  And 提供"重新发送验证码"选项
  
Scenario 5: 防刷限制
  Given 同一手机号 1 分钟内已请求 3 次验证码
  When 用户再次请求验证码
  Then 系统提示"操作过于频繁，请稍后再试"
  And 60 秒后才允许重新请求

用例模板示例

UC-001: 用户下单

参与者： 注册用户

前置条件：
- 用户已登录
- 购物车中有商品
- 商品有库存

主流程：
1. 用户进入购物车页面
2. 用户选择要购买的商品
3. 用户点击"去结算"
4. 系统显示订单确认页面（含商品清单、金额、收货地址）
5. 用户确认订单信息并选择支付方式
6. 用户点击"立即支付"
7. 系统调用支付网关
8. 用户完成支付操作
9. 支付网关返回支付成功
10. 系统创建订单并扣减库存
11. 系统显示订单成功页面
12. 系统发送订单确认通知（邮件/短信）

备选流程：
A1: 用户修改收货地址
  - 在步骤 4，用户可以点击"修改地址"
  - 系统弹出地址选择器
  - 用户选择新地址并确认
  - 返回步骤 4，更新显示

A2: 用户使用优惠券
  - 在步骤 5，用户可以点击"使用优惠券"
  - 系统显示可用优惠券列表
  - 用户选择优惠券
  - 系统重新计算订单金额
  - 继续步骤 6

异常流程：
E1: 支付失败
  - 在步骤 8，支付网关返回失败
  - 系统提示支付失败原因
  - 提供"重新支付"或"更换支付方式"选项
  - 用户可选择重试或取消订单

E2: 库存不足
  - 在步骤 6，系统检测到某商品库存不足
  - 系统提示"XX 商品库存不足"
  - 提供"移除商品"或"继续选购"选项
  - 用户调整后重新开始流程

后置条件：
- 订单状态为"已支付"
- 库存数量已扣减
- 用户账户生成订单记录
- 支付记录已保存

📋 完整功能需求示例

FR-USER-001: 手机号验证码登录

描述：
用户可以通过输入手机号和短信验证码的方式快速登录系统，无需记忆密码。
系统会向用户手机发送 6 位数字验证码，用户在有效期内输入正确验证码即可完成登录。
该功能支持新用户自动注册和老用户直接登录的无缝体验。

类型： 功能性需求

优先级： P0 - 关键

关联用户故事： ["US-LOGIN-001", "US-REGISTER-001"]

验收标准：
1. 用户输入有效手机号后，可以点击"获取验证码"按钮
2. 系统在 10 秒内发送 6 位数字验证码到用户手机
3. 验证码有效期为 5 分钟，超时后自动失效
4. 用户输入正确验证码后，系统在 2 秒内完成验证并登录
5. 新用户首次登录自动创建账户，老用户直接进入首页
6. 同一手机号 1 分钟内最多请求 3 次验证码
7. 同一手机号每天最多接收 20 条验证码
8. 验证码输入错误 5 次后，该验证码失效，需重新获取
9. 登录成功后，系统记录登录日志（时间、IP、设备）
10. 支持验证码语音播报功能（无障碍需求）

业务规则：
- 验证码格式：6 位纯数字
- 验证码生成算法：加密随机数生成
- 手机号格式校验：符合中国大陆手机号规则（11 位，1 开头）
- 自动注册规则：新用户登录后，系统自动创建账户，默认用户名=手机号
- 登录态有效期：7 天免登录（本地存储 Token）
- 频次限制：基于 IP+ 手机号双重限制

数据需求：
- 用户表：mobile(手机号), verify_code(验证码), code_expire_time(过期时间), 
          verify_attempts(验证尝试次数), last_login_time(最后登录时间)
- 验证码发送记录：mobile, send_time, ip_address, device_id, status(成功/失败)
- 登录日志：user_id, login_time, ip_address, device_info, login_type

UI 需求：
- 登录页面包含：手机号输入框、验证码输入框、获取验证码按钮、登录按钮
- 手机号输入框：实时格式校验，错误时红色边框提示
- 验证码输入框：6 个独立格子或连续输入框，支持自动聚焦下一格
- 获取验证码按钮：点击后进入 60 秒倒计时，期间禁用
- 登录按钮：输入完整前禁用，输入完成后启用
- 错误提示：输入框下方红色文字提示具体错误原因
- 加载状态：登录过程中按钮显示 loading 动画并禁用
- 成功反馈：登录成功后显示绿色对勾动画，然后跳转

API 需求：
- POST /api/v1/auth/send-code: 发送验证码
  请求：{mobile: string}
  响应：{success: boolean, message: string}
- POST /api/v1/auth/verify-code: 验证验证码
  请求：{mobile: string, code: string}
  响应：{success: boolean, token: string, user: object}
- 速率限制：每个接口独立限流，防止恶意调用

约束条件：
- 技术约束：必须使用公司指定的短信服务商（阿里云短信）
- 安全约束：验证码在数据库中必须加密存储
- 合规约束：必须符合《网络安全法》实名制要求
- 性能约束：验证码发送延迟<10 秒，验证响应时间<2 秒
- 兼容性约束：支持 iOS Safari、Android Chrome、微信内置浏览器

假设条件：
- 假设短信服务商可用性>99.9%
- 假设用户输入的手机号为其本人所有
- 假设用户手机能正常接收短信
- 假设网络环境稳定，无严重丢包

NFR-PERF-001: API 响应时间

类别： Performance

标题： API 接口响应时间要求

描述：
所有对外提供的 API 接口必须在规定负载条件下满足响应时间要求，
确保用户体验和系统性能。

度量指标： 平均响应时间、P95 响应时间、P99 响应时间

目标值：
- 平均响应时间：< 200ms
- P95 响应时间：< 500ms
- P99 响应时间：< 1000ms
- 错误率：< 0.1%

测量方法：
- 使用 APM 工具（如 New Relic/DataDog）持续监控
- 压测工具（如 JMeter/k6）定期压力测试
- 按接口维度统计，区分读/写操作
- 数据统计周期：按小时聚合，按天报告

优先级： P0 - 关键

测试场景：
1. 基准测试：单用户、理想网络条件下的响应时间
2. 负载测试：1000 并发用户，持续 30 分钟
3. 压力测试：逐步增加并发直到系统崩溃，找出瓶颈
4. 稳定性测试：80% 最大负载，持续 24 小时
5. 峰值测试：模拟促销活动时的突发流量（10 倍正常流量）

依赖条件：
- 网络延迟：< 50ms（国内）
- 数据库响应：< 50ms
- 缓存命中率：> 90%

例外情况：
- 文件上传/下载接口不适用此标准
- 复杂报表生成接口单独定义（<5 秒）
- 第三方 API 调用时间不计入（但需监控）

🔒 NFR-SEC-001: 数据安全

类别： Security

标题： 用户数据加密存储与传输

描述：
所有敏感用户数据必须在存储和传输过程中进行加密，
防止数据泄露和未授权访问。

度量指标： 加密覆盖率、密钥轮换周期、安全审计通过率

目标值：
- 敏感数据加密存储率：100%
- HTTPS 覆盖率：100%
- 密钥轮换周期：≤90 天
- 安全漏洞修复时间：高危<24 小时，中危<7 天

测量方法：
- 代码审查检查加密实现
- 渗透测试验证安全性
- 自动化扫描工具检测漏洞
- 安全审计报告跟踪

优先级： P0 - 关键

测试场景：
1. 数据传输抓包分析，验证 HTTPS 加密
2. 数据库直接查询，验证敏感字段加密存储
3. 中间人攻击模拟测试
4. SQL 注入、XSS、CSRF 等常见攻击防护测试
5. 权限绕过测试

合规要求：
- 符合《网络安全法》要求
- 符合 GDPR 数据保护规定（如适用）
- 符合 PCI DSS 支付卡行业标准（如处理支付）

🎨 设计系统要素

色彩系统：
- 主色：#6366f1 (Indigo)
  - 用于主要按钮、链接、重要图标
  - Hover 状态：#4f46e5 (加深 10%)
  - Active 状态：#4338ca (加深 20%)
  
- 辅助色：#8b5cf6 (Purple)
  - 用于次要操作、装饰元素
  
- 强调色：#06b6d4 (Cyan)
  - 用于提示、高亮、特殊状态
  
- 成功色：#10b981 (Green)
  - 用于成功提示、完成状态
  
- 警告色：#f59e0b (Amber)
  - 用于警告提示、注意信息
  
- 危险色：#ef4444 (Red)
  - 用于错误提示、删除操作
  
- 中性色：
  - 文字主色：#1e293b
  - 文字次要：#64748b
  - 边框色：#e2e8f0
  - 背景色：#f8fafc

字体系统：
- 英文字体：Inter, system-ui, sans-serif
- 中文字体：'PingFang SC', 'Microsoft YaHei', sans-serif
- 字号规范：
  - 超大标题：32px / 2.5rem (H1)
  - 大标题：24px / 2rem (H2)
  - 中标题：20px / 1.5rem (H3)
  - 小标题：16px / 1.25rem (H4)
  - 正文：14px / 1rem (Base)
  - 辅助文字：12px / 0.875rem (Small)
- 字重：
  - Regular: 400
  - Medium: 500
  - Semibold: 600
  - Bold: 700

间距系统：
- 基于 8px 网格系统
- 间距值：4, 8, 12, 16, 24, 32, 48, 64, 96, 128 px
- 组件内边距：16px (标准), 24px (大)
- 组件外边距：24px (标准), 32px (大)

圆角规范：
- 小圆角：4px (按钮、输入框)
- 中圆角：8px (卡片、弹窗)
- 大圆角：16px (模态框、特殊组件)
- 全圆角：9999px (头像、徽章)

阴影层级：
- Shadow Sm: 0 1px 2px rgba(0,0,0,0.05)
- Shadow Md: 0 4px 6px rgba(0,0,0,0.1)
- Shadow Lg: 0 10px 15px rgba(0,0,0,0.1)
- Shadow Xl: 0 20px 25px rgba(0,0,0,0.15)
- Shadow 2xl: 0 25px 50px rgba(0,0,0,0.25)

动效规范：
- 缓动函数：cubic-bezier(0.4, 0, 0.2, 1)
- 持续时间：
  - 快速：150ms (Hover、Focus)
  - 标准：300ms (一般过渡)
  - 慢速：500ms (大型动画)
- 动效原则：
  - 有意义：每个动画都有明确目的
  - 自然：符合物理规律
  - 克制：不过度使用动画

📊 示例：用户实体

DM-USER-001: User (用户表)

描述： 存储系统注册用户的基本信息和账户状态

属性：

| 字段名 | 类型 | 必填 | 默认值 | 说明 |
|--------|------|------|--------|------|
| id | UUID | ✅ | auto | 主键 ID |
| mobile | VARCHAR(11) | ✅ | - | 手机号（唯一） |
| email | VARCHAR(255) | ⭕ | NULL | 邮箱地址 |
| password_hash | VARCHAR(255) | ⭕ | NULL | 密码哈希（第三方登录为空） |
| nickname | VARCHAR(50) | ⭕ | NULL | 昵称 |
| avatar_url | VARCHAR(500) | ⭕ | NULL | 头像 URL |
| gender | TINYINT | ⭕ | 0 | 性别：0-未知，1-男，2-女 |
| birthday | DATE | ⭕ | NULL | 生日 |
| registration_source | VARCHAR(20) | ✅ | - | 注册来源：SMS/WECHAT/WEIBO |
| last_login_at | DATETIME | ⭕ | NULL | 最后登录时间 |
| last_login_ip | VARCHAR(45) | ⭕ | NULL | 最后登录 IP |
| status | TINYINT | ✅ | 1 | 状态：0-禁用，1-正常，2-注销 |
| created_at | DATETIME | ✅ | NOW() | 创建时间 |
| updated_at | DATETIME | ✅ | NOW() | 更新时间 |
| is_deleted | BOOLEAN | ✅ | FALSE | 软删除标记 |
| version | INT | ✅ | 1 | 乐观锁版本 |

索引：
- PRIMARY KEY (id)
- UNIQUE INDEX idx_mobile (mobile)
- INDEX idx_email (email)
- INDEX idx_status (status)
- INDEX idx_created_at (created_at)

关系：
- 1:N → Order (用户有多个订单)
- 1:N → Address (用户有多个收货地址)
- 1:1 → UserProfile (用户详情，一对一扩展)

约束：
- mobile 必须唯一且符合中国手机号格式
- email 必须符合邮箱格式（如果提供）
- status 默认为 1（正常）
- 软删除：is_deleted=true 的记录对业务不可见

示例数据：
```json
{
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "mobile": "13800138000",
  "email": "user@example.com",
  "nickname": "张三",
  "avatar_url": "https://cdn.example.com/avatars/001.jpg",
  "gender": 1,
  "birthday": "1990-01-01",
  "registration_source": "SMS",
  "last_login_at": "2026-03-13T10:30:00Z",
  "last_login_ip": "192.168.1.100",
  "status": 1,
  "created_at": "2026-01-01T00:00:00Z",
  "updated_at": "2026-03-13T10:30:00Z",
  "is_deleted": false,
  "version": 1
}
```

{
  "success": true,
  "data": {...},
  "message": "操作成功",
  "timestamp": "2026-03-13T10:30:00Z",
  "request_id": "uuid"
}

🔌 完整 API 示例

API-USER-001: 获取用户信息

端点： GET /api/v1/users/{id}

描述： 获取指定用户的详细信息，包括基本信息和扩展资料

认证： JWT Bearer Token（需要登录）

权限： 用户只能查看自己的信息，管理员可查看所有用户

速率限制： 100 requests/minute per user

路径参数：
| 参数 | 类型 | 必填 | 说明 |
|------|------|------|------|
| id | UUID | ✅ | 用户 ID |

查询参数：
| 参数 | 类型 | 必填 | 默认值 | 说明 |
|------|------|------|--------|------|
| fields | String | ⭕ | all | 字段过滤，逗号分隔 |
| include | String | ⭕ | none | 关联数据，如：orders,addresses |

请求头：
```
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json
```

成功响应 (200 OK)：
```json
{
  "success": true,
  "data": {
    "id": "550e8400-e29b-41d4-a716-446655440000",
    "mobile": "138****8000",
    "email": "user@example.com",
    "nickname": "张三",
    "avatar_url": "https://cdn.example.com/avatars/001.jpg",
    "gender": 1,
    "birthday": "1990-01-01",
    "registration_source": "SMS",
    "last_login_at": "2026-03-13T10:30:00Z",
    "created_at": "2026-01-01T00:00:00Z"
  },
  "message": "获取成功",
  "timestamp": "2026-03-13T12:00:00Z",
  "request_id": "req-abc123"
}
```

错误响应 (404 Not Found)：
```json
{
  "success": false,
  "error": {
    "code": "USER_NOT_FOUND",
    "message": "用户不存在",
    "details": {
      "user_id": "550e8400-e29b-41d4-a716-446655440000"
    }
  },
  "timestamp": "2026-03-13T12:00:00Z",
  "request_id": "req-abc123"
}
```

错误码说明：
| 状态码 | 错误码 | 说明 |
|--------|--------|------|
| 400 | INVALID_USER_ID | 用户 ID 格式无效 |
| 401 | UNAUTHORIZED | 未登录或 Token 过期 |
| 403 | FORBIDDEN | 无权查看该用户信息 |
| 404 | USER_NOT_FOUND | 用户不存在 |
| 429 | RATE_LIMIT_EXCEEDED | 请求频率超限 |
| 500 | INTERNAL_ERROR | 服务器内部错误 |

cURL 示例：
```bash
curl -X GET 'https://api.example.com/api/v1/users/550e8400-e29b-41d4-a716-446655440000?fields=id,nickname,avatar_url' \
  -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...' \
  -H 'Content-Type: application/json'
```

SDK 示例 (JavaScript)：
```javascript
const response = await fetch('/api/v1/users/550e8400-e29b-41d4-a716-446655440000', {
  method: 'GET',
  headers: {
    'Authorization': `Bearer ${token}`,
    'Content-Type': 'application/json'
  }
});

if (response.ok) {
  const { data } = await response.json();
  console.log('用户昵称:', data.nickname);
} else {
  const { error } = await response.json();
  console.error('获取失败:', error.message);
}
```

📋 风险评估示例

RISK-TECH-001: 短信服务商不稳定

类别： Technical

描述：
当前仅依赖单一短信服务商（阿里云短信），如果该服务商出现故障或限流，
将导致用户无法接收验证码，直接影响登录注册功能，造成用户流失。

概率： Medium（历史上曾发生过 2 次故障，每次约 30 分钟）

影响： High（登录注册是核心功能，故障期间新用户无法注册，老用户无法登录）

风险值： High（中 × 高）

触发条件：
- 短信发送成功率 < 95%
- 平均发送延迟 > 30 秒
- 服务商返回错误率 > 5%

缓解策略：
1. 【短期】接入备用短信服务商（腾讯云短信），实现双通道
2. 【中期】建立智能路由系统，根据成功率自动切换服务商
3. 【长期】建立短信发送监控告警系统，提前发现异常

实施计划：
- Week 1: 完成腾讯云短信账号申请和资质审核
- Week 2: 开发双通道发送逻辑，支持手动切换
- Week 3: 开发智能路由和监控告警系统
- Week 4: 灰度测试，观察效果后全量上线

应急计划：
1. 监控系统检测到故障后，自动切换到备用服务商
2. 发送告警通知给值班工程师（电话 + 短信 + 邮件）
3. 如备用服务商也故障，启动降级方案：
   - 已登录用户不受影响（Token 续期）
   - 新用户引导使用邮箱验证码或第三方登录
   - 官网首页发布公告，告知预计恢复时间
4. 联系主服务商技术支持，跟进故障修复进度

负责人： 李四（后端开发负责人）

状态： Open（缓解策略进行中）

最后更新： 2026-03-13

下次评审： 2026-03-20（每周评审一次，直到关闭）


RISK-BIZ-001: 用户增长不及预期

类别： Business

描述：
产品上线后，如果市场推广效果不佳或产品吸引力不足，可能导致用户增长缓慢，
无法达到预期的 10 万活跃用户目标，影响商业价值和投资回报。

概率： Medium（市场竞争激烈，获客成本上升）

影响： High（直接影响收入和估值）

风险值： High

缓解策略：
1. 制定多元化获客渠道：SEO、SEM、社交媒体、KOL 合作
2. 建立用户推荐机制：老带新奖励、邀请有礼
3. 优化产品体验：降低使用门槛、提升转化率
4. 数据驱动运营：A/B 测试、漏斗分析、用户分群

应急计划：
1. 如果首月新增用户 < 目标的 50%，启动应急预案
2. 加大市场投入，增加广告预算 50%
3. 推出拉新活动：注册送优惠券、首单立减
4. 调整产品策略，聚焦核心功能和目标用户群

负责人： 王五（运营负责人）

状态： Open

📝 假设条件列表示例

1. 技术假设：
   • 假设云服务商（阿里云）可用性≥99.9%
   • 假设 MySQL 主从复制延迟<1 秒
   • 假设 CDN 节点覆盖全国 95% 地区
   • 假设第三方 API（支付、物流）响应时间<2 秒
2. 资源假设：
   • 假设项目预算 500 万充足，无追加需求
   • 假设核心团队（产品 2+ 设计 2+ 开发 8+ 测试 3）稳定
   • 假设办公场地和设备按时到位
   • 假设外包团队（UI/安全审计）按时交付
3. 时间假设：
   • 假设项目按计划 2026-03-01 启动，2026-09-30 上线
   • 假设各阶段评审按时完成，无重大返工
   • 假设法定节假日不影响关键里程碑
   • 假设供应商按时交付（服务器、域名备案等）
4. 市场假设：
   • 假设目标市场规模保持 20% 年增长率
   • 假设主要竞争对手无颠覆性产品发布
   • 假设获客成本控制在 100 元/用户以内
   • 假设用户付费转化率≥5%

📅 Phase 1 - MVP 发布计划

阶段名称： Phase 1 - MVP（最小可行产品）

目标日期： 2026-06-30

发布时间窗： 2026-06-30 02:00-06:00（凌晨低峰期）

功能范围：
✅ 包含功能：
- 用户注册登录（手机号验证码）
- 个人资料管理
- 商品浏览和搜索
- 购物车功能
- 下单支付（微信支付、支付宝）
- 订单管理和物流追踪
- 基础客服（在线客服 + 工单）

❌ 不包含：
- 优惠券和积分系统
- 个性化推荐
- 社交分享功能
- 移动端 App（仅 H5）

成功指标：
- 注册转化率 ≥ 30%（访问→注册）
- 下单转化率 ≥ 5%（注册→下单）
- 支付成功率 ≥ 95%
- 页面加载时间 < 3 秒
- 系统可用性 ≥ 99.5%
- 用户满意度 ≥ 4.0/5.0
- 首周新增用户 ≥ 5000 人

发布策略：
1. 灰度发布：
   - Day 1: 10% 流量（500 用户）
   - Day 2: 30% 流量（1500 用户）
   - Day 3: 60% 流量（3000 用户）
   - Day 4: 100% 流量（全量）

2. 监控指标：
   - 实时错误率（目标<0.1%）
   - API 响应时间（P95<500ms）
   - 服务器 CPU/内存使用率（<70%）
   - 数据库连接数（<80%）
   - 业务指标（注册数、订单数、支付金额）

3. 值班安排：
   - 发布总指挥：张三（产品负责人）
   - 技术负责人：李四（后端 Lead）
   - 运维值班：王五 + 赵六（轮班）
   - 客服值班：钱七 + 孙八（轮班）
   - 应急响应：全员 on-call

回滚计划：
触发条件：
- 致命 Bug 导致核心功能不可用（登录/支付）
- 错误率 > 5% 且 30 分钟内无法修复
- 系统性能严重下降（响应时间>10 秒）
- 数据错误或丢失

回滚步骤：
1. 发布总指挥决策是否回滚
2. 运维团队执行回滚脚本（10 分钟内完成）
3. 切回到上一个稳定版本（v0.9.5）
4. 验证核心功能恢复正常
5. 发布公告告知用户（官网 + 社交媒体）
6. 问题修复后重新规划发布时间

沟通计划：
- 发布前 1 周： 内部全员邮件通知
- 发布前 1 天： 官网发布公告（维护通知）
- 发布当天： 实时同步进展（内部群）
- 发布成功： 全员庆祝邮件 + 用户感谢公告
- 发布失败： 诚恳道歉公告 + 补偿方案（优惠券）

验收标准：
- [ ] 所有 P0/P1 Bug 已修复
- [ ] 性能测试通过（压测报告）
- [ ] 安全扫描通过（无高危漏洞）
- [ ] 回归测试通过率 100%
- [ ] 运维手册和应急预案已准备
- [ ] 客服培训已完成
- [ ] 监控告警系统已配置
- [ ] 回滚演练已完成

📊 KPI 示例：用户留存率

KPI 名称： 用户留存率（Retention Rate）

定义：
在某一时间段内新增的用户中，在后续特定时间点仍然活跃的用户比例。
反映产品的用户粘性和长期价值。

公式：
留存率 = (第 N 日仍活跃的新增用户数 / 第 1 日新增用户总数) × 100%

常用留存周期：
- 次日留存（Day 1 Retention）
- 7 日留存（Day 7 Retention）
- 30 日留存（Day 30 Retention）

数据来源：
- 用户登录日志表（user_login_logs）
- 用户注册表（user_registration）
- 数据仓库（Hive/ClickHouse）

SQL 示例（7 日留存）：
```sql
SELECT 
  DATE(registration_date) AS reg_date,
  COUNT(DISTINCT u.user_id) AS new_users,
  COUNT(DISTINCT CASE WHEN l.login_date BETWEEN DATE_ADD(registration_date, 6) AND DATE_ADD(registration_date, 7) 
                      THEN u.user_id END) AS retained_users,
  ROUND(COUNT(DISTINCT CASE WHEN l.login_date BETWEEN DATE_ADD(registration_date, 6) AND DATE_ADD(registration_date, 7) 
                            THEN u.user_id END) * 100.0 / COUNT(DISTINCT u.user_id), 2) AS retention_rate
FROM user_registration u
LEFT JOIN user_login_logs l ON u.user_id = l.user_id
WHERE u.registration_date >= '2026-01-01'
GROUP BY DATE(registration_date)
ORDER BY reg_date;
```

基线值：
- 次日留存：40%（行业平均 35-45%）
- 7 日留存：20%（行业平均 15-25%）
- 30 日留存：10%（行业平均 8-12%）

目标值（上线后 6 个月）：
- 次日留存：≥ 50%
- 7 日留存：≥ 30%
- 30 日留存：≥ 15%

测量频率：
- 每日计算前一日新增用户的留存
- 每周汇总周报（按注册日期分组）
- 每月深度分析（ cohort analysis）

可视化：
- 折线图：展示留存率趋势变化
- 热力图：Cohort Analysis 矩阵
- 漏斗图：从注册到各留存节点的转化

负责人： 王五（运营负责人）

警戒线：
- 次日留存 < 35% 连续 3 天 → 触发预警
- 7 日留存 < 15% 连续 7 天 → 启动专项优化

改进措施（如低于目标）：
1. 新用户引导流程优化（Onboarding）
2. 推送个性化内容和优惠（Push Notification）
3. 建立用户成长体系（签到、任务、成就）
4. A/B 测试关键页面和功能
5. 用户调研和访谈，找出流失原因