直接切入正题吧。做了一年多就医陪诊小程序从需求调研、搭架构、上审核、跑通第一批订单到后来慢慢优化功能我对这个品类的“实用度”感受还挺深的。网上聊陪诊的文章大多是站在患者视角说它有多方便对流程的分析停留在“下单-陪诊-结束”三步真到了软件设计层面很多细节都要被重新审视。这篇文章就从开发者的视角拆一拆就医陪诊小程序的实用度到底体现在哪哪些功能是刚需哪些功能其实是在自嗨。先说一下大背景。就医陪诊这个服务能跑起来本质上是因为“医院越来越大、流程越来越碎、但家属能请假的时间越来越少”。挂号、取号、候诊、问诊、检查、缴费、取药一个普通门诊患者跑下来平均要进出六七个窗口中间还要应付各种“先去盖章再回来排队”的操作。对于老年人、孕妇、异地患者、手术前后行动不便的人这些流程是真消耗体力。陪诊师的价值不是“陪聊”而是把这些不产生医疗决策但极其消耗时间的事情接过去让患者只专心做一件事跟医生把病情说清楚。但这只是业务层面的逻辑。落到软件上事情就复杂了你既要让家属远程放心又不能把陪诊师的日程排得太死既要保证订单全流程可回溯又不能在用户界面堆满操作供需匹配的实时性、位置的精确度、异常情况的兜底每一个都是开发时的硬骨头。下面从几个角度慢慢展开。1. 项目定位与产品设计取舍1.1 先想清楚服务边界陪诊不是代诊我对这个项目的第一判断就是陪诊小程序的核心并不是“连接患者与陪诊师”这么简单而是要在一大堆医疗规则、隐私限制、服务标准的夹缝里找到一个能被线上化的服务边界。开发前我们做了不少用户访谈发现真正高频使用陪诊服务的用户诉求其实高度集中。最常见的是子女给父母下单其次是孕妇、异地患者、术后复查人群还有一小部分是企业给员工采购的健康福利。这里有个很大的误区很多人觉得陪诊师应该“帮患者做医疗决策”比如帮忙选科室、帮忙解读检查单甚至有人会问陪诊师能不能帮患者决定是否手术。这个边界绝对不能碰。陪诊师的工作是陪同、代办、记录、传达绝对不能介入诊断和治疗方案的判断。所以法律文本、免责声明、服务协议这些看起来“放在注册页没人看”的东西反而是项目地基。我们在用户端、陪诊师端、后台管理系统里分别放了不同颗粒度的服务条款在支付前必须勾选并且会把“不提供医疗建议”这一点用显眼字体标出来。别小看这一步后面所有功能设计都是围绕“事务代办信息同步”这条主线展开的边界越清楚产品功能就越不会被跑偏。1.2 为什么是小程序而不是独立App这个决策其实用不着太多纠结。用微信小程序主要有三个理由获客和触达成本低。用户扫码即用或者从公众号、朋友圈文章里点开就能打开不用跳转到应用商店下载几百兆的安装包。陪诊是一个典型的低频刚需服务“低频”意味着用户不愿意为你专门装一个App“刚需”意味着用户打开即走的概率很高。分享逻辑顺畅。家属下单后往往需要拉其他家庭成员一起关注服务进度。在微信里一个小程序卡片转到家庭群点开就能看到陪诊师到哪儿了、检查排到几号这种体验是App很难复制的。对陪诊师来说工作台放在小程序里也够用了他们真正高频用的功能就是接单、拨号、打卡、拍照上传。这些操作在服服务现场用手机完成不需要后台复杂的管理界面。当然小程序也有局限我们在后面“技术难点”部分会聊到比如后台位置保活、订阅消息次数限制、包体积限制等。但从商业验证角度看先用小程序跑通模型是最理性的选择。1.3 三类核心角色与各自的功能主线整个系统里主要有三个角色患者/家属下单方核心诉求是“快速下单全流程可见”。陪诊师服务方核心诉求是“单量稳定、流程清晰、减少扯皮”。运营/客服平台方核心诉求是“能实时看到每张订单在哪个节点出异常能介入”。这三类角色并不是简单地在一个App里做三套菜单而是要在同一个订单流程中协同。我画过好几版流程图最后的结论是所有页面和接口设计都必须围绕“订单状态机”来组织。用户端看到的是“已支付—待服务—服务中—已完成”陪诊师端看到的是“待接单—已接单—前往医院—已到达—服务中—服务完成—报告待提交”后台还有一套隐含的“指派失败—客服介入—退款处理”的异常状态。一张订单在三个端呈现出的状态不同但它们必须对应到同一条状态机数据上否则就会产生“用户认为服务还没开始陪诊师已经提交完成了”的纠纷。2. 核心功能模块拆解2.1 完整服务主链路从预约到售后回访我们这个项目的服务主链路最终落地为这么一条流程家属/患者通过小程序选择服务类型全程陪诊、单项代办、手术陪护等、医院、日期和时间段填写患者基本信息。提交订单并支付预付款预付款的作用是锁定陪诊师时间也过滤掉一部分乱下单的用户。系统将订单推送给符合条件的陪诊师条件包括所在城市、医院熟悉度、当日空闲时间段、服务类型匹配度。陪诊师抢单成功后进入履约流程出发前提醒、到达医院打卡、逐项执行排队取号、陪同就诊、代缴费用、取报告、取药每一步都要拍照 文字记录。服务完成陪诊师提交服务报告用户确认平台向家属推送报告摘要订单进入结算和评价环节。售后用户申请开具发票、联系客服、售后申诉、评价追踪。这些环节里容易被第一次做这类产品的人忽略的是“预约时间精度”和“医院实际排队时间”之间的冲突。你给用户承诺“陪诊师2点到医院”但医院候诊排队可能需要两小时这意味着陪诊师的时间被拉得非常长而用户支付的费用是按服务时长/服务类型算的。所以我们后来引入了“服务段价格”模式基础陪诊费覆盖一个标准时段超过时长后按半小时为单位加收超时费而且在订单页明确告知。这个规则看起来冷冰冰但真的能避免“用户觉得陪诊师一直在等着所以应该多陪”“陪诊师觉得超时了想加钱”的两头扯皮。2.2 订单状态机整个系统的“方向盘”如果说这个小程序只能留下一段代码我会保留订单状态机。它不只是一个字段更是一整套规则引擎。我们的订单状态设计主要有这几组待支付 / 已关闭用户未付款超时关闭待指派 / 待接单已支付等待陪诊师接单待服务陪诊师已接单未到服务时间服务中包含多个服务阶段前往、签到、排队、就诊、检查、缴费、取药、完成待确认 / 待结算陪诊师已提交报告已完成退款中 / 已退款已取消区分用户取消、陪诊师取消、平台介入取消每个状态下能执行的操作是被锁定的。比如用户已支付但陪诊师还没接单用户可以直接取消订单并全额退款一旦陪诊师接了单用户取消就需要陪诊师同意如果陪诊师已经开始履约取消订单可能产生一定的取消费用。这些规则若不用状态机约束散落在各个业务代码里早晚会出现“用户取消了订单但陪诊师照样到了医院”的乌龙。这里我建议开发者朋友状态机不要用简单的硬编码嵌套判断来实现每一条状态迁移都记录操作人、时间、原因后台能回溯。否则日后有人投诉“订单在什么时间点变成完成状态的”你连审计日志都给不出来就会非常被动。2.3 陪诊师端为了“少被打扰”而做的设计陪诊师端是我花心思最多的模块因为他们的使用场景非常特殊一只手拿着患者病历另一只手可能举着手机在医院大厅拍照时不时还要回复家属消息。陪诊师端的关键功能并不是一个复杂的项目管理工具而是三件事接单要快、打卡要方便、记录要省事。接单模块做了抢单大厅和时间筛选陪诊师可以设置自己熟悉的医院和可服务时间只接收匹配订单。打卡模块则在每个关键节点埋了“定位 拍摄上传”的双重验证比如到达医院后需要拍摄门诊大楼照片才能进入下一个步骤。这样既保证服务真实发生也方便后台审核。服务记录做成了类似“时间轴”的界面上架每完成一个步骤点一下自动追加时间戳拍完照直接附在对应步骤下面。这比“写一篇长报告”要省力得多。报告其实最后会自动生成一个结构化摘要家属端看到的就是一组有时间节点的记录。还有一个非常实用的细节陪诊师端内置了“常用医院路线指引”这个口碑功能可以节省大量培训沟通成本。很多陪诊师并不是每三甲医院都熟把核酸检测点、手术室、放射科在哪个楼哪层、取药窗口靠近哪个门、特需门诊入口位置这些信息以图文笔记沉淀下来新入驻陪诊师上手会快很多。这也是后来被认可为陪诊师端最实用的功能之一。2.4 用户端让家属“远程陪伴”而不是“远程焦虑”用户端的体验目标不是“功能丰富”而是“不焦虑”。所以我把关键信息做了层级化进入订单详情页用户首先看到的是一个简化的进度条而不是密密麻麻的日志列表。进度条分五步已接单、前往医院、服务中、服务完成、报告已生成。想看细节再下拉展开。比较有代表性的是“位置共享”和“摄像头拍照上传”的组合。陪诊师开始服务后用户可以看到陪诊师的大致位置脱敏后的以及每个时间点上传的现场照片。很多子女下单后并不能真的赶到医院只能远程看着父母在候诊区坐着而陪诊师每上传一张照片远程的家属就会觉得“有人看着我爸妈”。另外就是要做好“多端同步”。我们支持一个订单绑定多个关注人家属、子女、配偶可以在不同地点同时查看订单状态。这个功能实现起来不难但它触碰到的心理需求比表面看起来更深能够解决“消息就发到一个人手机上其他家属不知道进度”的问题。后来我们在很多订单完成后收到类似评论“最方便的就是可以把进度同步给姐姐她在外地也能看到检查结果出来了。”2.5 后台管理系统运营的“上帝视角”后台管理系统是很多人做此类项目时最容易敷衍的部分但我反而觉得它决定了项目能不能规模化。后台分几个子模块订单管理全量订单的搜索、筛选、导出每一单的时间轴记录。陪诊师管理审核入驻、排班、接单记录、服务评分。财务结算陪诊师服务费、用户退款、平台佣金、提现记录全部对账清晰。用户管理用户画像、敏感操作、投诉记录。异常处理超时未接单、服务中断、客服改单、退款审核。比较关键的是“超时未接单”的自动干预机制。我们设置的是当订单发布后10分钟内没有陪诊师接单后台自动给运营人员发送告警运营可以主动定向邀请附近空闲的陪诊师或者给用户发一张优惠券安抚等待时间。系统不能对这类异常视而不见因为用户很可能已经处在非常着急的状态里了。3. 技术选型与架构解析3.1 前端技术栈用uni-app做跨端性价比最高前端技术栈用了uni-app主要考虑是它能一套代码同时编到微信小程序、支付宝小程序和H5。就医陪诊这类业务用户来源不只在微信很多异地下单的家属可能在百度/支付宝搜索场景里出现所以预留了其他小程序端的可能性。而且uni-app的社区生态比较成熟地图、支付、扫码、音视频等原生能力都有现成插件省了很多适配时间。如果你问我原生小程序和uni-app选哪个我的建议是如果团队里没有熟悉原生的小程序工程师或者产品需要在多个平台上快速试错选uni-app更稳如果特别追求首屏性能、交互动效和极致的细节控制那原生开发肯定更顺手。我们的项目用uni-app没有遇到什么不可解决的瓶颈体感还是不错的。3.2 后端与消息通信状态同步的关键后端用了Spring Boot用一套RESTful接口提供业务能力搭配WebSocket做实时消息推送。订单状态的每次变化、聊天消息、位置上报都会通过WebSocket通道实时通知到相关端。这里有个设计细节WebSocket不是连到用户端就算完客户端要根据用户身份订阅对应的一批订单才能收到这些订单的通知。订阅关系的维护用到了Redis的Hash Set按用户维度存储“当前活跃的订阅列表”。如果团队没有WebSocket经验也可以用轮询查询订单状态。但陪诊过程本身可能要持续几个小时轮询太长实时性不够轮询太短对服务器压力成倍增加。WebSocket 订阅模式会稳定很多。对于第一次做这类实时交互项目的朋友建议预留心跳探测和断线重连机制小程序一旦切后台再回前台很容易碰到连接断开的问题。3.3 数据模型设计订单、服务记录、陪诊师档案核心数据模型大概有这些用户表患者详情、常用就诊人、隐私授权陪诊师表资质信息、熟悉医院列表、接单安排订单表订单号、状态、金额、服务类型、时间段、医院ID服务记录表每个状态节点的时序记录、拍照URL、定位坐标评价表用户对陪诊师、陪诊师对用户结算表陪诊师的收入流水、提现记录、平台佣金退款表退款单、原因、审核状态消息表站内信、聊天记录、订阅消息发送流水设计时两点提醒订单号的生成建议做成“可读性高”的格式比如 JY 年月日 6位自增 随机校验码。原因是没有哪个用户愿意向客服报一串20位乱码客服也得能从订单号里快速分辨出日期。服务记录不要设计成太规范化的关系表因为不同医院、不同服务类型的节点差异非常大。建议保留一组JSON格式的扩展字段灵活记录自定义步骤否则后端会天天被需求改表折腾。3.4 安全与合规这块的钱不能省这个项目最敏感的数据就是患者的个人信息和医疗信息。我们做了几件事实名认证。下单方和陪诊师都要求实名认证关键操作验证身份证号和本人照片比对。这是平台对服务真实性的底没有实名的“自由接单”模式后面出了诈骗事件后悔都来不及。数据脱敏。病历照片、诊断意见、检查报告在小程序端默认展示打码状态只有完成授权后可以查看原图。通信链路上用HTTPS 数据加密图片临时链接设置过期时间防止被长期盗用。授权记录留痕。每次访问重要隐私数据后台都会记录日志用户同意协议时也会记录协议版本号和同意时间。这里不是矫枉过正真遇到投诉时这些日志是平台自证清白的关键证据。用微信支付商户号时必须提交营业执照、经营类目和平台资质材料。这一步比想象中耗时建议项目启动早期就同步开始申请不要等代码写完再去申请。3.5 性能优化首屏要快弱网要稳陪诊小程序是典型的“打开即用、用完即走”的工具型产品首屏加载速度和弱网稳定性都直接决定转化率。首屏上我们对接口做了合并请求进入首页一次性拉取“城市列表 常用医院 可约时间段 陪诊师评分摘要”而不是拆成三四个请求慢慢返回。分包加载也做了一部分把用户不常访问的后台协议、帮助文档这一类页面放进分包主包体积控制好避免审核时碰见包大小红线。弱网优化则要处理两个场景客户端有时候在医院地下车库网络信号差陪诊师在医院走廊里上传照片网络断断续续。上传模块我们做了断点续传和失败重传并且在前端对图片做了压缩压到原图的30%左右后再上传。清晰度完全够用于服务留痕上传速度却快了很多。实测下来图片压缩后失败率明显下降。4. 实操过程中的难点与踩坑4.1 小程序类目和审核医疗相关审核更严小程序上架审核阶段我一度觉得产品设计都不是最难的事最难的是类目审核。陪诊服务性质比较特殊它不提供诊疗服务但又与医疗场景强相关。微信的类目体系里医疗健康类目对资质文件要求比较严特别是涉及在线问诊、挂号导诊等都需要医疗机构执业许可证之类的资质。而陪诊服务在不少地区的经营范围里并不属于医疗机构服务结果就是卡在类目选择上。我们的处理方式是营业执照上加“健康管理服务”“陪诊服务”“个人事务代办服务”这类经营描述同时把小程序里涉及医疗的专业术语做调整突出“陪护”“代办”“生活服务”属性弱化“医疗”“诊断”等字眼。提交审核时同步上传服务协议、免责声明、隐私政策页面链接并附了一份详细的服务边界说明写好之后审核顺利了不少。这个经验不一定适合每一个团队但至少说明一个道理类目资质不只是填个表单它决定了你的产品能用什么方式描述自己。做这类项目前一定要先把资质和类目研究透而不是先埋头写代码。4.2 派单调度抢单模式还是自动指派最初我们做的是派单大厅自主抢单实际上线后发现一个问题新入驻的陪诊师没有服务记录和评价抢单成功的概率极低数据越来越难看。后来做了改进结合“评分、接单率、响应时长、所在位置”做加权排序在派单大厅中把更近且评分高的陪诊师排在前面。另外也增加了“自动邀请”逻辑当匹配到高度合适的陪诊师时系统给他推送一条强提醒而不光靠他去大厅翻。这个场景里最让人头疼的是“同时只有一两个陪诊师在线”的情况。因为陪诊是一个供给分散的市场不是每时每刻都有大量陪诊师在线接单。订单发布后无人响应很快就变成“体验下降”的问题。我们的折中方案是在用户端设置“代排队/代取报告”这类低时长服务单和服务全流程的长单区分开碎片化地吸纳闲散时间让陪诊师更容易安排日程也让平台在非高峰时段也能消化订单。4.3 实时位置小程序没法“后台跑”小程序里做实时位置同步比App要难一个档次。微信小程序在离开前台后系统随时可能回收能力纯靠小程序本身没办法保证“一直把定位上报到服务器”。我们把位置同步的结构改成了三段式陪诊师在前台服务时每30秒上报一次经纬度更新订单位置记录。如果陪诊师切到后台小程序无法主动上报就用微信的订阅消息触发一个“回到前台补报位置”的提醒或者利用后台运行时机尝试再上报几次。当陪诊师进入关键阶段如已到达医院、开始候诊引导陪诊师主动点击打卡这个打卡动作里会强校验定位确保服务真实发生在医院附近。实际体验下来这样能实现的精度大约是“知道陪诊师大概在医院片区内”对用户端的展示目的已经足够。如果真的有陪诊师故意在服务中途不按要求打卡后台的定位间隔记录也能辅助判断。4.4 收费和结算简单透明比什么都重要一开始我们设计过复杂的“服务费 超时费 夜间服务费 距离补贴”叠加模型结果上线后发现用户看不懂客服被问爆。后来改成了一种更清爽的模式按服务精英时段定价比如早8点到下午5点之间一个价格夜间另加费。每次下单总价前就把预估费用、超时规则、取消规则统统展示清楚让用户自己确认。结算模型简化后退款纠纷和客服工作量明显下降。陪诊师结算方面我们采用“服务完成后T1自动结算满100可提现”的规则平台抽成比例在后台配置。这里提醒一点如果财务要为陪诊师提供提现服务需要对接企业付款到零钱能力在微信商户平台的“商家转账”功能里配置好否则人工提现会累死财务。4.5 用户体验细节这些功能真的被高频使用上线一段时间后我仔细看过后台的埋点数据性能和留存最高的几个功能订单进度提醒通过订阅消息推送。用户订阅后当订单状态从“已接单”变化成“服务中”时会自动推送消息家属不用一直盯着小程序刷新。这个功能的使用率极其高尤其是下单后就把小程序关掉的那些家属。服务记录的拍照留痕。陪诊师每拍一张照片后台都代表了一部分家属的信任感。这个东西看起来不起眼反而是评价里提到最多的细节。“我的就诊人”一码关联。用户可以预先维护好最多5个就诊人信息家属下单时不用临时手输身份证号、病历号下单时长缩短不少。客服一键拨号。遇到异常用户不用去订单详情页里找“联系客服”按钮而是通过聊天页右上角的电话图标直接拨打。做这个功能看似简单但直接改善了用户对平台“有没有人管我”的第一感受。4.6 真实遇到的问题速查表我把开发过程中遇到的高频问题整理了一下给后面做类似项目的人做个参考问题现象排查思路解决方案用户支付成功但订单状态仍显示待支付检查支付回调是否被微信拦截回调和业务逻辑是否在同一个事务中完成支付回调幂等处理增加定时补偿查询微信支付状态陪诊师端无法上传照片检查小程序后台配置的域名白名单是否包含OSS/COS域名配置合法域名前端对图片size检查正常后再调用上传订单状态中途异常导致用户/陪诊师操作都锁死状态机规则覆盖不完整增加“强制解锁”运营后台工具并记录操作日志订阅消息推送失败用户未授权或一次性订阅已耗尽在用户关键动作后引导多次授权订阅定位偏差导致到达打卡校验不通过GPS漂移或信号差允许离线补签并加入图片备注作为辅助证明投诉处理链路过长用户找不到人工客服入口增加服务中一键客服按钮结算对不上账订单金额和退款金额统计口径不一致统一通过订单流水表做财务聚合禁止散点求和5. 实用度复盘与迭代值得关注的方向5.1 哪些功能是“真实用”哪些是过度设计如果现在让我重新做一遍我会砍掉其中40%的功能。比如一开始过度设计的社区评论、陪诊师动态、积分商城用户基本不看。我们做的用户调研也承认这类功能占用比较多注意力。真正留下来的核心功能就三条下单快、进度清晰、异常有人处理。这三个词对应到系统里就是表单预填、订单状态机、客服与告警体系。所有能和这三个词挂钩的功能实用度都排在前面其他所有功能都是锦上添花可有可无。5.2 从“订单量”看产品实用度的本质如果你问一个正在赶去做检查的患者陪诊小程序产品的实用度是什么他不会回答你“功能丰富”他会回答“能帮我把事情办完”。服务类产品的实用度不是由功能数量决定的而是由完成率决定的。所以我一直认为这个项目的KPI不应只看下单数而要看“履约完成率”和“用户口碑推荐率”。履约完成率背后对应着调度是否合理、陪诊师是否靠谱、平台能不能处理异常口碑推荐率则背后对应着服务全程是否让对方安心、清晰、被尊重。只要围绕这两个指标做迭代产品就不会跑偏。实测下来哪个月重点关注“降低订单取消率”哪个月陪诊师端和用户端的服务评分都会跟着上涨。功能越多越容易模糊焦点。5.3 可以继续扩展的方向我自己的体会是就医陪诊这个模型跑通以后是可以向周边场景做复用的企业健康服务。很多公司给高管和高年资员工提供体检预约、就医陪诊、重疾绿色通道等福利可以由机构统一采购按使用量计费。医院和社区合作。陪诊服务可以开放给医院导诊台或社区养老服务中心作为院内服务的延伸。陪诊师工具化。目前陪诊师之间也会互相配合如果做成“共享排班日历”和“互助接单”机制单人接单量可以进一步提升。保险产品增值服务。部分高端医疗险和意外险本身附带就医陪诊服务如果能把陪诊能力作为保险权益打包也会是一个不错的合作方向。这些扩展方向不是短时间内就要全部做的。先把一个城市、一家医院、一批陪诊师之间的服务流程跑顺再考虑复制到其他城市。陪诊这种重运营的服务靠堆功能是堆不出规模的。6. 想对正在做或准备做同类产品的朋友说说实话这类小程序的门槛不在技术上而在运营和服务意识的积累。开发只占20%的时间剩下80%的时间是在一遍一遍打磨流程、培训陪诊师、处理棘手投诉。我见过很多团队两周写完了陪诊小程序却用两个月设计不清楚“用户取消订单陪诊师距离医院还有一公里退款扣多少”这种问题。还有一个小技巧把服务流程里每一个环节的负责人写清楚。不是写在代码注释里是写在团队的流程文档里。陪诊师、客服、运营都需要照着同一份流程来。哪一个环节没有负责人哪一天就会出一个投诉。如果你打算做同类型的产品我的建议是先别急着把所有通用能力都做进去。用一个月的时间选定一到两家医院手动派单、人工同步位置靠一个非常简陋的小程序配合大量人工把事情跑通。用这个粗糙版本去验证三件事用户愿不愿意付费、陪诊师愿不愿意接单、平台每天处理多少单以后人工开始跟不过来。这三件事验证完再动工优化体验都不迟。最后分享一个我做这个项目过程中最大的经验就医陪诊这个服务的本质是“用时间和秩序换安心”。家属缺的是时间患者缺的是引导陪诊师提供的是秩序。软件的作用就是把这个秩序搬到线上让每一方都能看到进度少一点焦虑。只要这个逻辑成立产品的实用度不会差。