删除 12-智慧康养志愿者管理系统-模块规划.md
This commit is contained in:
@@ -1,160 +0,0 @@
|
||||
# 智慧康养志愿者管理系统 模块规划
|
||||
|
||||
---
|
||||
|
||||
## 1. 模块定位
|
||||
|
||||
智慧康养志愿者管理系统是基于**"时间银行"公益机制**的志愿服务管理平台，核心创新在于通过区块链技术存证志愿服务时长，并允许志愿者以积累的"公益时间"兑换礼品或未来的养老服务权益。
|
||||
|
||||
本系统的核心用户为社会志愿者（及其家庭），以及负责志愿服务调度的社区工作人员。
|
||||
|
||||
---
|
||||
|
||||
## 2. 建设目标
|
||||
|
||||
1. 构建志愿者注册、技能认证和服务调度管理体系
|
||||
2. 实现时间银行账户管理：服务时长记录→区块链存证→时间积分发放
|
||||
3. 提供礼品管理（200+ SKU）和时间积分兑换功能
|
||||
4. 支持志愿服务数据统计汇总，供政府监管部门查阅
|
||||
5. 通过公益激励机制吸引社会志愿者参与养老服务
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心功能范围
|
||||
|
||||
### 3.1 一级模块
|
||||
|
||||
- 志愿者注册与档案管理
|
||||
- 志愿服务发布与调度
|
||||
- 服务执行管理
|
||||
- 时间银行账户体系
|
||||
- 礼品管理与兑换
|
||||
- 统计报表
|
||||
|
||||
### 3.2 二级模块
|
||||
|
||||
- **志愿者注册**：实名认证、技能标签（陪聊/助餐/助医/文体）、服务意愿设置
|
||||
- **服务发布**：社区发布服务需求、轮播/推送给合适志愿者
|
||||
- **服务执行**：志愿者签到（GPS打卡）、服务时长记录、老人确认
|
||||
- **时间银行**：时长积分账户余额、收支明细、区块链存证哈希查询
|
||||
- **礼品管理**：礼品目录（200+ SKU）、库存管理、积分价格配置
|
||||
- **兑换管理**：志愿者提交兑换申请、审核、实物/服务发放
|
||||
- **统计报表**：志愿者人数、服务时长、覆盖老人数、兑换数量
|
||||
|
||||
### 3.3 核心功能说明
|
||||
|
||||
| 功能 | 描述 | 技术要点 |
|
||||
| ------------ | -------------------------------------- | ------------------------------------- |
|
||||
| 时间银行积分 | 每分钟服务 = 1积分，专用于养老服务兑换 | 积分引擎（独立于mall积分） |
|
||||
| 区块链存证 | 每笔服务记录上链，防止篡改 | 联盟链（蚂蚁链/腾讯云区块链）写入存证 |
|
||||
| 礼品200+ SKU | 实物礼品库存管理与积分兑换 | 类似 mall 商品SKU但无购买概念 |
|
||||
| GPS服务签到 | 到达服务地点才可开始计时 | 高德定位 + 地理围栏 |
|
||||
| 志愿者匹配 | 按技能标签+距离推送服务需求 | 技能过滤 + GIS距离排序 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 与现有 mall 的关系
|
||||
|
||||
**契合度：D（不适配）**
|
||||
|
||||
表面上礼品兑换与 mall 商品管理有结构相似性，但存在根本性差异：
|
||||
|
||||
| 能力需求 | mall 现状 | 结论 |
|
||||
| ------------------------ | ------------------------------------ | -------------------------- |
|
||||
| 时间银行积分（公益时长） | 有积分体系，但为消费积分（购物赠送） | 业务逻辑完全不同，不可复用 |
|
||||
| 区块链存证 | 无 | 须独立建设 |
|
||||
| 礼品管理（兑换模式） | 有商品，但为销售模式 | 兑换无需支付，逻辑完全不同 |
|
||||
| 志愿者注册与技能管理 | 无志愿者实体 | 须独立建设 |
|
||||
| 志愿服务发布与调度 | 无 | 须独立建设 |
|
||||
| GPS服务计时 | 无 | 须独立建设 |
|
||||
|
||||
mall 是通用电商平台，不具备时间银行/公益激励的概念，积分体系的逻辑与商业电商积分完全不同，强行复用会造成数据模型混乱。
|
||||
|
||||
---
|
||||
|
||||
## 5. 规划判断
|
||||
|
||||
**独立系统建设**
|
||||
|
||||
- 志愿者端：uni-app（微信小程序）
|
||||
- 管理后台：Vue3 Web
|
||||
- 区块链存证：对接联盟链SDK（蚂蚁链/腾讯云区块链）
|
||||
- 礼品管理：独立实物库管系统（参考仓储管理）
|
||||
|
||||
---
|
||||
|
||||
## 6. 需新增业务能力
|
||||
|
||||
1. **公益时间积分引擎**：独立于商业积分的时间积分体系，以分钟为单位计算
|
||||
2. **区块链存证接入**：每笔完成服务→生成服务证明→上链存证→返回存证哈希
|
||||
3. **志愿者技能标签体系**：标准化志愿服务技能分类（国标参考或自定义）
|
||||
4. **服务发布与匹配**：社区发布养老志愿服务需求，系统智能推送给匹配志愿者
|
||||
5. **礼品库存管理**：200+ SKU实物礼品入库/出库/预警
|
||||
6. **兑换审核流程**：积分兑换申请→库存核查→发货→确认收到
|
||||
|
||||
---
|
||||
|
||||
## 7. 需新增数据模型
|
||||
|
||||
| 模型 | 关键字段 |
|
||||
| -------------------------- | ------------------------------------------------------------------------------------------ |
|
||||
| `volunteer` | id, user_id, name, id_verified, skill_tags, status, time_bank_balance |
|
||||
| `volunteer_service_task` | id, community_id, task_name, skill_required, elder_id, scheduled_at, status |
|
||||
| `volunteer_service_record` | id, task_id, volunteer_id, checkin_at, checkout_at, minutes_earned, blockchain_hash |
|
||||
| `time_bank_ledger` | id, volunteer_id, change_type(earn/redeem), minutes, balance_after, related_id, created_at |
|
||||
| `blockchain_cert` | id, record_id, chain_type, tx_hash, block_height, cert_url, created_at |
|
||||
| `gift_catalog` | id, name, sku_code, image, point_cost, stock, category, status |
|
||||
| `gift_redemption` | id, volunteer_id, gift_id, quantity, total_points, address, status, tracking_no |
|
||||
|
||||
---
|
||||
|
||||
## 8. 需新增技术栈 / 第三方能力 / 中间件
|
||||
|
||||
| 类别 | 技术选型 | 用途 |
|
||||
| -------- | ------------------------- | -------------------- |
|
||||
| 区块链 | 蚂蚁链 BaaS / 腾讯云TBaaS | 志愿服务时长存证 |
|
||||
| 定位 | 高德SDK | GPS签到打卡 |
|
||||
| 库存管理 | 自研轻量WMS | 礼品出入库管理 |
|
||||
| 推送 | 微信模板消息 | 服务需求推送给志愿者 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 外部系统对接关系
|
||||
|
||||
| 对接方 | 内容 | 方式 |
|
||||
| ------------------ | ------------------------ | ------- |
|
||||
| 数据库系统（02） | 老人档案（服务对象信息） | 内部API |
|
||||
| 政府监管（01） | 志愿者服务统计数据 | 内部API |
|
||||
| 系统管理中心（05） | 志愿者账号管理 | 内部API |
|
||||
|
||||
---
|
||||
|
||||
## 10. 风险与边界
|
||||
|
||||
| 风险 | 说明 | 应对 |
|
||||
| ------------------------ | ---------------------------------------- | ------------------------------------- |
|
||||
| 区块链成本 | 上链每笔有Gas费用 | 采用联盟链（低成本）而非公链 |
|
||||
| 虚假签到 | 志愿者远程打卡骗取时间积分 | GPS围栏严格核验 + 老人确认签字 |
|
||||
| 礼品库存管理难度 | 200+ SKU需完善的WMS功能 | 分阶段上架，先以小规模验证 |
|
||||
| 时间银行可持续性 | 公益时间未来能否真正换取服务 | ⚠️ 该商业模式需业务方提前规划兑付规则 |
|
||||
| 边界：不含志愿者薪酬发放 | 志愿服务为公益性质，不涉及劳动合同和薪酬 | 仅时间积分，不含货币结算 |
|
||||
|
||||
---
|
||||
|
||||
## 11. 实施优先级与分期建议
|
||||
|
||||
**优先级：P2**
|
||||
|
||||
| 分期 | 内容 | 前置条件 |
|
||||
| ------ | ------------------------------------ | ------------------ |
|
||||
| 第一期 | 志愿者注册 + 服务记录 + 基础时间积分 | 老人档案（02）就绪 |
|
||||
| 第二期 | 区块链存证 + 礼品兑换 | 区块链SDK选型确认 |
|
||||
| 第三期 | 服务匹配优化 + 统计报表 + 政府对接 | — |
|
||||
|
||||
---
|
||||
|
||||
## 12. 结论
|
||||
|
||||
志愿者管理系统虽然在礼品管理方面与 mall 有表面相似性，但时间银行（公益积分）与区块链存证的核心机制与商业电商积分逻辑完全不同，**不可在 mall 基础上改造，必须独立建设**。
|
||||
|
||||
建议区块链存证采用联盟链方案（阿里/腾讯BaaS），兼顾成本控制和存证可信度。礼品管理模块建议轻量实现，优先保证服务记录和时间积分的准确性与可信性。
|
||||
Reference in New Issue
Block a user