pyhealth

pyhealth 技能概览

pyhealth 的用途

pyhealth skill 适合用 PyHealth 搭建临床与医疗深度学习工作流，尤其适合把混乱的医疗数据整理成可重复的 Dataset → Task → Model → Trainer → Metrics 管线。它最适合处理 EHR、生理信号或医学影像的用户，目标不是只看概念介绍，而是要从原始数据集一路走到可训练、可实验的实现路径。

适合谁使用

如果你正在处理 MIMIC-III/IV、eICU、OMOP、EHRShot、SleepEDF、ChestXray14 或类似医疗数据，并且需要做预测、药物推荐、睡眠分期、ICD 编码或 EEG 事件建模，那么 pyhealth skill 很合适。它尤其适合希望获得一套结构清晰、可复现实验方案的科研用户，以及希望代码能够贴合 PyHealth 抽象层的使用者。

pyhealth 的差异化优势

pyhealth 的核心优势在于它模块化的临床工作流：datasets、tasks、models、trainer 逻辑和 metrics 的设计天然可以拼接起来。这会减少胶水代码，也让你更容易替换模型或任务，而不必重写整个实验。代价是你需要遵循库本身的管线形状；那种跳过任务构建或数据适配器、直接靠 prompt 生成的临时代码，往往会失败。

如何使用 pyhealth skill

安装并打开正确的文件

使用 npx skills add K-Dense-AI/claude-scientific-skills --skill pyhealth 安装 pyhealth skill。然后先打开 SKILL.md，因为它定义了预期的工作流和 PyHealth 特有的假设。如果你需要更多上下文，再阅读仓库中的 README.md、AGENTS.md、metadata.json，以及任何相关的 rules/、resources/、references/ 或 scripts/ 文件。

给 skill 一个完整的临床目标

像“用 pyhealth 做医疗预测”这种模糊请求会留下太多选择空间。更好的 prompt 要明确数据集、目标任务、数据模态和输出期待，例如：“使用 pyhealth 在 MIMIC-IV 上搭建一个基于结构化 EHR 的再入院预测管线，并展示 dataset/task/model/trainer 的配置。”如果你关心医学编码映射，也要说明具体编码体系，例如 ICD-10 到 ATC，或 NDC 到 RxNorm。

按照库的管线顺序来做

先识别 dataset class，再定义 task，接着选择 model，然后配置 trainer，最后才比较 metrics。这个顺序很重要，因为 pyhealth skill 的重点就在于 PyHealth 如何组合实验。按管线顺序提问，得到的输出会比泛泛地说“帮我写个模型”更容易运行、调试和改造。

以“先判断是否适合”为导向阅读仓库

在 pyhealth 的使用场景里，第一次最值得看的不是把仓库从头到尾翻完，而是先检查 skill 文件里支持哪些 datasets、tasks、model families，以及数据准备方面有哪些限制。先用这些信息判断项目是否适配，再决定要不要投入实现。如果你的工作负载不属于典型 PyHealth 流程，应该先问它最接近的受支持模式，而不是硬套库。

pyhealth skill 常见问题

pyhealth 只是给临床机器学习用的吗？

是的，主要就是这样。pyhealth skill 面向科研和医疗数据工作，尤其适合结构化临床预测和医学序列建模。如果你的任务和 EHR、信号、影像或医学编码无关，通常更适合用通用的 Python 或 ML prompt。

我需要已经安装好 PyHealth 吗？

如果要真正动手实现，需要。pyhealth 的安装步骤会添加 skill 指令，但你的环境里仍然需要 PyHealth 包，以及项目所需的数据集或预处理产物。如果你只是在评估可行性，这个 skill 也能帮助你在真正搭环境之前判断 pyhealth 是否适合你的场景。

这和普通 prompt 有什么不同？

普通 prompt 往往只会给出较宽泛的建议。pyhealth skill 的价值在于，你想要的是库的真实工作流：dataset 构建、task 定义、model 选择、训练和 metrics，而且顺序也要对。这样能降低拿到“看起来合理、其实不符合 PyHealth 抽象”的代码的概率。

什么情况下不该用 pyhealth？

如果工作内容不是医疗相关，如果你需要的是通用 ML 技术栈，或者数据并不适合它支持的临床模态，就不该用它。它也不适合那种完全自定义、并且故意忽略 dataset-task-model 模式的研究管线。

如何改进 pyhealth skill

明确数据形态

想让 pyhealth 结果更好，输入就要更具体：数据集名称、模态、目标标签、队列规则，以及模型要预测什么。比如，“MIMIC-IV 结构化 EHR、30 天再入院、成人 ICU 队列、二分类”就比“分析患者数据”更可执行。输入越精确，模型在预处理和任务定义上的猜测空间就越小。

说明实现约束

如果你在意运行时间、可解释性、基线对比或者代码简洁性，应该一开始就说清楚。PyHealth 支持多种 model families，所以这些约束会决定你更适合 transformer baseline、recurrent model，还是推荐导向的架构。对于 pyhealth 的科研工作尤其如此，因为可复现性和实验清晰度往往比新颖性更重要。

先要第一版结果，再逐步细化

先用第一版输出检查管线结构是否正确，再去优化模型选择或 metrics。如果结果太泛，就让 pyhealth skill 只收紧某一个环节：dataset 加载、task 构建、model 选择或评估。一次只迭代一个环节，通常比一口气要求完整端到端系统，更容易产出高质量的科研代码。

警惕常见失败模式

最常见的问题是 task 说得不够清楚，导致输出把互不兼容的数据集假设、标签逻辑或 metrics 混在一起。另一种失败模式是请求代码时不说明源数据集，这会让 pyhealth 的使用滑向占位符。想要稳定可靠的输出，最好同时给出明确的任务陈述、已知数据集和用于判断成功的指标。