一个循证医学框架，串起了我的5个医疗AI Skill

我在做一款随访AI产品时，碰到一个别扭的事：5个Skill，各自都能跑，但串在一起总觉得缺点什么。

不是说它们不协作——我设计了触发规则：患者上传检查报告，异常预警Skill检测到ALT升高，依从性分析Skill关联出漏服记录，话术推荐Skill生成沟通内容，医生再调用用药速查确认方案，最后随访计划Skill调整下次复查时间。这条链路跑得通。

但跑得通和跑得对是两回事。我能说清楚每个Skill做什么，说不清楚的是：为什么是这5个？为什么是这个顺序？为什么不是6个或者3个？触发规则是事后拼接的，还是有一个更底层的逻辑在驱动？

这个问题困扰了我一阵，直到我翻到循证医学里的PICO框架。

01

PICO是什么

PICO是循证医学做临床决策的标准框架，四个字母：

P — Patient/Problem — 患者有什么问题

I — Intervention — 当前用了什么干预

C — Comparison — 有没有对照，预期和实际差多少

O — Outcome — 结果怎样，下一步怎么办

PICO本来是教医学生怎么查文献的——把P/I/C/O填进去，去PubMed搜相关研究。医生面对任何一个临床问题，脑子里跑的也是这四步。我看了一遍这四个字母的排列逻辑，愣了一下：发现问题、展开干预、对照偏差、收束行动——这不就是我那5个Skill要干的事吗？

02

用PICO串5个医疗Skill

我试了一下映射，结果比预想的整齐：

P（发现问题）→ 异常指标预警Skill — 系统监测到患者的ALT升到95 U/L，触发黄色预警。这是整个链路的起点，"出了什么事"。

I（当前干预）→ 用药方案速查Skill — 医生看到预警，需要确认患者当前在吃什么药。他克莫司+吗替麦考酚酯，系统检测药物交互风险，确认方案本身没问题。这是"正在做什么"。

C（预期vs实际）→ 依从性分析Skill — 方案没问题，但执行到位了吗？系统对比医嘱和实际用药记录，发现漏服率43%。这是"差距在哪"。

O（收束行动）→ 随访计划生成Skill + 话术推荐Skill — 问题找到了，根因是依从性差。调整随访频次到每周一次，新增肝功能复查项目；同时生成关怀型沟通话术，重点提醒用药纪律。这是"接下来怎么办"。

拿某个患者的例子串一遍：肝移植术后3个月，上传了最近一次肝功能检查，ALT从60升到95。异常预警先触发，黄色预警推给主治医生。医生点进去，系统已经调出当前用药方案，速查确认药物没有交互问题。再往下看，依从性分析显示他最近两周漏服了43%的药——这大概率就是ALT升高的原因。最后，随访频次从两周一次调到每周一次，话术推荐生成的开场白是"张先生，最近检查有几个指标波动，想跟您聊聊用药情况"。

五个Skill，完整走完全流程，没有多余也没有缺失。

03

PICO的路由机制

映射关系理清楚之后，我原本以为PICO就是一个"事后解释框架"——产品做完了，找个学术概念包装一下逻辑。

后来发现不是这么回事。

PICO的四个阶段其实可以直接当Agent的编排依据来用。当系统接收到一个临床事件，Agent判断"当前处于PICO哪一步"，然后决定调哪个Skill：

处于P阶段 — 调异常指标预警，识别问题

处于I/C阶段 — 两条平行展开：用药速查走I线（当前方案是什么），依从性分析走C线（执行到位了吗）

处于O阶段 — 收束到随访计划生成和话术推荐

这意味着Skill的调用顺序不是通过规则限定死的，是PICO的决策流程定义的。我之前用"触发规则"来描述五个Skill的协同——患者上传报告→异常检测→依从性分析→话术推荐→计划调整——本质上就是PICO走了一遍完整流程，从P到I/C再到O。PICO不是额外加的框架，而是这条链路之所以成立的临床逻辑根基。

说实话，这个发现让我松了口气。之前总觉得触发规则是我自己拼的，心里没底——万一换个场景，这链条还成立吗？现在有了PICO做底，至少在医疗场景下，不管什么病例，决策路径都是这四步。Skill的编排有了行业自己的语法。

04

回到随访产品初心

我在一家互联网医疗公司做过随访产品，是和一家肝移植医学中心的科室主任合作的。他推动这件事有5个动因，其中最硬的一个是：数百名肝移植术后患者需要终身管理，纯人工不可持续。

肝移植术后要终身吃免疫抑制剂，他克莫司这类药，漏服就有器官排斥的风险。一个科室管几百个这样的患者，每个都要定期复查、调整用药、追踪指标。靠医生手工排随访、肉眼盯指标、凭经验判断依从性——人力撑不住。

PICO的价值在这里就具体了：当异常预警Skill发现指标波动，系统不需要医生去想"我接下来该查什么、该对比什么"，而是按P→I/C→O的逻辑自动展开。医生看到的不是一个孤立的预警，而是一条从问题识别到行动建议的完整决策路径。

5个Skill各自能跑，这是功能层面的事。PICO让它们按照临床决策的本来逻辑跑，这是Agent怎么决定"下一步调谁"的事。后者才是让科室主任愿意用的理由——他不需要理解Skill是什么，但他能感知到，这套系统的响应方式跟他自己面对患者时的思考方式是一致的。

05

每个行业有自己的编排策略

顺着这个思路，我看了下之前做供应链AI产品时的经验。

供应链的编排逻辑是"数据准备→差异分析→决策建议/操作"：先确保数据准确（比如库存报告生成），再基于准确数据定位问题（比如库存预警、差异定位），最后给行动建议甚至执行（比如补货建议、下退供单），执行结果又回到数据层形成闭环。

这个编排逻辑在随访AI里也成立——患者数据采集是数据准备，异常预警和依从性分析是差异分析，用药速查和话术推荐是决策建议。

不同的是，供应链用"数据准备→差异分析→决策建议/操作"就够了——这个流程本身就是供应链专家做决策的方式。但医疗领域还有一层PICO，它不止定义了怎么串——P先、I/C中、O后，还解释了为什么这么串，因为这是医生做临床决策的原生顺序。

所以我现在的认知是：跨行业做AI产品，不是把上一个行业的流程硬搬过来，而是去找这个行业专家做决策时脑子里跑的逻辑，然后让Skill的编排跟着那个逻辑走。

每个做AI应用层产品的人大概都会碰到类似的事：基于业务场景的能力模块拆好了，但串不起来。我们习惯用技术逻辑去编排——谁先谁后、谁触发谁、数据怎么流转。但也许更值得问的是：这个行业的专家做决策时，脑子里跑的是什么逻辑？

那个逻辑，就是这个agent最优解的编排策略。

END