做实验最痛苦的不是算法不对，而是环境不可复现——三个月前跑出结果的代码，现在重装一遍就报错，依赖版本变了，驱动对不上，结果再也复现不出来。
这篇聊一下实验类项目的环境规划方法。
一、先解决可复现性
可复现是实验的底线要求。论文要复现、结果要验证、代码要交付给导师，环境一乱全都做不了。
三个技术手段，按成本从低到高：
1. 依赖锁定。 Python 项目用 requirements.txt 固定版本号（不是 numpy>=1.20 而是 numpy==1.24.3），Node 项目提交 package-lock.json，Conda 环境导出 environment.yml。
2. 容器化。 把代码+依赖+系统库打进镜像。这是最彻底的方式——镜像跑起来就和当时的环境完全一致。代价是要学 Docker，构建镜像也要时间。
3. 系统快照。 云服务器做整盘快照，出问题时直接恢复到某个时间点。这种方式最省事，但快照文件占用存储，且换机器不一定能直接用。
实际建议：代码层面用依赖锁定，环境层面用快照。这两个组合成本低、效果够用。容器化留给需要长期维护、多人协作的项目。
二、数据放在哪里
实验数据的特点：体积大、读写频繁、需要保留多个版本。
几个原则：
别放系统盘。 系统盘装系统、装依赖，空间本来就紧。数据放独立的云盘或对象存储，系统重装时数据不受影响。
中间结果要能重建。 好的做法是把"原始数据 → 预处理 → 中间结果"这条链写成可重复执行的脚本，而不是手工操作。这样中间结果丢了可以重跑，不用提心吊胆地备份每一个临时文件。
结果要有版本。 跑不同参数得到的实验结果要能区分。建议按"实验名参数时间"的规则组织目录，配合一个实验记录表，写清楚每次跑的配置。
三、算力需求的估算方法
做实验前先估资源，避免跑到一半发现内存不够、或者买了大规格却用不上。
内存估算。 数据处理任务的内存占用大致是"数据量 × 处理时的放大系数"。用 pandas 读一个 2GB 的 CSV，实际内存占用可能是 4–8GB（类型推断、中间 DataFrame）。留 2 倍余量比较安全。
CPU 估算。 单线程任务看主频，多线程任务看核数。如果任务本身不能并行（很多 Python 脚本因为 GIL 就是单线程），堆核数没用，反而该看单核性能。
时长估算。 先用小样本跑一遍，测出单位数据的处理时间，再乘以全量数据量。这比凭感觉估准确得多。
GPU 需求。 如果要训练模型，先算显存：参数量 × 精度字节数 × 优化器状态系数。粗略说，全精度训练 7B 模型需要几十 GB 显存，量化推理只需要几 GB。两者的资源差距极大。
四、实验流程的工程化
把实验当成工程来做，几个习惯能省下大量返工：
1. 环境即代码。 环境搭建步骤写成脚本（install.sh），新机器跑一遍就能还原。不要依赖"我记得当时装了啥"。
2. 配置外置。 超参数不放代码里，用配置文件或命令行参数。这样同一个脚本能跑不同实验，日志里也能记录每次用的参数。
3. 日志要落盘。 训练过程、处理进度、错误信息都要写文件。用 tmux 或 nohup 跑长任务，断开 SSH 也不中断，日志随时能看。
4. 阶段产物要落盘。 预处理完的数据、训练完的模型权重，都保存到独立目录。不要全部留在内存或临时目录里。
5. 定期快照。 关键阶段完成后做一次快照。跑了几天的训练，机器故障就白跑了。
五、时间规划的技术视角
毕业设计有硬截止时间，时间规划比资源规划更关键。一个务实的排布：
第1阶段（1-2周）：环境搭建 + 数据准备
↓ 验证：能跑通一个小样本的完整流程
第2阶段（2-4周）：方法实现 + 小规模实验
↓ 验证：结果合理，指标能算出来
第3阶段（2-4周）：全量实验 + 调参
↓ 验证：结果稳定，能复现
第4阶段（1-2周）：整理结果 + 写论文
关键点是第一阶段必须有明确验收：能不能用小样本跑通端到端流程。这一步没跑通就开始大规模实验，后面全是返工。
六、换机器时怎么迁移
实验周期长，可能会换实例规格（比如前期小规格调试，后期大规格跑全量）。迁移时要注意：
数据先走。 数据量大的话，用对象存储或云盘挂载，换实例时重新挂载即可，不用重新上传。
环境可重建。 靠前面说的安装脚本或快照，新实例快速还原。
绝对路径要统一。 代码里写死 /home/user/data 这类路径，换机器路径不一致就跑不起来。用环境变量或配置文件指定根目录。
七、写在最后
实验类项目的环境规划，核心是三件事：能复现、数据不丢、资源够用。做到这三点，你就能把精力放在算法和结论上，而不是反复和环境问题搏斗。
学生算力资源与规格选择可以看官方页面——查看学生专属算力包的规格与使用规则。具体额度、规格与有效期以页面实际展示为准。
你做毕设时踩过环境不可复现的坑吗？最后怎么解决的？评论区聊聊。
