我因这三个低级错误，丢过一整周的计算结果

去年有个周二，我兴冲冲地打开一组算了整整一周的 DFT 结果，准备画图。结果发现能量分布差了一个数量级。排查了六个小时，问题出在脚本里 eV 和 kJ/mol 的换算系数写反了。那一周白跑。

从那以后我确信：材料计算代码最难的不是算法，是这些看起来“不可能错”的基础细节。

显式标注单位，是避免静默错误的最佳实践。

误区：觉得单位换算可以心算

埃、纳米、GPa、bar、eV、Ha……不同软件输出的单位千差万别。最坑的是，单位错了通常不会报错，只会默默给你一个“看起来合理”的结果。我曾经因此吃亏：把 5.0 Å 当成 0.5 nm 输进脚本，结构优化直接跑飞，三天后才发现。

我现在养成的习惯是：在脚本开头用常量显式定义单位，并且给每个输入输出函数加上单位注释。心算？不心算。

"/home/xxx/data/structure.xyz" 在你电脑上能跑，换台机器就崩。更隐蔽的是相对路径——你在脚本所在目录运行没事，换个目录就找不到文件。我观察到别人常犯的错误是，把所有数据文件和脚本放一个文件夹，然后疯狂用 ../../ 往上跳。

正确做法：用 pathlib 或命令行参数传入路径，脚本开头检查文件是否存在，报错信息写清楚“期望在哪找到谁”。

ASE、NumPy、pymatgen 这些库升级一次就可能让你的旧脚本崩溃。我曾经在师弟电脑上跑一个三个月前还能用的脚本，结果因为 pymatgen 版本差了一个 minor，API 变了，调了一晚上。

现在每个项目我必做三件事：独立虚拟环境、requirements.txt、关键计算用 conda 或 Docker 锁死版本。这是判断：可复现性比省事重要。

这三个坑都属于“有经验的程序员一眼能看出来，但科研新手经常忽略”的类型。DeepCode 的代码修复模式可以帮你快速定位：把代码和错误信息贴进去，它会返回修复后的版本，并解释为什么这样改。

但工具不会替你做任何物理判断。它能修好路径问题，但不会替你决定用哪个单位；它能指出版本冲突，但不会替你决定哪个版本更科学。工具加速执行，判断仍然靠人。

最好的代码习惯不是写得多巧妙，而是让六个月后的自己还能看懂、还能复现。

你最近有没有被这种“低级错误”坑过？说出来，大家一起避雷。