上传文件至「/」

10-智慧康养居家养老管理系统-模块规划.md

@@ -0,0 +1,173 @@
+# 智慧康养居家养老管理系统 模块规划
+
+---
+
+## 1. 模块定位
+
+智慧康养居家养老管理系统是面向**居家老人、上门服务员和机构管理员**的核心服务调度系统，承担老人档案管理、服务项目订单管理、家庭医生签约管理、老年活动中心管理及智能呼叫调度等职能。
+
+本系统是整个平台服务量最大的模块，是居家养老"最后一公里"服务的落地载体。
+
+---
+
+## 2. 建设目标
+
+1. 建立完整的居家老人服务档案体系，包含个人基本信息、服务历史、家庭关系
+2. 实现居家服务（上门护理/助浴/助餐/家政）的在线预约、派单和执行管理
+3. 构建家庭医生签约管理功能，支持线上问诊和服务计划制定
+4. 提供老年活动中心（日间照料）的入托/活动/绩效管理
+5. 集成智能呼叫调度，支持服务员端实时接单和工作台管理
+
+---
+
+## 3. 核心功能范围
+
+### 3.1 一级模块
+
+- 老人档案管理
+- 服务订单管理
+- 服务项目管理
+- 家庭医生管理
+- 老年活动中心
+- 智能呼叫调度
+- 工作台管理
+
+### 3.2 二级模块
+
+- **老人档案**：基本信息、家庭关系、失能等级（来自07评估）、紧急联系人、服务计划
+- **服务订单**：服务预约（老人/家属端）、订单分配（系统/手动）、服务执行确认（GPS打卡+照片）、评价
+- **服务项目**：服务目录维护（助浴/助餐/助洁/护理）、定价、服务时长标准
+- **家庭医生**：签约管理、服务计划制定、健康随访、在线咨询
+- **老年活动中心**：日间照料入托申请、活动课程、出勤记录、绩效报表
+- **智能呼叫**：老人一键呼叫→系统自动匹配就近服务员→推送接单通知
+- **工作台**：服务员端今日任务、路线规划、打卡记录、服务报告提交
+
+### 3.3 核心功能说明
+
+| 功能         | 描述                                          | 技术要点                   |
+| ------------ | --------------------------------------------- | -------------------------- |
+| 智能派单     | 根据老人地址+服务类型+服务员技能/距离自动分配 | GIS距离计算 + 技能匹配算法 |
+| GPS签到      | 服务员到达老人家地理围栏内才可开始服务        | 高德定位 + 地理围栏        |
+| 服务执行确认 | 服务完成后拍照/老人/家属电子签名              | 移动端拍照 + Canvas签名    |
+| 家庭医生签约 | 家庭医生与老人1:N签约，绑定服务计划           | 签约关系表 + 计划模板      |
+| 活动中心出勤 | 刷卡/人脸/签到记录日间照料出勤                | 一卡通API调用              |
+
+---
+
+## 4. 与现有 mall 的关系
+
+**契合度：C（低契合，部分可参考）**
+
+mall 具备部分可参考的能力，但差异显著：
+
+| 能力               | mall 现状                 | 可复用程度                                  |
+| ------------------ | ------------------------- | ------------------------------------------- |
+| 用户下单与服务预约 | 有商品下单流程            | 参考结构，需大量改造（服务型订单≠商品订单） |
+| 骑手配送端         | 有骑手App（GPS接单/打卡） | 可参考移动端框架，核心逻辑差异大            |
+| 订单状态机         | 有（7种状态）             | 参考状态机设计，适配服务订单状态            |
+| 工单/客服          | 有简单客服工单            | 不同场景，参考意义有限                      |
+| 评价体系           | 有商品评分                | 改造成服务评价                              |
+| 商品分类/目录      | 有SKU体系                 | 可参考目录结构，服务无库存概念              |
+| **老人档案**       | **无**                    | **须独立建设**                              |
+| **家庭医生签约**   | **无**                    | **须独立建设**                              |
+| **活动中心管理**   | **无**                    | **须独立建设**                              |
+| **GPS智能派单**    | **无**                    | **须独立建设**                              |
+
+**建设路径：mall + 独立微服务（C级）**
+
+mall 的订单状态机和移动端框架可作为参考蓝本，但不建议直接在 mall 代码库中增量开发，需独立建设服务型订单系统，并通过 API 对接 mall 的支付能力（如果服务需要收费）。
+
+---
+
+## 5. 规划判断
+
+**mall + 独立微服务（以独立为主）**
+
+- 老人/家属端：uni-app（小程序），复用 mall 的支付/登录组件
+- 服务员端：uni-app（独立应用，类似骑手端但完全重写）
+- 管理后台：Vue3 Web（独立）
+- 服务端：独立服务型订单服务（参考 mall 设计但独立部署）
+- 支付：对接 mall 现有支付网关（政府补贴/个人自费混合结算）
+
+---
+
+## 6. 需新增业务能力
+
+1. **服务型订单引擎**：服务订单（无库存概念）的预约→分配→签到→执行→确认→评价→结算
+2. **智能派单算法**：基于GIS距离 + 服务员技能 + 可用时间窗口的最优匹配
+3. **家庭医生签约与随访管理**：签约周期管理、随访计划提醒、在线咨询记录
+4. **补贴抵扣结算**：政府补贴额度 + 个人自费混合支付，支持长护险抵扣
+5. **服务质量监控**：服务员GPS轨迹核验、超时预警、服务评分聚合
+6. **老年活动中心管理**：日间照料预约、活动排班、出勤统计、绩效报表
+
+---
+
+## 7. 需新增数据模型
+
+| 模型                     | 关键字段                                                                                                    |
+| ------------------------ | ----------------------------------------------------------------------------------------------------------- |
+| `home_service_order`     | id, elder_id, service_type, scheduled_at, assignee_id, checkin_at, checkout_at, status, fee, subsidy_amount |
+| `service_catalog`        | id, name, category, description, price, duration_min, required_skills                                       |
+| `service_execution`      | id, order_id, checkin_photo, checkout_photo, elder_signature, notes, result_confirmed                       |
+| `family_doctor_contract` | id, doctor_id, elder_id, start_date, end_date, plan_id, status                                              |
+| `doctor_followup`        | id, contract_id, date, method(online/offline), notes, health_data_ref                                       |
+| `activity_center`        | id, name, address, capacity, manager_id                                                                     |
+| `day_care_booking`       | id, elder_id, center_id, date, checkin_at, checkout_at                                                      |
+| `call_dispatch`          | id, elder_id, call_type, dispatch_time, assignee_id, response_time                                          |
+
+---
+
+## 8. 需新增技术栈 / 第三方能力 / 中间件
+
+| 类别     | 技术选型         | 用途                             |
+| -------- | ---------------- | -------------------------------- |
+| GIS      | 高德路径规划API  | 智能派单距离计算、服务员路线导航 |
+| 定位     | 高德SDK          | 服务员GPS打卡                    |
+| 电子签名 | Canvas手写签名   | 服务完成老人确认签字             |
+| 补贴结算 | 自研补贴计算引擎 | 政府补贴额度抵扣计算             |
+| 在线咨询 | 腾讯云IM / 融云  | 家庭医生与老人文字/语音咨询      |
+
+---
+
+## 9. 外部系统对接关系
+
+| 对接方           | 内容                         | 方式            |
+| ---------------- | ---------------------------- | --------------- |
+| 评估系统（07）   | 失能等级→服务计划制定依据    | 内部API（只读） |
+| 服务商管理（11） | 服务员来源、技能标签、考核分 | 内部API         |
+| 长护险（18）     | 补贴抵扣额度同步             | 内部API         |
+| 呼叫中心（06）   | 呼叫工单→服务派单            | 内部API         |
+| 安全系统（09）   | SOS触发→居家服务员就近响应   | 消息队列        |
+| mall支付（19）   | 个人自费部分支付             | 内部支付网关    |
+| 数据库系统（02） | 老人档案读写                 | 内部API         |
+
+---
+
+## 10. 风险与边界
+
+| 风险                   | 说明                                           | 应对                                     |
+| ---------------------- | ---------------------------------------------- | ---------------------------------------- |
+| 补贴结算规则复杂       | 各省市补贴标准不统一                           | 补贴规则可配置化，不硬编码               |
+| 服务员定位造假         | GPS打卡可能被外挂软件欺骗                      | 设备+位置双重验证+照片时间戳             |
+| 家庭医生供给不足       | 签约需要真实医生资质                           | 引入第三方家庭医生平台 ⚠️ 待确认合作模式 |
+| 边界：不含机构住院护理 | 本系统为居家上门服务，机构内护理由其他模块处理 | 明确服务范围                             |
+
+---
+
+## 11. 实施优先级与分期建议
+
+**优先级：P1**
+
+| 分期   | 内容                                       | 前置条件                         |
+| ------ | ------------------------------------------ | -------------------------------- |
+| 第一期 | 老人档案 + 服务订单（预约+执行）+ 服务员端 | 数据库（02）、系统管理（05）就绪 |
+| 第二期 | 智能派单 + 补贴抵扣 + 评价体系             | 评估（07）、长护险（18）完成     |
+| 第三期 | 家庭医生签约 + 活动中心 + 统计报表         | —                                |
+
+---
+
+## 12. 结论
+
+居家养老管理系统是平台服务量最大的核心模块，mall 的订单状态机和移动端框架有一定参考价值（C级契合），但老人档案、智能派单、家庭医生签约等核心业务能力在 mall 中完全缺失。
+
+**建议以独立系统建设为主，参考 mall 设计模式，通过 API 对接 mall 的支付能力**，避免在 mall 内部堆砌医养业务逻辑导致架构污染。P1阶段优先完成核心服务订单闭环，家庭医生和活动中心在P1后期或P2补充。

11-智慧康养服务商管理系统-模块规划.md

@@ -0,0 +1,173 @@
+# 智慧康养服务商管理系统 模块规划
+
+---
+
+## 1. 模块定位
+
+智慧康养服务商管理系统是连接**平台（政府/运营方）与服务供给侧（服务商/从业人员）** 的 B2G/B2B/B2C 三维业务系统，负责服务商的注册准入、资质审核、人员管理、服务范围配置、订单履约管理、信用评分和 IoT 服务监控（500+ 终端）。
+
+本系统是整个平台"服务能力供给"的核心，服务商数量与质量直接决定居家养老、社区助餐等业务的履约能力。
+
+---
+
+## 2. 建设目标
+
+1. 实现服务商在线注册申请→政府资质审核→平台入驻的完整准入流程
+2. 管理服务商人员档案、技能认证、绩效考核
+3. 支持服务商自主配置服务范围（区域）和服务项目（价格/时长）
+4. 构建服务商信用体系，基于服务完成率、评分、投诉率等维度动态评分
+5. 提供服务监控能力，对 500+ IoT 终端和服务执行进行实时追踪
+
+---
+
+## 3. 核心功能范围
+
+### 3.1 一级模块
+
+- 服务商注册与审核
+- 服务商档案管理
+- 服务人员管理
+- 服务范围与项目管理
+- 订单管理
+- 绩效与考核体系
+- 信用评分体系
+- 服务监控
+
+### 3.2 二级模块
+
+- **注册审核**：服务商申请→资质材料上传→审核→入驻通知→账号激活
+- **档案管理**：基本信息、营业执照、服务许可、合同管理、开票信息
+- **人员管理**：招募、技能认证（护工/护士/医生证）、排班、考勤
+- **服务范围**：地图选区设置服务覆盖区域、可承接服务类型
+- **订单管理**：待接单队列、执行中订单、历史订单、订单异常处置
+- **绩效考核**：月度绩效报表、服务完成率、评分均值、投诉率分析
+- **信用评分**：综合评分算法（完成率/投诉/证书效期等），等级标签
+- **服务监控**：500+ IoT 终端状态汇总、告警统计、设备分布地图
+
+### 3.3 核心功能说明
+
+| 功能          | 描述                                                                  | 技术要点                     |
+| ------------- | --------------------------------------------------------------------- | ---------------------------- |
+| 资质审核流程  | 材料OCR识别 + 人工审核 + 多级批准                                     | OCR + 工作流引擎             |
+| 服务区域配置  | 地图绘制多边形服务区域                                                | 高德地图绘图API + 多边形存储 |
+| 信用评分算法  | 加权综合评分 = 完成率×40% + 评分均值×30% + 投诉率×-20% + 证书效期×10% | 定期计算任务                 |
+| 500+ 设备监控 | 实时展示所有设备在线率、告警数、最近上报                              | MQTT状态聚合 + 分页仪表盘    |
+| 订单分析      | 服务商维度的订单量/收入/退款分析                                      | 统计服务 + 图表              |
+
+---
+
+## 4. 与现有 mall 的关系
+
+**契合度：B（中契合，商家管理可参考）**
+
+mall 具备完整的商家（Merchant）管理体系，与本系统存在结构性相似：
+
+| 能力                 | mall 现状               | 可复用程度                       |
+| -------------------- | ----------------------- | -------------------------------- |
+| 商家注册与审核       | 有（资质上传+人工审核） | B - 可参考审核流程，但字段需扩展 |
+| 商家商品/服务管理    | 有（商品目录+SKU）      | B - 服务目录可参考，去除库存概念 |
+| 订单管理（商家侧）   | 有（接单/拒单/发货）    | B - 参考状态机，改造为服务型订单 |
+| 商家账单/提现        | 有                      | B - 可直接复用或少量改造         |
+| 商家评分/评价        | 有                      | B - 扩展为信用评分体系           |
+| **服务人员管理**     | **无**                  | **须新建**                       |
+| **IoT设备监控**      | **无**                  | **须新建**                       |
+| **地理服务区域配置** | **无**                  | **须新建**                       |
+| **信用评分算法**     | **无**                  | **须新建**                       |
+| **政府准入审批**     | **无**                  | **须新建（B2G部分）**            |
+
+**建设路径：mall 商家管理基础 + 大量独立微服务扩展**
+
+建议在独立系统中参考 mall 商家管理的设计模式（审核流程、账单结算），但不在 mall 内部改造，以避免电商逻辑与医养业务逻辑的交叉污染。
+
+---
+
+## 5. 规划判断
+
+**mall + 独立微服务（以独立为主，参考 mall B 级能力）**
+
+- 服务商端：uni-app（小程序）
+- 平台管理端：Vue3 Web
+- 服务端：独立服务商服务（参考 mall 商家服务的设计架构）
+- IoT监控层：依托 IoT 管理（16）和安全系统（09）的数据聚合
+
+---
+
+## 6. 需新增业务能力
+
+1. **服务商准入评审**：资质材料多维度核验（国标服务资质要求）
+2. **从业人员证件管理**：护理员/护士/医生证有效期自动预警
+3. **地理服务区域可视化配置**：服务商在地图上自助划定服务范围
+4. **信用评分引擎**：可配置权重的综合信用评分，等级自动更新
+5. **服务商资金分账**：订单完成后自动结算到服务商子账户
+6. **IoT监控聚合**：500+ 设备按服务商维度聚合展示状态
+
+---
+
+## 7. 需新增数据模型
+
+| 模型                         | 关键字段                                                                                        |
+| ---------------------------- | ----------------------------------------------------------------------------------------------- |
+| `service_provider`           | id, name, biz_license_no, service_license_no, district_code, credit_score, credit_grade, status |
+| `provider_qualification_doc` | provider_id, doc_type, doc_url, ocr_result(JSONB), expire_date, verify_status                   |
+| `provider_staff`             | id, provider_id, name, cert_type, cert_no, cert_expire, skill_tags, status                      |
+| `provider_service_area`      | provider_id, polygon_points(JSONB), effective_date                                              |
+| `provider_service_catalog`   | provider_id, service_catalog_id, price, min_duration_min, max_concurrent                        |
+| `provider_order`             | id, provider_id, order_id (ref home_service_order), status, staff_id                            |
+| `provider_credit_record`     | id, provider_id, score_before, score_after, reason, calc_at                                     |
+| `provider_wallet`            | provider_id, balance, frozen_amount, last_settled_at                                            |
+
+---
+
+## 8. 需新增技术栈 / 第三方能力 / 中间件
+
+| 类别     | 技术选型                  | 用途                     |
+| -------- | ------------------------- | ------------------------ |
+| GIS      | 高德地图绘图API           | 服务区域多边形绘制与存储 |
+| OCR      | 腾讯云OCR                 | 营业执照/证书自动识别    |
+| 分账     | 微信商户分账 / 支付宝分账 | 服务费用自动分账给服务商 |
+| 定时任务 | XXL-JOB                   | 每日信用评分重算         |
+| 消息推送 | 微信模板消息              | 审核结果、订单通知       |
+
+---
+
+## 9. 外部系统对接关系
+
+| 对接方             | 内容                     | 方式     |
+| ------------------ | ------------------------ | -------- |
+| 审批系统（04）     | 服务商资质审批结论       | 内部API  |
+| 居家养老管理（10） | 服务员派单、订单数据     | 内部API  |
+| IoT管理（16）      | 设备监控数据聚合         | 内部API  |
+| 数据库系统（02）   | 服务商档案写入、人员档案 | 内部API  |
+| mall支付（19）     | 服务费支付与分账         | 支付网关 |
+| 政府监管（01）     | 服务商信用、服务量统计   | 内部API  |
+
+---
+
+## 10. 风险与边界
+
+| 风险                     | 说明                             | 应对                                          |
+| ------------------------ | -------------------------------- | --------------------------------------------- |
+| 服务商造假资质           | 伪造营业执照或资质证书           | OCR + 人工双重验证 + 工商查询API（⚠️ 待确认） |
+| 分账合规                 | 资金分账需满足第三方支付监管要求 | 使用持牌支付机构的分账功能                    |
+| 信用评分算法公平性       | 新入驻服务商样本量少，评分不准确 | 新商家保护期机制（前30单不计负评）            |
+| 边界：不含服务员劳动合同 | HR管理和劳动合同不在本系统范围   | 仅管理技能资质和绩效，不涉及劳动关系          |
+
+---
+
+## 11. 实施优先级与分期建议
+
+**优先级：P1**
+
+| 分期   | 内容                                     | 前置条件                   |
+| ------ | ---------------------------------------- | -------------------------- |
+| 第一期 | 服务商注册审核 + 人员管理 + 服务目录配置 | 审批系统（04）就绪         |
+| 第二期 | 订单管理 + 服务区域配置 + 结算分账       | 居家养老（10）订单系统就绪 |
+| 第三期 | 信用评分 + IoT监控 + 绩效报表            | IoT管理（16）就绪          |
+
+---
+
+## 12. 结论
+
+服务商管理系统是平台服务能力的供给端，mall 商家管理体系（审核流程、账单结算）对本模块具有中等参考价值（B级），但服务人员证件管理、地理服务区域、IoT监控等核心医养特性能力须独立建设。
+
+**建议参考 mall 商家管理的设计模式独立建设**，通过API对接 mall 支付分账能力，避免在 mall 内部直接改造带来的代码耦合风险。

12-智慧康养志愿者管理系统-模块规划.md

@@ -0,0 +1,160 @@
+# 智慧康养志愿者管理系统 模块规划
+
+---
+
+## 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），兼顾成本控制和存证可信度。礼品管理模块建议轻量实现，优先保证服务记录和时间积分的准确性与可信性。

13-智慧康养短信平台系统-模块规划.md

@@ -0,0 +1,164 @@
+# 智慧康养短信平台系统 模块规划
+
+---
+
+## 1. 模块定位
+
+智慧康养短信平台系统是全平台的**消息基础设施**，为所有业务模块提供短信发送能力，包括业务通知短信（服务确认/审核结果/订单变更）、健康预警短信（体征异常推送家属）、系统告警短信（设备离线/SOS事件）以及模板管理、接口对接和发送统计等能力。
+
+本系统是平台级基础能力，不面向终端用户直接提供界面，而是作为内部服务对其他模块暴露 API。
+
+---
+
+## 2. 建设目标
+
+1. 提供统一的短信发送 API，所有业务模块通过统一入口发送短信，避免各模块各自对接运营商
+2. 管理短信模板，支持变量占位符（老人姓名/服务时间/家属联系方式）
+3. 实现健康预警短信的优先级发送（体征危急值 = 最高优先级）
+4. 提供发送统计与失败重试机制
+5. 支持多运营商/多通道切换，保障发送成功率
+
+---
+
+## 3. 核心功能范围
+
+### 3.1 一级模块
+
+- 短信发送服务
+- 健康预警短信
+- 告警自动发送
+- 模板管理
+- 运营商接口对接
+- 发送统计
+- 权限管理
+
+### 3.2 二级模块
+
+- **短信发送服务**：单发、群发、定时发送 API
+- **健康预警**：健康管理系统（08）触发危急值短信，优先级队列
+- **告警自动发送**：安全系统（09）SOS/跌倒/走失告警短信自动发送给家属/护工
+- **模板管理**：内置系统模板 + 自定义模板，工信部报备管理
+- **运营商对接**：阿里云短信/腾讯云短信/云之讯等多通道配置，自动故障切换
+- **发送统计**：每日/月发送量、成功率、费用统计、模板使用排行
+- **权限管理**：各模块调用限额、IP白名单、API密钥管理
+
+### 3.3 核心功能说明
+
+| 功能         | 描述                                                   | 技术要点                  |
+| ------------ | ------------------------------------------------------ | ------------------------- |
+| 统一短信API  | 内部HTTP API接口，接收目标号码+模板+变量，返回发送结果 | RESTful API + 异步回调    |
+| 优先级队列   | SOS告警 > 健康危急 > 业务通知，高优先级跳过排队        | 分级消息队列（多个Queue） |
+| 多通道切换   | 主通道失败→自动切换备用通道（<30s内）                  | 健康检查 + 故障转移逻辑   |
+| 模板变量渲染 | 模板中 ${name}、${time} 占位符替换                     | 字符串模板引擎            |
+| 失败重试     | 发送失败后按指数退避重试（最多3次）                    | 重试队列 + 退避算法       |
+
+---
+
+## 4. 与现有 mall 的关系
+
+**契合度：C（低契合，架构可参考但不可直接复用）**
+
+mall 自身集成了短信发送功能（注册验证码/订单通知），但：
+
+| 能力             | mall 现状                 | 结论                             |
+| ---------------- | ------------------------- | -------------------------------- |
+| 短信发送基础能力 | 有（阿里云短信SDK集成）   | 可参考实现方式，但未做成独立服务 |
+| 模板管理界面     | 无（模板硬编码在业务层）  | 须新建专项管理界面               |
+| 优先级消息队列   | 无                        | 须新建                           |
+| 多通道故障切换   | 无                        | 须新建                           |
+| 健康预警短信业务 | 无（纯电商领域无此需求）  | 须新建                           |
+| 多模块统一API    | 无（短信dispersed在各处） | 须统一接入点设计                 |
+
+**建设路径：独立微服务（C→D，以独立为主）**
+
+鉴于全平台27个模块都需要短信能力，建议将本系统建设为独立的基础设施微服务（类似短信网关），而非在 mall 中扩展。
+
+---
+
+## 5. 规划判断
+
+**独立微服务（短信基础设施）**
+
+- 无独立用户界面（仅有内部管理后台）
+- 对内：提供HTTP/gRPC短信发送API
+- 对外：对接阿里云/腾讯云短信平台
+- 管理界面：轻量级Vue3 Web（模板管理+统计查看）
+
+---
+
+## 6. 需新增业务能力
+
+1. **统一短信网关API**：标准化短信发送接口（单发/批量发/定时发）
+2. **模板管理与工信部报备**：短信模板的创建、审核状态管理、报备流程追踪
+3. **多通道编排**：配置主备通道，自动健康检查和故障切换
+4. **优先级队列**：至少三级优先级（紧急/普通/营销）
+5. **发送限流**：按调用方（模块）设置每小时/每日发送上限，防止异常刷量
+6. **号码黑名单**：支持用户退订（短信STOP指令处理），合规管理
+
+---
+
+## 7. 需新增数据模型
+
+| 模型                 | 关键字段                                                                                      |
+| -------------------- | --------------------------------------------------------------------------------------------- |
+| `sms_template`       | id, code, name, content, variables(array), channel_template_ids(JSONB), status, registered_at |
+| `sms_send_record`    | id, template_id, receiver, variables(JSONB), channel, priority, status, sent_at, fail_reason  |
+| `sms_channel_config` | id, provider(aliyun/tencent), access_key, priority_level, is_active, health_status            |
+| `sms_quota_config`   | caller_module, hour_limit, day_limit, current_hour_count, current_day_count                   |
+| `sms_blacklist`      | phone_no, reason, added_at, added_by                                                          |
+
+---
+
+## 8. 需新增技术栈 / 第三方能力 / 中间件
+
+| 类别       | 技术选型                         | 用途                     |
+| ---------- | -------------------------------- | ------------------------ |
+| 短信服务商 | 阿里云SMS（主）+ 腾讯云SMS（备） | 短信发送通道             |
+| 消息队列   | RabbitMQ（多级优先级队列）       | 异步发送、优先级管理     |
+| 缓存       | Redis                            | 限流计数器、号码频率控制 |
+| 监控       | Prometheus指标暴露               | 发送成功率、队列深度监控 |
+
+---
+
+## 9. 外部系统对接关系
+
+| 对接方（调用方） | 典型短信场景                    |
+| ---------------- | ------------------------------- |
+| 健康管理（08）   | 体征危急值告警 → 家属           |
+| 安全系统（09）   | SOS/跌倒/走失 → 家属+紧急联系人 |
+| 长护险（18）     | 服务完成确认 → 老人/监察员      |
+| 审批系统（04）   | 补贴审核结果 → 申请人           |
+| 居家养老（10）   | 服务预约确认 → 老人             |
+| 医养商城（19）   | 订单发货/物流更新 → 消费者      |
+| 系统管理（05）   | 账号注册/密码重置验证码         |
+
+---
+
+## 10. 风险与边界
+
+| 风险              | 说明                                                     | 应对                        |
+| ----------------- | -------------------------------------------------------- | --------------------------- |
+| 工信部模板审核    | 短信模板需报备审核，周期1-3天                            | 提前规划模板，预留报备时间  |
+| 短信费用失控      | 告警类短信量大，费用可能超预期                           | 限流配置 + 每日用量预警     |
+| 号码归属地屏蔽    | 某些运营商拦截短信                                       | 多通道备份 + 短信到达率监控 |
+| 边界：不含APP推送 | APP推送由各业务模块自行集成极光/腾讯推送，本系统仅做短信 | 明确能力范围                |
+
+---
+
+## 11. 实施优先级与分期建议
+
+**优先级：P1（基础设施，其他模块依赖）**
+
+| 分期             | 内容                                        | 说明                            |
+| ---------------- | ------------------------------------------- | ------------------------------- |
+| 第一期（P1同步） | 基础短信发送API + 验证码模板 + 阿里云单通道 | 所有P1模块的账号/通知依赖此能力 |
+| 第二期           | 模板管理界面 + 优先级队列 + 多通道切换      | —                               |
+| 第三期           | 用量统计報表 + 限流控制 + 黑名单管理        | —                               |
+
+---
+
+## 12. 结论
+
+短信平台是全平台级基础设施，须在P1阶段早期完成基础能力建设，支撑其他模块的通知依赖。
+
+mall 现有分散的短信代码可作为起点参考，但须重新设计为**独立微服务架构**，提供统一API入口，实现多通道管理、优先级调度和合规管控，避免27个模块各自维护短信代码的维护灾难。

14-智慧康养社区助餐可视化系统-模块规划.md

@@ -0,0 +1,167 @@
+# 智慧康养社区助餐可视化系统 模块规划
+
+---
+
+## 1. 模块定位
+
+智慧康养社区助餐可视化系统是以**老年人助餐服务**为核心的 O2O（线上到线下）平台，涵盖老人在线/到店点餐、刷卡/人脸识别结算、配送上门和助餐站可视化大屏管理等功能。
+
+本系统集商业价值（可快速产生可视化效果，用于招商展示）与民生价值（解决独居老人就餐难题）于一体，是平台早期可见成果最显著的模块之一。
+
+---
+
+## 2. 建设目标
+
+1. 支持老人在线点餐（小程序）和到店自助点餐（人脸识别终端）
+2. 实现助餐费用管理（政府补贴 + 个人支付混合）
+3. 提供配送上门服务（对接骑手配送系统）
+4. 构建助餐站可视化大屏（当日就餐人数/菜品销量/补贴使用情况）
+5. 与政府监管系统对接，输出助餐运营数据
+
+---
+
+## 3. 核心功能范围
+
+### 3.1 一级模块
+
+- 基本信息申请
+- 在线点餐
+- 到店自助点餐（人脸识别）
+- 配送上门
+- 助餐站管理系统
+- 可视化大屏
+
+### 3.2 二级模块
+
+- **基本信息申请**：老人助餐资格申请（年龄/失能等级），平台审核后享受补贴
+- **在线点餐**：菜品浏览、加购、下单、补贴自动抵扣、支付剩余金额
+- **自助点餐**：到店自助点餐机器（iPad/触摸屏），人脸识别身份+自动出餐
+- **配送上门**：不方便外出的老人选择配送，骑手接单配送
+- **助餐站管理**：菜品管理（每日菜单）、厨师出餐管理、库存管理、补贴核销
+- **可视化大屏**：当日就餐实时统计、补贴消耗、配送追踪地图
+
+### 3.3 核心功能说明
+
+| 功能         | 描述                                         | 技术要点                    |
+| ------------ | -------------------------------------------- | --------------------------- |
+| 人脸识别点餐 | 老人到助餐站刷脸，自动识别身份+弹出菜单      | 人脸识别SDK + 自助终端      |
+| 补贴自动抵扣 | 下单时自动计算政府补贴额度，老人只付差价     | 补贴计算引擎                |
+| 骑手配送对接 | 配送上门订单对接骑手系统（类 mall 外卖配送） | 参考 mall 骑手模块          |
+| 可视化大屏   | 实时展示当日助餐站运营数据                   | ECharts + WebSocket实时刷新 |
+| 每日菜单管理 | 助餐站每日上午更新菜品，老人11点前下单       | 定时任务 + 菜品状态         |
+
+---
+
+## 4. 与现有 mall 的关系
+
+**契合度：B（中契合）**
+
+mall 的外卖/餐饮类订单机制与本系统相似度较高：
+
+| 能力               | mall 现状                  | 可复用程度                             |
+| ------------------ | -------------------------- | -------------------------------------- |
+| 餐品目录管理       | 有商品CRUD，可视为菜品管理 | B - 直接参考，去除库存/物流复杂度      |
+| 在线下单支付       | 有完整下单链路             | B - 可直接参考，需加入补贴抵扣逻辑     |
+| 骑手配送           | 有骑手端+配送追踪          | **B - 配送上门可直接复用mall骑手模块** |
+| 商家管理（助餐站） | 有（类似外卖商家）         | B - 可参考商家端改造为助餐站管理       |
+| 支付体系           | 微信/支付宝支付            | B - 可直接对接                         |
+| **人脸识别点餐**   | **无**                     | **须独立建设**                         |
+| **政府补贴结算**   | **无**                     | **须独立建设**                         |
+| **可视化大屏**     | **无**                     | **须独立建设**                         |
+| **助餐资格申请**   | **无**                     | **须独立建设**                         |
+
+**建设路径：mall + 独立微服务（以mall为基础，扩展医养特性）**
+
+配送模块可直接复用 mall 骑手配送代码，在线点餐可参考 mall 下单流程；但补贴结算、人脸识别、可视化大屏需独立开发。
+
+---
+
+## 5. 规划判断
+
+**mall + 独立微服务**
+
+- 老人点餐端：uni-app（小程序），复用 mall 下单/支付组件
+- 助餐站管理端：uni-app 或 Vue3 Web（兼容平板收银台）
+- 骑手配送：**直接复用 mall 骑手模块**（仅需配置助餐专属配送逻辑）
+- 独立服务：补贴计算服务、人脸识别接入服务、可视化大屏服务
+
+---
+
+## 6. 需新增业务能力
+
+1. **助餐资格审核**：老人申请助餐资格→机构审核→激活补贴账户
+2. **补贴计算与核销**：按老人等级和地区标准计算补贴金额，订单完成后核销
+3. **人脸识别点餐终端**：对接助餐站触摸屏/平板的人脸识别硬件
+4. **每日菜单管理**：重复性菜品录入简化（复制前日菜单/固定菜库）
+5. **可视化大屏**：ECharts实时刷新，数据精确到分钟级
+6. **营养建议**：根据老人健康档案（可选），在点餐时展示营养搭配建议
+
+---
+
+## 7. 需新增数据模型
+
+| 模型                  | 关键字段                                                                                                                              |
+| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
+| `meal_station`        | id, name, address, district_code, manager_id, status                                                                                  |
+| `meal_qualification`  | elder_id, start_date, end_date, daily_subsidy, status                                                                                 |
+| `meal_menu`           | id, station_id, date, dishes(JSONB), publish_at, order_deadline                                                                       |
+| `meal_dish`           | id, name, image, price, category, allergen_tags                                                                                       |
+| `meal_order`          | id, elder_id, station_id, menu_date, order_type(delivery/dine-in/self-service), items(JSONB), total, subsidy_amount, self_pay, status |
+| `meal_delivery`       | id, order_id, rider_id, pickup_at, delivered_at, address, status                                                                      |
+| `meal_face_record`    | id, elder_id, station_id, recognized_at, order_id                                                                                     |
+| `meal_subsidy_ledger` | id, elder_id, month, used_amount, balance, settled_at                                                                                 |
+
+---
+
+## 8. 需新增技术栈 / 第三方能力 / 中间件
+
+| 类别     | 技术选型                        | 用途             |
+| -------- | ------------------------------- | ---------------- |
+| 人脸识别 | 腾讯云人脸识别 / 海康威视人脸机 | 到店刷脸点餐     |
+| 可视化   | ECharts + WebSocket             | 大屏实时数据展示 |
+| 骑手配送 | 复用mall骑手模块                | 配送上门         |
+| 支付     | 复用mall支付网关                | 自费部分收款     |
+
+---
+
+## 9. 外部系统对接关系
+
+| 对接方           | 内容                           | 方式            |
+| ---------------- | ------------------------------ | --------------- |
+| mall骑手模块     | 配送上门订单推送给骑手         | 内部API（复用） |
+| mall支付         | 自费部分支付                   | mall支付网关    |
+| 数据库系统（02） | 老人身份核验、档案关联         | 内部API         |
+| 审批系统（04）   | 助餐资格审核（如需政府审批）   | 内部API         |
+| 政府监管（01）   | 助餐运营数据上报               | 内部API         |
+| 长护险（18）     | 部分助餐费用可能纳入长护险报销 | ⚠️ 待确认       |
+
+---
+
+## 10. 风险与边界
+
+| 风险                   | 说明                                         | 应对                                 |
+| ---------------------- | -------------------------------------------- | ------------------------------------ |
+| 人脸识别硬件兼容       | 不同助餐站硬件品牌不统一                     | 制定统一的人脸设备入网标准           |
+| 补贴结算合规           | 补贴核销需接受民政部门审计                   | 完整留存核销记录，支持导出           |
+| 菜品食品安全           | 助餐属于食品服务，有卫生要求                 | 系统记录供餐机构卫生证，定期提醒续期 |
+| 边界：不含厨房备餐管理 | 系统不管理厨房内部流程，仅管理菜品目录和订单 | 明确系统边界                         |
+
+---
+
+## 11. 实施优先级与分期建议
+
+**优先级：P1**
+
+| 分期   | 内容                                             | 前置条件                     |
+| ------ | ------------------------------------------------ | ---------------------------- |
+| 第一期 | 在线点餐 + 到店核销（一卡通/扫码）+ 基础补贴抵扣 | mall支付、老人档案（02）就绪 |
+| 第二期 | 骑手配送上门 + 人脸识别终端 + 菜单管理           | mall骑手模块就绪             |
+| 第三期 | 可视化大屏 + 补贴核销报表 + 政府对接             | —                            |
+
+---
+
+## 12. 结论
+
+社区助餐系统是平台最具展示价值的民生服务模块，mall 在在线订餐和骑手配送方面具有 B 级可复用能力，尤其是**骑手模块可直接复用**，显著节省开发成本。
+
+建议以 mall 订单/配送能力为基础，独立开发助餐补贴结算、人脸识别点餐和可视化大屏三大核心扩展能力，**快速上线形成招商展示效果**，同时为后续政府补贴审计积累数据基础。