openmed

采用判断是“值得做受控试点，但不应仅凭热度直接全面上线”。最有力的依据来自官方 GitHub 仓库：项目明确定位为本地运行的医疗文本工具，覆盖临床 NER、HIPAA PII 去标识化，并提到 Apple MLX、Python、无云依赖和数据不离开网络。PR 与环境诊断命令也说明它并非只有概念展示。不过，GitHub fork 数、X 浏览量、转发和快速增长只能证明受关注，不能证明医疗级准确率、稳定性或合规性。它不是医院 HIS/EMR，也不是会直接给出诊断建议的“AI 医生”；更准确的类比是用于医疗文本抽取和隐私过滤的本地推理工具箱。

实际作用是让病历、临床文档或研究文本留在本地设备或内网中，再执行实体识别、结构化抽取和去标识化。官方仓库称支持 2,200+ 医疗模型和 21 种语言，作者在 X 上则提到 1,500+ 模型及 iPhone 端运行；这些数字存在口径差异，更适合看作项目覆盖范围的宣传信号，而非稳定能力承诺。作者展示过 privacy-filter v2 对 13,000 token 临床文件进行流式处理、识别 1,152 个标识符并达到 755 tokens/s，这属于“能运行”的好用证明，但仍是作者演示，不是独立机构的大规模生产验证。

门槛与成本方面，证据支持它需要本地部署、硬件准备和模型选择能力，但不足以支持明确的官方定价。官方仓库强调 local-first、no cloud；作者在 X 上提到可将部分模型转由 Hugging Face Inference Providers 执行并按 token 付费，也提到 CPU 可运行。这些属于社媒说法或演示路径，不是稳定套餐，不能据此承诺低成本或固定 API 费用。保守估计，纯本地使用的主要成本是硬件、部署、模型评估、维护和隐私流程审查；混合推理还会产生随调用量变化的 API 费用。

它更适合拥有 ML/IT 能力、需要控制敏感医疗文本流向的医疗机构、研究团队和开发者，不太适合期待零配置、现成工作流和成熟合规背书的小团队。社媒共识总体偏正面，真实开发协作和生态适配讨论是有价值的信号；但 evidenceSources 只有一个官方仓库加多条 X 内容，后者主要是作者发布、转发、简短互动和榜单式传播，第三方教程、长文、独立实测与生产案例明显有限。因此目前热度证明强于好用证明，采用前应自行验证脱敏召回率、误删率、多语言表现、端侧性能及合规流程。