医学影像项目很容易被一张漂亮的结果图带走。图上的框、颜色和概率看起来都很确定，但一套可重复的流程需要回答更多问题：输入从哪里来，模型请求是否真的执行，展示的图像和返回的诊断是不是同一份数据，跨域和失败时页面会怎样。
公开仓库里的眼智医由前端和后端组成，后端提交记录可以看到 AI Studio 代理接口、参数兼容和 CORS 配置，后续又加入了从两组眼底图像中随机选择素材的逻辑。把这些提交放在一起读，会发现项目的重点并不只在“接上模型”，而在于把一次演示拆成可以逐段检查的步骤。
模型接口最好先被当成普通的外部服务。请求参数需要有明确的结构，超时和错误要有可读的回执，原始响应和页面展示之间要留出转换层。这样当上游接口改变字段或版本时，问题会停在适配层，而不是悄悄变成页面上的一段空白文字。
样本选择也需要被写进流程。仓库里随机选择不同数据集的改动，说明“每次看起来不一样”并不等于“模型真的更准确”。演示数据可以用来验证页面和链路，但不能用来证明临床效果。展示页面要诚实标出模拟、示例和实际推理的边界，避免让视觉上的确定感超过数据本身。
跨域配置看起来是前端问题，实际上会影响整个验证过程。请求在浏览器里被拦截时，开发者可能误以为模型接口失败；如果为了演示临时放开所有来源，又会把本来应当收紧的服务暴露出去。正确的做法是先列出允许的页面来源，再验证预检、错误和正常响应三条路径。
我也重新看了一遍“准确率”这类数字。数字必须说明数据集、划分方式、指标和复现实验的入口；一张结果图只能证明某次运行产生了某个输出。没有测试脚本、样本说明和版本记录时，最稳妥的表达是“项目实现了某个流程”，而不是“系统已经具备某种诊断能力”。
这类项目的工程价值，往往藏在不显眼的地方：输入校验、失败提示、版本锁定、日志和数据脱敏。把这些环节写进流程以后，演示不一定更华丽，却更容易让别人复现，也更容易在下一次修改时知道哪里坏了。对医疗相关题目尤其如此，克制这是对结果边界负责。
如果以后继续维护，我会先补三类材料：脱敏后的输入样本、每次推理的请求和响应摘要、以及页面在模型超时或数据为空时的截图。它们不一定让 Demo 更好看，却能让一次“成功展示”变成别人可以复查的过程。
医学影像相关的页面尤其需要把“辅助”写清楚。模型输出只能作为一种待核对的结果，输入质量、样本分布和阈值变化都会影响它；页面不应该把概率值排版成确定诊断，更不能用一张成功样例替代总体评估。
如果继续做实验，我会把数据划分、预处理、模型版本和失败样本一起保存。这样下一次修改页面或接口时，可以先确认变化来自数据、模型还是展示层，而不是把所有差异都归到“模型变好了”。