企业官网建设流程全解析

从“10分钟一份病历”到“10秒生成草稿”：门诊病历智能生成系统架构设计实践

如果你在医院观察过门诊医生的工作状态，大概率见过这样的场景：一个上午要看 40 到 60 个患者，平均每个患者只有 5 到 8 分钟，医生一边问诊一边敲键盘，还要在患者起身离开后，花一到两分钟补完病历。一上午下来，真正留给医患沟通的时间被压缩得所剩无几。病历书写不是医疗行为里最复杂的部分，却是消耗医生精力最严重、最容易引起医患矛盾的后台环节。

一个被低估的事实是：门诊病历的书写瓶颈，不在“写不快”，而在“信息输入和结构化整理的成本过高”。医生不是不会写，而是要在短时间内在口述、检查报告、历史记录、患者主诉之间快速切换，这种信息检索和重新组织的过程才是真正的耗能点。

所以，当“大模型 + 医疗”成为 2024 年之后的热门方向时，很多人以为“门诊病历智能生成”就是一个对话机器人，医生说一句，AI 补一句。真正落地时你会发现，问题远没有那么简单：病历格式是否符合规范？主诉和现病史之间有没有逻辑断裂？诊断依据是否充分？用药建议是否和既往过敏史冲突？这些都不是“生成一段通顺文本”能解决的问题。

这篇文章要讲的，是门诊病历智能生成系统背后真正起作用的系统架构设计——不是某一个模型的调参技巧，而是从临床场景出发，对数据流、业务状态、AI 能力、人工闭环和合规安全的整体规划。如果你正在设计医疗 AI 系统、电子病历集成方案，或者需要把大模型能力嵌入到高合规要求的业务系统中，这篇文章的架构思路可以直接复用。

1. 门诊病历生成，难点不在生成，而在“把过程变成可计算的状态机”

很多人第一次接触门诊病历智能生成需求时，最大的误解是：找一个大模型 API，输入“根据以下信息生成门诊病历”，输出就完事了。真正进入研发后，你会被一连串问题反复摩擦：

• 病历模板那么多，每个科室、每种疾病都不一样，模型怎么知道用哪个？
• 主诉和现病史是患者复述的，医生口头补充的信息怎么和系统采集到的结构化数据融合？
• 一次门诊要经历“挂号-候诊-问诊-检查-诊断-开药-离院”多个阶段，病历生成到底是哪个阶段触发？
• 如果模型生成的内容有幻觉，谁来兜底？

这里面最关键的问题，不是“模型能不能写”，而是“系统怎么知道现在该写什么、依据是什么、写完怎么确认”。

经过多轮架构评审和临床试用反馈，我们最终确认了一个核心判断：病历智能生成系统必须建立在“就诊流程状态机”之上，AI 只是其中负责“整理和生成”的一个环节，而不是全部。换句话说，你需要先把门诊过程拆解为清晰的业务阶段，明确每个阶段的数据输入和状态流转，再让大模型在合适的节点介入。这样模型生成的病历不是凭空捏造的“一段话”，而是基于前置数据的“一次有序整理”。

1.1 系统边界：不是“取代医生写病历”，而是“帮医生省掉整理时间”

先明确系统做什么、不做什么，这个边界在架构设计之初就要划清楚。

一句话：系统是医生的“文书助理”，不是“诊疗决策者”。这个边界不仅决定了功能范围，也决定了技术架构的复杂度和合规路径。

• 边界之内，我们可以放开用大模型做生成。
• 边界之外，必须有严格的人工审核确认闭环。

落地时，这个边界就体现在一个不可跳过的环节——医生确认。系统生成的病历草稿必须由医生审阅、修改、签名后才能归档。架构设计里，这个环节不是流程上的装饰，而是一条硬性的业务规则。

2. 顶层架构：一个平台，三条数据流，四层能力

整个系统的顶层架构可以概括为：一个接入层对接院内系统，一个业务层编排门诊流程，一个智能层负责生成与质控，一个数据层沉淀知识和数据。核心不是模型本身，而是数据怎么在各层之间有序流转。

门诊病历智能生成系统 - 逻辑架构总览 ┌─────────────────────────────────────────────────────────┐ │ 接入与集成层 │ │ HIS 集成 | EMR 系统 | LIS 检验 | PACS 影像 | 字典服务 │ └─────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────┐ │ 业务编排层（核心状态机） │ │ 挂号 → 候诊 → 问诊 → 检查 → 诊断 → 医嘱 → 归档 │ │ ↓ 各阶段事件消息 │ └─────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────┐ │ 智能生成层 │ │ 病历生成模块 | 知识增强RAG | 结构化输出 | 质控校验 │ └─────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────┘ │ 数据与知识层 │ │ 病历库 | 医学知识图谱 | 模板库 | 术语字典 | 向量库 │ └─────────────────────────────────────────────────────────┘

配合上面这个分层，三条关键数据流必须理清：

1. 患者纵向数据流：从一个患者挂号开始，采集本次就诊全过程的主诉、现病史、体格检查、检验结果、诊断意见。这是生成病历的“事实基础”。
2. 知识横向数据流：从科室标准模板、医学知识库、历史优质病历中检索内容，作为生成病历的“参考规则”。这是控制质量和风格的关键。
3. 反馈回流数据流：医生对生成结果的修改、确认、退回操作，全部记录进入反馈库，用于后续模型优化和模板调整。没有这条流，系统很难持续变好用。

2.1 架构关键词：三个必须有的核心设计

第一次做医疗 AI 系统的团队，最容易忽略下面三个设计。它们不是可选项，而是决定系统能否从 Demo 走向生产的关键。

第一，事件驱动的就诊状态机。所有业务动作都以事件形式进入消息队列，系统根据当前状态和事件类型决定下一步行为。比如“医生点击问诊开始”事件触发“主诉采集”状态；“检验结果回传”事件触发“检查结果更新”状态。状态机的好处是：无论医生操作顺序怎么变化，系统都能准确知道当前应该准备什么数据。

第二，病历生成与数据采集解耦。生成模块只消费“已就绪的数据”，不直接依赖某个医生的实时输入。即使某个环节的数据还没有采集完整，生成模块也不会被阻塞——它会生成一个带有“待补充”标记的草稿，保证医生端始终有内容可以参照。

第三，生成前校验、生成中约束、生成后质控的三段式控制。生成前检查必填数据是否到位，生成中通过模板和知识库约束输出结构，生成后用规则引擎校验医学术语、禁用词、敏感信息。这三段缺一段，系统都会在真实门诊环境中出问题。

3. 核心模块设计：就诊状态机、上下文构建与智能生成

架构不能停留在概念分层，关键模块的设计直接决定系统的实际体验。下面拆解最核心的四个模块。

3.1 就诊流程状态机：让系统知道“现在发生了什么”

状态机是整个系统的骨架。我们定义的主状态包括：挂号完成、候诊中、问诊开始、问诊完成、检查中、检查完成、诊断书写中、医嘱开具中、病历待确认、病历已归档。

// 文件路径：src/main/java/com/hospital/ai/domain/VisitStateMachine.java // 说明：就诊状态机核心流转示例（简化版） public class VisitStateMachine { private VisitState currentState; private final Map<VisitState, Map<VisitEvent, VisitState>> transitions; public VisitStateMachine() { transitions = new HashMap<>(); // 挂号完成 → 候诊 addTransition(VisitState.REGISTERED, VisitEvent.ENTER_WAITING, VisitState.WAITING); // 候诊 → 问诊开始 addTransition(VisitState.WAITING, VisitEvent.DOCTOR_START_CONSULT, VisitState.CONSULTING); // 问诊开始 → 问诊完成（可循环） addTransition(VisitState.CONSULTING, VisitEvent.COLLECT_HISTORY, VisitState.CONSULTING); addTransition(VisitState.CONSULTING, VisitEvent.FINISH_CONSULT, VisitState.CONSULT_DONE); // 问诊完成 → 检查中（若有检查） addTransition(VisitState.CONSULT_DONE, VisitEvent.ORDER_EXAM, VisitState.EXAMINING); // 检查中 → 检查完成 addTransition(VisitState.EXAMINING, VisitEvent.EXAM_RESULT_BACK, VisitState.EXAM_DONE); // 检查完成 → 诊断书写 addTransition(VisitState.EXAM_DONE, VisitEvent.START_DIAGNOSIS, VisitState.DIAGNOSING); // 诊断书写 → 医嘱 → 病历待确认 addTransition(VisitState.DIAGNOSING, VisitEvent.FINISH_DIAGNOSIS, VisitState.ORDERING); addTransition(VisitState.ORDERING, VisitEvent.FINISH_ORDER, VisitState.RECORD_PENDING); // 病历待确认 → 已归档 addTransition(VisitState.RECORD_PENDING, VisitEvent.DOCTOR_CONFIRM, VisitState.RECORD_ARCHIVED); this.currentState = VisitState.REGISTERED; } public void fire(VisitEvent event) { Map<VisitEvent, VisitState> stateTransitions = transitions.get(currentState); if (stateTransitions == null || !stateTransitions.containsKey(event)) { throw new IllegalStateException("当前状态不能响应事件: " + currentState + " + " + event); } this.currentState = stateTransitions.get(event); } }

状态机设计里有三个容易踩坑的细节：

第一个坑：医生操作顺序不固定。实际门诊中医生可能先开检查、后写主诉，也可能直接完成问诊记录。所以状态机要支持循环态和跳跃态，不能设计成单一直线。最稳妥的做法是把“数据采集”和“业务节点”分开建模，数据采集是随时可补充的，业务节点是顺序推进的。

第二个坑：异常状态需要人工介入。如果某次就诊状态卡在“检查中”超过 24 小时，系统要能自动标记异常并通知运维人员。现实中经常发生患者刚抽完血就离开医院、第二天才回来拿报告的情况，这时候状态机不能死等。

第三个坑：同一个患者可能有多条就诊记录在流转。复诊、会诊、转科都会产生新的就诊上下文。状态机的 key 必须是“就诊实例 ID + 患者 ID”，不能只用患者 ID。

3.2 就诊上下文构建：决定病历质量的“隐形核心”

如果只选一个模块决定病历生成质量，我选上下文构建。模型本身能力再强，喂给它的上下文是残缺的、混乱的，输出的病历一定不符合要求。

一个完整的最小上下文包应该包含以下部分：

好的上下文构建，不是把这些信息简单拼接，而是要做四件事：实体统一、时间线整理、冲突标注、缺失提醒。

• 实体统一：把“高血压”“血压高”“HBP”统一为同一个标准概念。
• 时间线整理：把患者口中的“前几天”“上周”“两年前”归一化为具体的相对时间线。
• 冲突标注：如果患者 2022 年病历显示青霉素过敏，本次医嘱里又出现阿莫西林，系统必须亮黄牌。
• 缺失提醒：如果主诉里出现了“胸痛”但体格检查中没有心脏听诊记录，系统提示医生补全。

这四个动作执行完，得到的上下文是一个“经过清洗和校准的事实集合”，而不是原始的噪音堆。这一步的价值在大模型时代反而被放大了——模型的能力越强，对输入数据的质量要求就越高。

3.3 知识增强生成（RAG）：每次生成都“带着参考文献”进行

医疗场景不允许纯靠模型记忆来生成内容，这一点没有讨论余地。所以我们的生成模块不是直接向大模型提问，而是先检索、后生成。

检索来源包括三类：

1. 院内历史优质病历：同科室、同诊断的历史病历是最重要的参考。
2. 科室标准模板：每个科室维护自己的病历模板，规定了必填项和书写顺序。
3. 医学知识库：用于补充诊断依据、鉴别诊断要点、用药注意等专业内容。

检索之后，将命中的片段与就诊上下文一起构造为 Prompt。这个方案有效控制了幻觉的发生率——模型生成的内容不再是“全凭想象”，而是有依据的“抽取 + 整理 + 补全”。

下面是生成阶段使用的 Prompt 模板示例，这个模板在业务中已经经过多轮迭代，核心思路是：结构化约束 + 角色约束 + 缺失标记。

# 文件路径：config/prompts/outpatient_record_generation.yaml # 说明：门诊病历生成 Prompt 模板（生产环境精简版） system_prompt: | 你是一名门诊病历生成助手。你的任务是基于给定的就诊信息， 生成符合《病历书写基本规范》要求的门诊病历草稿。 生成时必须遵守以下规则： 1. 只能使用输入信息中明确提供的内容，不得编造症状、体征或检查结果。 2. 输入中未明确的信息，使用【待补充】标记，禁止自行假设。 3. 主诉应简明扼要，不超过20个字，包含主要症状和持续时间。 4. 现病史按时间顺序描述，包含起病诱因、症状演变、诊疗经过。 5. 诊断使用标准医学术语，多个诊断按重要性排序。 6. 所有药物过敏史必须完整呈现，不得遗漏。 user_prompt: | 请根据以下就诊信息生成门诊病历草稿： 【患者基础信息】 {{ patient_basic_info }} 【主诉】 {{ chief_complaint }} 【现病史采集】 {{ history_of_present_illness }} 【既往史】 {{ past_medical_history }} 【体格检查】 {{ physical_examination }} 【辅助检查】 {{ auxiliary_examination }} 【初步诊断】 {{ preliminary_diagnosis }} 【知识库参考】 {{ rag_context }} 请严格按照病历格式输出。

这个模板的实践要点是：

• 规则写清楚，语气要坚定。“只能使用输入信息中明确提供的内容”比“请综合上下文生成”的约束力强得多。
• 知识库参考放在 Prompt 后段。从实际测试看，放在末位的参考内容更容易被模型在生成时“看到”。
• “待补充”标记是刚需。它让模型在信息不全时不会硬编一段内容，而是诚实地留下缺口，让医生看到哪里需要补。

3.4 结构化输出与校验：病历不能是“文章”，必须是“结构化数据”

很多系统生成病历是直接生成一整段 HTML 或纯文本。这在演示时看起来没问题，落地就会发现致命缺陷：下游系统无法对文本做结构化存储、统计分析和质控检查。

我们的设计是：生成层输出结构化的 JSON，包含主诉、现病史、体格检查等全部字段，再由渲染层把 JSON 渲染为医生端看到的病历表单。这样既保留了模型的自然语言生成能力，又能支持字段级别的校验、修改和追溯。

// 文件路径：src/main/resources/samples/generated_record.json // 说明：病历生成结果的结构化示例 { "recordId": "REC-20250115-0001", "patientId": "P-2024000123", "visitId": "VISIT-20250115-0001", "status": "DRAFT", "sections": { "chiefComplaint": "反复胸痛3天，加重2小时", "presentIllness": "患者3天前无明显诱因出现胸骨后压榨样疼痛，...", "pastHistory": "高血压病史5年，规律服用氨氯地平；青霉素过敏史。", "physicalExamination": "T 36.5℃，P 78次/分，R 20次/分，BP 145/90mmHg...", "auxiliaryExamination": "心电图提示：窦性心律，ST-T改变...", "diagnosis": [ "冠状动脉粥样硬化性心脏病", "高血压病2级（高危）" ], "advice": "建议完善冠脉CTA，门诊随访" }, "generationInfo": { "modelVersion": "medical-llm-v1.2", "knowledgeBaseVersion": "kb-2025-q1", "createdAt": "2025-01-15T10:32:00Z", "confidenceScore": 0.87, "flags": ["待补充体格检查：心脏听诊"] } }

结构化输出的价值在后续的质控环节完全体现出来了。规则引擎可以直接检查：

• 必填字段是否为空？
• 诊断字段是否存在于标准 ICD-10 字典中？
• 主诉字段是否超过了 20 个字？
• 过敏史字段是否完成了与本次医嘱的药物冲突比对？
• 生成的每个字段是否都能追溯到对应的输入来源？

这些检查如果作用在一整段文本上，实现成本极高；但作用在结构化字段上，只是一个简单的规则判断。

4. 技术选型与关键取舍：选型不是选“最强”，而是选“最合适”

很多团队在做技术选型时容易陷入“追最强模型”的惯性。医疗场景的真实约束是：合规要求 > 数据安全 > 输出可控性 > 模型效果 > 推理速度。这个优先级排序在架构设计阶段就要定下来，否则后面每走一步都在摇摆。

4.1 模型部署形态：私有化优先

病历数据属于医疗健康数据，受严格的数据安全法规约束。任何一家医院把患者数据传到外部 API，在合规上都是不可接受的。因此，我们的架构设计从一开始就确定：模型私有化部署，支持纯内网环境运行。这也意味着，选型时不能只看模型效果排行榜，必须考虑模型是否支持本地部署、显存占用、推理性能和硬件成本。

从实践看，建议根据医院规模和预算分两条路线：

• 大型三甲医院或医联体中心医院：部署 70B 级别以上的通用底座模型 + 医疗微调，配合多卡推理集群。
• 二级医院或社区医院：部署 7B 到 14B 级别的模型，在病历生成场景上已经可以达到不错的实用水平，关键是把 Prompt 和知识库做扎实。

4.2 术业有专攻：通用大模型 + 专用小模型协同

这里分享一个重要的架构经验——不要指望一个大模型干完所有事。病历生成系统中的许多子任务，用相对轻量的专用模型或规则算法，效果更好且成本更低。

例如：识别病历中的“时间相关实体”（“三天前”“两年余”）并归一化，可以用一个只有几百万参数的 NER 模型完成，准确率远高于大模型，而且推理速度快得多。药物名称标准化、ICD-10 诊断编码映射，则更适合用规则 + 字典 + 相似度检索实现。

所以最终的技术架构是“混合架构”：

4.3 检索方案：不是只有一个向量库

医疗领域的知识检索不能只靠向量相似度。原因很直接：医学概念之间的语义相似并不代表临床相关性，“咳嗽”和“咳痰”向量相似度高，但这不是检索患者病历时的重点。我们需要的是和当前患者具体情况相关的历史病历、模板和知识片段。

实践方案是“混合检索”：先用规则和结构化标签过滤出候选集，再用向量召回做排序。比如先限定“同一科室”“同一主诊断”“近三年数据”作为结构化过滤条件，再在过滤后的集合内做语义相似度检索。效果和性能都明显优于单用向量库。

5. 数据模型设计：病历字段、事件数据与反馈数据

数据模型设计是系统从 demo 走向工程的必经关口。这里给出三个关键数据模型的设计思路。

5.1 病历主数据模型：横向扩展优先

病历的数据结构不能是“一张大表”，而要采用“主记录 + 分段明细”的方式，以便适应不同科室模板的差异。核心主表就是上文的 JSON Schema 对应的关系表结构。

-- 文件路径：sql/medical_record_schema.sql -- 说明：门诊病历主表结构（简化版） CREATE TABLE outpatient_record ( record_id VARCHAR(64) PRIMARY KEY, visit_id VARCHAR(64) NOT NULL, patient_id VARCHAR(64) NOT NULL, record_status VARCHAR(20) NOT NULL DEFAULT 'DRAFT', doctor_id VARCHAR(64) NOT NULL, department_id VARCHAR(64) NOT NULL, template_id VARCHAR(64) NOT NULL, chief_complaint TEXT, present_illness TEXT, past_history TEXT, physical_exam TEXT, auxiliary_exam TEXT, diagnosis JSONB, treatment_advice TEXT, generation_meta JSONB, confirm_time TIMESTAMP, archive_time TIMESTAMP, created_at TIMESTAMP NOT NULL DEFAULT NOW(), updated_at TIMESTAMP NOT NULL DEFAULT NOW() ); CREATE INDEX idx_outpatient_record_visit ON outpatient_record(visit_id); CREATE INDEX idx_outpatient_record_patient ON outpatient_record(patient_id); CREATE INDEX idx_outpatient_record_status ON outpatient_record(record_status);

实际项目中，建议把 JSONB 字段拆分为独立子表，尤其当需要做统计分析时。但如果是中小规模系统，JSONB 的灵活性能省去很多麻烦。平衡点是：需要检索和质检的字段放正表，纯展示性内容放 JSONB。

5.2 事件流水表：审计与复盘的“黑匣子”

事件流水表是容易被忽略但很重要的设计。系统内的所有关键动作都落一条事件记录，包括 AI 生成动作、医生修改动作、确认归档动作。

CREATE TABLE system_event_log ( event_id BIGSERIAL PRIMARY KEY, event_type VARCHAR(50) NOT NULL, visit_id VARCHAR(64) NOT NULL, operator_type VARCHAR(20) NOT NULL, operator_id VARCHAR(64), event_payload JSONB, trace_id VARCHAR(64), created_at TIMESTAMP NOT NULL DEFAULT NOW() );

这条表的价值在系统上线后逐渐显现：可以追溯任何一份病历的生成过程、医生做了哪些修改、模型哪个版本生成的、当时上下文包含哪些信息。最直接的应用场景是处理医患纠纷时，系统能提供完整的操作证据链。

5.3 反馈数据模型：可持续优化的燃料

病历智能生成系统的迭代离不开反馈数据。医生每一次的修改、删除、补充操作，都是模型优化的训练素材。

CREATE TABLE generation_feedback ( feedback_id BIGSERIAL PRIMARY KEY, record_id VARCHAR(64) NOT NULL, model_version VARCHAR(50) NOT NULL, prompt_version VARCHAR(50) NOT NULL, kb_version VARCHAR(50) NOT NULL, generated_json JSONB NOT NULL, final_json JSONB NOT NULL, field_diffs JSONB NOT NULL, is_confirmed BOOLEAN NOT NULL DEFAULT FALSE, created_at TIMESTAMP NOT NULL DEFAULT NOW() );

这个表适合在系统运行一段时间后做分析：哪些字段医生修改频率最高？哪些科室的生成准确率偏低？哪些模板需要调整？这些都是模型和提示词优化的直接依据。

6. 安全与合规设计：每一个环节都要回答“权限够不够”

医疗数据的安全要求是所有行业里最高的一档。架构设计在安全方面要做的不是“加一层防火墙”，而是在每一个数据访问环节都内置权限校验，做到“显式授权、最小访问、全程审计”。

6.1 数据分级与权限控制

把系统中的数据明确分为几个安全级别：

权限控制必须落实到 API 层和数据访问层，不能只做前端隐藏。任何从服务端返回数据的接口，都要根据当前登录用户的角色、科室、授权范围执行数据过滤。

6.2 模型生成的合规红线

生成模块的代码里，必须写死几条不可逾越的合规规则：

• 生成结果中禁止出现任何患者身份信息（姓名、身份证号、手机号）之外的额外隐私信息，如果模型从上下文中抽取到了，也要做脱敏遮蔽。
• 生成结果中必须保留过敏史、重大既往史等关键字段，不得遗漏。
• 生成结果中如果出现模型自行补充的、上下文不存在的诊断或检查建议，必须通过后置校验拦截，标记为“疑似幻觉”。

这些功能不能只靠 Prompt 约束。正确做法是：Prompt 做第一层软约束，规则引擎做第二层硬校验，两层都通过后才允许展示给医生。

6.3 操作审计与留痕

医生每次确认、修改病历，AI 每次生成、改写，都要有对应的审计日志。审计日志的核心字段包括：操作人、操作时间、操作类型、操作前后的内容对比、关联的模型版本和知识库版本。

这个设计虽然增加了一些存储成本，但在医疗场景下是刚需。一旦出现病历质量争议或医患纠纷，完整的审计链路是系统提供证据能力的基础。

7. 落地实施路径：从试点到全院推广的分阶段策略

架构设计得再完整，落地时如果一次性全面铺开，大概率会失败。医院环境比互联网产品复杂得多，科室差异大、医生接受度不一、系统集成历史包袱重。建议按下面三个阶段推进。

7.1 阶段一：单科室试点（1~2 个月）

选择一个病历规范程度高、患者量大、医生对新技术接受度高的科室作为试点，比如内分泌科或心内科。试点期间的目标是验证三件事：

1. 系统能否稳定地从 HIS/EMR 获取数据并完成病历生成？
2. 医生是否愿意使用生成结果并做基础修改？
3. 病历生成的质量是否达到“可直接修改后归档”的程度？

试点阶段不要追求覆盖率，重要的是收集真实反馈、发现问题、调优 Prompt 和知识库。

7.2 阶段二：多科室扩展（2~3 个月）

试点跑通后，可以扩大到 3 到 5 个科室。这个阶段要考虑的核心问题是模板配置的标准化流程。每个科室的模板差异极大，需要建立模板管理和版本控制的机制，让各科室的模板维护人可以自助完成配置。

同时，这个阶段要建立监控体系，包括生成成功率、医生采纳率、修改字段频次、系统响应耗时等核心指标。

7.3 阶段三：全院推广（持续迭代）

全院推广阶段，最大的技术挑战是并发压力和系统稳定性。需要提前规划生成服务的水平扩展能力、消息队列的积压告警、数据库的读写分离等生产级能力。

更重要的是开始构建“病历质量闭环”：定期统计医生修改最多的字段、科室反馈集中的问题，反哺知识库和模板优化。这个阶段的目标不再是“生成病历”，而是“持续提升病历质量”。

8. 常见问题与排查思路

根据实际项目中的高频问题，整理了下面这份排查清单，适合开发和运维人员在现场快速定位。

这套排查清单看起来简单，但在真实环境中，每个问题背后都可能藏着一个系统集成层的 bug。排查时优先看事件流水和上下文日志，大多数生成质量问题都能在“数据进模型之前”找到根因。

9. 最佳实践与工程建议

结合整个系统从设计到落地的过程，下面这几条建议如果能在项目早期就考虑进去，会少走很多弯路。

9.1 病历模板用版本管理

病历模板不是一次性配置完就结束的。科室的书写习惯、医院的质控要求、上级部门的规范更新，都会导致模板调整。建议将模板纳入独立的版本管理流程，每次修改都要经过科室负责人审核。同时，历史病历上要能追溯到当时使用的模板版本，否则批量质控时会发现同一类病历的格式对不上。

9.2 质控规则要“可解释”

医疗 AI 系统一个特殊要求是“为什么这样生成”必须能解释。结构化输出后，每个字段最好都能记录依据来源，比如某个体征描述来自医生录入还是模型推断还是既往史。这样医生看到生成结果时，如果觉得不对，可以直接追溯是哪条数据导致的问题。

9.3 医生反馈闭环不能省

没有反馈机制的 AI 系统，上线三个月后效果就开始跟不上实际需求。医生每天取消生成结果、重新手写的次数，就是系统改进最重要的信号。建议在门诊医生站界面加一个一行字的反馈入口——“生成结果不理想，点此提交原因”，哪怕是简单的选项（主诉不全、现病史不准确、格式不符、其他），都能为迭代提供巨大价值。

9.4 先用规则模型解决 80% 的问题

接入大模型之前，先把能用规则解决的事情做完：主诉字数自动截断、诊断编码自动映射、过敏史自动比对、缺失内容自动高亮。这些基础能力做完，大模型生成的质量已经有了初步保障，因为它面对的“输入数据”已经足够干净。很多团队一上来就调 Prompt，其实应该先调数据。

9.5 数据库和缓存设计要有冗余

门诊高峰时段（上午 8:30-11:30），生成系统的并发量是平时的数倍。建议做好三级缓存：常用知识库结果预热到内存、患者最近一次就诊的上下文保存到 Redis、生成结果落库前先做异步化。系统整体架构要支持在高峰期把 AI 生成降级为“规则模板生成”，保证医生的基本体验不受影响。

9.6 关注“医生取消生成”的原因

医生使用生成系统但不确认草稿，往往不是医生不认可 AI，而是生成结果和他在这个特定场景的书写习惯差异太大。这种情况最值得分析。建议在反馈数据模型里记录医生是在生成后直接修改，还是完全删除重写。直接修改说明生成方向对、细节偏差；完全删除则说明生成思路从一开始就不对，可能需要调整模板和上下文供给策略，而不是继续调模型。

10. 总结与下一步实践建议

门诊病历智能生成系统的架构设计，核心不是某个模型有多强，而是能不能构建一个临床流程驱动、数据质量可控、生成行为可解释、操作全程可追溯的闭环体系。

回顾全文，有几个必须记住的关键点：

• 边界清晰：系统是辅助生成工具，医生确认是硬性闭环，任何情况下都不能跳过。
• 状态机驱动：以就诊流程状态机为骨架，AI 模块只是处理数据的一个环节，而不是全部。
• 上下文决定质量：生成效果的上限取决于上下文构建的质量，Prompt 和模型只是“最后一公里”。
• 结构化是前提：生成结果必须是结构化数据，才能支撑校验、追溯和统计分析。
• 反馈是灵魂：没有反馈闭环的系统只是“一次性生成工具”，有反馈闭环的系统才能持续变好用。

如果你正准备在一个真实医院环境里落地类似系统，建议的下一步是：先选一个科室，梳理该科室的门诊流程和病历模板，画出状态机和上下文数据流，再用最小原型验证生成效果。不要一上来就追求全院覆盖，从单一科室、单一路径、最小闭环跑通开始，比什么都重要。

对于医疗行业的研发团队来说，这个系统的架构思路完全可以复用：先解决数据从哪里来、怎么变成干净的结构，再决定模型做什么、边界在哪里，最后把人工闭环和合规要求嵌入到流程的每一个节点。技术选型会变，模型会升级，但这条架构主线在相当长一段时间内都是稳定的。