# mini-demo 页面迁移项目 产品需求文档 (PRD)

## 版本信息
| 版本 | 日期 | 描述 | 作者 |
|------|------|------|------|
| 1.0 | 2025-10-15 | 基于项目简报更新为出行服务项目 | John (PM) |

## 1. 项目介绍和分析

### 1.1 项目概览

**项目名称**: mini-demo 页面迁移项目

**产品概念**: 将现有的 mini-demo（纯前端出行小程序演示）的16个功能页面迁移到 mini 项目中，并基于 src 目录构建完整的后端和管理后台系统。

**当前项目状态**:
- 🚗 **mini-demo**: 微信原生小程序，16个出行服务页面，纯前端演示
- 🛠️ **mini**: Taro + React 小程序项目，基础框架已搭建
- 🔧 **src**: Hono + TypeORM 后端API和管理后台，用户管理基础已实现

### 1.2 问题陈述

**当前痛点**:
- mini-demo 仅有前端界面，所有数据都是模拟的
- 无数据持久化，用户信息、订单数据无法保存
- 缺乏真实业务逻辑：订单处理、支付、司机匹配等
- 无管理后台，无法进行运营管理

**问题影响**:
- 无法作为真实产品上线运营
- 用户体验不完整，无法完成完整的出行服务流程
- 技术债务积累，难以迭代和维护

### 1.3 解决方案概述

**核心方法**:
将 mini-demo 的16个功能页面迁移到 mini 项目（Taro + React 技术栈），并基于 src 目录构建完整的后端 API 和管理后台系统。

**关键差异化**:
- 技术现代化：从微信原生迁移到 Taro + React
- 完整业务闭环：构建真实的后端服务
- 管理后台：提供运营管理界面
- 数据持久化：基于 PostgreSQL 实现数据存储

### 1.4 目标和背景

#### 业务目标
- 🚀 **产品转化**: 将演示原型转化为功能完整的出行服务平台
- 📈 **用户增长**: 3个月内达到1000名注册用户
- 💰 **收入目标**: 6个月内实现月订单收入10,000元
- 🔄 **技术升级**: 统一技术架构，提升可维护性和扩展性

#### 技术背景
项目已具备优秀的技术基础：
- mini: Taro + React + TypeScript + TailwindCSS 多端框架
- src: Hono + TypeORM + PostgreSQL 现代化后端架构
- 完整的用户认证和权限管理系统
- 生产就绪的部署配置和环境

## 2. 需求定义

### 2.1 功能需求

基于项目简报和实际项目分析，定义以下出行服务功能需求：

**FR1: 用户认证和基础管理**
- 支持微信小程序登录和注册
- 用户信息持久化存储到PostgreSQL数据库
- 乘客信息管理：身份证、姓名等基本信息
- 基础用户设置和偏好管理

**FR2: 出行服务核心功能 (MVP)**
- 路线查询和活动筛选（去程活动/返程活动）
- 线路管理：上车点、下车点、出发日期时间、车型、人数上限
- 订单管理：下单、支付、状态跟踪（待出发、行程中、已完成、已取消）
- 支付集成：微信支付完整流程

**FR3: 前端页面迁移和优化**
- 将mini-demo的核心页面迁移到Taro + React技术栈
- 响应式设计，支持多端发布（微信小程序、H5）
- 统一的UI组件库和设计规范
- 优化用户体验和交互流程

**FR4: 后端业务逻辑实现**
- 活动管理：活动创建、关联多条线路
- 订单处理流程：下单、支付、状态更新
- 线路和车型管理业务逻辑
- 基础数据统计功能

**FR5: 管理后台系统**
- 活动管理：活动配置、线路关联
- 订单管理：订单监控、状态管理
- 用户管理：用户信息、乘客信息管理
- 线路管理：线路配置、车型管理

### 详细 rationale (决策依据):

这些需求基于对mini-demo功能分析和现有技术架构的评估：
- **业务连续性**: 保持mini-demo的核心出行服务功能
- **技术现代化**: 利用现有Taro + React + Hono技术栈优势
- **数据完整性**: 基于现有用户管理基础扩展出行业务数据模型
- **运营需求**: 为商业化运营提供完整的管理后台支持

**关键假设**:
- 目标用户是出行服务需求人群和司机/运营人员
- 主要使用场景是城市内拼车、商务车、包车服务
- 微信小程序是主要发布平台
- 需要支持完整的出行服务业务流程

**需要验证的领域**:
- 现有用户数据如何迁移到新系统？
- mini-demo中模拟数据的转换策略？
- 司机端功能是否需要在MVP中实现？
- 积分系统的具体规则和兑换机制？



### 2.2 非功能性需求

**NFR1: 性能和响应速度**
- 页面加载时间 < 2秒，API响应时间 < 500ms
- 支持实时位置更新和状态同步
- 数据库查询优化，支持高并发访问
- 前端资源优化，减少首屏加载时间

**NFR2: 可靠性和稳定性**
- 订单处理流程必须保证数据一致性
- 支付系统需要99.9%的可用性
- 支持事务处理和异常恢复
- 系统监控和告警机制

**NFR3: 安全性和数据保护**
- 用户数据加密存储和传输
- 支付信息安全保护
- 防止SQL注入和XSS攻击
- 用户隐私数据合规处理

**NFR4: 可扩展性和维护性**
- 模块化架构，支持功能扩展
- 清晰的代码结构和文档
- 自动化测试覆盖核心业务逻辑
- 支持灰度发布和回滚

**NFR5: 用户体验和易用性**
- 直观的操作流程和界面设计
- 错误提示和引导信息清晰
- 支持离线操作和网络异常处理
- 多端体验一致性

### 详细 rationale (决策依据):

这些非功能性需求基于出行服务业务特点：
- **性能关键**: 出行服务需要快速响应和实时更新
- **可靠性优先**: 订单和支付系统必须稳定可靠
- **安全合规**: 用户数据和支付信息需要严格保护
- **扩展需求**: 业务增长需要系统能够水平扩展

**技术约束**:
- 必须兼容微信小程序平台限制
- 支持PostgreSQL关系型数据库
- 基于现有Taro + Hono技术栈
- 多八多云端开发容器环境部署

### 3.2 集成策略

**数据库集成策略**:
- 基于现有TypeORM实体扩展出行业务数据模型
- 支持订单、乘客、积分等复杂业务关系
- 数据库迁移和版本控制
- 连接池管理和性能优化

**API集成策略**:
- RESTful API设计，支持微信小程序调用
- Hono RPC确保前后端类型安全
- 统一的错误处理和响应格式
- 第三方服务集成：微信支付、地图服务

**前端集成策略**:
- Taro多端框架，支持微信小程序和H5
- 统一的UI组件库和设计规范
- 状态管理和数据流优化
- 微信小程序API集成



## 5. Epic和故事结构

### 5.1 Epic方法

**Epic结构决策**: 按业务领域划分Epic - 针对出行服务不同业务模块分别开发

**决策依据**:
- 项目需要从演示原型转化为完整产品
- 不同业务模块有明确的依赖关系和优先级
- 独立Epic便于并行开发和专门团队负责
- 每个Epic对应一个完整的业务功能模块

### 5.2 Epic详情

**Epic 005: 出行服务核心功能 (MVP优先)**
**Epic目标**: 实现路线查询、活动筛选、订单管理、乘客管理、支付集成等核心出行服务功能。
**成功标准**: 用户能够完成从查询路线到支付完成的完整出行流程，订单数据正确存储

**Epic 006: 前端页面迁移和基础框架**
**Epic目标**: 将mini-demo的核心页面迁移到Taro + React技术栈，建立统一的前端架构和组件库。
**成功标准**: MVP相关页面功能完整迁移，UI组件库建立，多端发布支持正常

**Epic 007: 用户认证和基础管理**
**Epic目标**: 基于现有用户管理基础，支持微信小程序登录和基础用户信息管理。
**成功标准**: 用户注册登录流程完整，乘客信息管理功能可用

**Epic 008: 管理后台系统**
**Epic目标**: 构建运营管理后台，支持订单管理、用户管理、数据统计等运营功能。
**成功标准**: 管理后台功能完整，运营人员能够正常进行日常管理操作

### 5.3 各Epic用户故事概览

**Epic 005 - 出行服务核心功能 (MVP优先)**:
- 路线查询和活动筛选功能（去程活动/返程活动）
- 线路管理：上车点、下车点、出发日期时间、车型、人数上限
- 订单管理：订单创建、支付、状态管理（待出发、行程中、已完成、已取消）
- 乘客信息管理：身份证、姓名
- 微信支付集成

**Epic 006 - 前端页面迁移和基础框架**:
- 首页迁移（静态焦点图）
- 路线查询和活动选择页面迁移
- 订单相关页面迁移（下单、支付、订单列表、详情）
- 乘客管理页面迁移
- 统一的UI组件库建设

**Epic 007 - 用户认证和基础管理**:
- 微信小程序登录注册功能
- 基础用户信息管理
- 乘客信息维护功能
- 用户设置和偏好管理

**Epic 008 - 管理后台系统**:
- 活动管理：活动创建、关联线路
- 线路管理：线路配置、车型管理
- 订单管理：订单监控、状态管理
- 用户管理：用户信息、乘客信息管理

## 6. 成功指标和验收标准

### 6.1 关键绩效指标(KPI)

**Epic 005 - 出行服务核心功能指标**:
- 🚗 路线查询准确率 > 95%
- 📦 订单创建到支付完成转化率 > 85%
- 💳 微信支付集成正常，支付成功率 > 98%
- 👥 乘客信息管理功能完整

**Epic 006 - 前端页面迁移指标**:
- ✅ MVP相关页面完整迁移，功能测试通过率100%
- ⚡ 页面加载时间 < 2秒，API响应时间 < 500ms
- 🎨 UI组件库建立，设计一致性达到95%
- 📱 多端发布支持正常（微信小程序、H5）

**Epic 007 - 用户认证和基础管理指标**:
- 👥 用户注册登录成功率 > 99%
- 👤 乘客信息管理功能完整，数据准确
- 🔐 微信小程序登录集成正常
- ⚙️ 基础用户设置功能正常

**Epic 008 - 管理后台系统指标**:
- 📊 订单管理功能完整，监控数据准确
- 👤 用户管理功能正常，行为分析可用
- 📈 运营数据统计报表生成正常
- 🚕 活动管理和线路配置功能完整

**总体业务指标**:
- 📈 **用户增长**: 3个月内达到1000名注册用户
- 💰 **收入目标**: 6个月内实现月订单收入10,000元
- 🔄 **用户留存**: 30天用户留存率达到40%
- ⚡ **订单转化**: 首页到下单转化率达到15%

### 6.2 验收标准

**项目级验收**:
- 所有16个页面功能完整迁移并测试通过
- 用户能够完成从查询路线到支付完成的完整出行流程
- 核心业务数据能够正确存储和展示
- 管理后台能够处理基本的订单和用户管理
- 系统稳定运行，无明显性能问题

**阶段性验收**:
- 每个Epic完成后进行功能演示和用户测试
- 每周演示进度和获取业务反馈
- 每月进行整体质量评估和业务指标检查
- MVP完成后进行上线前综合测试

## 7. 附录

### 7.1 参考资料
- 项目简报: `docs/brief.md`
- mini-demo项目: `./mini-demo/`
- mini项目: `./mini/`
- src后端项目: `./src/`

### 7.2 相关文档
- 技术架构文档: `docs/architecture.md`
- API文档: 通过 `/ui` 端点访问
- 开发指南: `docs/development.md`
- 部署指南: `docs/deployment.md`

### 7.3 联系方式
- 产品负责人: [待指定]
- 技术负责人: [待指定]
- 开发团队: [待指定]

### 7.4 项目约束和假设

**约束**:
- 预算：基于现有开发资源，无额外预算
- 时间线：MVP在4-6周内完成
- 资源：现有开发团队，无额外人员
- 技术：必须兼容微信小程序平台

**关键假设**:
- Taro框架能够满足出行小程序的功能需求
- 现有后端架构能够扩展支持出行业务
- 微信支付接口能够正常集成
- 用户接受新的界面设计和交互方式
- 市场对出行服务有持续需求
- MVP功能能够满足用户基本出行需求

---

**文档状态**: 已更新
**最后更新**: 2025-10-15
**下次评审**: 2025-10-22