1.立项原因:
家属找护工多靠中介和微信群,人靠不靠谱、什么时候上门、服务做到哪一步,往往对不上。小红护工要解决的是:家属在线发布照护需求并选定护工,护工按订单完成抢单或报价、预约、上门签到和服务;平台把支付、取消和售后放在同一条订单里,减少爽约、漏签到和结算纠纷。
2.行业场景
面向居家养老和医院陪护。分为短期陪护和长期住家照护。用户按被照顾人情况、服务地址和天数下单,护工按技能和位置接单,平台按订单状态验收和结算。
点击空白处退出提示
1.立项原因:
家属找护工多靠中介和微信群,人靠不靠谱、什么时候上门、服务做到哪一步,往往对不上。小红护工要解决的是:家属在线发布照护需求并选定护工,护工按订单完成抢单或报价、预约、上门签到和服务;平台把支付、取消和售后放在同一条订单里,减少爽约、漏签到和结算纠纷。
2.行业场景
面向居家养老和医院陪护。分为短期陪护和长期住家照护。用户按被照顾人情况、服务地址和天数下单,护工按技能和位置接单,平台按订单状态验收和结算。
1.功能模块
用户端、护工端、管理后台。用户端和护工端都有微信小程序和 App。客户端覆盖下单、接单、履约、支付和售后。
2.主要功能
(1)用户:绑定被照顾人、填写服务地址,发布短期或长期护工需求,查看护工、收藏、用券,并完成支付。
(2)选人:支持抢单,也支持护工报价后由用户选定。
(3)护工:入驻审核、抢单大厅、报价池、工作台;订单从待开始、待预约、待上门、上门签到到服务中、已完成。
(4)签到:到达服务地址后拍照签到,照片带水印,避免人未到场却显示已上门。
(5)异常:服务中可上报异常,取消走协商,必要时平台介入;用户可申请售后。
(6)收入:护工查看收入;后台审核入驻、订单和售后。
1. 我负责的任务
负责小红护工用户端、护工端的需求拆解、功能开发和回归验收。具体包括下单、抢单与报价、预约上门、签到、支付对接、售后,以及小程序和 App 的流程对齐。
2. 技术栈与架构
(1)用户端、护工端微信小程序。
(2)用户 App、护工 App 用 Flutter。
(3)接口和管理后台为 Node.js / Express + React,数据在 MySQL;支付走微信支付。
(4)各端共用同一套订单状态,身份按应用和账号隔离。
3. 亮点与难点
订单状态多,抢单、报价、预约、签到、取消、售后要在四个客户端上保持一致。上门签到要同时核对位置和现场照片。长期和短期护工的下单字段不一样,表单和风控要分开,避免填错仍能下单。







评论