软体负责人把自己的工位让出来，请韩路一坐下。其实这也怪丁耀先没说清楚，或者是廖伯韬交代的不够清楚。本来廖伯韬说的是让韩路一口头指导，这样真出了问题也没韩路一的责任，但是软体负责人以为是让韩路一直接改动。
韩路一也懒得纠正，乾脆地坐了下来。
软体负责人开始讲解代码库在什麽地方，对应的代码又在什麽地方。
但是说着说着才发现，面前这个年轻人看代码的速度比他讲解的还要快，他还没讲完，这位廖总请来的软体专家就已经开始改动了。
韩路一修长的手指在面前的键盘上飞速地跳动，发出一阵密集的声响。
不是，他看懂了麽就改?
软体负责人正忐忑着，却突然听见後面几个工程师在讨论的声音。
「诶，那个是不是韩路一啊?」
「什麽?起源的那个?做ai的韩路一?」
「对啊,他之前是做软体出身的,nllpinter,听说过吗?」
「卧槽,韩路一就是nllpinter?」
听完之後软体负责人放下心来。如果是起源的老板，那真出了问题，至少他赔得起。
整个改动非常简单，只要光学测量仪器传进来的补偿数值正好处在那几个出问题的临界区间，管理系统就会识别出来，停止曝光操作，让现场人员可以手动介入。
韩路一前後花了不到五分钟就写完了，还写了完整的测试代码。
不过，韩路一注意到，这台电脑上既没有安装御风，也没有安装其他的ai编程软体，看来冰芯内部的软体团队还算是比较慢的。
因为写得实在是太快，韩路一顺便把修复逻辑也一起写了。这个改动更大一些，因为冰芯的自研管理软体确实有问题。
他们的补偿值竟然是用浮点数来存储的！
要知道，因为计算机本身的局限性，它在内存里是没办法精确地表示小数的，所谓的小数，其实都是一些比例近似值。
在日常编程中这当然不是问题，但是在光刻机这种高精度的场景下，那些不被显示出来的内存近似值很可能会影响近似运算的取值结果。
所以在这些高精度场景下，都是严禁使用浮点数的，而是使用大整数来存储最小精度的单位，比如1.0001纳米存为10001，同时把单位记为0.1皮米。
不过韩路一没把这事当场说出来，只是自己默默写了修复逻辑，把这个问题修复了，同时加上了指定逻辑的对测量值取近似的操作。