最近半年我一直在做陪诊陪护类微信小程序的完整产品设计从需求调研、原型到前后端实现都走了一遍。做完最大的感受是陪诊小程序看起来像“跑腿挂号”的组合但真正落地时它比打车、外卖、家政都要复杂——因为它卖的不是一次服务而是一段让家属放心的“守护过程”。这篇文章不聊概念直接拆版块、讲设计逻辑、说技术实现里踩过的坑希望能帮到正在做同类产品或者打算接手相关项目的同学。1. 陪诊不是跑腿是一条需要“守护感”的服务闭环很多人第一次接触陪诊业务时都会下意识地按照“下单-派单-完成”的经典 O2O 模型去设计小程序。这个思路本身没有错但实际跑起来你会发现陪诊服务和网约车、跑腿有一个本质区别后者的核心是“把物品或人从 A 点送到 B 点”服务结束即交付而陪诊的核心是“陪用户走完整个就医过程”过程里的每一个节点都会影响用户的信任感和安全感。1.1 一次真实的就诊过程暴露了哪些需求去年我陪一位长辈去医院复查那天早上 8 点到的医院一直到下午 3 点才离开。中间经历了取号、候诊、看诊、开检查单、缴费、CT 排队、等报告、回诊、取药整整 9 个环节每个环节都需要在不同楼层、不同窗口之间往返。老人因为听力不好听不清叫号系统的播报因为腿脚不便上下楼、排队、拿药都需要有人搭把手家属因为上班没法陪同全程只能靠电话沟通但电话里很难说清楚“现在进行到哪一步了”。那天回去之后我就意识到:陪诊小程序如果只是解决“约一个人陪你去医院”这个动作那它和普通跑腿没有区别真正的价值在于把整段就医过程拆成清晰的节点让家属随时知道“人现在在哪、医生看完了没有、下面还要做什么”。这几件事直接决定了小程序的功能版块设计它必须有精确到节点的订单状态机必须有服务过程的实时位置和进度同步必须有异常情况的快速上报通道也必须有服务结束后的完整交付报告。1.2 三个角色与主流程下单、陪伴、交付从角色模型上看陪诊小程序至少需要三类角色用户通常是老年人或带子女/家属代下单的健康管理人群、陪诊师全职或兼职的服务提供者、平台运营/调度后台。小程序的端侧设计里用户端和陪诊师端是两个独立的微信小程序后台管理端则用 Web 管理后台承载。两端的小程序不共用一个入口原因是操作场景差异太大用户端强调的是信息清晰、操作简单陪诊师端强调的是接单效率、过程记录、异常上报混在一个小程序里会同时干扰两边的使用体验。主流程可以抽象成五步下单预约、智能匹配、服务过程跟踪、服务完成结算、事后评价与回访。表面上看这五步都很普通但每一步展开后都有专门的功能设计后面我会分版块拆开细说。值得注意的是陪诊订单的取消、改期、退款规则比普通服务复杂得多因为医院挂号和检查时间是不可控的强依赖医院现场的实际情况。这要求小程序从第一天起就把订单状态机设计清楚否则后面加需求会非常痛苦。2. 用户端的安心感靠哪些功能版块堆出来用户端的小程序是家属和老人直接接触的界面它的设计目标不是“功能多”而是“让人放心”。核心版块包括服务首页、预约下单、订单详情服务过程可视化、健康档案、服务报告、我的钱包与发票以及关怀模式。下面逐个拆解每个版块的功能要点和设计逻辑。2.1 预约下单模块字段设计决定了后端的路能走多远预约下单是用户端的第一个核心入口。很多团队会在这里犯一个错误把表单设计得极其简单只有一个医院名称的文本框、一个日期、一个备注。等量上来之后才发现数据完全没法支撑后续的服务分派、价格计算和标签推荐。我的建议是从第一版就按以下字段设计下单表单服务类型全程陪诊、半天陪诊、单项服务取报告、代取药、陪输液等不同类型对应不同的计价规则。医院信息医院、院区、科室建议做成三级联动医院和科室分别建表不要用自由文本。因为后面做派单时要按“陪诊师熟悉哪个医院、哪个科室”来匹配自由文本完全没法匹配。就诊时间用户填写的期望时间要允许“上午/下午/全天”这种模糊选项不要强制精确到分钟——老人和家属往往说不准医生具体几点能看到。患者信息姓名、年龄、关系以及是否行动不便、是否需要轮椅、是否有听力/视力障碍。这些字段直接决定后续派单时对陪诊师的要求。联系人信息下单人、患者、紧急联系人可能是三个人要分开维护。备注允许用户自由填写病情说明、医院要求等但在界面引导里给出提示模板避免用户留空或者写得太随意。访问旧版下单表单还有一个常见问题科室的层级关系。不同医院的科室名称差异很大有的叫“骨科”有的叫“骨科-关节外科”还有的医院门诊科室和住院科室完全不一样。为了兼顾后续可扩展性建议科室表至少包含三级结构并且每条科室记录都关联医院 ID避免出现“所有医院共用一套科室列表”的情况。2.2 服务过程可视化地图进度关键节点下单之后家属最焦虑的时间段就是服务过程中。用户端的订单详情页是整个用户端体验的重中之重它需要同时展示三件事陪诊师实时位置、服务流程的当前进度、以及服务节点的关键事件记录。实时位置建议采用微信小程序的地图组件配合 WebSocket 或轮询获取陪诊师端上报的经纬度。这里有一个实用细节不要高频上报位置每 10–15 秒上报一次足够否则电量消耗和服务器压力都会比较大。同时地图上建议圈出医院范围用户一眼就能看出陪诊师是否已经到达医院。服务进度要严格遵循订单状态机。我最终设计的节点是待支付 → 待接单 → 已接单 → 已到达 → 服务中 → 待确认 → 已完成其中“服务中”内部再拆为“候诊中、就诊中、检查中、取药中”等过程节点。这个设计的关键在于订单的“状态”保持稳定方便做对账和退款判断“过程节点”单独存在展示给家属看这样陪诊师在服务中切换子节点不会影响订单主状态逻辑上非常清晰。关键事件记录又是另一张表记录“XX:XX 已到达医院”“XX:XX 完成建档取号”“XX:XX 医生已看诊完”“XX:XX 已取完药”这类时间戳。这些记录一方面在订单详情页时间轴展示另一方面是服务结束后生成服务报告的数据来源。2.3 关怀模式与健康档案子女代约之外的护城河真正用过陪诊小程序的用户会知道不少订单是子女给父母下的但服务过程中需要和老人本人沟通。老人的手机操作水平差异很大因此关怀模式大字模式在用户端很有必要。它能一键把全站的字体放大、按钮间距拉开、图标换成更直观的语义符号甚至可以把首页改成一个极简的“一键拨号联系陪诊师”和“查看服务进度”两个大按钮其他功能全部折叠。健康档案模块也是容易被忽略但价值极高的版块。用户可以在下单前提前填写既往病史、过敏史、常用药清单、医保类型等信息下单时直接选择档案而不是每次重新填写。这样既能减少用户下单时输入的成本也能在陪诊师端展示给陪诊师帮助陪诊师更全面了解患者情况。注意健康档案属于敏感个人信息必须在用户授权的情况下填写和展示需要在隐私政策里明确说明信息的收集范围、使用目的和存储期限。此外用户端还要有一个评价与服务报告版块。服务完成后陪诊师需要提交一份格式化的服务报告包括就诊经过、医嘱要点、费用明细、后续复诊建议等字段。家属看完报告再决定是否评价打分。把“服务报告”放在“评价”之前其实是一种产品策略先把服务交付做完整再引导评价这样评价的参考价值更高对陪诊师也更公平。3. 陪诊师端与调度后台中间枢纽决定了体验的下限用户端的体验再好如果陪诊师端和调度后台跟不上整个服务的下限就会非常低。这块是很多产品经理容易忽略的部分我把它当成独立系统来设计它其实是三个子系统的组合陪诊师小程序、调度后台、指标体系。3.1 派单还是要抢单信任服务要的是确定性陪诊服务在匹配环节有一个取舍抢单模式还是派单模式。早期有些平台模仿网约车做抢单觉得能提高陪诊师积极性实际操作中问题很大——陪诊师的接单注意力分配不均热门医院订单被秒抢冷门时段和偏远医院长期无人接单对家属来说,等待的时间和不确定性都很难接受。陪诊服务本质上是高信任、低频率、非标化的服务用户要的是确定性几点有人接单、陪诊师是谁、能不能按时到。所以我的方案是平台调度优先陪诊师不能随意抢单。调度系统根据订单要求、陪诊师技能标签、当前忙碌程度、历史评分、性别偏好、熟悉医院等维度做一次性匹配。陪诊师端只展示“系统派给您的订单”陪诊师可以选择接受或拒绝但拒绝会影响后续派单优先级。这个逻辑很像急诊分级平台要先保证确定性再去谈效率。匹配规则其实不需要一开始就写很复杂的算法。第一版我用的是带权重的规则引擎匹配分 医院熟悉度×40% 历史评分×25% 距离×20% 性别偏好×10% 服务类型匹配×5%按分数排序取最优。等订单量大了再考虑用更复杂的算法。你不需要一上来就上机器学习先把规则跑通、把数据收集起来才是重点。3.2 服务中的强制动作打卡、核验、SOS、异常上报陪诊师端的核心不是“能接单”而是“服务过程能被平台有效监控”。我把陪诊师端的服务流程强制拆成几个硬性检查点接单后陪诊师必须与用户或家属电话沟通确认上门时间、患者位置、是否需要轮椅等系统要求至少完成一次通话记录。到达医院后必须在小程序上点击“我已到达”同时上报定位。调度后台会校验定位是否在医院围栏范围内避免虚假打卡。服务中关键节点完成取号、就诊中、检查中、取药完成必须手动或扫码触发。扫码可以扫患者病历本上的条码或药房窗口的单据尽可能避免误报。服务异常时陪诊师可以一键进入“异常上报”页面上报排队时间过长、医生临时停诊、患者身体不适等情况系统自动通知家属和调度人工介入。紧急情况下陪诊师端和用户端都有“紧急求助”按钮点击后会自动拨打平台紧急电话同时给家属发短信和订阅消息通知。这些强制动作的目的有两个一是让家属实时掌握动态减少焦虑二是为平台提供订单真实性审查的依据防止陪诊师未实际服务就虚报完成。前期我们设计了这些节点后人工审核的工作量反而降低了因为大部分问题在事件流里就能看出异常比如“到医院”和“完成取号”的时间间隔异常短基本可以断定是虚构服务。3.3 后台还差一个“服务雷达”数据看板设计要点调度后台不能让运营人员每天靠人肉翻订单来发现问题。我设计后台时重点做了三个看板订单大盘、异常事件监控、陪诊师质量分。订单大盘展示当日订单量、各状态订单分布、平均接单时长、平均服务时长、平均评分、取消率等核心指标。异常事件监控展示所有触发了异常上报、SOS、超时未到达等事件运营人员能第一时间看到并进行人工干预。陪诊师质量分则是把接单响应时长、准点率、服务节点完整度、用户评分、投诉次数综合成一个动态分数在派单时直接引用。有一个很容易踩的坑不要在后台页面上堆太多图表。运营人员最需要的不是一个炫酷的大屏而是一张能快速定位问题的业务表。先做明细表再做趋势图最后才考虑可视化大屏。我以前见过团队第一版就做了一个满屏图表的大屏结果运营基本不看因为数据粒度太粗点不进去没办法处理实际问题。4. 微信小程序工程实现那些热搜里的问题我都踩过从产品形态落到代码实现时微信小程序的技术细节会占用大量开发时间。这一节我挑几个最典型的工程问题展开说每个都是开发过程中真实遇到过的并且大部分能在各个开发者社群里反复看到的高频问题看到影子。4.1 登录态为什么 wx.login 拿到的 code 经常“失效”微信小程序获取登录后的用户信息是每个新手都会碰到的第一个难题。微信登录的完整链路并不简单。小程序端调用wx.login拿到一个临时code然后把 code 传给后端后端拿这个 code 去微信接口服务换取openid和session_key。这个 code 的有效期只有 5 分钟而且只能使用一次用完之后立即失效。我之前在社区里就看到有人把自己的小程序 appid类似wx1cb4398e1413dce7这种格式直接贴出来问“为什么获取登录后的微信用户失败”实际上很可能就是没有正确区分 code、openid、unionid、session_key 之间的关系。常见的登录问题有几种第一种是前端把wx.login的 code 当成长期凭证存起来下次进入页面直接复用结果后端换 session_key 时发现 code 已经过期第二种是后端在code2Session请求时需要配置正确的 appid 和 secret很多人把正式环境 appid 配成了测试 appid导致获取用户信息失败第三种是用户拒绝授权后前端没有做好二次引导用户点了一个需要授权的操作但没有任何弹窗提示体验比较割裂。现在微信已经把大部分用户信息的获取方式收紧了头像、昵称这类基本信息也不再返回真实的微信数据。对于陪诊场景建议不要在登录阶段就要求用户授权头像昵称而是在用户下单、绑定患者、发起服务这些真正需要身份信息的节点再做授权和数据收集。这样用户信息获取更顺利也符合最小化收集的原则。4.2 分包与包体积主包 2MB 红线下的规划微信小程序主包有 2MB 限制总包有 20MB 限制主包分包。陪诊小程序涉及的功能版块多页面数量很容易超过 50 个如果所有页面都放在主包里很容易触发“主包超过 2MB”的报错。我的建议是使用分包方案。主包只放启动页、首页、登录逻辑、公共组件等核心内容用户端的下单流程和服务流程页面放进subpackage-user陪诊师端页面全部放进subpackage-server健康档案、服务报告、隐私政策等低频页面放在subpackage-common。这样每个分包单独统计体积主包压力会小很多。这里要特别说明分包异步化。如果一个分包要引用另一个分包里的组件或接口常规方式是写成独立分包后通过接口调用但这样会增加开发成本。微信提供了“分包异步化”的能力允许一个分包异步引用另一个分包的 JS、自定义组件。比如陪诊师端需要复用用户端的一些组件时可以用异步引用避免代码重复和体积翻倍。4.3 导航栏、安全区、web-view 与定位兼容性三件套这三个问题是微信小程序开发里每到一个新项目几乎都会遇到的。自定义导航栏是一个经典坑。默认导航栏的样式太死板很多团队都会改成自定义导航栏。但自定义导航栏需要自己计算标题位置和胶囊按钮位置必须调用wx.getMenuButtonBoundingClientRect()获取胶囊按钮的坐标再结合wx.getSystemInfoSync()里的状态栏高度来计算导航栏高度。不同机型的状态栏高度差异很大iPhone 系列和安卓机型都不同必须动态计算不能写死数值。iPhone 底部安全区也是一个常见问题比如底部悬浮的“一键求助”按钮、支付按钮到了 iPhone X 及以上机型会被 Home Indicator 遮住。解决办法是在样式中使用env(safe-area-inset-bottom)或constant(safe-area-inset-bottom)作为 padding-bottom 的值。web-view 加载外部页面时页面域名必须先在小程序后台配置为业务域名并且要把校验文件放到服务器指定目录。否则会出现“无法打开该网页”的报错。另外小程序里嵌了 H5 页面之后H5 无法直接调用小程序的定位能力需要在小程序原生端获取地图选点经纬度后通过 URL 参数传给 H5或者使用小程序提供的 JSSDK。4.4 蓝牙设备接入与安卓 14 权限适配陪诊场景里有一个比较特殊但很实用的功能对接蓝牙健康设备如电子体温计、血压计、血氧仪等。陪诊师在服务过程中可以给老人测一次体温和血压数据直接记录到服务报告中。这个功能对老年患者和家属来说都是加分项因为就医时医生经常问“最近体温多少、血压稳不稳定”有了客观数据就不用凭记忆回答了。蓝牙模块在 iOS 上相对还算稳定Android 上的适配则比较麻烦。尤其是 Android 13/14 之后蓝牙相关的运行时权限要求有明显变化除了蓝牙本身的权限还必须声明并申请定位权限因为蓝牙扫描会关联位置信息。如果targetSdkVersion升到 33 以上还需要动态申请BLUETOOTH_SCAN、BLUETOOTH_CONNECT等权限而不是只写进 Manifest 就行。很多人在这块踩坑的典型现象是真机测试时蓝牙扫描不到设备或者扫描到了但连接失败最后发现是权限没申请全。4.5 真机调试与接口排查ERR_CONNECTION_RESET 的修复路径开发过程中大量时间都会花在排查接口问题上尤其是真机环境下的网络问题。一个非常常见的情况是开发者工具里接口请求正常但在真机上显示net::ERR_CONNECTION_RESET。这类问题通常有几个原因。第一是接口域名没有在小程序后台配置到 request 合法域名列表这时开发者工具里如果勾选了“不校验合法域名”看起来正常但真机一定会失败。第二是服务器端开启了 HTTPS 但证书链不完整某些 Android 机型在校验证书时更严格会直接导致连接被重置。排查时用开发者工具自带的调试器看请求详情或者用抓包工具看 TLS 握手阶段是否有异常基本就能定位。另外小程序上线前做接口调试时建议把请求日志打全包括请求头、参数、返回值、耗时、错误码。这些日志在排查故障时非常关键。尤其是在做陪诊这类业务时服务过程中的任何一个接口报错都会直接影响到线下的服务执行所以线上日志系统必须从一开始就搭建好。5. 消息触达与支付结算最容易翻车的两个版块最后一个大版块是消息触达和支付结算。这两个模块虽然看起来相对独立但实际往往决定了一个陪诊平台能不能高效运转。消息触达做不好用户下单后不知道状态变化焦虑感会直线上升支付结算做不好平台和陪诊师之间的资金关系混乱业务规模越大越容易出事。5.1 订阅消息方案一次性订阅与长期订阅的取舍微信小程序没有系统级推送唯一能主动触达用户的方式是订阅消息。但订阅消息有一个让所有开发者头疼的限制普通的一次性订阅消息需要用户每一次都点授权用户授权一次小程序才能给用户发送一条消息。陪诊场景里服务状态变更、医生排班变动、账单提醒都是需要多次触达的。如果每次都等用户点授权效果很差。所以我的做法是在下单完成页、订单详情页、服务完成页等关键节点把订阅授权拆成多个独立的请求每次只索要一种消息类型尽量提升授权转化率。在流感季这类服务高峰期订阅消息推送的到达率直接关系到服务质量。有条件的团队可以研究一下微信的长期订阅消息能力。长期订阅消息只开放给特定类目医疗、政务、民生等服务类目更有可能拿到申请资质。如果陪诊小程序属于医疗健康相关类目可以尝试申请长期订阅这样用户只需要授权一次平台就可以持续发送相关服务通知。不过长期订阅消息的申请审核周期较长、模板类型有限而且每年都要年审需要尽早准备。另外不要把短信能力完全砍掉。对于超时未支付、服务完成提醒、异常事件通知等关键通知短信作为兜底通道仍然很有价值特别是面对老年用户时短信的触达率往往比小程序订阅消息更高。5.2 支付、免押与分账SaaS 商家接入的几个关键点支付模块最核心的接入方式是微信支付但陪诊平台的角色不同接入方式也不同。如果是平台自营直接用普通商户号即可如果是给多个陪诊服务团队提供 SaaS 系统就要使用微信支付的服务商模式每个商家使用独立的子商户号资金直接结算到商家账户平台不碰钱。支付环节有几个容易被忽略的点第一用户发起支付后后端必须认真处理异步通知回调而不是只依赖前端微信支付成功的回调因为前端回调可能丢。第二退款必须做成后台可操作、可追溯用户在申请退款后需要支持部分退款和全额退款退款原因要分类记录方便财务对账。第三陪诊订单的金额里通常包含平台服务费和陪诊师服务费两部分要提前设计分账方案。陪诊师佣金在订单完成后从订单金额中分账实时结算或 T1 结算平台服务费单独入账避免资金混在一起。免押金服务也是一个值得做的功能点。针对“陪诊师上门服务”这个场景平台可以通过芝麻信用、微信支付分等方式让部分用户享受免押金下单资格。这里需要注意和微信支付分相关接口的对接规范用户服务完成后再批量发起“免押金代扣”这样可以减少用户操作负担提高服务体验。5.3 上线前的压测与故障演练别在流感季掉链子很多人觉得陪诊小程序是低频应用不需要做压力测试。这个想法很危险。在流感季节、儿科就诊高峰等时间段订单量会突然增长好几倍如果系统扛不住用户会同时涌向客服投诉造成较大的口碑问题。上线前至少要做一轮基础压测模拟 500 到 1000 人同时访问首页、同时下单、同时查询订单详情。重点观察数据库连接池、接口响应时间、订阅消息推送队列这几个容易成为瓶颈的环节。如果并发不够优先做接口缓存和数据库索引优化必要时再扩容服务器。故障演练同样重要。比如模拟订单支付回调丢失、订阅消息服务超时、陪诊师定位上传失败等场景确保系统有对应的补偿机制。我之前就遇到过一次线上事件支付成功但回调没有及时到达用户和陪诊师两边都显示订单未支付后来是后台做了一轮“主动查单”任务把所有支付状态异常的单子重新和微信支付侧核对最终才恢复了。这个主动查单机制应该在小程序上线的第一天就做进去。6. 从 0 到 1 的迭代节奏先做什么后做什么聊完了功能版块和技术实现最后讲一讲迭代顺序。陪诊小程序的坑在于功能版块多、角色多如果一开始就想把所有功能一次性做完项目大概率会中途烂尾。我建议按下面的顺序分三步走。6.1 MVP 版本的最小闭环第一版只做五件事下单预约、系统派单、陪诊师接单、服务过程打卡、服务完成后的支付与评价。这个闭环能覆盖陪诊服务的完整交易链路一天之内就能跑完整个业务流程是验证业务模式的最小集合。这个版本里暂时不做健康档案、暂不做蓝牙设备采集、暂不做复杂的运营后台。MVP 版一定要想清楚一件事陪诊师端的状态节点到底需要多细。建议先做“已到达、服务中、已完成”三个节点跑一段时间再看用户反馈再决定是否细化到“就诊中、检查中、取药中”。原因很简单节点的每一次增加都会增加陪诊师的操作负担如果陪诊师嫌麻烦不愿意点服务过程的透明度就无从谈起产品价值也就大打折扣。6.2 第二阶段推送、关怀模式、数据看板当业务跑通后第二步要加的是所有能提升服务体验和运营效率的功能消息订阅和短信通知完善、关怀模式、服务报告、调度后台的数据看板。这些功能在 MVP 阶段都是辅助但在单量稳定后它们决定了平台能不能长期留住用户和陪诊师。在这个阶段要把服务报告的模板设计得尽量标准化。比如“本次就诊小结、用药调整情况、下次复诊建议、费用说明”这些字段既方便家属查看也能沉淀成平台的数据资产。做数据分析时可以看到哪个科室的订单最多、哪个阶段的用户容易流失、哪个陪诊师的平均服务时长异常这些数据对业务优化非常关键。6.3 冷启动阶段的一点点务实建议我想分享一个可能有些反直觉的经验陪诊小程序在冷启动阶段真正难的不是技术而是“陪诊师从哪里来”。没有足够的陪诊师订单来了根本接不住。建议在产品开发的同时就同步组建陪诊师团队可以先用一个微信群来人工派单甚至用表格管理订单而不是等功能全部做完再开始招募。在冷启动阶段小程序功能不需要做到完美但有一点必须从第一天就做好用户隐私保护。陪诊涉及大量的医疗健康数据、家庭成员信息隐私政策、用户授权弹窗、数据存储安全这三件事必须合法合规这一点没有回旋的余地。不同地区对陪诊服务的定位和监管要求也有差异正式商业化前一定要确认当地对陪诊服务的资质要求和管理口径。从实际经历来看陪诊小程序的价值不在于它有多炫酷的功能而在于它是不是真的把“让家属放心”这件事做到了实处。每一次节点的更新、每一次异常上报的及时触达、每一个服务报告的完整呈现都在积累用户对平台的信任。我认为这也是“贴心守护”这四个字最本质的产品含义。
陪诊小程序设计与实现：从O2O模式到微信小程序工程实战
最近半年我一直在做陪诊陪护类微信小程序的完整产品设计从需求调研、原型到前后端实现都走了一遍。做完最大的感受是陪诊小程序看起来像“跑腿挂号”的组合但真正落地时它比打车、外卖、家政都要复杂——因为它卖的不是一次服务而是一段让家属放心的“守护过程”。这篇文章不聊概念直接拆版块、讲设计逻辑、说技术实现里踩过的坑希望能帮到正在做同类产品或者打算接手相关项目的同学。1. 陪诊不是跑腿是一条需要“守护感”的服务闭环很多人第一次接触陪诊业务时都会下意识地按照“下单-派单-完成”的经典 O2O 模型去设计小程序。这个思路本身没有错但实际跑起来你会发现陪诊服务和网约车、跑腿有一个本质区别后者的核心是“把物品或人从 A 点送到 B 点”服务结束即交付而陪诊的核心是“陪用户走完整个就医过程”过程里的每一个节点都会影响用户的信任感和安全感。1.1 一次真实的就诊过程暴露了哪些需求去年我陪一位长辈去医院复查那天早上 8 点到的医院一直到下午 3 点才离开。中间经历了取号、候诊、看诊、开检查单、缴费、CT 排队、等报告、回诊、取药整整 9 个环节每个环节都需要在不同楼层、不同窗口之间往返。老人因为听力不好听不清叫号系统的播报因为腿脚不便上下楼、排队、拿药都需要有人搭把手家属因为上班没法陪同全程只能靠电话沟通但电话里很难说清楚“现在进行到哪一步了”。那天回去之后我就意识到:陪诊小程序如果只是解决“约一个人陪你去医院”这个动作那它和普通跑腿没有区别真正的价值在于把整段就医过程拆成清晰的节点让家属随时知道“人现在在哪、医生看完了没有、下面还要做什么”。这几件事直接决定了小程序的功能版块设计它必须有精确到节点的订单状态机必须有服务过程的实时位置和进度同步必须有异常情况的快速上报通道也必须有服务结束后的完整交付报告。1.2 三个角色与主流程下单、陪伴、交付从角色模型上看陪诊小程序至少需要三类角色用户通常是老年人或带子女/家属代下单的健康管理人群、陪诊师全职或兼职的服务提供者、平台运营/调度后台。小程序的端侧设计里用户端和陪诊师端是两个独立的微信小程序后台管理端则用 Web 管理后台承载。两端的小程序不共用一个入口原因是操作场景差异太大用户端强调的是信息清晰、操作简单陪诊师端强调的是接单效率、过程记录、异常上报混在一个小程序里会同时干扰两边的使用体验。主流程可以抽象成五步下单预约、智能匹配、服务过程跟踪、服务完成结算、事后评价与回访。表面上看这五步都很普通但每一步展开后都有专门的功能设计后面我会分版块拆开细说。值得注意的是陪诊订单的取消、改期、退款规则比普通服务复杂得多因为医院挂号和检查时间是不可控的强依赖医院现场的实际情况。这要求小程序从第一天起就把订单状态机设计清楚否则后面加需求会非常痛苦。2. 用户端的安心感靠哪些功能版块堆出来用户端的小程序是家属和老人直接接触的界面它的设计目标不是“功能多”而是“让人放心”。核心版块包括服务首页、预约下单、订单详情服务过程可视化、健康档案、服务报告、我的钱包与发票以及关怀模式。下面逐个拆解每个版块的功能要点和设计逻辑。2.1 预约下单模块字段设计决定了后端的路能走多远预约下单是用户端的第一个核心入口。很多团队会在这里犯一个错误把表单设计得极其简单只有一个医院名称的文本框、一个日期、一个备注。等量上来之后才发现数据完全没法支撑后续的服务分派、价格计算和标签推荐。我的建议是从第一版就按以下字段设计下单表单服务类型全程陪诊、半天陪诊、单项服务取报告、代取药、陪输液等不同类型对应不同的计价规则。医院信息医院、院区、科室建议做成三级联动医院和科室分别建表不要用自由文本。因为后面做派单时要按“陪诊师熟悉哪个医院、哪个科室”来匹配自由文本完全没法匹配。就诊时间用户填写的期望时间要允许“上午/下午/全天”这种模糊选项不要强制精确到分钟——老人和家属往往说不准医生具体几点能看到。患者信息姓名、年龄、关系以及是否行动不便、是否需要轮椅、是否有听力/视力障碍。这些字段直接决定后续派单时对陪诊师的要求。联系人信息下单人、患者、紧急联系人可能是三个人要分开维护。备注允许用户自由填写病情说明、医院要求等但在界面引导里给出提示模板避免用户留空或者写得太随意。访问旧版下单表单还有一个常见问题科室的层级关系。不同医院的科室名称差异很大有的叫“骨科”有的叫“骨科-关节外科”还有的医院门诊科室和住院科室完全不一样。为了兼顾后续可扩展性建议科室表至少包含三级结构并且每条科室记录都关联医院 ID避免出现“所有医院共用一套科室列表”的情况。2.2 服务过程可视化地图进度关键节点下单之后家属最焦虑的时间段就是服务过程中。用户端的订单详情页是整个用户端体验的重中之重它需要同时展示三件事陪诊师实时位置、服务流程的当前进度、以及服务节点的关键事件记录。实时位置建议采用微信小程序的地图组件配合 WebSocket 或轮询获取陪诊师端上报的经纬度。这里有一个实用细节不要高频上报位置每 10–15 秒上报一次足够否则电量消耗和服务器压力都会比较大。同时地图上建议圈出医院范围用户一眼就能看出陪诊师是否已经到达医院。服务进度要严格遵循订单状态机。我最终设计的节点是待支付 → 待接单 → 已接单 → 已到达 → 服务中 → 待确认 → 已完成其中“服务中”内部再拆为“候诊中、就诊中、检查中、取药中”等过程节点。这个设计的关键在于订单的“状态”保持稳定方便做对账和退款判断“过程节点”单独存在展示给家属看这样陪诊师在服务中切换子节点不会影响订单主状态逻辑上非常清晰。关键事件记录又是另一张表记录“XX:XX 已到达医院”“XX:XX 完成建档取号”“XX:XX 医生已看诊完”“XX:XX 已取完药”这类时间戳。这些记录一方面在订单详情页时间轴展示另一方面是服务结束后生成服务报告的数据来源。2.3 关怀模式与健康档案子女代约之外的护城河真正用过陪诊小程序的用户会知道不少订单是子女给父母下的但服务过程中需要和老人本人沟通。老人的手机操作水平差异很大因此关怀模式大字模式在用户端很有必要。它能一键把全站的字体放大、按钮间距拉开、图标换成更直观的语义符号甚至可以把首页改成一个极简的“一键拨号联系陪诊师”和“查看服务进度”两个大按钮其他功能全部折叠。健康档案模块也是容易被忽略但价值极高的版块。用户可以在下单前提前填写既往病史、过敏史、常用药清单、医保类型等信息下单时直接选择档案而不是每次重新填写。这样既能减少用户下单时输入的成本也能在陪诊师端展示给陪诊师帮助陪诊师更全面了解患者情况。注意健康档案属于敏感个人信息必须在用户授权的情况下填写和展示需要在隐私政策里明确说明信息的收集范围、使用目的和存储期限。此外用户端还要有一个评价与服务报告版块。服务完成后陪诊师需要提交一份格式化的服务报告包括就诊经过、医嘱要点、费用明细、后续复诊建议等字段。家属看完报告再决定是否评价打分。把“服务报告”放在“评价”之前其实是一种产品策略先把服务交付做完整再引导评价这样评价的参考价值更高对陪诊师也更公平。3. 陪诊师端与调度后台中间枢纽决定了体验的下限用户端的体验再好如果陪诊师端和调度后台跟不上整个服务的下限就会非常低。这块是很多产品经理容易忽略的部分我把它当成独立系统来设计它其实是三个子系统的组合陪诊师小程序、调度后台、指标体系。3.1 派单还是要抢单信任服务要的是确定性陪诊服务在匹配环节有一个取舍抢单模式还是派单模式。早期有些平台模仿网约车做抢单觉得能提高陪诊师积极性实际操作中问题很大——陪诊师的接单注意力分配不均热门医院订单被秒抢冷门时段和偏远医院长期无人接单对家属来说,等待的时间和不确定性都很难接受。陪诊服务本质上是高信任、低频率、非标化的服务用户要的是确定性几点有人接单、陪诊师是谁、能不能按时到。所以我的方案是平台调度优先陪诊师不能随意抢单。调度系统根据订单要求、陪诊师技能标签、当前忙碌程度、历史评分、性别偏好、熟悉医院等维度做一次性匹配。陪诊师端只展示“系统派给您的订单”陪诊师可以选择接受或拒绝但拒绝会影响后续派单优先级。这个逻辑很像急诊分级平台要先保证确定性再去谈效率。匹配规则其实不需要一开始就写很复杂的算法。第一版我用的是带权重的规则引擎匹配分 医院熟悉度×40% 历史评分×25% 距离×20% 性别偏好×10% 服务类型匹配×5%按分数排序取最优。等订单量大了再考虑用更复杂的算法。你不需要一上来就上机器学习先把规则跑通、把数据收集起来才是重点。3.2 服务中的强制动作打卡、核验、SOS、异常上报陪诊师端的核心不是“能接单”而是“服务过程能被平台有效监控”。我把陪诊师端的服务流程强制拆成几个硬性检查点接单后陪诊师必须与用户或家属电话沟通确认上门时间、患者位置、是否需要轮椅等系统要求至少完成一次通话记录。到达医院后必须在小程序上点击“我已到达”同时上报定位。调度后台会校验定位是否在医院围栏范围内避免虚假打卡。服务中关键节点完成取号、就诊中、检查中、取药完成必须手动或扫码触发。扫码可以扫患者病历本上的条码或药房窗口的单据尽可能避免误报。服务异常时陪诊师可以一键进入“异常上报”页面上报排队时间过长、医生临时停诊、患者身体不适等情况系统自动通知家属和调度人工介入。紧急情况下陪诊师端和用户端都有“紧急求助”按钮点击后会自动拨打平台紧急电话同时给家属发短信和订阅消息通知。这些强制动作的目的有两个一是让家属实时掌握动态减少焦虑二是为平台提供订单真实性审查的依据防止陪诊师未实际服务就虚报完成。前期我们设计了这些节点后人工审核的工作量反而降低了因为大部分问题在事件流里就能看出异常比如“到医院”和“完成取号”的时间间隔异常短基本可以断定是虚构服务。3.3 后台还差一个“服务雷达”数据看板设计要点调度后台不能让运营人员每天靠人肉翻订单来发现问题。我设计后台时重点做了三个看板订单大盘、异常事件监控、陪诊师质量分。订单大盘展示当日订单量、各状态订单分布、平均接单时长、平均服务时长、平均评分、取消率等核心指标。异常事件监控展示所有触发了异常上报、SOS、超时未到达等事件运营人员能第一时间看到并进行人工干预。陪诊师质量分则是把接单响应时长、准点率、服务节点完整度、用户评分、投诉次数综合成一个动态分数在派单时直接引用。有一个很容易踩的坑不要在后台页面上堆太多图表。运营人员最需要的不是一个炫酷的大屏而是一张能快速定位问题的业务表。先做明细表再做趋势图最后才考虑可视化大屏。我以前见过团队第一版就做了一个满屏图表的大屏结果运营基本不看因为数据粒度太粗点不进去没办法处理实际问题。4. 微信小程序工程实现那些热搜里的问题我都踩过从产品形态落到代码实现时微信小程序的技术细节会占用大量开发时间。这一节我挑几个最典型的工程问题展开说每个都是开发过程中真实遇到过的并且大部分能在各个开发者社群里反复看到的高频问题看到影子。4.1 登录态为什么 wx.login 拿到的 code 经常“失效”微信小程序获取登录后的用户信息是每个新手都会碰到的第一个难题。微信登录的完整链路并不简单。小程序端调用wx.login拿到一个临时code然后把 code 传给后端后端拿这个 code 去微信接口服务换取openid和session_key。这个 code 的有效期只有 5 分钟而且只能使用一次用完之后立即失效。我之前在社区里就看到有人把自己的小程序 appid类似wx1cb4398e1413dce7这种格式直接贴出来问“为什么获取登录后的微信用户失败”实际上很可能就是没有正确区分 code、openid、unionid、session_key 之间的关系。常见的登录问题有几种第一种是前端把wx.login的 code 当成长期凭证存起来下次进入页面直接复用结果后端换 session_key 时发现 code 已经过期第二种是后端在code2Session请求时需要配置正确的 appid 和 secret很多人把正式环境 appid 配成了测试 appid导致获取用户信息失败第三种是用户拒绝授权后前端没有做好二次引导用户点了一个需要授权的操作但没有任何弹窗提示体验比较割裂。现在微信已经把大部分用户信息的获取方式收紧了头像、昵称这类基本信息也不再返回真实的微信数据。对于陪诊场景建议不要在登录阶段就要求用户授权头像昵称而是在用户下单、绑定患者、发起服务这些真正需要身份信息的节点再做授权和数据收集。这样用户信息获取更顺利也符合最小化收集的原则。4.2 分包与包体积主包 2MB 红线下的规划微信小程序主包有 2MB 限制总包有 20MB 限制主包分包。陪诊小程序涉及的功能版块多页面数量很容易超过 50 个如果所有页面都放在主包里很容易触发“主包超过 2MB”的报错。我的建议是使用分包方案。主包只放启动页、首页、登录逻辑、公共组件等核心内容用户端的下单流程和服务流程页面放进subpackage-user陪诊师端页面全部放进subpackage-server健康档案、服务报告、隐私政策等低频页面放在subpackage-common。这样每个分包单独统计体积主包压力会小很多。这里要特别说明分包异步化。如果一个分包要引用另一个分包里的组件或接口常规方式是写成独立分包后通过接口调用但这样会增加开发成本。微信提供了“分包异步化”的能力允许一个分包异步引用另一个分包的 JS、自定义组件。比如陪诊师端需要复用用户端的一些组件时可以用异步引用避免代码重复和体积翻倍。4.3 导航栏、安全区、web-view 与定位兼容性三件套这三个问题是微信小程序开发里每到一个新项目几乎都会遇到的。自定义导航栏是一个经典坑。默认导航栏的样式太死板很多团队都会改成自定义导航栏。但自定义导航栏需要自己计算标题位置和胶囊按钮位置必须调用wx.getMenuButtonBoundingClientRect()获取胶囊按钮的坐标再结合wx.getSystemInfoSync()里的状态栏高度来计算导航栏高度。不同机型的状态栏高度差异很大iPhone 系列和安卓机型都不同必须动态计算不能写死数值。iPhone 底部安全区也是一个常见问题比如底部悬浮的“一键求助”按钮、支付按钮到了 iPhone X 及以上机型会被 Home Indicator 遮住。解决办法是在样式中使用env(safe-area-inset-bottom)或constant(safe-area-inset-bottom)作为 padding-bottom 的值。web-view 加载外部页面时页面域名必须先在小程序后台配置为业务域名并且要把校验文件放到服务器指定目录。否则会出现“无法打开该网页”的报错。另外小程序里嵌了 H5 页面之后H5 无法直接调用小程序的定位能力需要在小程序原生端获取地图选点经纬度后通过 URL 参数传给 H5或者使用小程序提供的 JSSDK。4.4 蓝牙设备接入与安卓 14 权限适配陪诊场景里有一个比较特殊但很实用的功能对接蓝牙健康设备如电子体温计、血压计、血氧仪等。陪诊师在服务过程中可以给老人测一次体温和血压数据直接记录到服务报告中。这个功能对老年患者和家属来说都是加分项因为就医时医生经常问“最近体温多少、血压稳不稳定”有了客观数据就不用凭记忆回答了。蓝牙模块在 iOS 上相对还算稳定Android 上的适配则比较麻烦。尤其是 Android 13/14 之后蓝牙相关的运行时权限要求有明显变化除了蓝牙本身的权限还必须声明并申请定位权限因为蓝牙扫描会关联位置信息。如果targetSdkVersion升到 33 以上还需要动态申请BLUETOOTH_SCAN、BLUETOOTH_CONNECT等权限而不是只写进 Manifest 就行。很多人在这块踩坑的典型现象是真机测试时蓝牙扫描不到设备或者扫描到了但连接失败最后发现是权限没申请全。4.5 真机调试与接口排查ERR_CONNECTION_RESET 的修复路径开发过程中大量时间都会花在排查接口问题上尤其是真机环境下的网络问题。一个非常常见的情况是开发者工具里接口请求正常但在真机上显示net::ERR_CONNECTION_RESET。这类问题通常有几个原因。第一是接口域名没有在小程序后台配置到 request 合法域名列表这时开发者工具里如果勾选了“不校验合法域名”看起来正常但真机一定会失败。第二是服务器端开启了 HTTPS 但证书链不完整某些 Android 机型在校验证书时更严格会直接导致连接被重置。排查时用开发者工具自带的调试器看请求详情或者用抓包工具看 TLS 握手阶段是否有异常基本就能定位。另外小程序上线前做接口调试时建议把请求日志打全包括请求头、参数、返回值、耗时、错误码。这些日志在排查故障时非常关键。尤其是在做陪诊这类业务时服务过程中的任何一个接口报错都会直接影响到线下的服务执行所以线上日志系统必须从一开始就搭建好。5. 消息触达与支付结算最容易翻车的两个版块最后一个大版块是消息触达和支付结算。这两个模块虽然看起来相对独立但实际往往决定了一个陪诊平台能不能高效运转。消息触达做不好用户下单后不知道状态变化焦虑感会直线上升支付结算做不好平台和陪诊师之间的资金关系混乱业务规模越大越容易出事。5.1 订阅消息方案一次性订阅与长期订阅的取舍微信小程序没有系统级推送唯一能主动触达用户的方式是订阅消息。但订阅消息有一个让所有开发者头疼的限制普通的一次性订阅消息需要用户每一次都点授权用户授权一次小程序才能给用户发送一条消息。陪诊场景里服务状态变更、医生排班变动、账单提醒都是需要多次触达的。如果每次都等用户点授权效果很差。所以我的做法是在下单完成页、订单详情页、服务完成页等关键节点把订阅授权拆成多个独立的请求每次只索要一种消息类型尽量提升授权转化率。在流感季这类服务高峰期订阅消息推送的到达率直接关系到服务质量。有条件的团队可以研究一下微信的长期订阅消息能力。长期订阅消息只开放给特定类目医疗、政务、民生等服务类目更有可能拿到申请资质。如果陪诊小程序属于医疗健康相关类目可以尝试申请长期订阅这样用户只需要授权一次平台就可以持续发送相关服务通知。不过长期订阅消息的申请审核周期较长、模板类型有限而且每年都要年审需要尽早准备。另外不要把短信能力完全砍掉。对于超时未支付、服务完成提醒、异常事件通知等关键通知短信作为兜底通道仍然很有价值特别是面对老年用户时短信的触达率往往比小程序订阅消息更高。5.2 支付、免押与分账SaaS 商家接入的几个关键点支付模块最核心的接入方式是微信支付但陪诊平台的角色不同接入方式也不同。如果是平台自营直接用普通商户号即可如果是给多个陪诊服务团队提供 SaaS 系统就要使用微信支付的服务商模式每个商家使用独立的子商户号资金直接结算到商家账户平台不碰钱。支付环节有几个容易被忽略的点第一用户发起支付后后端必须认真处理异步通知回调而不是只依赖前端微信支付成功的回调因为前端回调可能丢。第二退款必须做成后台可操作、可追溯用户在申请退款后需要支持部分退款和全额退款退款原因要分类记录方便财务对账。第三陪诊订单的金额里通常包含平台服务费和陪诊师服务费两部分要提前设计分账方案。陪诊师佣金在订单完成后从订单金额中分账实时结算或 T1 结算平台服务费单独入账避免资金混在一起。免押金服务也是一个值得做的功能点。针对“陪诊师上门服务”这个场景平台可以通过芝麻信用、微信支付分等方式让部分用户享受免押金下单资格。这里需要注意和微信支付分相关接口的对接规范用户服务完成后再批量发起“免押金代扣”这样可以减少用户操作负担提高服务体验。5.3 上线前的压测与故障演练别在流感季掉链子很多人觉得陪诊小程序是低频应用不需要做压力测试。这个想法很危险。在流感季节、儿科就诊高峰等时间段订单量会突然增长好几倍如果系统扛不住用户会同时涌向客服投诉造成较大的口碑问题。上线前至少要做一轮基础压测模拟 500 到 1000 人同时访问首页、同时下单、同时查询订单详情。重点观察数据库连接池、接口响应时间、订阅消息推送队列这几个容易成为瓶颈的环节。如果并发不够优先做接口缓存和数据库索引优化必要时再扩容服务器。故障演练同样重要。比如模拟订单支付回调丢失、订阅消息服务超时、陪诊师定位上传失败等场景确保系统有对应的补偿机制。我之前就遇到过一次线上事件支付成功但回调没有及时到达用户和陪诊师两边都显示订单未支付后来是后台做了一轮“主动查单”任务把所有支付状态异常的单子重新和微信支付侧核对最终才恢复了。这个主动查单机制应该在小程序上线的第一天就做进去。6. 从 0 到 1 的迭代节奏先做什么后做什么聊完了功能版块和技术实现最后讲一讲迭代顺序。陪诊小程序的坑在于功能版块多、角色多如果一开始就想把所有功能一次性做完项目大概率会中途烂尾。我建议按下面的顺序分三步走。6.1 MVP 版本的最小闭环第一版只做五件事下单预约、系统派单、陪诊师接单、服务过程打卡、服务完成后的支付与评价。这个闭环能覆盖陪诊服务的完整交易链路一天之内就能跑完整个业务流程是验证业务模式的最小集合。这个版本里暂时不做健康档案、暂不做蓝牙设备采集、暂不做复杂的运营后台。MVP 版一定要想清楚一件事陪诊师端的状态节点到底需要多细。建议先做“已到达、服务中、已完成”三个节点跑一段时间再看用户反馈再决定是否细化到“就诊中、检查中、取药中”。原因很简单节点的每一次增加都会增加陪诊师的操作负担如果陪诊师嫌麻烦不愿意点服务过程的透明度就无从谈起产品价值也就大打折扣。6.2 第二阶段推送、关怀模式、数据看板当业务跑通后第二步要加的是所有能提升服务体验和运营效率的功能消息订阅和短信通知完善、关怀模式、服务报告、调度后台的数据看板。这些功能在 MVP 阶段都是辅助但在单量稳定后它们决定了平台能不能长期留住用户和陪诊师。在这个阶段要把服务报告的模板设计得尽量标准化。比如“本次就诊小结、用药调整情况、下次复诊建议、费用说明”这些字段既方便家属查看也能沉淀成平台的数据资产。做数据分析时可以看到哪个科室的订单最多、哪个阶段的用户容易流失、哪个陪诊师的平均服务时长异常这些数据对业务优化非常关键。6.3 冷启动阶段的一点点务实建议我想分享一个可能有些反直觉的经验陪诊小程序在冷启动阶段真正难的不是技术而是“陪诊师从哪里来”。没有足够的陪诊师订单来了根本接不住。建议在产品开发的同时就同步组建陪诊师团队可以先用一个微信群来人工派单甚至用表格管理订单而不是等功能全部做完再开始招募。在冷启动阶段小程序功能不需要做到完美但有一点必须从第一天就做好用户隐私保护。陪诊涉及大量的医疗健康数据、家庭成员信息隐私政策、用户授权弹窗、数据存储安全这三件事必须合法合规这一点没有回旋的余地。不同地区对陪诊服务的定位和监管要求也有差异正式商业化前一定要确认当地对陪诊服务的资质要求和管理口径。从实际经历来看陪诊小程序的价值不在于它有多炫酷的功能而在于它是不是真的把“让家属放心”这件事做到了实处。每一次节点的更新、每一次异常上报的及时触达、每一个服务报告的完整呈现都在积累用户对平台的信任。我认为这也是“贴心守护”这四个字最本质的产品含义。