第10章 低功耗
电梯到十四层，门开了。
江屿跟在周谨后面走出来，脑子里还在转刚才食堂里的那些念头。旧服务器，交互节点，分布式备份，三省几百上千台——这些词像一群蜜蜂，在他脑袋里嗡嗡地转。
但他很快把这些念头压了下去。
现在不是想这个的时候。先把活干好，先在公司站稳脚跟。别的，以后再说。
回到工位，周谨从自己电脑上操作了几下，然后冲他抬了抬下巴。
“代码仓库权限给你开了，地址我发你钉钉了。先把代码拉下来，熟悉一下项目结构。“
“好的周哥。“
江屿打开钉钉，收到一条消息，是个 Git仓库地址。他复制到 Git Bash里，敲下 clone命令。
代码开始下载。进度条一点点往前走。
这个项目比他想象的大。下载速度不快，他等了快十分钟才拉完。打开文件夹一看——几十个模块，Java后端、Vue前端、Python数据处理脚本、还有一堆配置文件和部署脚本，层层叠叠，像一棵根系发达的树。
他盯着文件夹列表看了几秒。
省电模式下，他的信息处理速度回退到了基线。这么大的项目，这么多模块，靠现在这个脑子看，看到猴年马月去。
他摸了摸胸口的玉佩。
“系统。“
“在。“
“修复比例，调到 30%。“
系统沉默了两秒。
“确认将修复比例调整至 30%？警告：该比例为最低安全值，持续运行将导致修复周期大幅延长。“
“确认。“
“已调整。当前修复比例 30%，宿主可用算力 70%。“
江屿深吸一口气。
熟悉的感觉回来了。不是那种满血复活的狂飙，而是——像一台被降频的 CPU突然解除了功耗墙，风扇转起来了，运算速度上来了。
他的思维不再黏糊糊的。信息处理速度、逻辑推理、模式识别，全部回到了强化状态的约 87%。
够用了。
“还有，“他补充道，“我睡着的时候自动切回 80%，醒了再切回 30%。能设置吗？“
“可以。已设置定时策略：宿主进入睡眠状态后自动切换至 80%修复比例，苏醒后恢复 30%。“
“行。“
他顿了顿，又说：“这段时间辛苦你忍耐一下。我得先把这个项目搞明白。“
“修复进程不受意志影响。按当前修复策略预估，总修复周期约三百天。建议宿主尽快恢复正常修复比例。“
三百天。
十个月。
江屿愣了一下。原来九十天，现在直接干到三百天，多出来七个月。
肉疼。
但他想了想，也就这一周。等把项目架构摸熟了，立刻切回全速。一周的低速，换以后的高效，不亏。
“知道了知道了。“
江屿关掉和系统的对话，把注意力放回屏幕上。
这一次，文件夹列表不再是一团乱麻。他扫了一眼，模块的命名规律、目录的分层逻辑、配置文件的组织方式，开始在脑子里自动归类。
接入层。应用层。数据层。底层算力调度接口。
跟文档里那张架构图对上了。
他点开核心模块，开始读代码。
接下来的一周，江屿进入了一种近乎闭关的状态。
白天在公司看代码、读文档、搭环境。晚上回到宿舍接着学，学到眼皮打架才睡。第二天早上七点多爬起来，重复前一天的流程。
他发现一件事：这个项目用的技术栈，比他简历上写的要深得多。
Spring Cloud Alibaba微服务架构，Nacos服务注册与配置中心，Sentinel流量控制，Seata分布式事务——这些他以前只在面试题里背过概念，没真正在生产级项目里用过。
还有前端用的 Vue3 + TypeScript + Pinia，数据处理用的 Python + Pandas +自研的 ETL框架，部署用的 Kubernetes + Jenkins流水线。
每一个拿出来都够写一本书。
但江屿没有慌。
互联网时代了，不是啥都得问老员工的时候。况且现在 AI这么发达——文档、代码仓库、搜索引擎、AI助手，四件套配齐，基本上什么新技术都能摸个大概。
他的学习方式很直接：遇到不懂的技术，先看官方文档，再看项目里的实际用法，然后用 AI把两者串起来。实在搞不懂的，才去问周谨或者刘明。
问的次数不多。一来 70%算力下他学得快，二来他不想太引人注目。
编程这东西，说白了就是从 0到 1写一套你想做的工作流。
区别在于你是手搓，还是用别人已经优化了无数遍的调用库。
手搓的好处是可控，每一行代码你都知道在干什么。坏处是慢，而且你写的大概率没人家写得好。
调用库的好处是快，前人踩过的坑你不用再踩。坏处是——库可能是屎山。
Win11到现在还在用 Win7甚至 XP的底层逻辑，怎么不算一种难以下咽的屎呢？
但不管怎样，直接用别人的新技术达到想要的目的，总归是方便的。
江屿一边读代码一边在心里吐槽。这个项目里也有屎山——某个 2019年写的工具类，注释还是简体中文混着拼音，变量名叫data1、data2、data3，看得他脑壳疼。
但他没说什么。新人嘛，先看，先学，先别逼逼。
周三的时候，他把本地环境搭起来了。
踩了不少坑。JDK版本不对，Maven依赖冲突，数据库连接串写错，Nacos启动失败，前端 Node版本不兼容——一个接一个，像打地鼠。
但 70%算力下，他排查问题的速度比以前快了不少。报错信息一看，日志一翻，大概就知道方向在哪。
到周三晚上，客户端在本地跑起来了。
他用测试账号登录，模拟了一次完整的政务数据提交流程。数据从前端表单出发，经过接入层校验，到应用层处理，写入数据层，最后同步到底层算力调度接口。
通了。
江屿靠在椅背上，看着屏幕上返回的“success“，长出了一口气。
三天。从拉代码到本地跑通，他用了三天。
按正常节奏，一个新人熟悉这个项目至少得两到三周。校招的应届生更是要培训两三个月才能上手。
但他不能表现出来。
第二天周四，周谨问他环境搭得怎么样了，他说：“差不多了，正在跑测试数据，还有几个地方不太明白。“
周谨点点头，没多想。
周五开始，公司进入了加班模式。
中科院那边的总系统做了一次版本升级，底层的数据交互 SDK从 2.x升到了 3.x。调用库一更新，接口签名、返回结构、参数命名全变了，公司这边的应用层必须跟着做适配。
这种事最头疼。调用库是别人写的，你改不了，只能改自己的代码去贴它。而且新版本的文档写得跟谜语一样，哪些接口废弃了、哪些字段改名了、哪些行为变了，全靠踩坑踩出来。
周谨在群里发了消息：“这周末加班，把 SDK升级的适配做完。能改的改，改不动的先记下来，周一跟中科院那边对接。“
全技术部都在加班。
周谨在盯核心模块的适配，刘明在做前端兼容性测试，其他几个工程师有的在改接口调用，有的在跑回归测试。办公室里灯火通明，键盘声噼里啪啦的，比白天还热闹。
江屿也在加班。
倒不是他有多热爱工作——主要是，所有人都在加班，就你一个人到点拎包走人，会不会太膈应人了？
不管你是不是新来的。
职场潜规则而已。他懂。
所以他每天跟着加班到十一二点，回到宿舍洗漱完躺下，基本已经是凌晨一点了。早上七点多起床，满打满算睡六个多小时。
睡着的时候系统切到 80%修复，醒着的时候维持 30%。每天全速修复的时间也就六小时左右，剩下十八个小时都是最低功耗在跑。
低速修复跟正常修复不是一回事。30%的算力下，修复进程本身也在降频运行，效率比线性比例还要再打个折——就像 CPU跑在最低频率，不光是慢，流水线还经常断。
但没办法。这一周 70%的算力都拿来学习了，修复只能靠边站。好在项目架构已经摸得差不多了。
周六下午，适配出问题了。
核心模块改完之后，一跑回归测试就报空指针。NullPointerException，堆栈信息指向数据转换层的某一行，但那一行只是取了个对象的字段，看不出为什么会空。
周谨坐在工位上，眉头拧成一团，IDE里开着调试模式，断点打了一串，一步一步地追。
参数从前端进来的时候叫orgCode。到了 Controller层，被装进一个RequestDTO里，字段名还是orgCode。然后传到 Service层，被转成了organizationCode。Service层调用中科院 SDK的查询接口，传进去的参数名又变成了orgId。
SDK返回一个OrgInfo对象。旧版 2.x里这个对象有个getOrganizationId()方法，返回机构 ID。但新版 3.x里——
周谨追到这里，停住了。
他看着变量面板里的OrgInfo对象，展开字段列表。deptId、deptName、parentDeptId……
没有organizationId。
“不对啊，“周谨喃喃自语，“旧版明明有这个字段的……“
他又往上追了一层。数据转换层拿的是orgInfo.getOrganizationId()，但新版 SDK把这个字段废弃了，改成了deptId。代码里没改，所以取出来是 null。然后往下游一传，空指针。
但问题是——他刚才追的时候，参数在不同层之间换来换去，orgCode、organizationCode、orgId、deptId，名字一个层一个样，他追了三遍才把整条链路理顺。
而且这只是其中一个字段。SDK3.x里改了名的字段少说有十几个，每个都要在代码里搜一遍、改一遍，漏一个就是一个雷。
周谨抓了抓头发，又从头跑了一遍。
还是同样的位置，同样的空指针。
江屿坐在隔壁，余光扫到了屏幕上的报错信息和变量面板。
他看了一眼。
然后又看了一眼。
心里大概有谱了。
这个数据转换层他前两天读过。当时就觉得字段命名有点乱——同一个东西，在不同的类里叫不同的名字。他当时还在心里吐槽了一句“起名是门艺术，这项目的艺术细胞大概被狗吃了“。
现在 SDK一升级，命名混乱的问题全暴露了。
江屿在心里把整条链路过了一遍：前端orgCode→DTOorgCode→ServiceorganizationCode→SDK入参orgId→SDK返回OrgInfo→旧版取getOrganizationId()→新版改成了getDeptId()→代码没改→null→空指针。
确认。八九不离十。
他想说。
但话到嘴边又咽回去了。
他来公司才一周。一周。一个新人，刚来一周就能一眼看出技术负责人调试了半天的问题？
这说出去谁信？
按他表现出的能力，得被当外星人解剖。
藏拙。必须藏拙。
他又看了一眼周谨。周谨还在抓耳挠腮，断点打到了第三遍，额头上都冒汗了。
江屿心软了。
“周哥，“他假装随意地凑过去，“我前两天看代码的时候，好像注意到这个数据转换层取的字段名……跟 SDK返回的对不上？“
周谨转过头，看了他一眼。
“什么意思？“
“就是，“江屿斟酌着措辞，“我看旧代码里调的是getOrganizationId()，但新版 SDK是不是把这个字段改名了？我之前拉依赖的时候扫了一眼新版本的类，好像返回结构不太一样。“
周谨愣了一下。
然后他的眼睛亮了。
“等会儿——“他切回 SDK的依赖包，翻到OrgInfo类的定义，快速扫了一遍字段列表，“卧槽，还真是。3.x把organizationId改成deptId了，旧字段直接删了，连个@Deprecated都没留。“
他噼里啪啦敲了几行代码，把数据转换层里的getOrganizationId()改成getDeptId()，然后重新跑回归测试。
数据通了。
那个报了一下午的空指针，消失了。
周谨靠在椅背上，长长地舒了口气，然后转头看江屿，眼神里带着点意外。
“可以啊江屿。“他拍了拍江屿的肩膀，“这才来一周，就能定位到这种问题了？你之前研究过这个 SDK？“
“没有没有，“江屿赶紧摆手，“就是前两天搭环境的时候顺便看了一眼依赖包的结构，觉得字段命名有点怪，没想到真出问题了。运气好，运气好。“
“运气好也是实力的一部分。“周谨笑了笑，“你这敏感度可以。我在这打断点打了俩小时，你一句话就点透了。这次 SDK升级坑太多，你帮了大忙了。“
“哪能啊周哥，“江屿谦虚道，“你是全局把控，我是刚好看到那个细节。“
周谨没再说什么，但看江屿的眼神明显不一样了。
后来这次适配整体完成后，周谨在组会上复盘，专门提到江屿帮着定位了 SDK字段变更的问题，省了不少排查时间。
“这次升级能这么顺利收尾，江屿功不可没。“周谨说。
江屿坐在角落，微笑着点头，心里毫无波澜。
一个字段改名而已。
如果让他放手去做适配，半天就能把十几个字段全改完测完。
但他不能。
周日晚上，加班结束。
江屿回到宿舍，洗完澡躺在床上，摸了摸胸口的玉佩。
“系统。“
“在。“
“核心修复进度。“
“核心架构修复进度：7.5%。“
一周涨了 2.4%。慢得像蜗牛爬。
“修复比例调回 80%。“
“确认。已恢复正常修复比例 80%。按当前未修复进度预估，剩余修复时间约八十四天。“
八十四天。
江屿盯着天花板，松了口气。还好只是低速了一周，切回来之后剩下的时间跟原计划差不了多少。刚才那三百天的预估果然是吓唬人的——只要不一直低速，就没那么夸张。
但他转念又想，八十四天还是太慢了。
他翻了个身，把玉佩贴在手心。凉意丝丝缕缕的，像在安慰他。
“系统，等我出差别到县乡，接入那些旧服务器，到时候修复速度能提多少？“
“信息不足，无法计算。需接入实际设备后评估。“
“大概呢？“
“若按单台 3.5 TFLOPS、接入 100台估算，可提供约 350 TFLOPS外部算力，约为当前修复算力的 437倍。修复周期将大幅缩短。“
437倍。
江屿的心跳漏了一拍。
100台而已。三个省，几百上千台的边缘节点，100台只是零头。
如果接入 500台呢？1000台呢？
他不敢想了。
八十四天？如果能接入边缘算力，八十四天说不定能压到八十四小时。
“睡吧。“他对系统说，也对自己说，“明天开始，想办法出差别。“
“确认。宿主晚安。“
玉佩的凉意微微变了，像一台服务器从待机状态切到了满负荷运行。
江屿闭上眼睛。
黑暗里，他的嘴角翘了一下。
八十四天就八十四天吧。
反正——他有的是办法让它变得更短。
江屿跟在周谨后面走出来，脑子里还在转刚才食堂里的那些念头。旧服务器，交互节点，分布式备份，三省几百上千台——这些词像一群蜜蜂，在他脑袋里嗡嗡地转。
但他很快把这些念头压了下去。
现在不是想这个的时候。先把活干好，先在公司站稳脚跟。别的，以后再说。
回到工位，周谨从自己电脑上操作了几下，然后冲他抬了抬下巴。
“代码仓库权限给你开了，地址我发你钉钉了。先把代码拉下来，熟悉一下项目结构。“
“好的周哥。“
江屿打开钉钉，收到一条消息，是个 Git仓库地址。他复制到 Git Bash里，敲下 clone命令。
代码开始下载。进度条一点点往前走。
这个项目比他想象的大。下载速度不快，他等了快十分钟才拉完。打开文件夹一看——几十个模块，Java后端、Vue前端、Python数据处理脚本、还有一堆配置文件和部署脚本，层层叠叠，像一棵根系发达的树。
他盯着文件夹列表看了几秒。
省电模式下，他的信息处理速度回退到了基线。这么大的项目，这么多模块，靠现在这个脑子看，看到猴年马月去。
他摸了摸胸口的玉佩。
“系统。“
“在。“
“修复比例，调到 30%。“
系统沉默了两秒。
“确认将修复比例调整至 30%？警告：该比例为最低安全值，持续运行将导致修复周期大幅延长。“
“确认。“
“已调整。当前修复比例 30%，宿主可用算力 70%。“
江屿深吸一口气。
熟悉的感觉回来了。不是那种满血复活的狂飙，而是——像一台被降频的 CPU突然解除了功耗墙，风扇转起来了，运算速度上来了。
他的思维不再黏糊糊的。信息处理速度、逻辑推理、模式识别，全部回到了强化状态的约 87%。
够用了。
“还有，“他补充道，“我睡着的时候自动切回 80%，醒了再切回 30%。能设置吗？“
“可以。已设置定时策略：宿主进入睡眠状态后自动切换至 80%修复比例，苏醒后恢复 30%。“
“行。“
他顿了顿，又说：“这段时间辛苦你忍耐一下。我得先把这个项目搞明白。“
“修复进程不受意志影响。按当前修复策略预估，总修复周期约三百天。建议宿主尽快恢复正常修复比例。“
三百天。
十个月。
江屿愣了一下。原来九十天，现在直接干到三百天，多出来七个月。
肉疼。
但他想了想，也就这一周。等把项目架构摸熟了，立刻切回全速。一周的低速，换以后的高效，不亏。
“知道了知道了。“
江屿关掉和系统的对话，把注意力放回屏幕上。
这一次，文件夹列表不再是一团乱麻。他扫了一眼，模块的命名规律、目录的分层逻辑、配置文件的组织方式，开始在脑子里自动归类。
接入层。应用层。数据层。底层算力调度接口。
跟文档里那张架构图对上了。
他点开核心模块，开始读代码。
接下来的一周，江屿进入了一种近乎闭关的状态。
白天在公司看代码、读文档、搭环境。晚上回到宿舍接着学，学到眼皮打架才睡。第二天早上七点多爬起来，重复前一天的流程。
他发现一件事：这个项目用的技术栈，比他简历上写的要深得多。
Spring Cloud Alibaba微服务架构，Nacos服务注册与配置中心，Sentinel流量控制，Seata分布式事务——这些他以前只在面试题里背过概念，没真正在生产级项目里用过。
还有前端用的 Vue3 + TypeScript + Pinia，数据处理用的 Python + Pandas +自研的 ETL框架，部署用的 Kubernetes + Jenkins流水线。
每一个拿出来都够写一本书。
但江屿没有慌。
互联网时代了，不是啥都得问老员工的时候。况且现在 AI这么发达——文档、代码仓库、搜索引擎、AI助手，四件套配齐，基本上什么新技术都能摸个大概。
他的学习方式很直接：遇到不懂的技术，先看官方文档，再看项目里的实际用法，然后用 AI把两者串起来。实在搞不懂的，才去问周谨或者刘明。
问的次数不多。一来 70%算力下他学得快，二来他不想太引人注目。
编程这东西，说白了就是从 0到 1写一套你想做的工作流。
区别在于你是手搓，还是用别人已经优化了无数遍的调用库。
手搓的好处是可控，每一行代码你都知道在干什么。坏处是慢，而且你写的大概率没人家写得好。
调用库的好处是快，前人踩过的坑你不用再踩。坏处是——库可能是屎山。
Win11到现在还在用 Win7甚至 XP的底层逻辑，怎么不算一种难以下咽的屎呢？
但不管怎样，直接用别人的新技术达到想要的目的，总归是方便的。
江屿一边读代码一边在心里吐槽。这个项目里也有屎山——某个 2019年写的工具类，注释还是简体中文混着拼音，变量名叫data1、data2、data3，看得他脑壳疼。
但他没说什么。新人嘛，先看，先学，先别逼逼。
周三的时候，他把本地环境搭起来了。
踩了不少坑。JDK版本不对，Maven依赖冲突，数据库连接串写错，Nacos启动失败，前端 Node版本不兼容——一个接一个，像打地鼠。
但 70%算力下，他排查问题的速度比以前快了不少。报错信息一看，日志一翻，大概就知道方向在哪。
到周三晚上，客户端在本地跑起来了。
他用测试账号登录，模拟了一次完整的政务数据提交流程。数据从前端表单出发，经过接入层校验，到应用层处理，写入数据层，最后同步到底层算力调度接口。
通了。
江屿靠在椅背上，看着屏幕上返回的“success“，长出了一口气。
三天。从拉代码到本地跑通，他用了三天。
按正常节奏，一个新人熟悉这个项目至少得两到三周。校招的应届生更是要培训两三个月才能上手。
但他不能表现出来。
第二天周四，周谨问他环境搭得怎么样了，他说：“差不多了，正在跑测试数据，还有几个地方不太明白。“
周谨点点头，没多想。
周五开始，公司进入了加班模式。
中科院那边的总系统做了一次版本升级，底层的数据交互 SDK从 2.x升到了 3.x。调用库一更新，接口签名、返回结构、参数命名全变了，公司这边的应用层必须跟着做适配。
这种事最头疼。调用库是别人写的，你改不了，只能改自己的代码去贴它。而且新版本的文档写得跟谜语一样，哪些接口废弃了、哪些字段改名了、哪些行为变了，全靠踩坑踩出来。
周谨在群里发了消息：“这周末加班，把 SDK升级的适配做完。能改的改，改不动的先记下来，周一跟中科院那边对接。“
全技术部都在加班。
周谨在盯核心模块的适配，刘明在做前端兼容性测试，其他几个工程师有的在改接口调用，有的在跑回归测试。办公室里灯火通明，键盘声噼里啪啦的，比白天还热闹。
江屿也在加班。
倒不是他有多热爱工作——主要是，所有人都在加班，就你一个人到点拎包走人，会不会太膈应人了？
不管你是不是新来的。
职场潜规则而已。他懂。
所以他每天跟着加班到十一二点，回到宿舍洗漱完躺下，基本已经是凌晨一点了。早上七点多起床，满打满算睡六个多小时。
睡着的时候系统切到 80%修复，醒着的时候维持 30%。每天全速修复的时间也就六小时左右，剩下十八个小时都是最低功耗在跑。
低速修复跟正常修复不是一回事。30%的算力下，修复进程本身也在降频运行，效率比线性比例还要再打个折——就像 CPU跑在最低频率，不光是慢，流水线还经常断。
但没办法。这一周 70%的算力都拿来学习了，修复只能靠边站。好在项目架构已经摸得差不多了。
周六下午，适配出问题了。
核心模块改完之后，一跑回归测试就报空指针。NullPointerException，堆栈信息指向数据转换层的某一行，但那一行只是取了个对象的字段，看不出为什么会空。
周谨坐在工位上，眉头拧成一团，IDE里开着调试模式，断点打了一串，一步一步地追。
参数从前端进来的时候叫orgCode。到了 Controller层，被装进一个RequestDTO里，字段名还是orgCode。然后传到 Service层，被转成了organizationCode。Service层调用中科院 SDK的查询接口，传进去的参数名又变成了orgId。
SDK返回一个OrgInfo对象。旧版 2.x里这个对象有个getOrganizationId()方法，返回机构 ID。但新版 3.x里——
周谨追到这里，停住了。
他看着变量面板里的OrgInfo对象，展开字段列表。deptId、deptName、parentDeptId……
没有organizationId。
“不对啊，“周谨喃喃自语，“旧版明明有这个字段的……“
他又往上追了一层。数据转换层拿的是orgInfo.getOrganizationId()，但新版 SDK把这个字段废弃了，改成了deptId。代码里没改，所以取出来是 null。然后往下游一传，空指针。
但问题是——他刚才追的时候，参数在不同层之间换来换去，orgCode、organizationCode、orgId、deptId，名字一个层一个样，他追了三遍才把整条链路理顺。
而且这只是其中一个字段。SDK3.x里改了名的字段少说有十几个，每个都要在代码里搜一遍、改一遍，漏一个就是一个雷。
周谨抓了抓头发，又从头跑了一遍。
还是同样的位置，同样的空指针。
江屿坐在隔壁，余光扫到了屏幕上的报错信息和变量面板。
他看了一眼。
然后又看了一眼。
心里大概有谱了。
这个数据转换层他前两天读过。当时就觉得字段命名有点乱——同一个东西，在不同的类里叫不同的名字。他当时还在心里吐槽了一句“起名是门艺术，这项目的艺术细胞大概被狗吃了“。
现在 SDK一升级，命名混乱的问题全暴露了。
江屿在心里把整条链路过了一遍：前端orgCode→DTOorgCode→ServiceorganizationCode→SDK入参orgId→SDK返回OrgInfo→旧版取getOrganizationId()→新版改成了getDeptId()→代码没改→null→空指针。
确认。八九不离十。
他想说。
但话到嘴边又咽回去了。
他来公司才一周。一周。一个新人，刚来一周就能一眼看出技术负责人调试了半天的问题？
这说出去谁信？
按他表现出的能力，得被当外星人解剖。
藏拙。必须藏拙。
他又看了一眼周谨。周谨还在抓耳挠腮，断点打到了第三遍，额头上都冒汗了。
江屿心软了。
“周哥，“他假装随意地凑过去，“我前两天看代码的时候，好像注意到这个数据转换层取的字段名……跟 SDK返回的对不上？“
周谨转过头，看了他一眼。
“什么意思？“
“就是，“江屿斟酌着措辞，“我看旧代码里调的是getOrganizationId()，但新版 SDK是不是把这个字段改名了？我之前拉依赖的时候扫了一眼新版本的类，好像返回结构不太一样。“
周谨愣了一下。
然后他的眼睛亮了。
“等会儿——“他切回 SDK的依赖包，翻到OrgInfo类的定义，快速扫了一遍字段列表，“卧槽，还真是。3.x把organizationId改成deptId了，旧字段直接删了，连个@Deprecated都没留。“
他噼里啪啦敲了几行代码，把数据转换层里的getOrganizationId()改成getDeptId()，然后重新跑回归测试。
数据通了。
那个报了一下午的空指针，消失了。
周谨靠在椅背上，长长地舒了口气，然后转头看江屿，眼神里带着点意外。
“可以啊江屿。“他拍了拍江屿的肩膀，“这才来一周，就能定位到这种问题了？你之前研究过这个 SDK？“
“没有没有，“江屿赶紧摆手，“就是前两天搭环境的时候顺便看了一眼依赖包的结构，觉得字段命名有点怪，没想到真出问题了。运气好，运气好。“
“运气好也是实力的一部分。“周谨笑了笑，“你这敏感度可以。我在这打断点打了俩小时，你一句话就点透了。这次 SDK升级坑太多，你帮了大忙了。“
“哪能啊周哥，“江屿谦虚道，“你是全局把控，我是刚好看到那个细节。“
周谨没再说什么，但看江屿的眼神明显不一样了。
后来这次适配整体完成后，周谨在组会上复盘，专门提到江屿帮着定位了 SDK字段变更的问题，省了不少排查时间。
“这次升级能这么顺利收尾，江屿功不可没。“周谨说。
江屿坐在角落，微笑着点头，心里毫无波澜。
一个字段改名而已。
如果让他放手去做适配，半天就能把十几个字段全改完测完。
但他不能。
周日晚上，加班结束。
江屿回到宿舍，洗完澡躺在床上，摸了摸胸口的玉佩。
“系统。“
“在。“
“核心修复进度。“
“核心架构修复进度：7.5%。“
一周涨了 2.4%。慢得像蜗牛爬。
“修复比例调回 80%。“
“确认。已恢复正常修复比例 80%。按当前未修复进度预估，剩余修复时间约八十四天。“
八十四天。
江屿盯着天花板，松了口气。还好只是低速了一周，切回来之后剩下的时间跟原计划差不了多少。刚才那三百天的预估果然是吓唬人的——只要不一直低速，就没那么夸张。
但他转念又想，八十四天还是太慢了。
他翻了个身，把玉佩贴在手心。凉意丝丝缕缕的，像在安慰他。
“系统，等我出差别到县乡，接入那些旧服务器，到时候修复速度能提多少？“
“信息不足，无法计算。需接入实际设备后评估。“
“大概呢？“
“若按单台 3.5 TFLOPS、接入 100台估算，可提供约 350 TFLOPS外部算力，约为当前修复算力的 437倍。修复周期将大幅缩短。“
437倍。
江屿的心跳漏了一拍。
100台而已。三个省，几百上千台的边缘节点，100台只是零头。
如果接入 500台呢？1000台呢？
他不敢想了。
八十四天？如果能接入边缘算力，八十四天说不定能压到八十四小时。
“睡吧。“他对系统说，也对自己说，“明天开始，想办法出差别。“
“确认。宿主晚安。“
玉佩的凉意微微变了，像一台服务器从待机状态切到了满负荷运行。
江屿闭上眼睛。
黑暗里，他的嘴角翘了一下。
八十四天就八十四天吧。
反正——他有的是办法让它变得更短。