一台完全离线的临床决策系统，能在本地跑大模型、查1.4万种疾病、分析医学影像——开发团队只有四个学生，预算为零。

从问题出发：大医院才用得起的工具

打开网易新闻 查看精彩图片

临床决策支持系统是个老赛道。Epic、Cerner、UpToDate这些名字，医院采购部的人耳熟能详。它们的共同点？贵，贵到只有大型机构才付得起授权费。

四个学生坐下来规划学期项目时，反复问自己：用纯开源工具，一个学期能做出什么？

他们的答案叫MedAI。核心承诺很具体：医生或医学生输入患者体征、症状和病史，一分钟内拿到结构化的风险评估——在自己的笔记本上跑完，不需要网络，不需要外部API，不会因为某个云服务宕机就罢工。

技术栈：能省则省，能本地绝不云端

MedAI的架构透着一股"穷学生智慧"。

Web层用Flask 3.x配Flask-CORS。大模型运行时选Ollama本地部署，文本用llama3.2，影像分析切到llava或llama3.2-vision。知识库直接扒Human Disease Ontology的HumanDO.obo文件，1.4万多种疾病、ICD编码、同义词全塞进去。数据库用MongoDB，六个集合，分析缓存做了TTL索引。前端Jinja2模板，支持暗黑/亮色主题，流式SSE响应。

依赖树干净得惊人：Flask、Flask-Cors、requests、Pillow、pymongo。没了。

关键设计在RAG（检索增强生成）与结构化本体的结合。大模型不需要凭空编造疾病定义——1.4万条标准定义已经在HumanDO.obo里等着被检索。幻觉风险被压到最低。

为什么选MongoDB：临床数据太"脏"

团队原话：最大的挑战不是接大模型，是管理那些塞不进刚性schema的临床数据。

一份患者评估文档包含什么？体征数据、检索匹配的疾病列表及评分、风险百分比、大模型生成的完整报告、还有元数据记录用了哪个Ollama模型。影像记录完全是另一套结构。聊天对话又不一样。

用SQL数据库？每给评估schema加一个新字段就要写迁移脚本。MongoDB让他们把每条记录存成自包含文档，形状跟着数据自然走。集合之间隔离清楚，查询和聚合照样方便。

还有个彩蛋：MongoDB在MedAI里是可选组件。没装的话，应用照样干净启动，所有评估——

（原文此处截断）

本地优先的底气从哪来

MedAI的"无云端依赖"不是口号，是技术选型的自然结果。Ollama跑本地模型，HumanDO.obo是离线文件，MongoDB可装可不装。整套系统的故障域被压缩到单台机器。

这对医疗资源匮乏的场景有现实意义。网络不稳定、云服务未覆盖、数据不能出境——这些约束下，"离线可用"是刚需而非噱头。

四个学生的学期项目，无意中切中了一个被大厂忽视的市场缝隙。

这件事为什么值得关注

MedAI的价值不在于它有多先进，而在于它证明了"足够好"的临床AI可以用零预算、纯开源、短周期交付。它把门槛从"医院信息化预算"降到了"个人笔记本算力"。

当行业都在追逐云端大模型、企业级部署、百万美元合同时，反向做减法可能打开新的可能性空间。如果这套思路被验证可行，下一个问题会是：哪些临床场景最适合这种"轻量、离线、低维护"的架构？哪些必须坚守云端？这条分界线会怎么画？