MindGuard 产品需求文档 (PRD)
项目状态: 半成品完善增强 | 版本: v4.0 | 日期: 2025-10-17
文档类型: Brownfield Enhancement PRD | 团队规模: 2-3人 | 预估工期: 4-5周
📋 目录
📖 项目概述和分析
Analysis Source: IDE-based fresh analysis
- 分析来源：IDE中现有项目文件
- 核心文档：CLAUDE.md（项目全景架构文档）
- 项目状态：半成品，需要需求规范化
Current Project State
MindGuard 是一个面向高校场景的心理健康支持微信小程序，当前处于半成品开发状态。
当前实现的核心功能：
- 五个主要Tab页面：今天、任务、树洞、随笔、我的
- 情绪打卡系统和心情轮统计
- 任务管理基础框架
- REBT日记功能基础
- 社区树洞功能基础
- 心语精灵AI对话系统框架
- 徽章系统和护心周报基础
技术栈现状：
- 前端：微信小程序 + TDesign组件库
- 后端：微信云开发 (CloudBase)
- AI集成：Dify工作流
- 数据库：NoSQL数据库
项目成熟度：
- ✅ 架构设计完整
- ✅ 基础功能框架搭建完成
- ⚠️ 功能闭环尚未完全形成
- ⚠️ 用户体验需要打磨
- ⚠️ 需求文档缺乏标准化
项目目标和背景
Goals:
- 将MindGuard从半成品状态完善为功能完整的心理健康支持平台
- 建立完整的"情绪打卡→AI建议→任务执行→效果验证"价值闭环
- 实现稳定、流畅、安全的用户体验
- 确保技术架构的可扩展性和可维护性
Background Context: MindGuard项目目前已完成基础架构搭建和核心功能框架，但在功能完整性、用户体验优化、系统集成等方面存在明显缺口。作为面向高校学生的心理健康应用，需要进一步完善功能闭环，提升用户粘性，并确保在提供专业心理健康服务的同时保护用户隐私和安全。本次PRD旨在系统性地解决这些问题，将项目从半成品状态提升为生产就绪的完整产品。
🎯 需求定义
基于现有系统分析，以下需求确保从半成品到完整产品的平滑过渡：
Functional Requirements（功能需求）
FR1: 完善情绪打卡系统，支持多种情绪类型选择和强度调节，并生成准确的心情轮统计图表
FR2: 实现AI微建议生成的完整工作流，包括情绪分析、个性化建议生成和建议跟踪
FR3: 完善任务管理系统，支持从AI建议自动创建任务、任务执行跟踪和完成度统计
FR4: 实现完整的社区树洞功能，包括发帖、互动、风险识别和守护机制
FR5: 完善REBT日记功能，支持结构化记录、自动分析和情绪模式识别
FR6: 实现SOS紧急求助的完整流程，包括一键触发、危机评估和专业资源对接
FR7: 完善心语精灵AI对话系统，支持多Agent切换、对话历史和个性化建议
FR8: 实现完整的徽章和激励系统，包括成就解锁、进度可视化和社交分享
FR9: 建立护心周报的自动生成机制，包括数据统计、趋势分析和个性化建议
Non-Functional Requirements（非功能需求）
NFR1: 系统响应时间必须在2秒内完成基础操作，AI生成内容不超过5秒
NFR2: 确保数据隐私和安全，所有敏感信息必须加密存储，遵循最小权限原则
NFR3: 支持离线基础功能，包括情绪打卡和日记记录，网络恢复后自动同步
NFR4: 系统可用性达到99.5%，SOS功能必须保证100%可用性
NFR5: 支持至少1000并发用户，数据库查询响应时间小于500ms
Compatibility Requirements（兼容性需求）
CR1: 必须保持现有API接口的向后兼容性，确保已有功能不受影响
CR2: 数据库模式变更必须支持现有数据的平滑迁移，不能丢失用户历史数据
CR3: UI/UX必须保持TDesign设计规范的一致性，新组件要符合现有设计语言
CR4: 与微信云开发的现有集成必须保持稳定，Dify工作流集成不能破坏现有AI功能
需求优先级矩阵
| 优先级 | 功能需求 | 评分依据 | 用户价值 | 开发复杂度 | 风险等级 |
|---|---|---|---|---|---|
| P0 | FR4: 社区树洞功能 | 核心社交功能，用户留存关键 | 中等 | 高 | |
| P0 | FR1: 情绪打卡系统 | 基础功能，产品核心价值 | 低 | 低 | |
| P1 | FR2: AI微建议生成 | 差异化功能，AI核心竞争力 | 高 | 中 | |
| P1 | FR5: REBT日记功能 | 专业功能，目标用户刚需 | 中等 | 中 | |
| P2 | FR3: 任务管理系统 | 闭环功能，增强用户粘性 | 中等 | 低 | |
| P2 | FR7: 心语精灵对话 | AI功能扩展，增值服务 | 高 | 高 | |
| P3 | FR6: SOS紧急求助 | 安全功能，法律合规要求 | 高 | 高 | |
| P3 | FR8: 徽章激励系统 | 游戏化功能，提升参与度 | 低 | 低 | |
| P4 | FR9: 护心周报 | 数据洞察，长期价值 | 中等 | 中 |
🏗️ Epic和故事结构
Epic Approach
Epic Structure Decision: 单一史诗方式
合理性分析：
- 🎯 目标一致性: 所有功能都服务于"完善半成品→完整产品"的统一目标
- 🔗 技术依赖: 各模块间有紧密的数据流依赖（情绪→建议→任务→社区）
- 👥 团队协作: 单一史诗便于小团队集中精力，避免多史诗并行导致资源分散
- 📈 增量交付: 故事可以按优先级逐步交付，符合敏捷开发原则
Epic 1: MindGuard 产品完善增强
Epic Goal: 将MindGuard从半成品状态完善为功能完整、用户体验流畅的心理健康支持平台
Integration Requirements:
- 保持现有技术架构和数据模型的兼容性
- 确保新功能不影响现有用户数据
- 维持TDesign设计语言的一致性
- 遵循微信小程序开发规范和云开发最佳实践
用户故事详情
Story 1.1: 完善情绪打卡系统 (3点 - 简单)
As a 高校学生用户, I want 使用完整的情绪打卡功能记录我的心情状态, so that 我能够追踪情绪变化并获得个性化的心理健康建议。
Acceptance Criteria:
- AC1: 用户可以选择多种预设情绪类型（开心、平静、焦虑、悲伤等）
- AC2: 支持情绪强度调节（1-5级滑块选择）
- AC3: 打卡后自动生成心情轮统计，支持周/月视图
- AC4: 支持添加文字备注和标签（可选）
- AC5: 数据自动同步到云端，离线状态可缓存
Integration Verification:
- IV1: 确认现有的用户登录和个人资料功能正常工作
- IV2: 验证情绪数据能正确写入现有checkins数据库集合
- IV3: 测试心情轮组件性能，确保不影响页面加载速度
Story 1.2: 实现AI微建议生成工作流 (8点 - 复杂)
As a 用户, I want 基于我的情绪状态获得个性化的AI建议, so that 我能够得到专业的心理健康指导并采取行动。
Acceptance Criteria:
- AC1: 集成Dify工作流，根据情绪数据生成个性化建议
- AC2: 建议内容包含情绪分析、具体建议和行动指引
- AC3: 支持建议的收藏、分享和执行状态跟踪
- AC4: AI响应时间控制在5秒内
- AC5: 支持建议质量反馈机制，持续优化生成效果
Integration Verification:
- IV1: 确认与现有suggestionOrchestrator云函数正常集成
- IV2: 验证建议数据正确存储到journals数据库集合
- IV3: 测试网络异常时的降级处理和用户提示
Story 1.3: 完善社区树洞核心功能 (5点 - 中等)
As a 用户, I want 在安全的社区环境中分享我的想法和获得支持, so that 我能够获得同伴支持并减少孤独感。
Acceptance Criteria:
- AC1: 支持匿名发帖，包含文字、图片、标签选择
- AC2: 实现抱抱、评论等基础互动功能
- AC3: 集成风险识别算法，自动标记高风险内容
- AC4: 支持内容举报和审核机制
- AC5: 实现个性化内容推荐和关注功能
Integration Verification:
- IV1: 确认与现有treeholeModeration云函数正常协作
- IV2: 验证论坛数据正确写入forum_posts数据库集合
- IV3: 测试高并发情况下的系统稳定性
Story 1.4: 建立任务管理和执行闭环 (4点 - 中等)
As a 用户, I want 将AI建议转化为可执行的任务并跟踪进度, so that 我能够真正落实心理健康改善行动。
Acceptance Criteria:
- AC1: 支持从AI建议一键创建任务
- AC2: 提供任务分类、优先级设置和截止日期管理
- AC3: 实现任务执行状态跟踪和完成度统计
- AC4: 支持任务提醒和打卡功能
- AC5: 生成任务完成报告和成就反馈
Integration Verification:
- IV1: 确认与现有taskWorkflow云函数的数据同步
- IV2: 验证任务数据正确写入behavior_tasks数据库集合
- IV3: 测试任务推送通知的准确性和及时性
🔧 技术约束和集成要求
Existing Technology Stack
Languages:
- JavaScript (ES6+) - 小程序前端和云函数开发
- WXML/WXSS - 微信小程序标记语言和样式
Frameworks:
- 微信小程序原生框架
- TDesign Miniprogram v1.0+ - UI组件库
- 微信云开发 CloudBase - 后端服务
Database:
- 微信云数据库 (NoSQL) - 主要数据存储
- 云存储 - 文件和媒体资源存储
Infrastructure:
- 微信云开发环境 (cloud1-9gpfk3ie94d8630a)
- Dify AI工作流平台 - AI服务集成
External Dependencies:
- 微信开放平台API - 用户授权和支付
- Dify API - AI建议生成和对话
- 第三方心理评估API (可选) - 专业内容增强
Integration Strategy
Database Integration Strategy:
- 新字段添加: 为现有集合添加必要字段（如checkins添加情绪强度字段）
- 索引优化: 为新增查询模式创建复合索引
- 数据迁移: 制定向后兼容的数据迁移计划，确保现有用户数据完整性
- 事务处理: 关键操作使用数据库事务确保数据一致性
API Integration Strategy:
- 现有云函数复用: 最大程度复用现有的7个云函数
- 新云函数开发: 仅在必要时新增，保持架构简洁
- 错误处理统一: 遵循现有的
{ok, data, error}返回格式 - 性能监控: 集成现有的遥测和日志系统
Frontend Integration Strategy:
- 分包加载策略: 新增功能优先放入独立分包，控制主包大小
- TDesign组件规范: 严格遵循设计系统，确保UI一致性
- 状态管理: 继续使用现有的页面级状态管理模式
- 路由导航: 复用现有的导航和预加载机制
Testing Integration Strategy:
- Mock数据扩展: 为新功能添加完整的Mock数据支持
- 单元测试: 为服务层新增API调用测试
- 集成测试: 重点测试AI工作流集成和数据一致性
- 端到端测试: 覆盖关键用户旅程
Code Organization and Standards
File Structure Approach:
miniprogram/
├── pages/ # 主包页面优化
├── packages/ # 分包扩展
│ ├── community/ # 社区功能增强
│ └── ai-features/ # AI相关新功能分包
├── services/ # API服务层扩展
└── independent/ # 独立分包扩展
└── ai-agents/ # 新AI Agent分包
cloudfunctions/
├── existing-functions/ # 现有云函数优化
└── new-functions/ # 必要的新云函数Naming Conventions:
- 文件命名: kebab-case (如 emotion-checkin.js)
- 函数命名: camelCase (如 validateEmotionData)
- 数据库字段: snake_case (如 emotion_intensity)
- 组件命名: PascalCase (如 EmotionPicker)
Coding Standards:
- 严格模式: 所有文件使用
'use strict'; - 异步处理: 统一使用
async/await模式 - 错误处理: 完整的 try-catch-finally 结构
- 注释规范: JSDoc 格式，包含参数和返回值说明
- 代码审查: 所有PRD实施前必须经过代码审查
Deployment and Operations
Build Process Integration:
- 微信开发者工具: 继续使用现有构建流程
- 分包预加载: 更新 app.json 中的分包预加载配置
- 代码压缩: 保持现有的代码压缩和混淆设置
- 资源优化: 图片和音频资源的压缩和CDN分发
Deployment Strategy:
- 增量部署: 新功能采用灰度发布策略
- 云函数版本管理: 使用版本控制确保回滚能力
- 数据库迁移: 制定详细的数据库变更和回滚计划
- 环境隔离: 开发/测试/生产环境严格分离
Monitoring and Logging:
- 性能监控: 集成现有的页面加载时间监控
- 错误追踪: 增强现有的错误收集和分类机制
- 用户行为分析: 扩展现有的用户行为数据收集
- AI服务监控: 重点监控Dify API调用的成功率响应时间
📅 实施计划
项目实施策略
采用敏捷迭代方法，结合渐进式功能发布策略：
- MVP优先: 先交付核心价值闭环，再逐步完善
- 数据驱动: 基于用户反馈和使用数据调整优先级
- 风险控制: 每个迭代都包含完整的测试和回滚机制
- 团队效率: 基于现有技术栈，最大化开发效率
详细时间线和里程碑
| 里程碑 | 时间 | 主要交付 | 成功标准 |
|---|---|---|---|
| Milestone 1 | Week 1 End | 完善的情绪打卡系统 | 多情绪类型、强度调节、心情轮统计 |
| Milestone 2 | Week 2 End | AI微建议生成工作流 | Dify集成、个性化建议、反馈机制 |
| Milestone 3 | Week 3 End | 社区树洞核心功能 | 发帖互动、风险识别、内容审核 |
| Milestone 4 | Week 4 End | 完整的任务管理闭环 | 任务创建、跟踪、统计功能 |
| Milestone 5 | Week 5 End | 生产就绪的完整产品 | 端到端测试、性能优化、发布就绪 |
Phase 1: 基础功能完善 (Week 1-3)目标: 建立稳定的情绪-建议-任务闭环
Phase 2: 功能闭环完善 (Week 4)目标: 完成完整的用户体验闭环
Phase 3: 测试和发布准备 (Week 5)目标: 确保产品质量和发布就绪
团队配置和职责分工
推荐团队配置 (2-3人):
前端开发者 (1人):
- 负责所有小程序UI/UX开发
- TDesign组件集成和样式统一
- 分包加载和性能优化
后端开发者 (1人):
- 云函数开发和API接口设计
- 数据库设计和性能优化
- AI服务集成和错误处理
产品经理/全栈 (0.5人):
- 项目协调和进度管理
- 质量保证和测试协调
- 用户反馈收集和需求调整
工作量和复杂度估算
| 故事 | 复杂度 | 故事点 | 开发天数 | 测试天数 | 总工作量 | 关键路径 |
|---|---|---|---|---|---|---|
| Story 1.1 完善情绪打卡系统 | 🟢 简单 | 3点 | 2-3天 | 1天 | 3-4天 | ✅ 关键路径 |
| Story 1.2 AI微建议生成 | 🔴 复杂 | 8点 | 5-7天 | 2天 | 7-9天 | ✅ 关键路径 |
| Story 1.3 社区树洞功能 | 🟡 中等 | 5点 | 3-4天 | 2天 | 5-6天 | ✅ 关键路径 |
| Story 1.4 任务管理闭环 | 🟡 中等 | 4点 | 2-3天 | 1天 | 3-4天 | 非关键路径 |
总工作量估算：
- 总故事点：20点
- 开发时间：12-17天
- 测试时间：6天
- 项目总工期：18-23天（约3-4周）
🎯 质量标准和验收条件
成功指标和验收标准
技术指标:
- 性能: 页面加载时间 < 2秒，API响应时间 < 500ms
- 稳定性: 系统可用率 > 99%，错误率 < 0.1%
- 兼容性: 支持微信7.0+版本，覆盖98%用户
业务指标:
- 功能完整性: 所有P0/P1功能正常工作
- 用户体验: 用户满意度 > 4.0/5.0
- 数据准确性: 情绪识别准确率 > 85%，AI建议相关性 > 80%
质量指标:
- 代码覆盖率: 核心功能测试覆盖率 > 80%
- 安全合规: 通过隐私合规审查，数据加密率100%
- 文档完整: 所有API接口文档完整，部署文档齐全
关键里程碑和交付物
Milestone 1: Week 1 End交付物: 完善的情绪打卡系统
- 多情绪类型选择和强度调节
- 基础心情轮统计
- 数据存储和同步功能
Milestone 2: Week 2 End交付物: AI微建议生成工作流
- Dify集成和个性化建议
- 建议跟踪和反馈机制
- 错误处理和性能优化
Milestone 3: Week 3 End交付物: 社区树洞核心功能
- 发帖和互动基础功能
- 风险识别和内容审核
- 用户安全和隐私保护
Milestone 4: Week 4 End交付物: 完整的任务管理闭环
- AI建议自动转化为任务
- 任务执行跟踪和统计
- 推送通知和提醒功能
Milestone 5: Week 5 End交付物: 生产就绪的完整产品
- 端到端功能测试完成
- 性能优化和安全审查通过
- 发布文档和运维准备就绪
⚠️ 风险评估和缓解策略
关键风险点监控
Technical Risks:
- AI服务依赖: Dify API稳定性和响应时间不可控
- 缓解策略: 实现服务降级和本地缓存机制
- 数据一致性: 多集合数据操作可能导致不一致
- 缓解策略: 使用数据库事务和补偿事务机制
- 性能瓶颈: AI功能可能影响整体性能
- 缓解策略: 异步处理和智能缓存策略
Integration Risks:
- 现有功能破坏: 新功能可能影响现有用户体验
- 缓解策略: 全面的回归测试和渐进式发布
- 第三方API变更: 微信或Dify API变更
- 缓解策略: 版本锁定和适配层设计
- 数据迁移风险: 用户数据丢失或损坏
- 缓解策略: 详细的数据备份和回滚计划
Deployment Risks:
- 版本兼容性: 小程序基础库版本兼容问题
- 缓解策略: 渐进式兼容性测试和降级方案
- 审核延迟: 小程序审核可能被延迟
- 缓解策略: 提前提交和多个版本预案
应急响应机制
- Bug分级: P0级(4小时)、P1级(24小时)、P2级(72小时)
- 热修复机制: 关键bug的快速修复和发布流程
- 回滚预案: 每个版本的完整回滚方案
缓解策略
- 渐进式发布: 功能分阶段发布，降低单次发布风险
- 监控告警: 实时监控关键指标，快速发现问题
- 回滚机制: 完整的回滚预案和一键回滚能力
- 团队培训: 确保团队熟悉新技术和流程
📋 附录
术语表
- PRD: Product Requirements Document (产品需求文档)
- Epic: 大型功能集合，通常包含多个用户故事
- Story: 具体的用户需求描述，包含验收标准
- Sprint: 时间盒限制的开发迭代 (通常1-4周)
- MVP: Minimum Viable Product (最小可行产品)
- Brownfield: 现有项目/系统上的功能增强
- TDesign: 腾讯设计体系的小程序UI组件库
文档版本历史
| 版本 | 日期 | 变更描述 | 作者 |
|---|---|---|---|
| v1.0 | 2025-10-17 | 初始版本创建 | John (PM Agent) |
相关文档
- 项目架构文档:
CLAUDE.md - 分包规划:
docs/分包规划方案.md - 数据库设计:
docs/数据库设计.md - 功能列表:
docs/功能列表.md - UI组件文档:
docs/UI组件文档.md
文档结束 | 下次更新: 根据开发进展和用户反馈持续更新
注意事项: 本PRD为动态文档，随着开发进展和用户反馈会持续更新和完善。所有开发活动应严格遵循本PRD中的技术规范和验收标准。
贡献者
Cai Hongyu