一个教 CATIA 建模和无人机飞控的助教，为什么突然搞起了医学影像平台？这要从几个月前的一次聊天说起。
缘起：一段让人沉默的对话
几个月前，一位在医学院读研的朋友跟我吐槽她的日常：
「导师让我用 nnU-Net 跑一组肺部 CT 的分割实验。我花了两周配环境——CUDA 版本不对、PyTorch 和 MONAI 打架、DICOM 文件读进去全是乱码。真正跑实验只用了两天，剩下时间全在折腾代码。」
我问她：「你读的是医学影像学，不是计算机科学，对吧？」
她沉默了两秒：「对。但我们组所有人都得会写 Python。」
这件事让我想了很久。我教 CATIA、教无人机、教 PLC，面对的是工科学生——他们至少还有编程基础。而医学研究者呢？他们本该专注于临床问题、实验设计、结果解读，却被困在了技术栈的泥潭里。
于是有了 RadCloud。
问题：医学影像研究的「代码困境」
医学影像深度学习的研究流程，通常长这样：
DICOM 导入 → 数据预处理 → 特征提取 → 模型训练 → 评估验证 → 论文图表导出
每一步都对应一大堆工具和依赖：
| 环节 | 典型工具 | 痛点 |
|---|---|---|
| DICOM 读取 | pydicom、SimpleITK | 格式复杂，元数据解析繁琐 |
| 数据预处理 | MONAI、ITK | 配准、归一化、增强——每一步都要写代码 |
| 特征提取 | PyRadiomics | 参数配置依赖文档，试错成本高 |
| 模型训练 | nnU-Net、PyTorch | GPU 环境配置是噩梦 |
| 结果评估 | scikit-learn、自定义脚本 | 指标计算后还要手动画图 |
| 论文图表 | matplotlib、seaborn | 调参两小时，出图两分钟 |
对于一个医学研究生来说，这六步里至少有四步跟他的专业没关系。他真正擅长的是读片子、设计实验、理解病理——而不是跟 CUDA_VISIBLE_DEVICES 较劲。
更麻烦的是：每一步都是一次性的。你今天跑完了肺部分割，明天要做脑肿瘤分类，代码又要从头改。
RadCloud：把流程变成积木
RadCloud 的核心想法很简单：把每一步封装成一个「算子」，用拖拽的方式拼成一条实验管线。
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ DICOM │───▶│ 预处理 │───▶│ nnU-Net │───▶│ 评估 │
│ 导入 │ │ 模块 │ │ 训练 │ │ 报告 │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
不需要写一行代码。你在编辑器里拖节点、连管道、配参数，后端自动调度 GPU 任务。做完导出即可拿到论文所需的统计表格和 ROC 曲线。
目前覆盖的流程：
- 影像组学（Radiomics）：DICOM → ROI 勾画 → PyRadiomics 特征提取 → 特征筛选 → 机器学习建模 → 评估报告
- 深度学习（Deep Learning）：DICOM → 预处理 → nnU-Net / MONAI 训练 → 推理 → Dice/IoU 评估
- LLM 实验助手：基于 DeepSeek API，辅助解读结果、生成方法学段落、检查统计规范性
设计哲学：像一间干净的实验室
做临床软件，最忌讳的是「炫技」。医生的界面不需要花哨的动画和渐变色——他们需要的是可靠、清晰、低认知负荷。
RadCloud 的设计系统围绕一个核心概念展开：Clinical Precision（临床精度）。
色彩
- 主色 Medical Teal：和医疗场景天然契合，传递清洁、卫生、可信赖的心理暗示
- 背景 Clean Slate：冷调白色，降低长时间阅片时的屏幕眩光
- 功能色：成功/错误/警告色都做了轻微去饱和，保持临床审美，同时满足 AA 级无障碍对比度
排版
全站使用 Inter 字体。标题和正文严格分层——标题用更紧凑的字间距和更重的字重作为视觉锚点，正文用标准间距优化长篇阅读。数据表格启用等宽数字（tnum），确保诊断数据纵向对齐。
空间
8px 基础节奏，4px 微调。导航固定，内容区 12 列流体网格，最大宽度 1440px。信息密集区（如实验报告）可以降到 4px 节奏，但容器内边距不低于 1rem——界面永远不能让人觉得拥挤。
这些设计决策不是拍脑袋定的。每一条都回答同一个问题：如何让一个非技术用户在打开 RadCloud 时，第一感觉是「这个我能搞定」？
技术选型：不重复造轮子
RadCloud 不是从零开始写一个深度学习框架——那既不现实也没必要。我们的策略是：对接最好的开源工具，把复杂度封装在下面。
| 层 | 技术 | 选择理由 |
|---|---|---|
| 前端 | React 18 + TypeScript + Vite | 类型安全 + 极快的 HMR |
| 画布编辑器 | React Flow | 成熟的节点编排库，比自研画布省半年工期 |
| 图表 | ECharts | 医学图表需求复杂，ECharts 的配置粒度最合适 |
| 后端 | FastAPI (Python 3.11+) | 异步原生支持，自动生成 OpenAPI 文档 |
| 任务队列 | Celery + Redis | GPU 任务是典型的长耗时异步场景 |
| AI 引擎 | PyTorch + MONAI + nnU-Net v2 + PyRadiomics | 医学影像领域的事实标准，对接而非重写 |
| LLM | DeepSeek API | 实验助手和结果解读，性价比高 |
| 存储 | PostgreSQL + MinIO | 结构化数据 + 对象存储，医学影像文件动辄几百 MB |
选型的原则只有一条：站在巨人的肩膀上，把精力花在「降低使用门槛」这件事上。
当前状态与后续计划
RadCloud 目前还在开发阶段。已完成的部分：
- 项目框架搭建（前后端 + AI 引擎 + Docker 开发环境）
- 设计系统落地（色彩、排版、组件规范）
- DSL 编辑器原型（React Flow 画布 + 算子节点）
- 后端 API 骨架（FastAPI + 数据模型 + Celery 任务调度）
接下来几个月会集中攻克：
- 算子库扩展（影像组学完整链路）
- nnU-Net 训练的 GPU 调度
- LLM 实验助手的对话体验
- 论文图表一键导出
如果你对医学影像研究有需求，或者单纯对这个方向感兴趣，欢迎来试用、提意见、甚至一起参与。 项目仓库会在完成核心功能后开源。
写在最后
从 CATIA 到 nnU-Net，从无人机飞控到 DICOM 解析——跨度确实有点大。但说到底，我做的事情一直没变：把复杂的工具变简单，让非技术用户也能高效地完成专业工作。
教学生建模是这样，做 RadCloud 也是这样。
如果你也在做类似的事情，或者有医学影像研究的需求，欢迎邮件联系我（mltree.bl@gmail.com），一起聊聊。
#RadCloud #医学影像 #深度学习 #影像组学 #零代码 #开源