医生读AI全书 - 临床医学的AI实战指南

写作状态：初稿字数：约3400字日期：2026-07-10

引子：USB诞生之前

1990年代，要给电脑接一个打印机，你需要：找到对应的串口/并口、安装专用驱动、祈祷系统兼容。每种外设都有自己的接口标准，乱成一团。

1996年，USB（通用串行总线）诞生。一个接口，所有设备通用——鼠标、键盘、U盘、打印机、摄像头，插上就能用。

2024年11月，Anthropic发布了MCP（Model Context Protocol，模型上下文协议）。它在AI世界做的事，和USB在电脑世界做的事一模一样。

想象你想让AI帮你「查一下我下周有没有空」。在MCP之前，这件事需要：

AI服务商和日历服务商一对一对接每个AI要对接Google Calendar、Outlook、苹果日历……N×M种组合每换一个日历服务，AI就要重写一遍接口代码数据安全上，你的日历信息要经过AI服务商的服务器这就像每个品牌的打印机都要专门配一根线——混乱、低效、不安全。

MCP之前	MCP之后
连接方式	一对一对接，N×M组合一套协议，即插即用
数据安全	数据经过AI服务商服务器数据可在本地，AI只拿到权限去查
扩展性	每加一个工具都要重写代码符合MCP标准的工具直接接入
类比工作流程你的请求：「帮我查一下下周三有没有空」	每种打印机专用接口 USB统一接口
→	AI理解意图：需要访问日历
→	AI通过MCP协议向你的日历服务发起查询（「查一下下周三的日程」）
→	日历服务返回数据（「那天09:00-12:00有手术安排」）
→	AI整合信息回答你（「下周三上午有手术，下午时段是空的」）

场景一：病历系统+AI

医生：「帮我总结一下张某某过去一年的住院记录。」
→ AI通过MCP → 连接医院HIS系统（只读权限）
→ 调取脱敏摘要 → 生成总结
→ 数据不出医院内网

场景二：文献数据库+AI

医生：「帮我搜PubMed上关于机器人辅助TKA的最新文献。」
→ AI通过MCP → 连接PubMed API
→ 检索 → 筛选 → 返回结构化结果

场景三：个人日历+AI

医生：「我下个月有哪些学术会议要参加？帮我加到日历里。」
→ AI通过MCP → 读取日历 → 列出会议 → 新建日程

场景四：多系统联动

科室主任：「下周二的MDT，帮我通知所有参会医生，发文献包，定会议室。」
→ AI通过MCP：
→ 查日历（找空闲时间）
→ 查通讯录（确定参会医生）
→ 查会议室系统（预定）
→ 查文献库（打包相关文献）
→ 发通知（邮件/微信）

一步完成。

组件	说明	医生类比
MCP	Client（客户端）AI助手这一端，发起请求	你拿起手机要查东西

MCP Server（服务器）外部工具/数据源，响应请求医院的HIS/PACS/LIS系统

组件	说明	医生类比
协议	两者之间的通信语言规范	医嘱的标准化格式

为什么是Anthropic发布的？ Anthropic是Claude的开发商，他们一直以「AI安全」为核心理念。发布MCP的本质是：与其让每家AI公司都试图「吃掉」你的数据，不如建一个开放标准，让AI只「借用」你的数据。

传统API	MCP
连接模式开发者工作量每对接一个工具写一套代	每个工具单独的API 统一协议，多个工具
码	写一次MCP Server，所有MCP Client都能用
标准化	各家用各家的格式统一的JSON-RPC协议
发现机制	需要事先知道API文档 MCP Server可以告诉Client「我能提供什么」
安全性	取决于API设计内置权限控制和数据最小化原则

一个典型的一天：早上查房前，AI通过MCP读取昨夜新出的检验报告，整理变化趋势；查房时语音记录要点，AI通过MCP生成病历草稿并推送至HIS；下午做研究，AI通过文献MCP自动检索和整理最新文献。

医疗场景下的MCP，有三条铁律：

铁律	说明
最小权限	MCP Server只开放必要的数据字段，不开放整个数据库
只读优先	查数据可以，写数据需要人工二次确认
审计留痕	每次MCP调用记录时间、操作者、数据范围，可追溯

医疗场景连接HIS/PACS/LIS/文献库/日历，让AI真正进入临床工作流安全第一最小权限+只读优先+审计留痕，三条铁律不可破下一章：RAG——MCP让AI能连接外部世界，RAG让AI在回答之前先「查资料」。这俩是AI可信度的左右护法。