mini-starter/docs/prd.md

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