于江水这是山东大学软件学院创新项目实训进入第二阶段后的开发记录。系统的目标没变：用UE搭建3D虚拟诊室，由LLM驱动一位会“带情绪、有隐瞒、会纠结”的标准化患者，让医学生能在里面反复练习医患沟通，结束后拿到一份结构化的沟通能力评价报告。这一篇的内容，主要是LLM对话链路怎么真正接进UE、患者角色怎么“演得像”、评价模块怎么从主观打分变成可解释的反馈。如果你也在做医疗教育信息化、虚拟仿真实训，或者正在折腾把大模型塞进UE项目，这篇的经验可以直接搬。
1. 阶段目标拆解：先别急着炫技，把“可用的闭环”跑通
1.1 项目最终要解决什么问题
先摆一摆现实背景。医患沟通能力的训练，在医学教育里一直是个老大难。传统的标准化病人（SP）模式效果很好，但成本高、可重复性差、病例覆盖有限，遇到疫情等原因还经常中断。而纯粹用预设对话树做的模拟系统，学生只要记住几个固定选项就能蒙混过关，练不出真实对话中的临场感和情绪处理能力。
我们希望做出来的系统，是一个“能练、能评、能复盘”的闭环。学生进入一个虚拟诊室，面对一个由LLM扮演的、有具体症状和情绪状态的患者，用自然语言自由问诊。系统在后台记录整段对话，从信息采集完整性、共情表达、问诊结构、信息告知等多个维度给出评价。训练结束后，学生能看到自己的得分和具体的改进话术，老师也能看到班级整体的能力画像。
到了第二阶段，技术任务细化下来就是三件事：把大模型接到UE项目里并保证稳定对话、让UE端患者的情绪和反馈跟上对话内容、把评价逻辑做成一套能落地的规则引擎加LLM分析服务。这三件事互为支撑，谁拖后腿整个演示都会崩。
1.2 为什么技术栈偏偏是UE加LLM
选型的过程我们其实推翻过好几版。最初有人提议直接做Web版，用网页加聊天框实现，开发快、部署方便。但这类沟通训练对“临场感”的要求很高，学生需要看到患者的表情、坐姿、情绪变化，甚至后续我们会加入VR头显版本，UE在这一层的优势是其他方案很难替代的。再加上项目组希望在场景里实现可交互的3D检查设备、体征展示面板，UE的实时渲染和蓝图快速迭代能力正好能承接这些内容。
LLM替代传统对话树的原因更直接。预设分支的用户体验是断裂的，学生一旦换了说法，系统就答非所问，训练就变成了猜答案。LLM可以在角色设定约束下自由生成回答，学生无论用口语化、书面化甚至方言化的表达，患者都能自然回应。把LLM当作患者的大脑，把UE当作患者的身体，这个组合就成了整套系统的技术底座。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 患者角色的灵魂：从角色卡到Prompt工程
2.1 患者角色卡设计：信息结构化才能让LLM不发散
LLM默认什么都知道，但我们要的不是一个“全知患者”，而是一个只知道自身病情、对医学知识一知半解的普通人。所以第一步就是做角色卡，把患者的个人信息、主诉、现病史、既往史、性格特征、情绪状态全部结构化。
我们的角色卡放在服务器端的JSON里，字段包括：name、age、job、chiefComplaint、presentIllness、pastHistory、personality、currentEmotion、communicationStyle、knowledgeBoundary。其中knowledgeBoundary特别重要，它明确告诉模型哪些检查结果患者自己也不知道、哪些医学名词患者听不懂，防止模型“开天眼”把不该说的信息直接抛出来。
把病例拆成数据而不是写死在Prompt里，是为了让指导老师也能配置病例。老师不熟悉代码，我们就做了一套简单的病例编辑界面，输出固定JSON结构，系统启动时由UE请求服务端拉取病例列表。
在每轮对话开始前，系统会把角色卡转成一段system prompt，大致结构是这样的：
text复制你是一名前来内科门