# Project Brief: mini-demo 页面迁移项目

## Executive Summary

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

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

**解决的主要问题：**
- mini-demo 目前只是一个纯前端演示，缺乏真实的后端支持
- 无数据持久化，用户信息、订单数据无法保存
- 缺乏业务逻辑，没有真实的订单处理、支付、司机匹配等核心功能
- 技术栈限制，基于微信原生开发，扩展性和维护性有限

**目标市场：**
- 出行服务小程序用户
- 需要拼车、商务车、包车等出行需求的个人用户
- 提供出行服务的司机和运营人员

**核心价值主张：** 通过迁移和重构，将演示原型转化为功能完整的出行服务平台，具备用户管理、订单处理、司机管理、积分商城等完整业务功能。

## Problem Statement

**当前状态和痛点：**

mini-demo 作为一个出行服务小程序演示，目前存在以下核心问题：

1. **纯前端演示** - 仅有前端界面，所有数据都是模拟的，无法作为真实产品使用
2. **无数据持久化** - 用户信息、订单数据、积分记录等无法保存，重启即丢失
3. **缺乏业务逻辑** - 没有真实的订单处理、支付流程、司机匹配等核心功能
4. **技术栈限制** - 基于微信原生开发，扩展性和维护性有限
5. **无管理后台** - 无法进行司机管理、订单监控、运营分析等后台操作

**问题影响：**
- 无法作为真实产品上线运营
- 用户体验不完整，无法完成完整的出行服务流程
- 技术债务积累，难以迭代和维护
- 缺乏运营管理能力，无法进行商业化运营

**现有解决方案的不足：**
- mini-demo 停留在原型阶段，无法满足生产环境需求
- 缺乏完整的业务闭环和数据流
- 没有真实的后端服务支持
- 管理功能完全缺失

**紧迫性和重要性：**
出行服务市场需求持续增长，需要快速将演示转化为可运营产品。技术架构需要统一和现代化，以支持后续的业务扩展和功能迭代。

## Proposed Solution

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

**关键差异化因素：**
1. **技术现代化** - 从微信原生迁移到 Taro + React，提升开发效率和可维护性
2. **完整业务闭环** - 构建真实的后端服务，支持完整的出行业务流程
3. **管理后台** - 提供运营管理界面，支持司机管理、订单监控、用户管理等
4. **数据持久化** - 基于 PostgreSQL 实现数据存储和业务逻辑
5. **实时功能** - 支持实时位置跟踪、订单状态更新等实时功能

**成功因素：**
- 成熟的 Taro 框架支持多端发布
- 基于 Hono + TypeORM 的现代化后端架构
- 清晰的业务领域模型和 API 设计
- 渐进式迁移策略，降低风险

**产品愿景：**
将演示原型转化为功能完整的出行服务平台，为用户提供可靠、便捷、经济的出行服务体验。

## Target Users

**Primary User Segment: 出行用户**
- **用户画像：** 需要拼车、商务车、包车等出行服务的个人用户
- **当前行为：** 通过小程序查找出行路线、预订座位、管理订单
- **核心需求：**
  - 便捷的路线查询和预订
  - 实时订单状态跟踪
  - 安全的支付体验
  - 积分奖励和优惠券使用
- **目标：** 获得可靠、便捷、经济的出行服务

**Secondary User Segment: 司机/运营人员**
- **用户画像：** 提供出行服务的司机和后台运营人员
- **当前行为：** 通过管理后台处理订单、管理车辆、监控运营
- **核心需求：**
  - 高效的订单分配和管理
  - 实时位置跟踪和路线规划
  - 收益统计和分析
  - 乘客信息管理
- **目标：** 提高运营效率和服务质量

**目标业务场景：**
- 城市内拼车出行服务
- 商务车专车服务
- 包车旅游服务
- 企业员工通勤服务

## Goals & Success Metrics

### Business Objectives
- **用户增长**：3个月内达到 1000 名注册用户
- **订单转化**：首页到下单转化率达到 15%
- **用户留存**：30天用户留存率达到 40%
- **收入目标**：6个月内实现月订单收入 10,000 元

### User Success Metrics
- **订单完成率**：用户下单到完成的转化率 > 85%
- **用户满意度**：用户评价平均分 > 4.5/5
- **功能使用率**：核心功能（路线查询、下单、支付）使用率 > 70%
- **响应时间**：页面加载时间 < 2秒，API 响应时间 < 500ms

### Key Performance Indicators (KPIs)
- **DAU/MAU**：日活跃用户/月活跃用户比率 > 30%
- **订单量**：日均订单数量达到 50 单
- **客单价**：平均订单金额 > 50 元
- **复购率**：30天内重复下单用户比例 > 25%

## MVP Scope

### Core Features (Must Have)
- **首页**：路线查询、热门路线推荐、活动展示
- **订单管理**：订单列表、订单详情、订单状态跟踪
- **用户中心**：个人信息、积分管理、优惠券
- **积分商城**：积分兑换、商品展示
- **乘客管理**：常用乘客信息管理
- **基础支付**：微信支付集成

### Out of Scope for MVP
- **高级推荐算法**：基于用户行为的个性化推荐
- **多语言支持**：国际化功能
- **复杂营销活动**：复杂的优惠券和促销系统
- **司机端独立应用**：专门的司机端小程序
- **高级数据分析**：复杂的运营数据分析和报表

### MVP Success Criteria
- 用户能够完成从查询路线到支付完成的完整出行流程
- 核心业务数据能够正确存储和展示
- 管理后台能够处理基本的订单和用户管理
- 系统稳定运行，无明显性能问题

## Post-MVP Vision

### Phase 2 Features
- **司机端功能**：专门的司机端小程序，支持接单、路线导航
- **实时位置跟踪**：订单实时位置共享和跟踪
- **智能推荐**：基于历史行为的路线和司机推荐
- **会员体系**：会员等级和专属权益
- **客服系统**：在线客服和问题反馈

### Long-term Vision
- **多平台支持**：扩展到 H5、App 等多端
- **业务扩展**：扩展到货运、旅游包车等更多出行场景
- **生态建设**：构建出行服务生态，接入更多服务提供商
- **智能化运营**：基于 AI 的智能调度和运营优化

### Expansion Opportunities
- **企业服务**：为企业提供定制化出行解决方案
- **跨城服务**：扩展到跨城市的长途出行服务
- **增值服务**：保险、餐饮、住宿等配套服务
- **数据服务**：出行数据分析和行业洞察

## Technical Considerations

### Platform Requirements
- **目标平台**：微信小程序为主要发布平台
- **浏览器/系统支持**：兼容主流微信版本和手机系统
- **性能要求**：支持实时位置更新，API 响应时间 < 500ms

### Technology Preferences
- **前端**：Taro + React + TypeScript + TailwindCSS
- **后端**：Hono + TypeORM + PostgreSQL + Redis
- **数据库**：PostgreSQL 17（已配置）
- **部署/基础设施**：多八多云端开发容器环境

### Architecture Considerations
- **仓库结构**：保持现有的三目录结构（mini-demo、mini、src）
- **服务架构**：前后端分离，RESTful API 设计
- **集成需求**：微信支付、地图服务、消息推送
- **安全/合规**：用户数据保护、支付安全、API 认证

## Constraints & Assumptions

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

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

## Risks & Open Questions

### Key Risks
- **技术风险**：Taro 框架在复杂业务场景下的稳定性
- **业务风险**：出行业务模型的市场接受度
- **集成风险**：第三方服务（微信支付、地图）的稳定性
- **性能风险**：实时位置跟踪对系统性能的影响

### Open Questions
- 现有用户数据如何迁移到新系统？
- 如何处理 mini-demo 中模拟数据的转换？
- 司机端功能是否需要在 MVP 中实现？
- 积分系统的具体规则和兑换机制？

### Areas Needing Further Research
- 微信小程序在出行服务领域的最佳实践
- 实时位置跟踪的技术方案和性能优化
- 出行服务的合规要求和资质认证
- 竞品分析和差异化策略

## Appendices

### A. Research Summary

#### mini-demo 功能分析
- **14个核心页面**：首页、选择活动、班次列表、下单、添加乘客、支付成功、订单列表、订单详情、积分商城、个人中心、积分商城、积分历史、我的优惠券、乘客管理
- **4个底部导航**：首页、出行、积分、我的
- **业务功能**：路线查询、班次选择、乘客管理、订单处理、积分系统

#### mini 项目现状
- **基础框架**：Taro + React + TypeScript
- **现有页面**：首页、发现、个人中心、登录、注册
- **技术栈**：TailwindCSS、React Hook Form、Zod 验证

#### src 后端架构
- **框架**：Hono + TypeORM + PostgreSQL
- **现有模块**：用户管理、权限管理、文件上传
- **API 设计**：OpenAPI 规范，支持 Swagger UI

### B. References
- [mini-demo 项目结构](./mini-demo/)
- [mini 项目代码](./mini/)
- [src 后端代码](./src/)
- [项目配置文档](./.bmad-core/core-config.yaml)

## Next Steps

### Immediate Actions
1. **详细功能分析**：深入分析每个页面的业务逻辑和数据需求
2. **API 设计**：设计完整的后端 API 接口规范
3. **数据模型设计**：设计数据库表和实体关系
4. **页面迁移计划**：制定具体的页面迁移顺序和优先级
5. **开发环境配置**：配置完整的开发、测试、生产环境
6. **开发实施**：按照优先级逐步实施迁移和开发
7. **测试验证**：功能测试、性能测试、用户体验测试
8. **部署上线**：部署到生产环境并监控运行状态

### PM Handoff

此项目简报为 mini-demo 页面迁移项目提供了完整的上下文。请从 'PRD 生成模式' 开始，彻底审阅此简报，与用户协作按模板指示逐节创建 PRD，询问任何必要的澄清或建议改进。

---

*项目简报创建完成时间：2025-10-15*
*分析师：Mary 📊*