Y8
实战手册 · 领域实战手册
医疗场景智能体。
病历记录、事前授权、分诊接待——这些是医疗中智能体真正节省人力的少数任务，以及离开它们就不能上线的隐私与临床安全护栏。医疗里那块狭窄的高产区是真实存在的；但它周围的监管与临床安全接触面，比任何其他贴近消费者的领域都更大。正确的提问不是"智能体能不能做临床工作"，而是"哪些行政工作能从临床医生肩上挪下来、而又不越过临床决策这条线"。
STEP 1
今天医疗智能体真正在做的事。
大部分真正的省力发生在这三类工作上：
- 环境式病历记录——以书记员的方式转录一次门诊对话，再起草一份 SOAP 病历。由医生编辑并签字；智能体的产出单独不构成医疗记录。
- 事前授权——起草面向支付方的信函、操作支付方门户、从病历里拼接支持材料。这是智能体可以稳定削减的繁琐工作；医疗必要性的主张仍由医生持有。
- 分诊接待——通过对话采集症状，把患者主诉汇总给医生，并把紧急情况路由给人。智能体不向患者建议什么，它在为医生作准备。
模式依旧是：行政压缩，关键步骤上有医生。这里没有任何一项是让智能体独立做出临床判断，也没有任何一项应该是。
STEP 2
医疗智能体不该出现的地方。
有三处必须拒绝，无论 demo 怎样：
- 无持牌医生在场的诊断。对患者说出一个病名，就是在做临床工作；在任何面向患者的产品中，把这块接触面视为禁区。
- 治疗建议——包括非处方建议，包括"你可以考虑……"——若没有医生签字路径，多数法域都把它视为执业医疗行为。
- 任何会落入"软件即医疗器械"框架的事情（如美国 FDA 的 SaMD 定义、其他法域的对应类别），却不走相应的审批流程。如果你的产出意图用于疾病的诊断、治疗或预防，那你做的就不是一个效率智能体，而是一台受监管的医疗器械。
绝不让智能体在没有持牌医生在回路的情况下做诊断或治疗建议。诱惑很大，因为模型听起来很专业；后果是，你把一台受监管的医疗器械以聊天产品的名义上线，然后在患者受到伤害之后才发现两者的区别。
STEP 3
不可让步的硬约束：隐私、临床安全表达、交接。
三条约束贯穿任何医疗用例：
- 隐私。在美国，按 HIPAA 对受保护健康信息（PHI）做合规处理；在欧盟，按 GDPR 并将健康数据视为特殊类别。落到工程上：最小必要访问、模型供应商不留存数据、每一次读取都进审计、prompt 里不放一点多余的 PHI。如果一家供应商签不出对应的数据处理协议、说不清 PHI 静态与传输态分别在哪里，这桩集成就还没准备好。
- 临床安全式表达。每一句面向患者的输出读起来都是信息性的、而非指令式的。不写"你应该"、不写"这是"——而写"你的临床医生可以确认是否……"，并明确指引就医。这套表达是结构性的，不是事后客气几句；它正是让同样的字句不至于变成治疗建议的那道东西。
- 明确的交接路径。智能体永远知道如何升级给一位人类临床医生，而升级入口在一次点击之内，不被埋起来。紧急症状识别需即时路由给人；其余的也都有一条记录在案的下车通道。
STEP 4
审计与可重复性。
医疗审计比金融审计更难，因为"正确答案"往往是临床判断而不是一个数。所需的纪律：
- 每一次患者交互都带时间戳记录下来：模型版本、检索到的上下文、医生身份（若涉及）、以及任何工具调用。
- 进入临床记录的产出都携带来源信息：「由智能体 v3.4 于 2026-05-22 起草，由 X 医生审阅并签字。」签字版才是记录，草稿是支持材料。
- 留存策略与底层医疗记录策略对齐，而非沿用智能体的默认——通常意味着审计留存更长，而 prompt 中夹带的 PHI 清理更严。
STEP 5
上线的最低门槛。
在医疗智能体接触到患者或医生之前，你欠自己几个答案：
- 所有进入医疗记录的产出，是否都由持牌医生审阅并签字，且签字与智能体草稿分开存储？
- 面向患者的接触面（如果有）读起来是信息性的吗？紧急情况是否即时路由给人？
- PHI 访问是否做到最小必要、记录可查、按医疗记录策略而非智能体默认进行留存？
- 对"这是不是医疗器械"是否有一个站得住脚的答案？如果可能是，是否在上线前就走在审批路径上，而不是上线后才补？
- 是否存在按医生、按机构、以及全局的急停开关？最近一季是否真演练过，而不止是写在文档里？
医疗对走捷径的惩罚，比这一节里任何其他领域都更稳定。先把护栏建好；高产区是真实的，但很窄，只有在护栏之内它才有价值。