📝 docs(prd): 更新产品需求文档为出行服务项目

- 重命名项目为"mini-demo 页面迁移项目"，明确产品概念和目标
- 调整项目介绍，聚焦将16个前端演示页面迁移到完整项目
- 重构功能需求，定义用户认证、出行服务、页面迁移等核心功能
- 更新非功能性需求，强调性能、可靠性和用户体验指标
- 按业务领域划分Epic结构，明确各模块开发目标和成功标准
- 设定业务KPI，包括用户增长、收入目标和订单转化率
- 添加项目约束和假设，明确时间线和资源限制

docs/prd.md

@@ -1,197 +1,185 @@
-# D8D Starter 产品需求文档 (PRD)
+# mini-demo 页面迁移项目 产品需求文档 (PRD)
 
 ## 版本信息
 | 版本 | 日期 | 描述 | 作者 |
 |------|------|------|------|
-| 1.0 | 2024-09-14 | 初始PRD版本 | John (PM) |
-| 1.1 | 2025-09-17 | 更新Epic结构和指标，与实际epic对齐 | Sarah (PO) |
-| 1.2 | 2025-09-19 | 在Epic 001中集成数据库备份功能 | Winston |
+| 1.0 | 2025-10-15 | 基于项目简报更新为出行服务项目 | John (PM) |
 
 ## 1. 项目介绍和分析
 
-### 1.1 现有项目概览
+### 1.1 项目概览
 
-**分析来源**: 基于现有架构文档 `docs/brownfield-architecture.md`
+**项目名称**: mini-demo 页面迁移项目
 
-**当前项目状态**: D8D Starter 是一个现代化的全栈Web应用启动模板，提供：
-- 🚀 **快速开发基础**: Node.js + React 技术栈
-- 🔐 **身份认证系统**: JWT-based 用户认证
-- 👥 **用户管理**: 完整的用户和角色管理功能
-- 📊 **数据库集成**: TypeORM + PostgreSQL 数据持久化
-- 🎨 **现代化UI**: React 19 + Tailwind CSS 界面
+**产品概念**: 将现有的 mini-demo（纯前端出行小程序演示）的16个功能页面迁移到 mini 项目中，并基于 src 目录构建完整的后端和管理后台系统。
 
-### 1.2 可用文档分析
+**当前项目状态**:
+- 🚗 **mini-demo**: 微信原生小程序，16个出行服务页面，纯前端演示
+- 🛠️ **mini**: Taro + React 小程序项目，基础框架已搭建
+- 🔧 **src**: Hono + TypeORM 后端API和管理后台，用户管理基础已实现
 
-✅ **技术文档完整**:
-- 技术栈和版本信息
-- 源码结构和模块组织
-- 数据模型和API规范
-- 技术债务和已知问题
-- 开发和部署指南
+### 1.2 问题陈述
 
-⚠️ **需要补充的业务文档**:
-- 产品愿景和目标
-- 用户需求和场景
-- 功能优先级
-- 业务指标
+**当前痛点**:
+- mini-demo 仅有前端界面，所有数据都是模拟的
+- 无数据持久化，用户信息、订单数据无法保存
+- 缺乏真实业务逻辑：订单处理、支付、司机匹配等
+- 无管理后台，无法进行运营管理
 
-### 1.3 增强范围定义
+**问题影响**:
+- 无法作为真实产品上线运营
+- 用户体验不完整，无法完成完整的出行服务流程
+- 技术债务积累，难以迭代和维护
 
-**项目类型**: 现有项目功能完善和业务需求文档化
+### 1.3 解决方案概述
 
-**主要目标**:
-1. 将现有技术实现与业务需求对齐
-2. 定义清晰的产品方向和成功标准
-3. 为未来功能扩展建立需求基线
+**核心方法**:
+将 mini-demo 的16个功能页面迁移到 mini 项目（Taro + React 技术栈），并基于 src 目录构建完整的后端 API 和管理后台系统。
+
+**关键差异化**:
+- 技术现代化：从微信原生迁移到 Taro + React
+- 完整业务闭环：构建真实的后端服务
+- 管理后台：提供运营管理界面
+- 数据持久化：基于 PostgreSQL 实现数据存储
 
 ### 1.4 目标和背景
 
 #### 业务目标
-- 📈 **确立产品市场定位**: 明确D8D Starter的目标用户和使用场景
-- 🎯 **定义成功指标**: 建立可衡量的产品成功标准
-- 🔄 **建立迭代流程**: 为持续改进提供需求框架
-- 🤝 **促进团队对齐**: 确保技术实现与业务目标一致
+- 🚀 **产品转化**: 将演示原型转化为功能完整的出行服务平台
+- 📈 **用户增长**: 3个月内达到1000名注册用户
+- 💰 **收入目标**: 6个月内实现月订单收入10,000元
+- 🔄 **技术升级**: 统一技术架构，提升可维护性和扩展性
 
 #### 技术背景
-D8D Starter已经具备优秀的技术基础：
-- 现代化的全栈技术架构
-- 模块化的代码组织
-- 完整的认证和用户管理系统
-- 生产就绪的部署配置
-
-现在需要将技术能力转化为明确的业务价值主张。
+项目已具备优秀的技术基础：
+- mini: Taro + React + TypeScript + TailwindCSS 多端框架
+- src: Hono + TypeORM + PostgreSQL 现代化后端架构
+- 完整的用户认证和权限管理系统
+- 生产就绪的部署配置和环境
 
 ## 2. 需求定义
 
 ### 2.1 功能需求
 
-基于现有技术实现，我定义了以下功能需求。请仔细审核这些需求是否准确反映了项目的业务目标：
-
-**FR1: 用户认证和管理系统**
-- 必须提供完整的用户注册、登录、密码重置功能
-- 支持基于JWT的安全认证机制
-- 用户信息需要持久化存储到PostgreSQL数据库
-- 提供用户角色和权限管理基础框架
-
-**FR2: 现代化前端界面**
-- 使用React 19构建响应式用户界面
-- 采用Tailwind CSS确保一致的视觉设计
-- 提供管理后台和用户主页两种界面模式
-- 支持组件化开发和代码复用
-
-**FR3: 类型安全的API架构**
-- 使用Hono RPC (hc) 提供前后端统一的类型安全
-- 集成@hono/zod-openapi自动生成OpenAPI文档
-- 使用@hono/swagger-ui提供交互式API文档界面
-- 实现通用的CRUD路由和服务，避免每个实体重复编写
-- **支持关联查询和复杂数据关系处理**
-- 前后端共享Zod schema，确保表单验证一致性
-
-**FR4: 数据库集成和ORM**
-- 使用TypeORM进行数据库操作抽象
-- 支持PostgreSQL数据库连接和连接池管理
-- 提供数据模型定义和迁移能力
-- 实现基础的数据验证和约束
-
-**FR5: 开发和生产环境支持**
-- 提供Vite开发服务器支持热重载
-- 支持生产环境构建和优化
-- 集成Docker Compose用于本地开发环境
-- 提供环境变量配置管理
+基于项目简报和实际项目分析，定义以下出行服务功能需求：
+
+**FR1: 用户认证和会员系统**
+- 支持微信小程序登录和注册
+- 用户信息持久化存储到PostgreSQL数据库
+- 积分管理系统：积分获取、使用、历史记录
+- 优惠券管理：发放、使用、过期处理
+
+**FR2: 出行服务核心功能**
+- 路线查询和班次列表展示
+- 订单管理：下单、支付、状态跟踪、取消
+- 乘客管理：常用乘客信息维护
+- 支付集成：微信支付完整流程
+
+**FR3: 前端页面迁移和优化**
+- 将mini-demo的16个页面迁移到Taro + React技术栈
+- 响应式设计，支持多端发布（微信小程序、H5）
+- 统一的UI组件库和设计规范
+- 优化用户体验和交互流程
+
+**FR4: 后端业务逻辑实现**
+- 订单处理流程：下单、支付、司机匹配、完成
+- 积分系统业务逻辑：积分规则、兑换机制
+- 实时位置跟踪和状态更新
+- 数据统计和分析功能
+
+**FR5: 管理后台系统**
+- 订单管理：订单监控、状态管理、异常处理
+- 用户管理：用户信息、积分管理、行为分析
+- 运营管理：活动配置、优惠券发放、数据统计
+- 司机管理：司机信息、接单管理、收益统计
 
 ### 详细 rationale (决策依据):
 
-这些需求基于对现有代码的深入分析：
-- **技术选择权衡**: 选择了Hono而不是Express，主要因为Hono RPC提供前后端类型安全
-- **架构决策**: 采用shadcn管理后台模板，专注于提供高质量的管理界面组件
-- **API设计**: 使用@hono/zod-openapi实现自动API文档生成和类型安全
-- **开发效率**: 通用CRUD路由和服务大幅减少重复代码编写
-- **数据验证**: 前后端共享Zod schema确保验证逻辑一致性
+这些需求基于对mini-demo功能分析和现有技术架构的评估：
+- **业务连续性**: 保持mini-demo的核心出行服务功能
+- **技术现代化**: 利用现有Taro + React + Hono技术栈优势
+- **数据完整性**: 基于现有用户管理基础扩展出行业务数据模型
+- **运营需求**: 为商业化运营提供完整的管理后台支持
 
 **关键假设**:
-- 目标用户是需要快速构建管理后台的全栈开发者
-- 主要使用场景是创建企业级管理界面和CRUD操作
-- 开发体验和类型安全是核心价值主张
-- 需要提供生产就绪的认证和权限管理
+- 目标用户是出行服务需求人群和司机/运营人员
+- 主要使用场景是城市内拼车、商务车、包车服务
+- 微信小程序是主要发布平台
+- 需要支持完整的出行服务业务流程
 
 **需要验证的领域**:
-- 这些功能需求是否覆盖了所有重要的业务场景？
-- 是否有遗漏的关键功能？
-- 优先级排序是否合理？
+- 现有用户数据如何迁移到新系统？
+- mini-demo中模拟数据的转换策略？
+- 司机端功能是否需要在MVP中实现？
+- 积分系统的具体规则和兑换机制？
 
 
 
 ### 2.2 非功能性需求
 
-**NFR1: 类型安全和开发体验**
-- 必须提供端到端的类型安全，减少运行时错误
-- 开发环境需要支持热重载和快速迭代
-- 代码提示和自动完成需要完整支持
-- 构建过程应该快速且可靠
-
-**NFR2: 代码质量和可维护性**
-- 遵循一致的代码风格和架构模式
-- 提供清晰的模块边界和接口定义
-- 支持代码复用和组件化开发
-- 文档需要保持与代码同步
-- 通用CRUD路由和服务必须支持自定义路由和服务的扩展
-- **关联查询功能需要保持性能和可维护性**
-
-**NFR3: 安全性和认证**
-- 实现基于JWT的安全认证机制
-- 提供角色基础的权限控制(RBAC)
-- 输入验证必须使用Zod schema
-- 防止常见Web安全漏洞(XSS, CSRF等)
-
-**NFR4: 性能和可扩展性**
-- API响应时间应该在100ms以内
-- 支持数据库连接池和性能优化
-- 前端打包需要优化加载性能
-- 架构应该支持水平扩展
-
-**NFR5: 文档和开发者体验**
-- 自动生成完整的API文档
-- 提供清晰的使用示例和教程
-- 错误信息应该具有指导性
-- 配置过程应该简单直观
+**NFR1: 性能和响应速度**
+- 页面加载时间 < 2秒，API响应时间 < 500ms
+- 支持实时位置更新和状态同步
+- 数据库查询优化，支持高并发访问
+- 前端资源优化，减少首屏加载时间
+
+**NFR2: 可靠性和稳定性**
+- 订单处理流程必须保证数据一致性
+- 支付系统需要99.9%的可用性
+- 支持事务处理和异常恢复
+- 系统监控和告警机制
+
+**NFR3: 安全性和数据保护**
+- 用户数据加密存储和传输
+- 支付信息安全保护
+- 防止SQL注入和XSS攻击
+- 用户隐私数据合规处理
+
+**NFR4: 可扩展性和维护性**
+- 模块化架构，支持功能扩展
+- 清晰的代码结构和文档
+- 自动化测试覆盖核心业务逻辑
+- 支持灰度发布和回滚
+
+**NFR5: 用户体验和易用性**
+- 直观的操作流程和界面设计
+- 错误提示和引导信息清晰
+- 支持离线操作和网络异常处理
+- 多端体验一致性
 
 ### 详细 rationale (决策依据):
 
-这些非功能性需求反映了项目的核心价值主张：
-- **类型安全优先**: 选择Hono RPC和Zod是为了最大化开发效率和减少错误
-- **开发者体验**: shadcn模板和通用CRUD服务专注于提升开发速度
-- **扩展性设计**: 通用CRUD服务支持自定义路由和服务扩展，平衡便利性和灵活性
-- **生产就绪**: 包含认证、权限、安全等企业级功能
-- **文档自动化**: @hono/zod-openapi确保文档与代码同步
+这些非功能性需求基于出行服务业务特点：
+- **性能关键**: 出行服务需要快速响应和实时更新
+- **可靠性优先**: 订单和支付系统必须稳定可靠
+- **安全合规**: 用户数据和支付信息需要严格保护
+- **扩展需求**: 业务增长需要系统能够水平扩展
 
 **技术约束**:
-- 必须保持与现有shadcn设计系统的兼容性
-- 需要支持PostgreSQL关系型数据库
-- 前端构建基于Vite，后端基于Hono
-- 部署环境支持Docker容器化
+- 必须兼容微信小程序平台限制
+- 支持PostgreSQL关系型数据库
+- 基于现有Taro + Hono技术栈
+- 多八多云端开发容器环境部署
 
 ### 3.2 集成策略
 
 **数据库集成策略**:
-- 使用TypeORM实体定义数据模型
-- **支持复杂的关联查询和关系映射**
-- 支持数据库迁移和版本控制
-- 实现连接池管理优化性能
-- 提供事务支持和数据一致性保证
+- 基于现有TypeORM实体扩展出行业务数据模型
+- 支持订单、乘客、积分等复杂业务关系
+- 数据库迁移和版本控制
+- 连接池管理和性能优化
 
 **API集成策略**:
-- RESTful API设计遵循OpenAPI规范
+- RESTful API设计，支持微信小程序调用
 - Hono RPC确保前后端类型安全
 - 统一的错误处理和响应格式
-- 支持API版本管理(v1前缀)
-- **通用CRUD服务支持关联查询参数**
+- 第三方服务集成：微信支付、地图服务
 
 **前端集成策略**:
-- shadcn UI组件库提供一致的设计语言
-- React Query管理服务端状态
-- 基于Zod的表单验证和类型安全
-- 响应式设计支持多种设备
-- **关联数据的高效渲染和处理**
+- Taro多端框架，支持微信小程序和H5
+- 统一的UI组件库和设计规范
+- 状态管理和数据流优化
+- 微信小程序API集成
 
 
 
@@ -199,124 +187,144 @@ D8D Starter已经具备优秀的技术基础：
 
 ### 5.1 Epic方法
 
-**Epic结构决策**: 多Epic并行结构 - 针对不同关注点分别优化
+**Epic结构决策**: 按业务领域划分Epic - 针对出行服务不同业务模块分别开发
 
 **决策依据**:
-- 项目已经具备完整的技术基础架构
-- 不同功能领域有明确的优化目标和优先级
+- 项目需要从演示原型转化为完整产品
+- 不同业务模块有明确的依赖关系和优先级
 - 独立Epic便于并行开发和专门团队负责
-- 每个Epic有明确的成功标准和验收指标
+- 每个Epic对应一个完整的业务功能模块
 
 ### 5.2 Epic详情
 
-**Epic 001: 测试基础设施搭建**
-**Epic目标**: 为现有项目建立完整的测试基础设施，包括单元测试、集成测试和端到端测试，确保代码质量和可维护性。
-**成功标准**: 测试覆盖率达标（单元测试 > 70%, 集成测试 > 50%），CI/CD流水线集成测试执行正常，数据库备份恢复机制完善
+**Epic 001: 前端页面迁移和基础框架**
+**Epic目标**: 将mini-demo的16个页面迁移到Taro + React技术栈，建立统一的前端架构和组件库。
+**成功标准**: 所有页面功能完整迁移，UI组件库建立，多端发布支持正常
 
-**Epic 002: 用户管理界面现代化增强**
-**Epic目标**: 优化现有用户管理界面的用户体验和功能完整性，使其更符合现代Web应用标准。
-**成功标准**: 用户管理操作效率提升30%，界面响应时间保持在200ms以内
+**Epic 002: 用户和会员系统**
+**Epic目标**: 基于现有用户管理基础，扩展积分、优惠券等会员功能，支持微信小程序登录。
+**成功标准**: 用户注册登录流程完整，积分系统正常运行，优惠券功能可用
 
-**Epic 003: Lint配置集成**
-**Epic目标**: 集成完整的ESLint代码质量检查配置，确保代码风格一致性和质量规范。
-**成功标准**: ESLint配置能够正确检查所有.ts和.tsx文件，修复现有代码中的lint错误
+**Epic 003: 出行服务核心功能**
+**Epic目标**: 实现路线查询、订单管理、乘客管理、支付集成等核心出行服务功能。
+**成功标准**: 用户能够完成从查询到支付的完整出行流程，订单数据正确存储
 
-**Epic 004: API实际请求测试增强**
-**Epic目标**: 为现有API系统添加实际HTTP请求测试，验证系统在真实数据库环境下的行为。
-**成功标准**: 所有核心API端点都有实际请求测试，测试通过率100%
+**Epic 004: 管理后台系统**
+**Epic目标**: 构建运营管理后台，支持订单管理、用户管理、数据统计等运营功能。
+**成功标准**: 管理后台功能完整，运营人员能够正常进行日常管理操作
 
 ### 5.3 各Epic用户故事概览
 
-**Epic 001 - 测试基础设施**:
-- 基础单元测试框架搭建
-- 集成测试环境配置
-- 端到端测试流水线
-- 数据库备份和恢复工具集成
-
-**Epic 002 - 用户管理增强**:
-- 用户搜索和过滤功能
-- 批量操作支持
-- 用户详情页优化
-
-**Epic 003 - Lint配置**:
-- ESLint基础框架配置
-- Prettier和代码格式化集成
-- 开发工作流集成和问题修复
-
-**Epic 004 - API实际测试**:
-- 实际请求测试基础设施
-- 用户API实际请求测试实现
-- CI/CD流水线集成
+**Epic 001 - 前端页面迁移**:
+- 首页和路线查询页面迁移
+- 订单相关页面迁移（下单、支付、订单列表、详情）
+- 积分商城和个人中心页面迁移
+- 乘客管理和优惠券页面迁移
+- 统一的UI组件库建设
+
+**Epic 002 - 用户和会员系统**:
+- 微信小程序登录注册功能
+- 积分获取和使用规则实现
+- 优惠券发放和使用功能
+- 会员等级和权益管理
+
+**Epic 003 - 出行服务核心功能**:
+- 路线查询和班次列表功能
+- 订单创建、支付、状态管理
+- 乘客信息管理和常用乘客
+- 微信支付集成和回调处理
+
+**Epic 004 - 管理后台系统**:
+- 订单管理和监控功能
+- 用户管理和行为分析
+- 运营数据统计和报表
+- 司机管理和收益统计
 
 ## 6. 成功指标和验收标准
 
 ### 6.1 关键绩效指标(KPI)
 
-**Epic 001 - 测试基础设施指标**:
-- ✅ 单元测试覆盖率 > 70%
-- ✅ 集成测试覆盖率 > 50%
-- ✅ CI/CD测试流水线执行成功率 100%
-- ⏱️ 测试执行时间优化在可接受范围内
-- 💾 数据库备份恢复测试通过率 100%
-
-**Epic 002 - 用户管理增强指标**:
-- ⚡ 用户管理操作效率提升 30%
-- ⏱️ 界面响应时间 < 200ms (p95)
-- 📊 用户搜索和过滤功能使用率 > 80%
-- 👍 用户满意度评分 > 4/5
-
-**Epic 003 - Lint配置指标**:
-- ✅ ESLint错误修复率 100%
-- 🔧 代码风格一致性达到 95%
-- 📝 开发工作流集成完成度 100%
-- 🚀 开发效率提升（减少代码审查时间）
-
-**Epic 004 - API实际测试指标**:
-- ✅ 核心API端点测试覆盖率 100%
-- ✅ 实际请求测试通过率 100%
-- 🐛 生产环境缺陷减少 50%
-- 🔄 测试数据管理自动化程度 100%
-
-**总体项目指标**:
-- 📚 文档完整性：API文档覆盖率达到100%
-- 🚀 项目使用率：内部项目采用率>60%
-- 📈 功能完成度：PRD需求实现率100%
+**Epic 001 - 前端页面迁移指标**:
+- ✅ 16个页面完整迁移，功能测试通过率100%
+- ⚡ 页面加载时间 < 2秒，API响应时间 < 500ms
+- 🎨 UI组件库建立，设计一致性达到95%
+- 📱 多端发布支持正常（微信小程序、H5）
+
+**Epic 002 - 用户和会员系统指标**:
+- 👥 用户注册登录成功率 > 99%
+- 💰 积分系统正常运行，积分获取和使用记录准确
+- 🎫 优惠券功能可用，发放和使用流程完整
+- 🔐 微信小程序登录集成正常
+
+**Epic 003 - 出行服务核心功能指标**:
+- 🚗 路线查询准确率 > 95%
+- 📦 订单创建到支付完成转化率 > 85%
+- 💳 微信支付集成正常，支付成功率 > 98%
+- 👥 乘客信息管理功能完整
+
+**Epic 004 - 管理后台系统指标**:
+- 📊 订单管理功能完整，监控数据准确
+- 👤 用户管理功能正常，行为分析可用
+- 📈 运营数据统计报表生成正常
+- 🚕 司机管理基础功能实现
+
+**总体业务指标**:
+- 📈 **用户增长**: 3个月内达到1000名注册用户
+- 💰 **收入目标**: 6个月内实现月订单收入10,000元
+- 🔄 **用户留存**: 30天用户留存率达到40%
+- ⚡ **订单转化**: 首页到下单转化率达到15%
 
 ### 6.2 验收标准
 
 **项目级验收**:
-- 所有功能需求和非功能需求实现
-- 文档完整且与代码同步
-- 测试覆盖率达到目标
-- 性能指标满足要求
-- 安全审计通过
+- 所有16个页面功能完整迁移并测试通过
+- 用户能够完成从查询路线到支付完成的完整出行流程
+- 核心业务数据能够正确存储和展示
+- 管理后台能够处理基本的订单和用户管理
+- 系统稳定运行，无明显性能问题
 
 **阶段性验收**:
-- 每个用户故事完成后进行代码审查
-- 每周演示进度和获取反馈
-- 每月进行整体质量评估
+- 每个Epic完成后进行功能演示和用户测试
+- 每周演示进度和获取业务反馈
+- 每月进行整体质量评估和业务指标检查
+- MVP完成后进行上线前综合测试
 
 ## 7. 附录
 
 ### 7.1 参考资料
-- 现有架构文档: `docs/brownfield-architecture.md`
-- Hono框架文档: https://hono.dev
-- Zod验证库: https://zod.dev
-- shadcn/ui组件库: https://ui.shadcn.com
+- 项目简报: `docs/brief.md`
+- mini-demo项目: `./mini-demo/`
+- mini项目: `./mini/`
+- src后端项目: `./src/`
 
 ### 7.2 相关文档
+- 技术架构文档: `docs/architecture.md`
 - API文档: 通过 `/ui` 端点访问
 - 开发指南: `docs/development.md`
 - 部署指南: `docs/deployment.md`
-- 贡献指南: `docs/contributing.md`
 
 ### 7.3 联系方式
 - 产品负责人: [待指定]
 - 技术负责人: [待指定]
 - 开发团队: [待指定]
 
+### 7.4 项目约束和假设
+
+**约束**:
+- 预算：基于现有开发资源，无额外预算
+- 时间线：MVP在4-6周内完成
+- 资源：现有开发团队，无额外人员
+- 技术：必须兼容微信小程序平台
+
+**关键假设**:
+- Taro框架能够满足出行小程序的功能需求
+- 现有后端架构能够扩展支持出行业务
+- 微信支付接口能够正常集成
+- 用户接受新的界面设计和交互方式
+- 市场对出行服务有持续需求
+
 ---
 
 **文档状态**: 已更新
-**最后更新**: 2025-09-17
-**下次评审**: 2025-09-24
+**最后更新**: 2025-10-15
+**下次评审**: 2025-10-22