有爱设计

应用数
95
安装量
1.3万

应用圈

最后在线：: 2026-08-22
客服时间：: 工作日 9时~21时

其他应用

热门应用

陪诊陪护服务平台V1.0

收藏分享投诉

¥1298.00

统　　计:共 0 次下载
更新日期:2026-07-31
适配编码:UTF8SC
兼容版本:X5.0 X5.1
PHP版本:8.0 8.1 8.2 8.3 8.4
标签分类:社区功能增强其他功能
移动属性:该版本安装后自带手机版（触屏版）
开发方式:作者申明该应用大量使用 AI 辅助开发，请谨慎考虑

购买应用 免责声明

应用介绍

# 知晓陪护 · 陪诊陪护服务平台（详细介绍）

&amp;gt; 面向论坛与社区场景的陪诊陪护服务管理插件，连接平台审核的陪护师与有照护需求的家庭，覆盖 H5 页面、Discuz RESTful 小程序接口与后台运营，帮助把预约、派单、履约、结算等环节集中到一套流程中管理。

## 一、插件概述

「知晓陪护」是一款运行于 Discuz! 平台的陪诊陪护服务管理插件，围绕到院陪诊、住院陪护、上门护理、跑腿代办等服务场景，提供服务展示、在线预约、接单派单、服务留痕、支付结算与售后评价等能力。

插件按业务环节组织功能，前台页面、RESTful 接口与后台管理共用同一套业务逻辑，便于在多种终端保持一致的体验与数据口径。整体设计强调「流程可追溯、金额可核对、权限可校验」：订单的每一次状态变化都留有审计记录，款项与佣金可逐单核对，关键操作在执行前都会校验登录态、归属与状态。

## 二、服务目录与 SKU 体系

插件内置一组示例服务，运营方可在此基础上增删改：

- **到院陪诊**：挂号取号、检查陪同、报告代取、医患沟通等院内流程陪同；
- **住院陪护**：病房值守、协助进食翻身、术后观察、医护沟通等；
- **上门护理**：康复期居家照护、日常起居协助、康复训练陪同等；
- **跑腿代办**：报告代取、药品代开、窗口排队、资料打印等；
- **其他服务**：如代办问诊、康复陪同、夜间值守、慢病陪访等，可按需扩展。

每个服务项目作为**独立 SKU** 管理，包含编号、分类、图标、名称、描述、标签、基准价、计价单位、数量上下限、提前预约时间下限、是否热门、排序与上下架状态等字段。热销服务可标记以便前台突出展示，列表支持按分类与排序呈现。

## 三、运营区与区域定价

**运营区**是服务与定价的空间维度，每个运营区可配置：

- 名称与排序、上下架状态；
- 接单模式（抢单或后台派单）；
- 各方分成比例（陪护师、团队长、推广人、运营区、平台）；
- 派单模式下的派单员账号。

**区域价格**在「服务 + 运营区」的维度上配置，可为同一服务在不同运营区设置不同的单价、夜间费用、 * ** * 或节假日加价率、指定陪护师费用以及数量与预约限制。这样，价格既能在区域间差异化，又能在订单生成时被准确引用。

## 四、下单与计价

下单页选择服务、运营区、数量、时段（白天 / 夜间 / 节假日或 * ** * ）与是否指定陪护师后，**由服务端重新核算费用**，客户端展示的价格不作为成交依据。订单会保存单价、基础费用、时段附加、指定费用与合计，以及一份完整的报价快照，使后续改价不影响历史订单。

金额口径上，服务与订单层面以**整数元**记录，在支付网关、佣金与提现的边界处换算为**分**，以减少浮点误差；非平台角色的份额向下取整，余数归入平台，使每笔订单的佣金流水合计与订单净额保持一致。

## 五、订单状态机与审计

订单状态定义为：待支付、待接单、已接单、服务中、待确认、已完成，以及已取消、已退款、退款中等分支。主流程为「待支付 → 待接单 → 已接单 → 服务中 → 待确认 → 已完成」。

所有业务流转**统一经过合法状态迁移校验**，后台不再允许任意更改状态；每一次创建、支付、派单、开始服务、完成、确认、取消、售后与退款操作，都会写入订单审计记录，包含操作人、角色、变更前后状态、原因与请求标识，便于事后追溯与对账。

## 六、陪护师身份、派单与抢单

可接单身份需同时满足：关联论坛账号、平台审核启用、已有审核时间、运营区匹配、服务资质匹配、接单状态为可接单。缺少运营区或服务资质的旧展示档案不会进入派单池。

- **抢单**：采用条件更新，保证在并发场景下同一订单只有一名陪护师接单成功；
- **派单**：运营区可配置为后台派单，指定陪护师的订单在支付后自动尝试派给指定账号，匹配失败时生成运营通知，便于人工跟进；
- **更换陪护师**：仅在已接单且尚未开始服务时允许，并清空原派单快照后重新进入待派单。

## 七、服务过程留痕

服务过程中，陪护师可提交服务进展、到达打卡、完成凭证等记录，每条记录可包含文字、图片与定位信息。提交时会校验订单归属与服务状态，完成服务前需提交服务记录。用户在订单详情中查看已提交的进展、图片与定位，以及由审计记录构成的时间线，使关键节点有据可查。

## 八、支付、计划任务与售后

**支付**：下单由服务端报价并创建待支付订单，随后进入统一收银台。统一支付不可用时，仅当已配置真实热线或收款说明才允许回退线下支付，空配置不会生成无法履约的付款单。支付回调按支付单金额校验，并原子推进订单状态，重复回调保持幂等。

**计划任务**：插件提供订单维护计划任务，安装或升级时自动注册为定期执行，负责待支付取消、支付单过期、超时待接单提醒、超时自动确认、补结算、佣金解冻与通知重试等维护工作，每次运行写入维护日志。

**售后**：退款先原子抢占为「执行中待核对」，避免重复触发网关退款，异常中断的记录保留给人工对账。用户可针对订单提交退款、投诉或更换陪护师工单，由后台按类型处理；退款仍走独立的退款审批链路。

**评价**：已完成订单仅可评价一次，评价包含服务质量、服务态度、响应效率等维度与标签、内容，可选择匿名展示；评价会自动回算陪护师的完成单量、平均评分与好评率，没有有效评价时如实显示「暂无评分」，不预设满分。

## 九、通知与外部回调

通知先写入通知日志，再分别投递论坛站内通知与可选的外部回调；每个渠道记录各自的发送时间，重试时不会重复发送已成功的渠道，从而在保证送达的同时避免重复打扰。运营方可配置外部回调地址与签名密钥，用于与自有系统对接。

## 十、团队、推广与结算

团队可配置团队长、推广人、运营区与邀请码。用户推广归属**仅允许首次绑定**，并在下单时快照推广人及推广团队；后续调整团队不会反向影响历史订单。派单时另行快照陪护师团队与团队长，避免覆盖用户的推广归属。

订单完成后，按运营区的陪护师、团队长、推广人、运营区与平台费率，生成精确到分的佣金流水；无有效归属的份额并入平台，历史少记的分录可幂等补齐到订单净额，多记时保留原账并提示人工核对。提现按所选角色的可提现流水采用先进先出方式预占，后台人工打款或拒绝后再完成或释放预占。

## 十一、接口能力（RESTful）

插件提供一组 RESTful 接口，按功能分组：

- **公共目录**：首页聚合、服务列表、陪护师列表、运营区、常见问题、价格计算；
- **用户订单**：创建订单、我的订单、订单详情、取消、支付、确认完成；
- **收入提现**：收入统计、申请提现、提现列表；
- **陪护师作业**：入驻申请与状态、档案、在线状态、可接订单、抢单、接单列表、开始服务、完成服务、添加记录、上传图片；
- **售后评价**：售后申请与列表、评价提交与详情；
- **通知推广**：通知列表与已读、推广绑定与统计。

业务层统一返回「状态码 + 提示信息 + 数据」的结构；经 Discuz RESTful 网关时，该结构位于网关响应的数据字段中。写接口仅接受 POST 请求；H5 入口校验表单令牌，RESTful 入口由网关鉴权并启用接口级限流。图片上传必须携带订单标识，且 * ** * 服务阶段、订单所属陪护师操作。

## 十二、后台运营配置

后台可依次配置运营区与分成、服务 SKU、区域价格、团队、陪护师账号与资质范围及接单状态；并可在插件设置中配置服务热线、平台收款与通知账号、外部回调地址与签名密钥等。未配置真实热线或收款说明时，线下支付保持关闭；平台账号未配置时，平台佣金进入内部对账桶，但不能发起平台提现。

## 十三、数据与计划任务

数据层由多张表构成，覆盖基础与定价（运营区、服务、区域价格）、身份与团队（入驻申请、陪护师、团队、推广归属）、订单与审计（订单、订单审计、服务记录）、支付结算（支付单、支付配置、退款、佣金流水、提现）、运营闭环（通知日志、售后、评价、计划任务日志）等。安装时写入示例运营区、服务 SKU、常见问题与支付渠道骨架，便于快速体验；计划任务在安装或升级时自动注册，可在后台「计划任务」中查看与启停。

## 十四、适用场景

- 在论坛或社区内开设陪诊陪护服务板块；
- 面向长者照护、术后陪护、就医陪同等需求的预约与对接；
- 需要把服务过程、订单与结算集中管理的运营团队；
- 希望通过团队与推广人扩大服务覆盖的运营场景。

## 十五、温馨提示

- 服务时间、接单响应、售后处理与赔付等事项，以平台实际运营规则与公示的服务协议为准；
- 陪护师资质由平台审核，具体可服务范围以运营区配置与订单约定为准；
- 价格以下单时服务端核算并保存的报价快照为准，运营区与服务的定价以后台配置为准；
- 本插件为服务信息管理与流程协作工具，不代替专业医疗诊断与治疗，如有健康需求请遵医嘱或及时就医。