构建本地优先的AI医疗文书助手：以浏览器为前沿，重塑临床信任与工作流
1. 项目缘起：当AI医疗文书助手遇到信任危机
最近我动手做了一个基于浏览器的AI医疗文书助手原型。这事儿听起来可能有点技术宅的自娱自乐，但背后的动机其实挺直接的：我想验证一个在行业里被反复讨论，但可能问错了方向的问题。市面上几乎所有的“环境智能AI文书助手”产品，宣传重点都放在“生成的病历质量有多高”上——语法更流畅、结构更清晰、用词更专业。这当然重要，但当我真正和一线临床医生、医院信息科的管理者聊过，再翻看那些关于医生职业倦怠的研究报告后，我意识到，大家内心深处最大的疙瘩，可能根本不是“笔记写得好不好看”，而是“我能不能信任这个黑盒子”。
想想看医生的日常。一项发表在《内科学年鉴》上的经典工时研究发现，医生在门诊日仅有27.0%的时间用于与患者面对面交流，却有高达49.2%的时间花在了电子病历系统和案头文书工作上。另一项《家庭医学年鉴》的研究描述得更直白：初级保健医生每提供1小时直接患者护理，就需要在电子病历相关任务上花费近2小时。这种时间上的挤压是真实而痛苦的，也难怪任何能“减负”的工具都会引起关注。有早期证据显示，在某些场景下，环境智能文书助手确实能降低行政负担和职业倦怠感。例如，《JAMA网络开放》上的一项多中心质量改进研究显示，使用环境AI文书助手30天后，报告职业倦怠的临床医生比例从51.9%下降到了38.8%。
然而，工具好用和医生敢用是两回事。当我把一个能生成漂亮总结的AI演示给医生看时，他们最常问的不是“它写得怎么样”，而是一连串更尖锐的问题：这段对话录音和文本数据最终存在哪里？谁有权查看处理过程？如果AI理解错了，我该怎么高效地复核和修正，而不是陷入另一种形式的“校对苦役”？如何审计这个工具在什么时间、基于什么输入、产出了什么？最重要的是，这个生成的文档，怎么能不是以一个孤零零的附件形式，而是真正结构化地回流到我们的医院信息系统里？这些问题，指向的都是信任、治理与工作流整合，而不仅仅是文本质量。
这让我把问题收窄，变成了一个更具体、甚至有点“笨拙”的技术实验：在不依赖项目后端服务器的情况下，一个有用的环境智能文书助手工作流，能否完全在用户的浏览器里跑起来？我们能否通过“本地优先”的设计，从起点上重塑关于数据隐私和可控性的对话？
2. 技术选型：为什么浏览器再次成为前沿战场
几年前，“在浏览器里做AI”可能只是个炫技的演示，离实用很远。但技术风向确实变了。浏览器正从单纯的“网页渲染器”演变为一个强大的本地计算平台，关键推动力是设备端模型能力的开放。以谷歌Chrome的“内置AI”计划为例，它明确将客户端模型定位为一种在保护敏感数据、降低延迟的同时提供AI功能的方式。其提供的Prompt API，让开发者能在浏览器中调用像Gemini Nano这样的轻量级模型。这意味着，语音转录、文本摘要这些原本必须上传云端才能完成的任务，现在有机会在用户自己的设备上闭环处理。
这个转变意义重大。根据Chrome的官方文档，在初始模型下载完成后，后续的使用可以离线进行，并且明确声明在使用该模型时，不会将任何数据发送给谷歌或第三方。虽然目前这类API仍有平台和硬件限制（例如特定的操作系统要求，以及Chrome配置文件所在卷需要有至少22GB的可用空间），设置过程也还带着“实验性功能”的毛糙感，但它指出了一个清晰的趋势：浏览器正在成为一个兼顾强大AI能力和数据隐私的、唾手可得的沙盒。
“本地优先”并非银弹，但它为解决医疗AI中最棘手的信任问题提供了一个全新的起点。当数据处理的全流程——从音频捕获、语音转文字、到文本分析与结构化——都发生在用户设备本地时，关于数据泄露、云端存储合规性、第三方数据使用的许多担忧，从架构上就被极大地缓解了。这为与临床医生、信息科和合规部门的对话，奠定了一个更坚实、更可信的基础。我的原型项目“AI Medical Scribe”正是基于这个思路的一次构建尝试，它完全开源，并明确将自己定位为一个用于激发讨论的“概念验证”，而非一个成熟的临床工具。
3. 核心工作流设计与功能拆解
这个浏览器原型的目标，是模拟一个完整的诊室文书生成闭环，同时确保所有敏感数据不出设备。它的核心工作流可以分解为几个关键阶段，每个阶段都针对“信任”和“可用性”做了特别设计。
3.1 信息捕获与结构化标记
工作流始于诊室对话。原型利用浏览器的Web Speech API或MediaRecorder API进行实时音频捕获和语音转写。这里的第一步设计取舍就出现了：纯粹的本地语音识别（如使用WebAssembly版本的Whisper）能提供最佳的隐私性，但识别精度和速度在浏览器环境中可能不及成熟的云端服务。作为原型，我优先确保了“本地”这一属性，接受其在专业医学术语识别上可能存在的折衷。
更重要的是，在转写的同时，医生可以实时进行手动标记。这不是简单的打字记录，而是通过预设的快捷键或按钮，在对话时间轴上打上结构化的“标记点”。例如，当患者描述“胸痛”症状时，医生可以快速标记为[症状]；当提到“阿司匹林”用药史时，标记为[用药史]。这些标记在后端并非装饰，而是为后续的AI理解提供强力的上下文锚点。它相当于医生在实时引导AI：“注意，接下来这段是关于既往史的”，这能显著提升后续信息提取的准确性和结构性。
3.2 本地AI生成与“置信度”感知
当问诊结束，点击生成按钮后，最核心的魔法在本地发生。转写文本和标记序列被组合成一个详细的提示词，发送给浏览器内置的AI模型（如通过Prompt API调用的Gemini Nano）。我设计的提示词工程远不止“请总结以下对话”，而是包含了明确的指令：
- 角色定义：你是一名专业的医疗文书助手。
- 输出结构：请按照“主诉”、“现病史”、“既往史”、“体格检查”、“评估与计划”等标准临床章节组织内容。
- 信息源引用：要求AI在生成的文本中，尽可能引用原始对话的时间戳或标记点，例如“（基于对话第120秒处患者描述）”。
- 不确定性标注：对于模糊或冲突的信息，要求AI以高亮或
[待确认]的形式标注出来。
这一步生成的不是一段普通的文本，而是一份带有初步结构和置信度提示的草稿。模型会对其生成的不同部分给出内在的置信度评分（如果模型支持）。原型界面会将这些信息可视化，比如用浅黄色背景标出低置信度片段，提醒医生此处需要重点审核。
3.3 审核界面与可审计的修改
生成草稿后，医生进入审核界面。这是整个工具价值体现的关键，也是区别于“另一个文本编辑器”的核心。审核界面被设计为“三栏对比视图”：
- 左侧栏：原始的、带时间戳的对话转录文本。
- 中间栏：AI生成的、结构化的临床笔记草稿，其中低置信度部分已高亮。
- 右侧栏：一个可编辑的最终文档区域，初始内容为AI草稿。
医生可以逐段审核。点击AI草稿中的任何一句话，界面会自动在左侧的原始转录中定位并高亮对应的源文本段落，实现“溯源式审核”。医生可以直接在右侧栏修改最终文档。所有修改行为——增、删、改，连同修改时间、修改前的原文和修改后的文本——都会被自动记录到一个本地的、仅追加的审计日志中。这个日志是加密存储在浏览器IndexedDB中的，它提供了完整的操作溯源，回答了“谁在什么时候改了哪里，从什么改成了什么”这个关键的审计问题。
3.4 结构化输出与FHIR标准握手
审核定稿后，最后一步是输出。原型提供了两种方式：
- 标准临床文档：导出为结构化的Word或PDF文档，包含所有标准章节。
- FHIR格式导出：这是为了探索与医院信息系统整合的可能性。原型会将最终的笔记内容，按照HL7 FHIR标准，打包成一个
Bundle资源，其类型为document，并且严格遵循“Composition资源作为Bundle第一条目”的规范。Composition资源包含了文档的元数据（作者、时间、状态）和章节结构，而具体的观察、诊断、用药建议等内容则作为被引用的其他资源（如Observation,Condition）一同包含在Bundle中。
这个FHIR Bundle可以通过一个简单的HTTP POST请求，发送到一个预先配置好的接收端点（例如医院信息系统的集成引擎）。虽然一个原型不可能解决真实的EHR集成所有复杂问题（如身份认证、工作流触发、数据映射），但生成一个符合标准的FHIR文档，迫使我们在设计之初就思考“结构化交接”的真正含义，而不是停留在“输出一段文本”的层面。
4. 本地优先架构的深层考量与挑战
构建一个“无后端”的浏览器应用，听起来像是把复杂性都扔给了前端，但实际上，这种架构选择带来了一系列独特的好处和必须直面的挑战。
4.1 隐私与数据主权的架构优势
最明显的优势是隐私。所有数据——敏感的医患对话录音、转写文本、生成的草稿、审计日志——都留在用户的设备上。没有中心服务器存储，从根本上消除了大规模数据泄露的风险，也简化了合规论述。对于医疗机构而言，这意味着工具可能绕过一些最复杂的数据出境和第三方数据处理协议。部署也变得极其简单：只需要一个URL。医生在任何有现代浏览器的电脑上打开链接即可使用，无需IT部门安装客户端软件或配置服务器。版本更新对用户也是透明的。
4.2 性能、能力与离线工作的现实约束
然而，优势的反面就是约束。设备端AI模型的能力和速度目前无法与强大的云端GPU集群相比。处理一段20分钟的诊室对话，在本地生成总结可能需要几十秒甚至更长时间，而云端可能只需几秒。模型的“知识”被冻结在下载的那一刻，无法像云端模型那样持续更新。浏览器的存储（IndexedDB）有容量限制，长期大量使用需要设计数据清理归档策略。复杂的操作（如处理超长音频）可能导致浏览器标签页卡顿甚至崩溃。
注意：“本地优先”绝不等于“自动合规”或“绝对安全”。即使数据不出设备，你仍然需要回答一系列严肃的安全治理问题：运行应用的电脑本身是否安全（是否加密、是否有恶意软件）？浏览器扩展是否会窃取数据？如何管理设备丢失风险？如何设置访问控制（防止非授权人员使用）？数据的本地保留期限和清理策略是什么？正如相关机构指南中反复强调的，组织需要的是具体的治理、信息治理和安全实践，而非基于“感觉安全”的安慰。
4.3 与开源生态的对话与定位
在这个领域，我的浏览器原型并非孤例，它只是探索设计空间的一个点。例如，OpenScribe是一个开源医疗文书助手，它采用了混合架构：在网页端进行本地Whisper语音转写，但将文本发送到云端Anthropic的Claude模型生成笔记，同时也提供完全本地的桌面端版本。而Open Medical Scribe则采用了“可插拔供应商”架构，支持完全本地运行（通过Ollama本地运行大模型），也支持在隐私约束允许时切换至云端供应商。
我的原型没有试图比它们“更好”，而是做了一个不同的技术赌注：如果分发机制就是一个URL，并且默认的信任边界尽可能小，会怎样？它牺牲了一些能力和灵活性，换来了极致的部署简易性和隐私清晰度。这些不同的项目共同描绘了医疗AI工具未来可能的多条路径：全云端、混合、全本地桌面端、全本地浏览器端。选择哪条路，取决于具体场景下对隐私、能力、成本和集成深度的权衡。
5. 无法回避的硬核问题：审核负担与系统集成
即使我们完美解决了本地捕获和生成的问题，两个最硬的骨头依然摆在那里：医生如何高效审核AI产出？以及审核后的成果如何无缝融入现有临床工作流？
5.1 审核负担：从“重写”到“高效校验”
如果医生需要以从头书写病历的同等仔细程度来审核AI生成的每一句话，那么节省时间的承诺就会落空，工作只是从“书写”转移到了“校对”，负担并未减轻。这并非理论风险。多项评估AI生成临床笔记的研究都指出了“全面性”与“风险”之间的权衡。例如，一项研究发现，环境智能LLM生成的笔记中，存在“幻觉”（即AI编造或误解信息）的比例约为31%，而医生手写的“黄金标准”笔记中这一比例约为20%。但同时，AI生成的笔记在条理性和完整性上可能更好。
这个数据恰恰说明，工具设计的重点不应是“让段落更优美”，而是构建能应对已知失败模式（如幻觉）的审核工具。我的原型尝试通过几种方式缓解审核负担：
- 置信度可视化：直接高亮AI自己都不确定的部分，引导医生优先关注。
- 溯源对照：一键链接生成内容与原始对话，让复核有据可依。
- 差异对比：在审计日志中清晰展示历次修改，快速定位变动。
- 模板化片段：为常见诊断和计划提供可快速插入的标准化文本块，减少重复性编辑。
审核界面的设计哲学，是让医生扮演“编辑”和“验证者”的角色，而不是“抄写员”。工具应该提供所有必要的上下文和辅助信息，支持医生快速做出专业判断。
5.2 系统集成：从“玩具”到“工具”的鸿沟
如果AI生成的精美文档最终只能以PDF附件的形式手动上传到电子病历系统，或者更糟，需要医生复制粘贴，那么这个工具就注定是一个“边车工具”，会在采购评估、实际部署或日常使用的摩擦中逐渐被弃用。相关指南对此毫不讳言，它强调了与电子病历/患者记录系统集成的重要性，甚至明确指出像FHIR/HL7这类标准对于成功采用的关键作用。
这就是为什么我在原型中加入了FHIR导出功能。并非因为“FHIR导出就等于解决了集成”，它远非如此。真正的集成涉及单点登录、患者上下文匹配、工作流触发（例如，在诊间结束后自动弹出草稿）、以及与医院特定数据模型的深度映射。FHIR导出更像是一种“思维实验”或“集成就绪性”的测试。它迫使我们去思考：一个结构化交接的最小可行产品应该长什么样？FHIR标准本身对临床“文档”的形状有明确定义：一个单独的Composition资源不是文档，它必须是一个类型为document的Bundle资源中的第一个条目，并且所有被引用的资源都必须包含在这个Bundle中。
遵循这种结构，即使是在原型中，也能引导设计远离“这是一些文本”，转向“这是一个理论上可以传输的、结构化的信息包”。它为与医院IT部门或集成商的对话提供了一个具体的、基于标准的起点，而不是空泛的功能描述。
6. 实践复盘：经验、教训与未来方向
构建并展示这个原型的过程，本身就是一个密集的学习和反馈循环。它验证的不是技术成熟度，而是一种沟通方式的有效性。
6.1 原型验证的核心价值：让抽象讨论落地
这个实验证明的最重要一点是：我们现在已经足够接近，可以在浏览器中构建一个可信的本地优先文书助手工作流原型。而一旦它存在，相关的讨论就会变得更具象、更深入。当你能向临床医生、信息科主任或合规官展示一个实际可用的东西，而不是仅仅描述一个概念时，问题会变得非常具体：
- “数据流”具体指什么？录音数据在捕获层是缓存在内存里还是立即写入硬盘？转写过程中的中间文本如何处理？
- 当已知AI会有“幻觉”时，审核界面应该提供哪些信息来辅助医生识别风险？
- 对于一个仍需人工签核的工具，“可审计性”具体意味着要记录哪些元数据（如模型版本、提示词模板）？
- 如果真正的壁垒是集成工作，那么“交接”的最小数据集是什么？是完整的FHIR Bundle，还是一个更简单的JSON结构？
原型成了一个强大的沟通锚点，将关于隐私、信任、工作流的抽象辩论，拉回到了具体的功能、界面和数据处理细节上。
6.2 开发中的关键决策与避坑指南
在实现过程中，有几个技术决策点值得分享：
- 音频处理策略：最初尝试完全在浏览器内进行实时流式转录，这对性能挑战极大，尤其当对话较长时。后来调整为“录制后整体转写”模式，降低了实时处理的压力，更符合诊室“问诊-记录”分步进行的实际场景。
- 本地存储策略：使用
IndexedDB存储审计日志和对话记录，但必须设计有效的清理策略。我们实现了自动滚动归档，只保留最近N次会话的详细数据，更早的数据仅保留摘要和FHIR输出，防止存储膨胀。 - 模型交互的降级方案：不是所有用户的浏览器都支持内置AI API。原型必须包含一个优雅的降级方案：检测API可用性，如果不可用，则提示用户“本地AI功能不可用”，但依然保留手动笔记、标记和导出等核心功能，确保工具的基本可用性。
- 提示词工程的迭代：生成质量极度依赖提示词。我们经历了多轮迭代，才让模型学会区分“患者自述”和“医生询问”，并正确归类到“现病史”和“既往史”。加入“请避免使用诊断性语言，仅客观记录症状”这样的约束也至关重要。
6.3 临床反馈与产品化思考
向临床医生演示时，反馈非常直接。他们普遍对“数据留在本地”的概念表示赞赏，这直接回应了他们的首要关切。审核界面中的“溯源对照”功能被评价为“最有价值的部分”，因为它解决了对AI“胡编乱造”的恐惧。然而，他们也指出了关键差距：
- 医学术语支持：本地通用模型对专业药物名称、罕见病名的识别和拼写准确率不足。
- 工作流打断：目前的原型还是一个独立的浏览器标签页，与医生日常沉浸其中的电子病历系统是分离的，切换成本高。
- 自定义模板：不同科室、不同医生有自己的文书习惯和模板，原型需要支持高度自定义。
这些反馈清晰地指出，从“可信的原型”到“可用的产品”，还有很长的路要走。下一步可能不是让浏览器原型变得更复杂，而是思考如何将其核心组件（本地AI处理、审核界面、审计日志）封装成可嵌入的模块，通过标准协议（如FHIR, SMART on FHIR）与现有的电子病历平台进行深度集成，让医生在不离开熟悉工作环境的前提下，享受到本地AI辅助带来的隐私与效率平衡。
这个项目的代码完全开源，它更像一个抛出的问题，而非一个给出的答案。它邀请开发者、临床工作者和医疗IT专家共同思考：在AI席卷医疗健康的时代，我们如何能既拥抱技术带来的效率，又坚守对患者隐私和临床安全的承诺？本地优先的架构，或许为我们提供了一条值得深入探索的路径。