|
|
@@ -1,220 +1,227 @@
|
|
|
-# Project Brief: shadcn全栈管理后台启动模板
|
|
|
+# Project Brief: 展会AR徽章收集小程序
|
|
|
|
|
|
## Executive Summary
|
|
|
|
|
|
-**项目名称:** shadcn全栈管理后台启动模板
|
|
|
+**项目名称:** 展会AR徽章收集小程序
|
|
|
|
|
|
-**产品概念:** 一个基于shadcn/ui的全栈管理后台启动模板,提供预配置的用户管理系统、通用CRUD路由和服务,旨在显著减少新项目启动时的重复开发工作。
|
|
|
+**产品概念:** 一个基于AR技术的展会互动小程序,通过扫描文物展品、参与知识问答和共创活动来收集虚拟徽章,增强展会参与体验和文物知识传播。
|
|
|
|
|
|
**解决的主要问题:**
|
|
|
-- 新项目开发中重复的基础架构搭建工作
|
|
|
-- 缺乏标准化的管理后台起点
|
|
|
-- 开发团队在项目初期需要反复实现相同的核心功能
|
|
|
+- 传统展会参观体验单一,缺乏互动性
|
|
|
+- 文物知识传播方式枯燥,难以吸引年轻观众
|
|
|
+- 缺乏数字化互动手段来提升展会参与度
|
|
|
+- 参观者难以系统性地了解展品信息
|
|
|
|
|
|
**目标市场:**
|
|
|
-- 中小型软件开发团队
|
|
|
-- 全栈开发者
|
|
|
-- 需要快速启动管理后台项目的创业公司
|
|
|
+- 博物馆、艺术展览馆
|
|
|
+- 文化传承类展会
|
|
|
+- 教育性展览活动
|
|
|
+- 文化旅游推广活动
|
|
|
|
|
|
-**核心价值主张:** 提供开箱即用的专业级管理后台基础架构,让开发团队能够专注于业务逻辑而非重复的基础设施建设。
|
|
|
+**核心价值主张:** 通过AR技术和游戏化设计,将传统展会转变为沉浸式互动体验,让参观者在趣味游戏中学习文物知识,提升文化传播效果。
|
|
|
|
|
|
## Problem Statement
|
|
|
|
|
|
**当前状态和痛点:**
|
|
|
|
|
|
-在新项目开发中,特别是管理后台类项目,开发团队面临以下挑战:
|
|
|
+在传统展会和文化展览活动中,参观体验面临以下挑战:
|
|
|
|
|
|
-1. **重复劳动严重** - 每个新项目都需要重新实现用户认证、权限管理、基础CRUD操作等通用功能
|
|
|
-2. **开发效率低下** - 项目初期大量时间花费在基础设施搭建而非业务逻辑开发上
|
|
|
-3. **代码质量不一致** - 不同开发者实现的相同功能存在质量差异,缺乏统一标准
|
|
|
-4. **维护成本高** - 分散的实现方式导致后续维护和升级困难
|
|
|
-5. **学习曲线陡峭** - 新成员需要时间熟悉项目特有的基础架构
|
|
|
+1. **互动性不足** - 传统展品展示方式单向,缺乏观众参与和互动
|
|
|
+2. **知识传播效果有限** - 文字说明和讲解难以吸引年轻观众,知识留存率低
|
|
|
+3. **体验同质化** - 不同展会参观体验相似,缺乏独特性和记忆点
|
|
|
+4. **数字化程度低** - 缺乏利用移动设备增强体验的技术手段
|
|
|
+5. **数据收集困难** - 难以量化参观者行为和兴趣偏好
|
|
|
|
|
|
**问题影响:**
|
|
|
-- 项目启动时间延长30-50%
|
|
|
-- 开发团队生产力受到基础工作的拖累
|
|
|
-- 技术债务从项目初期就开始积累
|
|
|
-- 团队难以专注于核心业务价值创造
|
|
|
+- 年轻观众参与度低,文化传承面临断层风险
|
|
|
+- 展会吸引力下降,影响参观人数和传播效果
|
|
|
+- 缺乏有效的观众行为数据分析
|
|
|
+- 传统展示方式难以适应数字化时代需求
|
|
|
|
|
|
**现有解决方案的不足:**
|
|
|
-- 通用后台框架过于臃肿,包含大量不需要的功能
|
|
|
-- 现有模板缺乏现代化技术栈整合(如shadcn/ui + 全栈架构)
|
|
|
-- 大多数模板只提供前端或后端,缺乏完整的全栈解决方案
|
|
|
-- 定制化程度不够,难以适应具体业务需求
|
|
|
+- 简单的二维码扫描功能过于基础,缺乏趣味性
|
|
|
+- 独立的AR应用下载门槛高,用户使用意愿低
|
|
|
+- 缺乏完整的游戏化机制和社交互动功能
|
|
|
+- 大多数方案只关注技术展示,忽视内容传播
|
|
|
|
|
|
**紧迫性和重要性:**
|
|
|
-随着数字化转型加速,企业对内部管理系统的需求快速增长,开发团队需要更高效的工具来应对快速变化的市场需求。现在解决这个问题能够显著提升开发团队竞争力。
|
|
|
+随着年轻一代对数字化体验的需求增长,传统文化机构需要创新展示方式来吸引新观众。AR技术和游戏化设计能够有效提升文化传播效果,现在解决这个问题对于文化传承具有重要意义。
|
|
|
|
|
|
## Proposed Solution
|
|
|
|
|
|
**核心概念和方法:**
|
|
|
-提供一个精心设计的全栈管理后台启动模板,基于现代化的技术栈组合:shadcn/ui前端 + 类型安全的全栈框架。模板将包含预配置的用户管理系统、认证流程、权限控制和通用CRUD操作。
|
|
|
+开发一个小程序形式的AR徽章收集系统,包含四大功能模块:AR扫描基础、徽章收集任务、社交互动和奖励机制。通过游戏化设计让参观者在互动中学习文物知识。
|
|
|
|
|
|
**关键差异化因素:**
|
|
|
-1. **技术栈优势** - 结合shadcn/ui的优秀设计系统和现代全栈框架
|
|
|
-2. **开箱即用** - 无需配置即可运行,包含开发环境所需的一切
|
|
|
-3. **模块化设计** - 易于扩展和定制,不强制特定的架构模式
|
|
|
-4. **类型安全** - 前后端完全类型安全,减少运行时错误
|
|
|
-5. **最佳实践** - 内置代码规范、测试配置和部署脚本
|
|
|
+1. **多层次徽章系统** - 普通徽章(扫描文物)、特色徽章(知识问答)、稀有徽章(共创活动)
|
|
|
+2. **AR技术集成** - 内置文物定位地图,精准识别展品
|
|
|
+3. **社交互动功能** - 徽章集市交换、现场对对碰、社交平台分享
|
|
|
+4. **实体奖励激励** - 集齐徽章兑换实体AR透卡和专属印章
|
|
|
|
|
|
**成功因素:**
|
|
|
-- 专注于解决具体的痛点(重复劳动)
|
|
|
-- 提供真实可用的代码而非概念验证
|
|
|
-- 保持轻量级,避免框架膨胀
|
|
|
-- 良好的文档和示例
|
|
|
+- 低门槛参与(小程序形式,无需下载)
|
|
|
+- 渐进式难度设计(从简单扫描到深度互动)
|
|
|
+- 社交传播机制(分享稀有徽章)
|
|
|
+- 实体奖励激励(增强成就感)
|
|
|
|
|
|
**产品愿景:**
|
|
|
-成为全栈开发者首选的管理后台起点,显著降低项目启动门槛,让团队能够更快地交付业务价值。
|
|
|
+成为文化展会数字化转型的标准解决方案,通过趣味互动提升文化传播效果,让传统文化以现代方式触达年轻观众。
|
|
|
|
|
|
## Target Users
|
|
|
|
|
|
-**Primary User Segment: AI编码代理**
|
|
|
-- **技术背景:** 需要结构化、标准化的代码模板来生成一致性高的代码
|
|
|
-- **工作流程:** 基于模板快速生成业务系统代码,减少重复性工作
|
|
|
-- **核心需求:** 预配置的架构、清晰的代码规范、易于扩展的模式
|
|
|
-- **痛点:** 需要为每个项目重新定义基础架构,缺乏标准化起点
|
|
|
+**Primary User Segment: 展会参观者(年轻观众)**
|
|
|
+- **年龄范围:** 18-35岁,对新技术和互动体验感兴趣
|
|
|
+- **技术背景:** 智能手机熟练用户,熟悉小程序操作
|
|
|
+- **行为特征:** 喜欢游戏化体验,乐于在社交媒体分享
|
|
|
+- **核心需求:** 有趣、便捷、有成就感的参观体验
|
|
|
+- **痛点:** 传统展会枯燥,缺乏参与感和互动性
|
|
|
|
|
|
-**Secondary User Segment: 非专业开发人员**
|
|
|
-- **技术背景:** 基础编程知识,需要低代码/模板化的解决方案
|
|
|
-- **工作流程:** 使用现成模板快速搭建业务系统,专注于业务逻辑配置
|
|
|
-- **核心需求:** 开箱即用、易于理解、最小化配置需求
|
|
|
-- **痛点:** 从零开始搭建系统的复杂性,技术细节的学习成本
|
|
|
+**Secondary User Segment: 展会主办方**
|
|
|
+- **机构类型:** 博物馆、艺术馆、文化展会组织者
|
|
|
+- **业务需求:** 提升参观体验,增加观众参与度,收集参观数据
|
|
|
+- **核心需求:** 易于部署、成本可控、效果可量化的数字化解决方案
|
|
|
+- **痛点:** 缺乏有效的数字化互动工具,难以吸引年轻观众
|
|
|
|
|
|
**目标业务场景:**
|
|
|
-- 数据驱动的业务管理系统
|
|
|
-- 需要大量CRUD操作的企业应用
|
|
|
-- 内部管理工具和后台系统
|
|
|
-- 中小型企业的定制化业务系统
|
|
|
+- 文物艺术展览
|
|
|
+- 传统文化推广活动
|
|
|
+- 教育性博物馆展览
|
|
|
+- 文化旅游节庆活动
|
|
|
|
|
|
## Goals & Success Metrics
|
|
|
|
|
|
### Business Objectives
|
|
|
-- 建立AI驱动的需求开发自动化流程
|
|
|
-- 通过BMAD方法论实现端到端的开发规范
|
|
|
-- 减少人工干预,提高需求到代码的转换效率
|
|
|
-- 为业务逻辑开发提供标准化框架
|
|
|
+- 提升展会参观体验和观众参与度
|
|
|
+- 增强文物知识传播效果和留存率
|
|
|
+- 建立数字化展会互动标准
|
|
|
+- 收集观众行为数据用于优化展览
|
|
|
|
|
|
### User Success Metrics
|
|
|
-- **上手时间:** 新用户30分钟内理解并使用开发流程
|
|
|
-- **任务完成率:** 用户能够成功完成95%的常见开发任务
|
|
|
-- **满意度:** 用户反馈评分4.5/5以上
|
|
|
+- **参与率:** 80%以上参观者使用小程序参与互动
|
|
|
+- **完成率:** 60%以上用户完成至少3个徽章收集
|
|
|
+- **满意度:** 用户反馈评分4.2/5以上
|
|
|
+- **分享率:** 30%以上用户在社交平台分享徽章
|
|
|
|
|
|
### Key Performance Indicators (KPIs)
|
|
|
-- **开发效率提升:** 需求到可运行代码的时间减少50%以上
|
|
|
-- **代码一致性:** AI生成代码与规范符合度达到90%+
|
|
|
-- **人工干预率:** 需要人工修正的代码比例低于10%
|
|
|
-- **需求覆盖度:** 能够处理80%以上的常见业务场景
|
|
|
-- **处理速度:** 单个需求处理时间<5分钟
|
|
|
-- **准确率:** 代码生成准确率>85%
|
|
|
-- **扩展性:** 支持至少10种常见业务模式
|
|
|
-- **稳定性:** 系统可用性99.9%
|
|
|
+- **徽章收集率:** 平均每个用户收集4个以上徽章
|
|
|
+- **知识问答正确率:** 漆艺知识问答平均正确率70%+
|
|
|
+- **社交互动率:** 20%以上用户参与徽章交换
|
|
|
+- **实体奖励兑换率:** 15%以上用户兑换实体AR透卡
|
|
|
+- **用户停留时间:** 平均参观时间延长30%
|
|
|
+- **重复使用率:** 同一用户在不同展区的重复使用率40%+
|
|
|
+- **技术稳定性:** AR识别准确率95%+
|
|
|
+- **系统可用性:** 小程序可用性99.5%
|
|
|
|
|
|
## MVP Scope
|
|
|
|
|
|
### Core Features (Must Have)
|
|
|
-- **用户管理系统**
|
|
|
- - 用户注册、登录、认证
|
|
|
- - 基本的用户信息管理
|
|
|
- - 权限和角色管理基础框架
|
|
|
-
|
|
|
-- **通用CRUD路由及服务**
|
|
|
- - 标准化的CRUD操作接口
|
|
|
- - 统一的数据验证和错误处理
|
|
|
- - 类型安全的API设计
|
|
|
-
|
|
|
-- **关联查询支持**
|
|
|
- - 基础的表关联查询功能
|
|
|
- - 标准化的关联数据处理模式
|
|
|
- - 查询性能优化基础
|
|
|
-
|
|
|
-- **用户操作跟踪**
|
|
|
- - 基本的操作日志记录
|
|
|
- - 用户行为追踪框架
|
|
|
- - 审计日志基础功能
|
|
|
+- **AR扫描基础功能**
|
|
|
+ - 内置文物定位地图
|
|
|
+ - 现场采集文物图作为扫描参照物
|
|
|
+ - 精准AR识别和定位
|
|
|
+ - 普通徽章收集(扫描对应文物获得)
|
|
|
+
|
|
|
+- **徽章收集任务系统**
|
|
|
+ - 特色徽章获取(AR扫描文物+漆艺知识问答)
|
|
|
+ - 稀有徽章获取(共创互动体验区任务)
|
|
|
+ - 徽章展示和管理界面
|
|
|
+ - 收集进度跟踪
|
|
|
+
|
|
|
+- **基础社交互动**
|
|
|
+ - 徽章集市(支持玩家交换徽章)
|
|
|
+ - 现场对对碰交换功能
|
|
|
+ - 稀有徽章社交平台分享
|
|
|
+
|
|
|
+- **奖励兑换系统**
|
|
|
+ - 集齐徽章兑换实体AR透卡
|
|
|
+ - 专属文物纹样印章加盖
|
|
|
+ - 服务台兑换流程
|
|
|
|
|
|
### Out of Scope for MVP
|
|
|
-- 高级权限管理系统
|
|
|
-- 复杂的数据分析功能
|
|
|
-- 第三方服务集成
|
|
|
-- 高级报表和仪表板
|
|
|
-- 移动端适配
|
|
|
+- 复杂的AR特效和3D模型
|
|
|
+- 高级社交功能(好友系统、排行榜)
|
|
|
- 多语言支持
|
|
|
-- 高级缓存策略
|
|
|
+- 离线模式
|
|
|
+- 高级数据分析仪表板
|
|
|
+- 第三方支付集成
|
|
|
+- 复杂的权限管理系统
|
|
|
|
|
|
### MVP Success Criteria
|
|
|
-- 能够处理80%的基础业务CRUD需求
|
|
|
-- 开发新实体时间减少70%以上
|
|
|
-- 代码生成准确率达到85%
|
|
|
-- 系统稳定运行无重大故障
|
|
|
+- AR识别准确率达到90%以上
|
|
|
+- 用户能够顺利完成徽章收集流程
|
|
|
+- 社交分享功能正常工作
|
|
|
+- 奖励兑换流程顺畅
|
|
|
+- 系统在展会期间稳定运行
|
|
|
|
|
|
## 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
|
|
|
+- **Target Platforms:** 微信小程序,支持iOS和Android系统
|
|
|
+- **Browser/OS Support:** 微信小程序环境,Node.js 20.19.2后端服务
|
|
|
+- **Performance Requirements:** AR识别响应时间<2秒,API响应时间<500ms,支持展会期间1000+并发用户
|
|
|
|
|
|
### Technology Preferences
|
|
|
-- **Frontend:** React + TypeScript,shadcn/ui组件库,Vite构建工具
|
|
|
-- **Backend:** Node.js + TypeScript,Express/NestJS框架
|
|
|
-- **Database:** TypeORM/Prisma ORM,PostgreSQL,Redis缓存
|
|
|
-- **Hosting/Infrastructure:** Docker容器化,Kubernetes就绪,云原生架构
|
|
|
+- **Frontend:** 微信小程序原生开发,支持AR识别功能
|
|
|
+- **Backend:** Node.js + TypeScript,Hono框架,PostgreSQL数据库
|
|
|
+- **Database:** TypeORM ORM,PostgreSQL 17,Redis 7缓存
|
|
|
+- **Storage:** MinIO对象存储(d8dai存储桶)
|
|
|
+- **Hosting/Infrastructure:** 多八多云端容器环境,8080端口外网访问
|
|
|
|
|
|
### Architecture Considerations
|
|
|
-- **Repository Structure:** 单体仓库(monorepo)设计,前后端分离但统一管理
|
|
|
-- **Service Architecture:** 模块化设计,支持微服务扩展,插件架构支持自定义扩展
|
|
|
-- **Integration Requirements:** RESTful API设计,GraphQL就绪,WebSocket支持
|
|
|
-- **Security/Compliance:** JWT认证,RBAC权限控制,数据加密,审计日志
|
|
|
+- **Repository Structure:** 单体仓库(monorepo)设计,前后端统一管理
|
|
|
+- **Service Architecture:** 模块化设计,支持展会配置和内容管理
|
|
|
+- **Integration Requirements:** 微信小程序API集成,AR识别SDK,社交分享API
|
|
|
+- **Security/Compliance:** 用户数据隐私保护,展会数据安全存储
|
|
|
|
|
|
## Constraints & Assumptions
|
|
|
|
|
|
### Constraints
|
|
|
- **Budget:** 基于现有云端开发环境,无额外基础设施成本
|
|
|
-- **Timeline:** 3个月实现核心MVP,6个月达到生产就绪
|
|
|
+- **Timeline:** 2个月实现核心MVP,3个月达到展会部署就绪
|
|
|
- **Resources:** 现有开发团队,基于多八多云端容器环境
|
|
|
-- **Technical:** 必须兼容Node.js 20.18.3,PostgreSQL 15,Redis 7,MinIO存储
|
|
|
+- **Technical:** 必须兼容Node.js 20.19.2,PostgreSQL 17,Redis 7,MinIO存储
|
|
|
+- **Platform:** 必须支持微信小程序平台和AR识别功能
|
|
|
|
|
|
### Key Assumptions
|
|
|
-- 开发环境和生产环境配置一致性能够简化部署
|
|
|
-- 现有技术栈能够满足BMAD方法论的技术需求
|
|
|
-- AI驱动开发流程能够在该技术栈上有效实现
|
|
|
-- 团队具备足够的TypeScript和全栈开发经验
|
|
|
-- 云端容器环境稳定可用
|
|
|
-- 数据库和存储服务性能满足需求
|
|
|
-- 网络延迟在可接受范围内
|
|
|
-- 安全配置符合企业标准
|
|
|
+- 微信小程序平台能够满足AR识别功能需求
|
|
|
+- 展会现场网络环境稳定,支持实时AR识别
|
|
|
+- 参观者具备智能手机并熟悉小程序操作
|
|
|
+- 展会主办方能够提供文物图片和知识内容
|
|
|
+- 云端容器环境在展会期间稳定可用
|
|
|
+- AR识别技术在展会光照条件下表现良好
|
|
|
+- 用户愿意参与徽章收集和社交互动
|
|
|
|
|
|
## Risks & Open Questions
|
|
|
|
|
|
### Key Risks
|
|
|
-- **技术栈复杂性风险:** Hono框架 + TypeORM + React组合相对较新,社区支持可能不如传统组合成熟
|
|
|
-- **AI集成风险:** BMAD方法论与现有技术栈的集成可能遇到兼容性问题
|
|
|
-- **性能风险:** TypeORM在复杂关联查询下的性能需要验证
|
|
|
-- **安全风险:** JWT认证和权限系统的实现需要严格的安全审计
|
|
|
+- **AR识别准确性风险:** 展会现场光照、角度变化可能影响识别准确率
|
|
|
+- **网络稳定性风险:** 展会期间大量用户同时使用可能造成网络拥堵
|
|
|
+- **用户体验风险:** AR扫描操作复杂度可能影响用户参与意愿
|
|
|
+- **内容管理风险:** 展会内容更新和维护需要简化流程
|
|
|
|
|
|
### Open Questions
|
|
|
-- Hono框架与BMAD方法论的适配程度需要进一步验证
|
|
|
-- TypeORM在多数据库场景下的迁移策略
|
|
|
-- 前端状态管理(React Query)与后端缓存的一致性
|
|
|
-- 实时功能(WebSocket)与现有架构的集成方式
|
|
|
+- 微信小程序AR识别功能的性能和兼容性
|
|
|
+- 展会现场网络带宽和延迟对AR体验的影响
|
|
|
+- 不同手机型号对AR识别效果的差异
|
|
|
+- 用户数据隐私保护和合规要求
|
|
|
|
|
|
### Areas Needing Further Research
|
|
|
-- Hono框架的最佳实践和性能优化
|
|
|
-- TypeORM高级特性(数据迁移、查询优化)
|
|
|
-- React Server Components与现有架构的兼容性
|
|
|
-- 微服务拆分策略和时机
|
|
|
+- 微信小程序AR SDK的技术限制和最佳实践
|
|
|
+- 展会现场网络优化方案
|
|
|
+- AR识别在不同光照条件下的表现
|
|
|
+- 用户参与度和徽章收集行为的分析模型
|
|
|
|
|
|
## Next Steps
|
|
|
|
|
|
### Immediate Actions
|
|
|
-1. 技术栈深度评估和验证
|
|
|
-2. 建立开发环境和工具链
|
|
|
-3. 制定详细的开发计划和时间表
|
|
|
-4. 组建核心开发团队并分配角色
|
|
|
-5. 建立代码规范和开发流程
|
|
|
+1. 微信小程序AR功能技术验证和原型开发
|
|
|
+2. 展会内容管理系统设计和开发
|
|
|
+3. 徽章系统和用户进度跟踪功能实现
|
|
|
+4. 社交互动和分享功能集成
|
|
|
+5. 展会现场测试和优化
|
|
|
|
|
|
### 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.
|
|
|
+This Project Brief provides the full context for 展会AR徽章收集小程序. 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.
|
|
|
|
|
|
**项目已就绪,可以开始PRD生成流程。**
|