上周，达拉斯一位程序员脖子僵了，转头都困难。不致命，但急。他打开远程医疗 App，最早预约：30小时后。
这个场景被 Prashant Anand 记了下来。不是系统崩了，是系统本来就这么设计的。医疗的问题从来不是缺专家，是决策链条太长。他算了一笔账：症状描述→医生理解→分诊判断→药房对接，每个环节都在吞时间。
他的解法不是造"AI医生"，而是做一个把流程压扁的"临床协处理器"。
从"话说不清"到"结构化的病历"
患者说话是混沌的。"脖子疼，昨晚开始的，有点晕，可能睡落枕了"——这是人话，不是医学术语。传统系统要么让护士手工录入，要么扔给患者填标准化问卷，体验极差。
Anand 的方案是用大语言模型（LLM，Large Language Model）做特征提取。患者自由输入，AI 实时解析，输出结构化字段：症状部位（颈部）、性质（疼痛/活动受限）、持续时间（12小时）、伴随症状（轻度头晕）、诱因（睡眠姿势）。
他对比了两种路径。纯规则引擎需要预设数千条关键词映射，"落枕"要关联到"颈椎肌肉痉挛"，"晕"要区分眩晕/头晕/昏厥。维护成本极高，且覆盖不了方言和口语变体。LLM 的泛化能力直接跳过这个坑，零样本就能理解"像被人从后面打了一棍"是在描述颈强直。
关键设计：提取后的字段必须可人工校验。医生能看到原始描述和 AI 解析结果，不一致时可以一键修正。这是医疗场景的刚需——黑箱不可接受。
分诊引擎：不是诊断，是优先级排序
系统核心是一个轻量级决策树，输入结构化症状，输出 triage 等级和建议路径。Anand 明确划了红线：不做最终诊断，只做分流。
他的四级分类很直接。P0（紧急）：胸痛伴呼吸困难、意识改变、严重过敏反应——直接触发急诊绿色通道。P1（当日处理）：剧烈疼痛伴功能丧失、高热不退、疑似感染——推送给值班医生，2小时内响应。P2（常规预约）：慢性症状稳定、轻微不适——进入标准排队，但附带 AI 预问诊摘要。P3（自我管理）：明确轻微问题（如普通感冒）、已有明确用药史——推送药房建议+复诊提醒。
那位 Dallas 程序员的 neck 疼，系统判为 P1。AI 摘要显示："35岁男性，急性颈痛12小时，无外伤史，无神经症状（无手麻、无步态不稳），VAS 评分 6/10，建议 NSAIDs（非甾体抗炎药）+ 肌肉松弛剂，48小时无缓解需影像检查。"
医生收到这条，决策时间从平均 8 分钟压缩到 47 秒。不是替代判断，是把信息预嚼碎了喂到嘴边。
药房闭环：从"建议"到"可执行"
很多远程医疗卡在最后一英里。医生开了建议，患者还得自己找药房、比价、等库存。Anand 的系统接入了实时药房 API，根据患者地理位置、保险覆盖、库存状态，推送 2-3 个可立即取药的选项。
技术实现上，他用了一个微服务架构。LLM 特征提取是独立容器，支持热切换模型版本（GPT-4 成本高时 fallback 到 Claude 3 Haiku）。分诊引擎是规则+轻量模型的混合，确保可解释性。药房对接用了标准 FHIR（Fast Healthcare Interoperability Resources，医疗信息快速互操作资源）协议，兼容主流电子病历系统。
他公开了一组测试数据：在 200 例模拟病例上，AI 提取的字段与人工标注一致性 94.3%，过度分诊率（把 P2 判成 P1）8.7%，漏检紧急病例 0%。后者是生死线，他花了最多时间调优——宁可过度分流，不可漏掉 P0。
一个被刻意保留的"低效"设计：每个 P0/P1 案例，系统强制要求医生二次确认。AI 可以快，但责任不能外包。
临床协处理器的边界
Anand 在文档里写了一句很产品经理的话："这个系统的用户不是患者，是医生背后的时间。"他不避讳局限性。LLM 会幻觉，所以所有输出都有置信度分数，低置信字段标红。罕见病覆盖不足，系统明确提示"症状不典型，建议面诊"。儿科、孕产期、多重用药患者，自动降级处理优先级，推给更有经验的医生。
他对比了两种产品路线。Google Med-PaLM 2 那种端到端诊断模型，技术炫目，但临床落地极难——监管、责任、医生信任都是深坑。他的路线是"AI 作为草稿生成器"，医生始终握有终审权，合规路径清晰得多。
项目开源在 GitHub，但 Anand 加了一条 unusual 的声明：代码可自由使用，但用于真实医疗场景前，必须通过当地监管审批。他知道技术乐观主义在医疗领域有多危险。
那个 Dallas 程序员后来怎么样了？Anand 没写。但他在文末贴了一张系统截图：同一症状输入，传统路径 30 小时，AI 辅助路径 47 秒。数字旁边有一行小字——"医生确认时间：1分 12秒"。
AI 省下的 29 小时，医生只花了 1 分钟。剩下的时间，医生去看了另一个 P0 病例。这个账，你觉得算得对吗？
热门跟贴