把医学影像软件刻成光盘交付
2026 年 8 月。比赛要求把软件刻录到光盘上交。在这之前，我写的所有东西都只在"我这台电脑上跑得起来"。
交付和演示是两件事
在本地开发的时候，我的判断标准很简单：跑起来不报错，界面看着对。但刻盘交付意味着几件额外的事：
- 运行环境不由我控制：对方的显卡可能不支持 GPU 加速，甚至可能没有独立显卡
- 装不了东西：不能指望别人现场
pip install - 没人帮你解释："这里点一下再点那里"这句话传不到评审现场
硬件降级不是配置项，是第二套构建
一开始我想的是加一个配置开关：检测不到 GPU 就走 CPU。真做的时候才发现没那么简单——预处理尺寸、模型精度、批处理方式在两条路径上都不一样，某些依赖在 CPU 环境下根本装不上。
最后的做法是维护两套发行配置，各自测过再打包，而不是指望运行时自动降级。"自动适配"听起来优雅，但真正交付的时候，可预测比优雅重要。
界面要靠点，不能靠看
软件有十几个页面、两百多个可点击元素。人工点一遍要半天，而且点漏了自己也不知道。
所以我用自动化测试驱动真实的桌面应用把每个按钮都点了一遍，记录下点击次数和失败数：13 个页面、265 个按钮、192 次实际点击、零失败。这个数字后来直接写进了交付说明——它比"界面检查过了"有说服力得多。
有个细节值得记：能点击 ≠ 点了有用。自动化能覆盖"按钮点下去不报错、界面不崩"，但"这个按钮的业务逻辑对不对"还是得人判断。所以我的做法是让脚本负责覆盖面，人负责抽查关键流程。
打包时最容易忽略的是路径和缓存
最后一公里踩的坑基本都不在代码里：
- 开发环境的绝对路径写死在某个配置里，换台机器立刻找不到文件
- 编译缓存和旧的构建产物混进发行包，包体莫名其妙地大
- 依赖版本在本机能装上，是因为本机早就装过了，干净环境里装不上
解决办法很土但有效：在一台干净的机器上，从零走一遍解压、安装、启动的完整流程，把这当成交付前的固定动作。
一点体会
写算法的时候，我关心的是分数能不能再高一点；做交付的时候，我关心的是别人能不能把它用起来。这两件事需要的完全是不同的思维方式，而后者在课程里几乎不会被训练。
刻盘这件事让我第一次意识到：一个东西"做出来了"和"交付出去了"之间，隔着的全是细节。