小程序问诊链路交互功能优化记录

今天主要对小程序端的问诊链路做了一轮交互功能优化。之前小程序已经能够完成问诊提交、页面跳转和基础信息展示但是从真实用户的角度来看问诊并不是“提交一次表单”就结束了。用户更关心的是提交之后系统有没有处理、医生有没有接诊、检查有没有安排、结果有没有更新。所以这次修改的重点不是单纯增加页面而是让问诊过程中的关键状态能够被用户看见。首先调整的是问诊会话里的状态反馈。原来的后端流程中分诊、医生审核、转诊、检查安排等状态其实已经在系统内部发生了变化但这些变化主要体现在数据库字段或接口返回值上用户端感知不强。这样会导致一个问题用户提交问诊后只看到页面停留在某个状态却不知道系统正在做什么。为了改善这个体验我在后端问诊服务中增加了统一的患者状态消息写入方法。这里的逻辑是把系统状态变化转化成一条患者能看懂的消息并写入当前问诊会话中。它本质上还是一条问诊消息但是消息类型被标记为STATUS_UPDATE内容则是面向用户的自然语言提示。这样小程序端不需要额外设计一套复杂的状态展示机制只要继续展示当前会话消息流就能让用户看到流程推进。比如当系统完成医生分配时后端会自动向会话中插入一条提示告诉用户本次问诊已经分配到哪个科室并由哪位医生继续处理。这个设计比单独显示一个“待处理”状态更清楚因为用户可以直接知道当前任务已经进入了医生审核阶段而不是停留在一个模糊的等待状态。第二个重点是医生审核动作和患者提醒之间的联动。医生端执行接诊、转交、退回继续分析等操作时原本更多是医生任务状态发生变化小程序患者端不一定能马上感受到。现在这些医生操作会同时触发患者侧通知例如“医生已接诊”“问诊已转交”“问诊继续分析中”等。这样用户不需要反复刷新或猜测流程是否推进打开问诊会话就能看到对应提醒。这一部分我主要是在后端审核接口中补充了通知逻辑。以医生接诊为例接口不再只是简单返回任务状态而是先调用服务层完成任务状态更新再根据返回的session_id和session_status触发患者通知。这样接口、业务状态和用户提醒之间就形成了一个完整闭环医生做了操作系统状态改变患者端收到可理解的反馈。第三个调整是检查安排相关的交互。问诊流程中如果需要进一步检查用户必须知道检查项目和设备安排否则体验上会很断裂。所以在创建检查项目时后端会把检查安排写成患者可见消息例如检查名称、设备信息和预约时间。检查结果回写后也会继续向问诊会话补充结果已更新的提示。这样用户在同一个问诊页面里就能看到“为什么要检查、安排了什么、结果是否回来了”。这类状态消息还有一个好处就是它不会把患者端页面做得很复杂。对于用户来说问诊本来就是一个对话过程把系统处理状态放进对话流里反而更自然。用户不需要理解后端的任务表、检查表或状态字段只需要按时间顺序查看消息就能知道问诊进展。第四个修改是消息模块的联系人逻辑。之前消息页里有一些偏系统内部的概念比如对象栏、患者、医生分组等从患者角度看并不够直观。尤其是联系人这个功能如果直接展示所有医生会让用户误以为自己可以随便联系任意医生这和实际业务流程并不一致。所以我把联系人来源改成了真实业务关系。现在联系人不是简单展示所有医生而是根据聊天会话和问诊分配关系来判断。也就是说患者只有在某位医生接诊、参与当前问诊或者双方已经产生过会话之后才会看到这位医生出现在联系人中。这样“联系人”这个概念就更合理也更接近真实产品中的使用逻辑。从代码上看这里主要通过 SQL 条件限制联系人范围。它会检查当前用户是否和对方存在聊天会话或者是否通过问诊分配建立了医生和患者的关系。这样可以避免把系统里的全部医生暴露给患者同时也避免出现“看得到联系人但实际上没有业务关系”的情况。最后还调整了检查计划和检查进度的整合方式。之前前端分别展示计划和进度用户需要自己把两部分信息对应起来。现在小程序端会在接口数据处理时生成planItems把每个检查项目和它对应的进度、下一步动作组合到一起。这样页面展示时就不再是割裂的两块内容而是每个检查项目都有自己的状态说明。这次修改后小程序的主链路比之前更完整了。用户提交问诊后可以持续看到系统追问、医生处理、检查安排和结果回写等信息医生端或后端状态发生变化时也会同步转化为患者能理解的提示。整体上小程序不再只是“能发起问诊”而是开始具备“能跟踪问诊过程”的产品体验。这次优化让我比较明显地感受到前后端联调并不只是接口能不能通更重要的是接口背后的状态变化有没有被用户理解。后端负责维护流程小程序负责表达流程。只有这两部分对齐用户才会觉得这个功能是真的可用而不是只完成了一个技术上的闭环。