📝 docs(brief): 更新项目简报内容

- 重命名项目为"mini-demo 页面迁移项目"
- 更新产品概念，明确迁移目标和范围
- 调整问题陈述，反映当前演示版本的局限性
- 扩展目标用户群体，增加出行用户和运营人员
- 新增业务目标和成功指标，包括用户增长和订单转化
- 细化MVP功能范围，明确核心业务流程
- 添加技术架构说明，包括前后端技术栈
- 新增附录部分，包含功能分析和项目现状调研
- 调整下一步行动计划，聚焦迁移实施细节

docs/brief.md

@@ -1,220 +1,260 @@
-# Project Brief: shadcn全栈管理后台启动模板
+# Project Brief: mini-demo 页面迁移项目
 
 ## Executive Summary
 
-**项目名称：** shadcn全栈管理后台启动模板
+**项目名称：** mini-demo 页面迁移项目
 
-**产品概念：** 一个基于shadcn/ui的全栈管理后台启动模板，提供预配置的用户管理系统、通用CRUD路由和服务，旨在显著减少新项目启动时的重复开发工作。
+**产品概念：** 将现有的 mini-demo（纯前端出行小程序演示）的功能页面迁移到 mini 项目中，并基于 src 目录构建完整的后端和管理后台系统。
 
 **解决的主要问题：**
-- 新项目开发中重复的基础架构搭建工作
-- 缺乏标准化的管理后台起点
-- 开发团队在项目初期需要反复实现相同的核心功能
+- mini-demo 目前只是一个纯前端演示，缺乏真实的后端支持
+- 无数据持久化，用户信息、订单数据无法保存
+- 缺乏业务逻辑，没有真实的订单处理、支付、司机匹配等核心功能
+- 技术栈限制，基于微信原生开发，扩展性和维护性有限
 
 **目标市场：**
-- 中小型软件开发团队
-- 全栈开发者
-- 需要快速启动管理后台项目的创业公司
+- 出行服务小程序用户
+- 需要拼车、商务车、包车等出行需求的个人用户
+- 提供出行服务的司机和运营人员
 
-**核心价值主张：** 提供开箱即用的专业级管理后台基础架构，让开发团队能够专注于业务逻辑而非重复的基础设施建设。
+**核心价值主张：** 通过迁移和重构，将演示原型转化为功能完整的出行服务平台，具备用户管理、订单处理、司机管理、积分商城等完整业务功能。
 
 ## Problem Statement
 
 **当前状态和痛点：**
 
-在新项目开发中，特别是管理后台类项目，开发团队面临以下挑战：
+mini-demo 作为一个出行服务小程序演示，目前存在以下核心问题：
 
-1. **重复劳动严重** - 每个新项目都需要重新实现用户认证、权限管理、基础CRUD操作等通用功能
-2. **开发效率低下** - 项目初期大量时间花费在基础设施搭建而非业务逻辑开发上
-3. **代码质量不一致** - 不同开发者实现的相同功能存在质量差异，缺乏统一标准
-4. **维护成本高** - 分散的实现方式导致后续维护和升级困难
-5. **学习曲线陡峭** - 新成员需要时间熟悉项目特有的基础架构
+1. **纯前端演示** - 仅有前端界面，所有数据都是模拟的，无法作为真实产品使用
+2. **无数据持久化** - 用户信息、订单数据、积分记录等无法保存，重启即丢失
+3. **缺乏业务逻辑** - 没有真实的订单处理、支付流程、司机匹配等核心功能
+4. **技术栈限制** - 基于微信原生开发，扩展性和维护性有限
+5. **无管理后台** - 无法进行司机管理、订单监控、运营分析等后台操作
 
 **问题影响：**
-- 项目启动时间延长30-50%
-- 开发团队生产力受到基础工作的拖累
-- 技术债务从项目初期就开始积累
-- 团队难以专注于核心业务价值创造
+- 无法作为真实产品上线运营
+- 用户体验不完整，无法完成完整的出行服务流程
+- 技术债务积累，难以迭代和维护
+- 缺乏运营管理能力，无法进行商业化运营
 
 **现有解决方案的不足：**
-- 通用后台框架过于臃肿，包含大量不需要的功能
-- 现有模板缺乏现代化技术栈整合（如shadcn/ui + 全栈架构）
-- 大多数模板只提供前端或后端，缺乏完整的全栈解决方案
-- 定制化程度不够，难以适应具体业务需求
+- mini-demo 停留在原型阶段，无法满足生产环境需求
+- 缺乏完整的业务闭环和数据流
+- 没有真实的后端服务支持
+- 管理功能完全缺失
 
 **紧迫性和重要性：**
-随着数字化转型加速，企业对内部管理系统的需求快速增长，开发团队需要更高效的工具来应对快速变化的市场需求。现在解决这个问题能够显著提升开发团队竞争力。
+出行服务市场需求持续增长，需要快速将演示转化为可运营产品。技术架构需要统一和现代化，以支持后续的业务扩展和功能迭代。
 
 ## Proposed Solution
 
 **核心概念和方法：**
-提供一个精心设计的全栈管理后台启动模板，基于现代化的技术栈组合：shadcn/ui前端 + 类型安全的全栈框架。模板将包含预配置的用户管理系统、认证流程、权限控制和通用CRUD操作。
+将 mini-demo 的 14 个功能页面迁移到 mini 项目（Taro + React 技术栈），并基于 src 目录构建完整的后端 API 和管理后台系统。
 
 **关键差异化因素：**
-1. **技术栈优势** - 结合shadcn/ui的优秀设计系统和现代全栈框架
-2. **开箱即用** - 无需配置即可运行，包含开发环境所需的一切
-3. **模块化设计** - 易于扩展和定制，不强制特定的架构模式
-4. **类型安全** - 前后端完全类型安全，减少运行时错误
-5. **最佳实践** - 内置代码规范、测试配置和部署脚本
+1. **技术现代化** - 从微信原生迁移到 Taro + React，提升开发效率和可维护性
+2. **完整业务闭环** - 构建真实的后端服务，支持完整的出行业务流程
+3. **管理后台** - 提供运营管理界面，支持司机管理、订单监控、用户管理等
+4. **数据持久化** - 基于 PostgreSQL 实现数据存储和业务逻辑
+5. **实时功能** - 支持实时位置跟踪、订单状态更新等实时功能
 
 **成功因素：**
-- 专注于解决具体的痛点（重复劳动）
-- 提供真实可用的代码而非概念验证
-- 保持轻量级，避免框架膨胀
-- 良好的文档和示例
+- 成熟的 Taro 框架支持多端发布
+- 基于 Hono + TypeORM 的现代化后端架构
+- 清晰的业务领域模型和 API 设计
+- 渐进式迁移策略，降低风险
 
 **产品愿景：**
-成为全栈开发者首选的管理后台起点，显著降低项目启动门槛，让团队能够更快地交付业务价值。
+将演示原型转化为功能完整的出行服务平台，为用户提供可靠、便捷、经济的出行服务体验。
 
 ## Target Users
 
-**Primary User Segment: AI编码代理**
-- **技术背景：** 需要结构化、标准化的代码模板来生成一致性高的代码
-- **工作流程：** 基于模板快速生成业务系统代码，减少重复性工作
-- **核心需求：** 预配置的架构、清晰的代码规范、易于扩展的模式
-- **痛点：** 需要为每个项目重新定义基础架构，缺乏标准化起点
-
-**Secondary User Segment: 非专业开发人员**
-- **技术背景：** 基础编程知识，需要低代码/模板化的解决方案
-- **工作流程：** 使用现成模板快速搭建业务系统，专注于业务逻辑配置
-- **核心需求：** 开箱即用、易于理解、最小化配置需求
-- **痛点：** 从零开始搭建系统的复杂性，技术细节的学习成本
+**Primary User Segment: 出行用户**
+- **用户画像：** 需要拼车、商务车、包车等出行服务的个人用户
+- **当前行为：** 通过小程序查找出行路线、预订座位、管理订单
+- **核心需求：**
+  - 便捷的路线查询和预订
+  - 实时订单状态跟踪
+  - 安全的支付体验
+  - 积分奖励和优惠券使用
+- **目标：** 获得可靠、便捷、经济的出行服务
+
+**Secondary User Segment: 司机/运营人员**
+- **用户画像：** 提供出行服务的司机和后台运营人员
+- **当前行为：** 通过管理后台处理订单、管理车辆、监控运营
+- **核心需求：**
+  - 高效的订单分配和管理
+  - 实时位置跟踪和路线规划
+  - 收益统计和分析
+  - 乘客信息管理
+- **目标：** 提高运营效率和服务质量
 
 **目标业务场景：**
-- 数据驱动的业务管理系统
-- 需要大量CRUD操作的企业应用
-- 内部管理工具和后台系统
-- 中小型企业的定制化业务系统
+- 城市内拼车出行服务
+- 商务车专车服务
+- 包车旅游服务
+- 企业员工通勤服务
 
 ## Goals & Success Metrics
 
 ### Business Objectives
-- 建立AI驱动的需求开发自动化流程
-- 通过BMAD方法论实现端到端的开发规范
-- 减少人工干预，提高需求到代码的转换效率
-- 为业务逻辑开发提供标准化框架
+- **用户增长**：3个月内达到 1000 名注册用户
+- **订单转化**：首页到下单转化率达到 15%
+- **用户留存**：30天用户留存率达到 40%
+- **收入目标**：6个月内实现月订单收入 10,000 元
 
 ### User Success Metrics
-- **上手时间：** 新用户30分钟内理解并使用开发流程
-- **任务完成率：** 用户能够成功完成95%的常见开发任务
-- **满意度：** 用户反馈评分4.5/5以上
+- **订单完成率**：用户下单到完成的转化率 > 85%
+- **用户满意度**：用户评价平均分 > 4.5/5
+- **功能使用率**：核心功能（路线查询、下单、支付）使用率 > 70%
+- **响应时间**：页面加载时间 < 2秒，API 响应时间 < 500ms
 
 ### Key Performance Indicators (KPIs)
-- **开发效率提升：** 需求到可运行代码的时间减少50%以上
-- **代码一致性：** AI生成代码与规范符合度达到90%+
-- **人工干预率：** 需要人工修正的代码比例低于10%
-- **需求覆盖度：** 能够处理80%以上的常见业务场景
-- **处理速度：** 单个需求处理时间<5分钟
-- **准确率：** 代码生成准确率>85%
-- **扩展性：** 支持至少10种常见业务模式
-- **稳定性：** 系统可用性99.9%
+- **DAU/MAU**：日活跃用户/月活跃用户比率 > 30%
+- **订单量**：日均订单数量达到 50 单
+- **客单价**：平均订单金额 > 50 元
+- **复购率**：30天内重复下单用户比例 > 25%
 
 ## MVP Scope
 
 ### Core Features (Must Have)
-- **用户管理系统**
-  - 用户注册、登录、认证
-  - 基本的用户信息管理
-  - 权限和角色管理基础框架
-
-- **通用CRUD路由及服务**
-  - 标准化的CRUD操作接口
-  - 统一的数据验证和错误处理
-  - 类型安全的API设计
-
-- **关联查询支持**
-  - 基础的表关联查询功能
-  - 标准化的关联数据处理模式
-  - 查询性能优化基础
-
-- **用户操作跟踪**
-  - 基本的操作日志记录
-  - 用户行为追踪框架
-  - 审计日志基础功能
+- **首页**：路线查询、热门路线推荐、活动展示
+- **订单管理**：订单列表、订单详情、订单状态跟踪
+- **用户中心**：个人信息、积分管理、优惠券
+- **积分商城**：积分兑换、商品展示
+- **乘客管理**：常用乘客信息管理
+- **基础支付**：微信支付集成
 
 ### Out of Scope for MVP
-- 高级权限管理系统
-- 复杂的数据分析功能
-- 第三方服务集成
-- 高级报表和仪表板
-- 移动端适配
-- 多语言支持
-- 高级缓存策略
+- **高级推荐算法**：基于用户行为的个性化推荐
+- **多语言支持**：国际化功能
+- **复杂营销活动**：复杂的优惠券和促销系统
+- **司机端独立应用**：专门的司机端小程序
+- **高级数据分析**：复杂的运营数据分析和报表
 
 ### MVP Success Criteria
-- 能够处理80%的基础业务CRUD需求
-- 开发新实体时间减少70%以上
-- 代码生成准确率达到85%
-- 系统稳定运行无重大故障
+- 用户能够完成从查询路线到支付完成的完整出行流程
+- 核心业务数据能够正确存储和展示
+- 管理后台能够处理基本的订单和用户管理
+- 系统稳定运行，无明显性能问题
+
+## Post-MVP Vision
+
+### Phase 2 Features
+- **司机端功能**：专门的司机端小程序，支持接单、路线导航
+- **实时位置跟踪**：订单实时位置共享和跟踪
+- **智能推荐**：基于历史行为的路线和司机推荐
+- **会员体系**：会员等级和专属权益
+- **客服系统**：在线客服和问题反馈
+
+### Long-term Vision
+- **多平台支持**：扩展到 H5、App 等多端
+- **业务扩展**：扩展到货运、旅游包车等更多出行场景
+- **生态建设**：构建出行服务生态，接入更多服务提供商
+- **智能化运营**：基于 AI 的智能调度和运营优化
+
+### Expansion Opportunities
+- **企业服务**：为企业提供定制化出行解决方案
+- **跨城服务**：扩展到跨城市的长途出行服务
+- **增值服务**：保险、餐饮、住宿等配套服务
+- **数据服务**：出行数据分析和行业洞察
 
 ## Technical Considerations
 
 ### Platform Requirements
-- **Target Platforms:** Web应用，支持现代浏览器（Chrome, Firefox, Safari, Edge最新版本）
-- **Browser/OS Support:** Node.js 18+ 环境，支持Docker容器化部署
-- **Performance Requirements:** API响应时间<200ms (p95)，并发支持100+用户，复杂查询<1s
+- **目标平台**：微信小程序为主要发布平台
+- **浏览器/系统支持**：兼容主流微信版本和手机系统
+- **性能要求**：支持实时位置更新，API 响应时间 < 500ms
 
 ### Technology Preferences
-- **Frontend:** React + TypeScript，shadcn/ui组件库，Vite构建工具
-- **Backend:** Node.js + TypeScript，Express/NestJS框架
-- **Database:** TypeORM/Prisma ORM，PostgreSQL，Redis缓存
-- **Hosting/Infrastructure:** Docker容器化，Kubernetes就绪，云原生架构
+- **前端**：Taro + React + TypeScript + TailwindCSS
+- **后端**：Hono + TypeORM + PostgreSQL + Redis
+- **数据库**：PostgreSQL 17（已配置）
+- **部署/基础设施**：多八多云端开发容器环境
 
 ### Architecture Considerations
-- **Repository Structure:** 单体仓库(monorepo)设计，前后端分离但统一管理
-- **Service Architecture:** 模块化设计，支持微服务扩展，插件架构支持自定义扩展
-- **Integration Requirements:** RESTful API设计，GraphQL就绪，WebSocket支持
-- **Security/Compliance:** JWT认证，RBAC权限控制，数据加密，审计日志
+- **仓库结构**：保持现有的三目录结构（mini-demo、mini、src）
+- **服务架构**：前后端分离，RESTful API 设计
+- **集成需求**：微信支付、地图服务、消息推送
+- **安全/合规**：用户数据保护、支付安全、API 认证
 
 ## Constraints & Assumptions
 
 ### Constraints
-- **Budget:** 基于现有云端开发环境，无额外基础设施成本
-- **Timeline:** 3个月实现核心MVP，6个月达到生产就绪
-- **Resources:** 现有开发团队，基于多八多云端容器环境
-- **Technical:** 必须兼容Node.js 20.18.3，PostgreSQL 15，Redis 7，MinIO存储
+- **预算**：基于现有开发资源，无额外预算
+- **时间线**：MVP 在 4-6 周内完成
+- **资源**：现有开发团队，无额外人员
+- **技术**：必须兼容微信小程序平台
 
 ### Key Assumptions
-- 开发环境和生产环境配置一致性能够简化部署
-- 现有技术栈能够满足BMAD方法论的技术需求
-- AI驱动开发流程能够在该技术栈上有效实现
-- 团队具备足够的TypeScript和全栈开发经验
-- 云端容器环境稳定可用
-- 数据库和存储服务性能满足需求
-- 网络延迟在可接受范围内
-- 安全配置符合企业标准
+- Taro 框架能够满足出行小程序的功能需求
+- 现有后端架构能够扩展支持出行业务
+- 微信支付接口能够正常集成
+- 用户接受新的界面设计和交互方式
+- 市场对出行服务有持续需求
 
 ## Risks & Open Questions
 
 ### Key Risks
-- **技术栈复杂性风险：** Hono框架 + TypeORM + React组合相对较新，社区支持可能不如传统组合成熟
-- **AI集成风险：** BMAD方法论与现有技术栈的集成可能遇到兼容性问题
-- **性能风险：** TypeORM在复杂关联查询下的性能需要验证
-- **安全风险：** JWT认证和权限系统的实现需要严格的安全审计
+- **技术风险**：Taro 框架在复杂业务场景下的稳定性
+- **业务风险**：出行业务模型的市场接受度
+- **集成风险**：第三方服务（微信支付、地图）的稳定性
+- **性能风险**：实时位置跟踪对系统性能的影响
 
 ### Open Questions
-- Hono框架与BMAD方法论的适配程度需要进一步验证
-- TypeORM在多数据库场景下的迁移策略
-- 前端状态管理（React Query）与后端缓存的一致性
-- 实时功能（WebSocket）与现有架构的集成方式
+- 现有用户数据如何迁移到新系统？
+- 如何处理 mini-demo 中模拟数据的转换？
+- 司机端功能是否需要在 MVP 中实现？
+- 积分系统的具体规则和兑换机制？
 
 ### Areas Needing Further Research
-- Hono框架的最佳实践和性能优化
-- TypeORM高级特性（数据迁移、查询优化）
-- React Server Components与现有架构的兼容性
-- 微服务拆分策略和时机
+- 微信小程序在出行服务领域的最佳实践
+- 实时位置跟踪的技术方案和性能优化
+- 出行服务的合规要求和资质认证
+- 竞品分析和差异化策略
+
+## 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. 建立开发环境和工具链
-3. 制定详细的开发计划和时间表
-4. 组建核心开发团队并分配角色
-5. 建立代码规范和开发流程
+1. **详细功能分析**：深入分析每个页面的业务逻辑和数据需求
+2. **API 设计**：设计完整的后端 API 接口规范
+3. **数据模型设计**：设计数据库表和实体关系
+4. **页面迁移计划**：制定具体的页面迁移顺序和优先级
+5. **开发环境配置**：配置完整的开发、测试、生产环境
+6. **开发实施**：按照优先级逐步实施迁移和开发
+7. **测试验证**：功能测试、性能测试、用户体验测试
+8. **部署上线**：部署到生产环境并监控运行状态
 
 ### PM Handoff
 
-This Project Brief provides the full context for shadcn全栈管理后台启动模板. Please start in 'PRD Generation Mode', review the brief thoroughly to work with the user to create the PRD section by section as the template indicates, asking for any necessary clarification or suggesting improvements.
+此项目简报为 mini-demo 页面迁移项目提供了完整的上下文。请从 'PRD 生成模式' 开始，彻底审阅此简报，与用户协作按模板指示逐节创建 PRD，询问任何必要的澄清或建议改进。
+
+---
 
-**项目已就绪，可以开始PRD生成流程。**
+*项目简报创建完成时间：2025-10-15*
+*分析师：Mary 📊*