huangzhenbao/------------
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

上传文件至「契合度」

Browse Source
This commit is contained in:
huangzhenbao
2026-03-31 01:27:54 +00:00
parent 8e30e83a9a
commit aea5434544
5 changed files with 825 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

173
契合度/11-智慧康养服务商管理系统-模块规划.md Normal file
View File

@@ -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 内部直接改造带来的代码耦合风险。

160
契合度/12-智慧康养志愿者管理系统-模块规划.md Normal file
View File

@@ -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），兼顾成本控制和存证可信度。礼品管理模块建议轻量实现，优先保证服务记录和时间积分的准确性与可信性。

164
契合度/13-智慧康养短信平台系统-模块规划.md Normal file
View File

@@ -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个模块各自维护短信代码的维护灾难。

167
契合度/14-智慧康养社区助餐可视化系统-模块规划.md Normal file
View File

@@ -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 订单/配送能力为基础，独立开发助餐补贴结算、人脸识别点餐和可视化大屏三大核心扩展能力，**快速上线形成招商展示效果**，同时为后续政府补贴审计积累数据基础。

161
契合度/15-家庭床位及适老化改造系统-模块规划.md Normal file
View File

@@ -0,0 +1,161 @@
# 家庭床位及适老化改造系统 模块规划
---
## 1. 模块定位
家庭床位及适老化改造系统是对接**政府补贴政策**的居家养老基础设施建设管理系统，覆盖家庭养老床位的申请审核、适老化改造项目管理、智能硬件设备安装与管理、上门服务管理以及完工后的监管与数据反馈全生命周期。
本系统是政府"家庭养老床位"补贴项目落地的数字化载体，兼具政策性（审批合规）和服务性（改造施工管理）特征。
---
## 2. 建设目标
1. 实现家庭床位申请→政府审核→签约的在线化流程
2. 管理适老化改造项目（无障碍改造/辅具适配/智能设备安装）的施工进度
3. 提供智能硬件设备的入户安装记录和运营状态管理
4. 构建上门服务管理（改造施工人员的任务派发与执行记录）
5. 支持改造完成后的监管验收和数据分析
---
## 3. 核心功能范围
### 3.1 一级模块
- 家庭床位申请与签约
- 适老化改造管理
- 智能硬件设备管理
- 上门服务管理
- 监管与验收
- 数据分析
### 3.2 二级模块
- **申请与签约**：老人/家属提交申请（住房信息/失能等级）→政府审核→合同签约→补贴确认
- **适老化改造**：改造项目清单（防滑扶手/坡道/加宽门框等）、预算核定、施工队派单
- **硬件设备**：智能设备清单（呼叫器/摄像头/传感器）、安装记录、设备与老人档案绑定
- **上门服务**：施工人员任务分配、进场打卡（GPS+照片）、阶段验收、完工交付
- **监管验收**：政府/机构人员现场验收、照片留存、验收结论、补贴拨付触发
- **数据分析**：改造户数、覆盖率、改造类型分布、设备使用率
### 3.3 核心功能说明
| 功能 | 描述 | 技术要点 |
| ------------ | -------------------------------------------------------- | --------------------------------- |
| 改造项目清单 | 标准化改造项目目录，老人可选择，自动计算补贴金额 | 项目目录 + 补贴单价配置 |
| 施工进度追踪 | 施工人员上传每阶段进度照片，管理员远程查看 | 移动端拍照 + OSS存储 + 进度状态机 |
| 硬件设备绑定 | 设备SN码与老人档案绑定，安装完成后自动接入安全系统（09） | 设备注册API调用 |
| 验收流程 | 竣工照片+验收人员签字→触发补贴核定指令 | 电子签名 + 工作流 |
| 数据看板 | 改造进度、户数统计、资金使用率 | ECharts |
---
## 4. 与现有 mall 的关系
**契合度：C（低契合，部分结构可参考）**
mall 的服务型订单和上门服务概念与本系统有部分相似性：
| 能力 | mall 现状 | 可复用程度 |
| -------------------------- | -------------------- | ---------------------------------- |
| 服务订单状态机 | 有（居家服务参考） | C - 可参考状态流转设计 |
| 上门服务人员（类骑手） | 骑手端GPS打卡+照片 | C - 可参考移动端设计，场景差异大 |
| 审核流程 | 商家入驻审核（基础） | C - 参考意义有限，合同签约逻辑不同 |
| **家庭床位申请（政策性）** | **无** | **须独立建设** |
| **改造项目目录与补贴核算** | **无** | **须独立建设** |
| **IoT设备入户安装** | **无** | **须独立建设** |
| **政府验收与补贴拨付触发** | **无** | **须独立建设** |
**建设路径：mall + 独立微服务（以独立为主，参考 mall 服务订单设计模式）**
---
## 5. 规划判断
**mall + 独立微服务（独立为主）**
- 老人/家属申请端：uni-app（小程序）
- 施工人员端：uni-app（移动端）
- 管理/验收端：Vue3 Web
- 服务端：独立项目管理服务
- 与安全系统（09）和IoT管理（16）通过API对接完成设备注册
---
## 6. 需新增业务能力
1. **家庭床位申请流程**：在线填写住房信息、上传证明材料、等待政府审核
2. **标准改造项目目录**：国家/地方补贴支持的改造项目清单和补贴金额上限
3. **施工人员任务派发**：按地区和技能分配施工任务，移动端接单
4. **多阶段验收机制**：开工照片→中期照片→竣工照片→政府/机构验收
5. **设备入户注册**：安装设备后自动注册到IoT平台，与老人档案绑定
6. **补贴核算与拨付请求**：验收通过后自动生成补贴申请单，流转至审批系统（04）
---
## 7. 需新增数据模型
| 模型 | 关键字段 |
| ------------------------- | -------------------------------------------------------------------------------------------------- |
| `home_bed_application` | id, elder_id, address, house_type, disability_grade, status, approved_at, contract_url |
| `renovation_project` | id, application_id, items(JSONB), total_estimated_cost, subsidy_amount, start_date, end_date |
| `renovation_item_catalog` | id, name, category, unit, max_subsidy_per_unit, description |
| `renovation_execution` | id, project_id, worker_id, checkin_time, checkin_photo, phase, phase_photos(array), notes |
| `renovation_acceptance` | id, project_id, acceptor_id, accept_type(gov/platform), accept_date, result, photos, signature_url |
| `iot_device_install` | id, project_id, device_sn, device_type, elder_id, install_at, registered_to_iot_at |
---
## 8. 需新增技术栈 / 第三方能力 / 中间件
| 类别 | 技术选型 | 用途 |
| -------- | ---------------------- | ------------------------ |
| 文件存储 | 阿里云OSS | 施工照片存储 |
| 电子签名 | Canvas签名 / 法大大 | 验收签字 |
| 工作流 | 参考04号模块轻量工作流 | 申请→审核→签约→施工→验收 |
| GIS | 高德地图 | 施工人员打卡定位 |
---
## 9. 外部系统对接关系
| 对接方 | 内容 | 方式 |
| ---------------- | ------------------------------------ | ------------- |
| 审批系统（04） | 家庭床位申请政府审核、验收后补贴申请 | 内部工作流API |
| 数据库系统（02） | 老人档案查询、失能等级核验 | 内部API |
| IoT管理（16） | 安装设备注册到IoT平台 | 内部API |
| 安全系统（09） | 安装设备后与老人绑定，启动监测 | 内部API |
| 政府监管（01） | 改造覆盖率、验收完成率统计 | 内部API |
---
## 10. 风险与边界
| 风险 | 说明 | 应对 |
| ------------------------ | ---------------------------------------------------------------- | ----------------------------------- |
| 补贴政策地区差异 | 各地适老化改造补贴标准不同 | 改造项目目录和补贴金额可按地区配置 |
| 施工质量纠纷 | 改造完工后老人不满意 | 完整照片留存 + 验收签字防止事后争议 |
| 设备安装标准 | 不同品牌设备安装规范不同 | 建立设备安装规范文档 |
| 边界：不含房屋结构性改造 | 只管理适老化改造（辅具/设备/无障碍），不涉及房屋产权和结构性施工 | 明确改造项目范围 |
---
## 11. 实施优先级与分期建议
**优先级：P1（政策窗口期必须抓住）**
| 分期 | 内容 | 前置条件 |
| ------ | ------------------------------------------ | --------------------------------- |
| 第一期 | 家庭床位申请 + 基本改造项目管理 + 施工执行 | 老人档案（02）就绪 |
| 第二期 | 政府验收流程 + 补贴核算 + IoT设备注册 | 审批系统（04）、IoT管理（16）就绪 |
| 第三期 | 数据分析 + 政府监管对接 | — |
---
## 12. 结论
家庭床位及适老化改造系统兼具政策性和服务性，mall 的服务订单框架对本系统有一定参考价值（C级），但改造项目管理、政府审批闭环、IoT设备入户注册等核心医养特性须独立建设。
**建议以独立系统建设为主**，在P1阶段优先完成申请→审核→施工→验收的核心流程，把握政府"家庭养老床位"建设补贴的政策窗口期。