brief.md 11 KB
Project Brief: mini-demo 页面迁移项目
Executive Summary
项目名称： mini-demo 页面迁移项目
产品概念： 将现有的 mini-demo（纯前端出行小程序演示）的功能页面迁移到 mini 项目中，并基于 src 目录构建完整的后端和管理后台系统。
解决的主要问题：
- mini-demo 目前只是一个纯前端演示，缺乏真实的后端支持
- 无数据持久化，用户信息、订单数据无法保存
- 缺乏业务逻辑，没有真实的订单处理、支付、司机匹配等核心功能
- 技术栈限制，基于微信原生开发，扩展性和维护性有限
目标市场：
- 出行服务小程序用户
- 需要拼车、商务车、包车等出行需求的个人用户
- 提供出行服务的司机和运营人员
核心价值主张： 通过迁移和重构，将演示原型转化为功能完整的出行服务平台，具备用户管理、订单处理、司机管理、积分商城等完整业务功能。
Problem Statement
当前状态和痛点：
mini-demo 作为一个出行服务小程序演示，目前存在以下核心问题：
- 纯前端演示 - 仅有前端界面，所有数据都是模拟的，无法作为真实产品使用
- 无数据持久化 - 用户信息、订单数据、积分记录等无法保存，重启即丢失
- 缺乏业务逻辑 - 没有真实的订单处理、支付流程、司机匹配等核心功能
- 技术栈限制 - 基于微信原生开发，扩展性和维护性有限
- 无管理后台 - 无法进行司机管理、订单监控、运营分析等后台操作
问题影响：
- 无法作为真实产品上线运营
- 用户体验不完整，无法完成完整的出行服务流程
- 技术债务积累，难以迭代和维护
- 缺乏运营管理能力，无法进行商业化运营
现有解决方案的不足：
- mini-demo 停留在原型阶段，无法满足生产环境需求
- 缺乏完整的业务闭环和数据流
- 没有真实的后端服务支持
- 管理功能完全缺失
紧迫性和重要性： 出行服务市场需求持续增长，需要快速将演示转化为可运营产品。技术架构需要统一和现代化，以支持后续的业务扩展和功能迭代。
Proposed Solution
核心概念和方法： 将 mini-demo 的 14 个功能页面迁移到 mini 项目（Taro + React 技术栈），并基于 src 目录构建完整的后端 API 和管理后台系统。
关键差异化因素：
- 技术现代化 - 从微信原生迁移到 Taro + React，提升开发效率和可维护性
- 完整业务闭环 - 构建真实的后端服务，支持完整的出行业务流程
- 管理后台 - 提供运营管理界面，支持司机管理、订单监控、用户管理等
- 数据持久化 - 基于 PostgreSQL 实现数据存储和业务逻辑
- 实时功能 - 支持实时位置跟踪、订单状态更新等实时功能
成功因素：
- 成熟的 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
Next Steps
Immediate Actions
- 详细功能分析：深入分析每个页面的业务逻辑和数据需求
- API 设计：设计完整的后端 API 接口规范
- 数据模型设计：设计数据库表和实体关系
- 页面迁移计划：制定具体的页面迁移顺序和优先级
- 开发环境配置：配置完整的开发、测试、生产环境
- 开发实施：按照优先级逐步实施迁移和开发
- 测试验证：功能测试、性能测试、用户体验测试
- 部署上线：部署到生产环境并监控运行状态
PM Handoff
此项目简报为 mini-demo 页面迁移项目提供了完整的上下文。请从 'PRD 生成模式' 开始，彻底审阅此简报，与用户协作按模板指示逐节创建 PRD，询问任何必要的澄清或建议改进。
项目简报创建完成时间：2025-10-15 分析师：Mary 📊