坏块标记：存储系统在运行过程中发现某个扇区存在读写异常时，会将该扇区标记为"坏块"并从可用空间中剔除。系统不会尝试修复坏块，也不会在上面写入新数据——它只做一件事：记住这里有问题，绕开它。
坏块不是 bug。坏块是硬盘的物理现实。
真正的 bug 是——你知道有坏块，却假装它不存在。
星期五。
苏念冬到得很早。
八点十分，十九楼市场部办公区只有零星几个人——前台还没把灯全部打开，空调嗡嗡地吹着没散尽的闷气。深圳的七月像一块拧不干的湿毛巾，即使办公室里恒温二十四度，从楼下走上来的那几分钟也足够让后背出一层薄汗。
她把帆布包放在工位上，从抽屉里拿出一包还没拆封的荔枝味水果糖——昨天在城中村小卖部买的，和上周是同一个口味。按照她的习惯，每周一换一种口味，但这周事情太多，忘了买新的，只好继续荔枝。她剥开一颗含在嘴里，没嚼。
"嚼碎就没有甜味了。"她小声对自己说。
然后把沈暮白给她的那张手写参数表从文件夹里取出来，展开放在键盘旁边。
A4纸，正面是昨天在楼梯间递给她的那份——"全闪存阵列关键参数速查"，八项参数，每项标了来源和测试条件，字迹工整到不像匆忙写的。
她翻到背面——
背面也有字。
她愣了一下。昨天在楼梯间光顾着紧张，接过纸就走了，根本没翻到背面。
背面的字更小，密密麻麻写了一整版，标题是"参数交叉验证逻辑"，下面分了三个区块：
① 容量计算链
原始容量 → RAID级别扣除 → 重删/压缩扣除 → 快照预留 → 可用容量
（每一环都必须标注扣减系数，不允许跳步）
② 性能交叉验证
IOPS → 单盘IOPS × 盘数 × RAID惩罚 → 有效IOPS
延迟 → 读延迟 / 写延迟需分开标注
（标称延迟必须注明测试条件：块大小、读写比、队列深度）
③ 兼容性验证
LUN映射 → 主机连接数 → 多路径 → 实际可用LUN
（标称最大值 ≠ 实际可用值）
苏念冬盯着这张纸看了很久。
她想起昨天沈暮白在楼梯间说的那句话——"不是信任问题，是流程问题。"
原来他给的不仅是一张正确的参数表。他给的是一套验证方法。
昨天他可能以为她会看到背面。也可能他根本不在乎她看不看——他只是写了，给不给、看不看，是接收方的事。
但苏念冬现在看到了。
她从笔筒里抽出一支笔，在一张黄色的便签上写下：
"参数交叉验证三步法：① 容量计算链 ② 性能交叉验证 ③ 兼容性验证"
然后把便签贴在显示器边框上——和蓝色的那张"机房男=傲慢但厉害"并排。
蓝色说她对他的感受。黄色说她从他那里学到的方法。
颜色是她的心情晴雨表。蓝色是惊讶，黄色是认真。
上午九点，办公室渐渐满了起来。
苏念冬的工位在市场部最里面靠窗的位置——不是什么好位置，旁边是复印机，对面是饮水机，人来人往的。但她不介意，她觉得靠窗好，能看到外面——虽然外面只是深南大道的车流和对面写字楼的玻璃幕墙。
她打开电脑，调出昨天评审会用的那份参数表——被周明远点出错误的那份。然后打开沈暮白给的手写参数表，开始逐项替换。
这是一个比她想象中更耗时的过程。
沈暮白的参数表上的数据，每一项都标了三个信息：来源、测试条件、引用文献。她要把这些信息全部补进电子版的参数表里，格式还得统一——来源用方括号标注，测试条件用圆括号，引用文献用脚注。
她不赶时间。评审会已经翻车了，这份参数表是补救措施，不是赶工交差。每一个数字，她都重新查了一遍——有些在公开技术白皮书里能找到，有些要去厂商官网下载产品规格书，有些得翻技术wiki的历史版本。
到十点半的时候，她整理完了容量计算链的部分——八项参数里的前三项。RAID级别、重删/压缩比、可用容量，全部按沈暮白背面的"参数交叉验证逻辑"重新算了一遍。
她发现一个问题。
不，不是"一个问题"。是一个矛盾。
参数表第七行：数据缩减方式——在线重删 + 后压缩（Inline Dedup + Post-Process Compression）。
参数表第十二行：最大写入延迟——< 1ms（4K随机写，队列深度=1）。
苏念冬的手停了。
她含着水果糖，盯着这两个参数看了整整两分钟。
在线重删。她这两天查了很多资料。在线重删的意思是——每一次写入操作，在数据落盘之前，系统都会先计算这段数据的哈希值，然后在重删哈希表中查找是否已存在相同的块。如果存在，就不写入新数据，只更新指针；如果不存在，才写入新数据并更新哈希表。
这个查找过程需要时间。
哈希计算需要时间。哈希表查找需要时间。如果哈希表很大——在重删比4.5:1的系统中，哈希表可能有数亿条目——查找时间可能更长。
也就是说，开了在线重删，写入延迟不可能还是< 1ms。
除非——
她翻了翻厂商的公开技术白皮书。在白皮书的附录里，她找到了一行小字：
"性能数据基于全闪存配置，重删/压缩功能关闭，4K随机读，队列深度=32。"
重删/压缩功能关闭。
也就是说，参数表上标的"< 1ms"写入延迟，是在关闭重删和压缩功能的情况下测出来的。但参数表同时又标了"数据缩减方式：在线重删 + 后压缩"。
这两个参数放在一起，在工程上是不成立的。
你不可能同时声称"开了在线重删"和"写入延迟< 1ms"——因为在线重删本身就增加了写入路径的延迟。根据哈希表大小不同，额外的延迟可能在1.5ms到4ms之间。
也就是说，如果客户真的开启了在线重删（这也是他们买这套系统的核心原因——为了省容量），实际写入延迟很可能是标称值的2到4倍。
苏念冬的心跳加速了。
她不确定自己是不是对的。她只是一个入职五天的管培生，大学学的是计算机科学但不是存储方向，她对重删的理解来自这两天在wiki和厂商文档上的自学。她有可能漏掉了什么——也许厂商有一种特殊的硬件加速方案，可以在不增加延迟的情况下完成在线重删？
也许她错了。
但她又想起沈暮白背面写的那行字——"标称延迟必须注明测试条件：块大小、读写比、队列深度。"
白皮书附录里确实注明了测试条件。但参数表上没有。
参数表上只写了一个光秃秃的"< 1ms"，没有注明这个数字是在重删关闭的条件下测得的。
这不是一个数字错误。这是一个逻辑矛盾。
苏念冬在工位上坐了十五分钟，没有动。
她在犹豫。
昨天评审会翻车的记忆还很清晰——周明远当着二十个人的面说"这个数据不对"，陆星野的脸色铁青，刘洋在旁边低头不说话。她不想再出丑了。
如果她现在在wiki上发一篇笔记，说"参数表上的写入延迟和重删方式存在逻辑矛盾"——然后被证明是她自己理解错了呢？
那她就不是"出了丑"，而是"不懂装懂"了。前者是能力不足，后者是态度问题。
能力不足可以被原谅。态度问题不会。
她把水果糖咬碎了。
甜味一下子涌满口腔，然后迅速消散。
"嚼碎就没有甜味了。"她对自己说。
然后她重新含了一颗。
不嚼。
她打开浏览器，进入瀚海科技技术wiki。昨天发布的第一篇笔记——《数据缩减比的场景差异：为什么4.5:1不等于3.2:1》——显示状态是"已审核，已公开"。审核人是"smubai"。
他通过了她的笔记。
苏念冬盯着那个"已审核"看了三秒钟，心里涌上一股说不清的感觉——不是高兴，是踏实。像是交了一份作业，老师批改了，没有打叉，只在旁边画了一个小小的勾。
她不知道沈暮白有没有看那篇笔记的内容。也许他只是例行公事地点了"通过"，根本没看。管理员权限就是这样，有些管理员闭着眼批量审核，不管内容质量。
但万一他看了呢？
万一他看的时候觉得——"这个人写的东西还不错"呢？
苏念冬摇了摇头，把这些乱七八糟的想法甩掉。
她想做的事很简单：在wiki上发一篇技术笔记，把她在参数表里发现的矛盾写出来，请懂行的人帮忙判断她是不是对的。
如果她是对的，参数表需要修正——这不是一件小事，这是竞标用的技术方案，每一个参数都可能影响客户的技术评分。
如果她是错的，她至少学到了为什么——是她漏掉了什么条件，还是理解有误。
先学，再问。
她打开wiki编辑器，开始写。
这篇笔记她写了将近两个小时。
不是因为内容多——其实核心矛盾只需要三段话就能说清楚。而是因为她反复修改措辞，每句话都查了至少两个来源，每个技术术语都确认了中英文对照。
标题她改了四次：
第一次：《参数表第七行和第十二行有矛盾》——太直白，像是在指责谁。
第二次：《关于在线重删与写入延迟的疑问》——好一点，但太模糊。
第三次：《在线重删场景下写入延迟标称值的合理性分析》——太学术了，像论文题目。
第四次：她删掉前面的，重新写——《同一个参数表里，"在线重删"和"<1ms写入延迟"能同时成立吗？》
这个标题好。它是一个问题，不是结论。她在问，不是在断言。
笔记的正文她分了三段：
第一段，她列出两个参数的原文和出处。
第二段，她解释在线重删的工作原理——哈希计算、哈希表查找、写入路径增加的额外步骤。每一步都标了引用来源（厂商技术白皮书附录、IEEE一篇关于inline deduplication的论文摘要、以及技术wiki上一位前员工写的重删机制分析文章）。
第三段，她写出自己的推理：
"根据上述原理，开启在线重删后，写入路径会增加哈希计算和查表环节，额外延迟取决于哈希表规模和查找算法。厂商白皮书附录中标注的测试条件为'重删/压缩功能关闭'，这意味着标称的<1ms写入延迟并未包含重删功能开启时的额外开销。
如果两套参数同时出现在同一份参数表中，客户可能会误以为'开启重删的同时仍能获得<1ms写入延迟'，但实际场景中，这通常需要额外的硬件加速或写缓存策略来弥合延迟差异。
我的疑问是：参数表中是否应该标注'标称延迟基于重删关闭条件测得'这一前提？或者，是否存在我未了解到的硬件加速方案，可以使在线重删不增加写入延迟？
如果我理解有误，请指正。"*
她在最后加了一行：
"注：本笔记基于厂商公开技术白皮书及wiki公开资料整理，如有遗漏请补充。"
她看了三遍。每一句都确认过来源。每一个推理步骤都标了依据。结论用疑问句而不是陈述句。
然后她点击发布。
wiki系统弹出提示："您的笔记已发布，已通知相关标签关注者。"
相关标签关注者——她发笔记时加了"存储技术""竞标方案"两个标签。关注这两个标签的人，wiki系统会自动发邮件通知。
沈暮白是wiki管理员，应该会收到通知。
但"应该"这个词让苏念冬不太放心。也许他关掉了邮件通知。也许他今天不在线。也许他看到了标题就划走了——一个入职五天的管培生写的技术疑问，有什么好看的？
她关掉浏览器，强迫自己回去继续整理参数表。第四项到第八项还没做完。
但她心里一直在想那篇笔记。
中午十二点，苏念冬去茶水间热饭。
她带的是昨晚在城中村楼下快餐店打包的青椒肉丝饭——十二块钱，比公司食堂便宜三块，量还更大。她用微波炉热了两分钟，端着饭盒回到工位。
经过饮水机的时候，她听到市场部项目经理刘洋在跟另一个同事说话。
"……那个新来的小姑娘，昨天评审会上出丑了是吧？"刘洋的声音不大，但茶水间不大，苏念冬听得清清楚楚。
"嗯，数据缩减比填错了，被周总当面怼了。"另一个同事说。
"嗐，陆总监也是，让一个刚来五天的小孩整理参数表，不出问题才怪。"刘洋说。"不过这小姑娘也挺轴的，昨天居然在wiki上发了篇笔记，我看了一眼，写得还挺像那么回事。"
"她发了wiki笔记？"
"对，数据缩减比那个。我还寻思，这是不是第一天入职写的第一篇？够猛的。"
苏念冬端着饭盒，假装在饮水机前接水，等他们说完了才走回工位。
她不知道该是什么表情。
被人议论总是不舒服的。但刘洋最后那句"写得还挺像那么回事"让她有一点点——只有一点点——安慰。
她坐在工位上吃饭。青椒肉丝饭有点凉了，微波炉没热透，中间的米饭还是冰的。她把凉的扒到一边，只吃热的那部分。
吃完饭她打开wiki看了一眼。
没有新回复。
通知栏显示"您有0条新消息"。
她关掉页面，告诉自己：不要急。也许下午就会有人回复。也许明天。也许下周。
先学，再问。先学，再等。
下午，苏念冬把剩下的参数整理完了。
第四项到第八项：快照数量、LUN数量、主机连接数、协议支持、保修条款。每一项她都按沈暮白背面的"兼容性验证"逻辑走了一遍——LUN映射数不能超过主机连接数，多路径配置会影响实际可用LUN，标称最大值不等于实际可用值。
她发现了一个细节：参数表标称"最大LUN数量：1024"，但"最大主机连接数：256"。按照多路径标准配置（每台主机2条路径），1024个LUN全部分配需要至少512台主机。但主机连接数上限是256，也就是说实际可同时映射的LUN数量上限是256（如果每台主机一个LUN）。
这不是错误——1024是系统的物理上限，256是并发连接限制，两个数字都有意义。但它们放在一起时，如果客户不做计算，会误以为系统能同时给1020台主机各分一个LUN。
她在参数表旁边加了一列注释："实际可用并发映射数 = 主机连接数上限 ÷ 多路径数"，把这个关系标了出来。
这是她自己想出来的补充。不是沈暮白教的，不是wiki上写的。
她有点忐忑——这个注释会不会显得多余？会不会被陆星野看到觉得"你一个管培生加什么注释"？
但她还是留着了。因为沈暮白在背面写了"标称最大值 ≠ 实际可用值"，而她把这个原则用到了一个具体场景里。
五点。她把整理好的参数表发给了陆星野，抄送了项目组相关人员。
然后她打开了wiki。
还是没有回复。
她关掉页面，收拾东西，准时下班。
苏念冬走后，十九楼的灯光一盏一盏灭掉。
市场部最后一个走的是刘洋——他六点半关的灯。研发部那边还有人，但不多。二十楼总工办的灯亮着，那是沈暮白的办公室，但他通常不在办公室待着——他在十八楼的实验室或者机房。
实际上，沈暮白今天下午一直在十八楼的实验室。
他在调试一台全闪存阵列的原型机——NovaStor项目的硬件验证平台。这台原型机用了二十四块NVMe SSD，组了两组RAID 5，跑的是他自己写的存储引擎。他在测重删引擎在不同数据集下的表现——办公数据、虚拟机镜像、数据库日志，三种数据类型的重删比差异很大。
他喜欢这种工作。安静的实验室，服务器的风扇噪音像白噪音，没有人来打扰。数据在跑，他在旁边看终端的输出日志，偶尔修改参数，重启测试。
六点十五分，他回到二十楼的办公室拿东西。
办公室不大，一张桌子，一把椅子，一台旧ThinkPad。桌上什么私人物品都没有——没有照片，没有绿植，没有水杯。唯一的"装饰"是一个黑色保温杯，放在桌角，里面是早上泡的美式咖啡，不加糖，现在已经凉了。
他拿起保温杯喝了一口——凉的，苦的，但是他习惯的味道。
然后他坐下来，打开ThinkPad，习惯性地检查了三个地方：GitHub通知、工作邮件、wiki后台。
GitHub上NovaStor项目又多了两个star，不认识的人，他没在意。
工作邮件有七封未读，三封是会议通知，两封是跨部门协调邮件，一封是行政通知（办公区空调维护），一封是wiki系统的自动通知——"用户smindong发布了新笔记，标签：存储技术、竞标方案。"
他停了一下。
smindong。昨天在GitHub上star了NovaStor的那个用户名。
他点开wiki后台。
笔记列表里多了一条——
《同一个参数表里，"在线重删"和"<1ms写入延迟"能同时成立吗？》
作者：smindong（苏念冬）
发布时间：今天 10:47
标签：存储技术、竞标方案
状态：待审核
沈暮白盯着标题看了五秒钟。
然后他点开了笔记。
他读得很慢。
不是因为内容难——对他来说，在线重删的写入路径延迟分析是基础得不能再基础的东西。他读得慢是因为他在看苏念冬的推理过程。
她的推理结构是对的。
哈希计算增加写入路径延迟——对。
哈希表查找时间取决于表规模——对。
厂商白皮书附录标注的测试条件是"重删关闭"——对。
标称延迟未包含重删开启时的额外开销——对。
结论用疑问句而不是陈述句——
他停在这一行。
"如果我理解有误，请指正。"
这行字让沈暮白想起了什么。
不是想起了某个具体的人或事。是想起了一种感觉——一种他自己很久没有的感觉。
那种"不确定自己是对是错，但还是决定把问题说出来"的感觉。
他做存储引擎做了十几年。刚入行的时候，他也这样——发现一个问题，翻了很多资料，写了很长的分析，最后不确定，加一句"如果我理解有误，请指正"。
后来他不加这句话了。不是因为他不会错了，是因为他变成了"总工"——总工不应该说"如果我错了"。总工应该说"这个方案有问题，理由如下"。
但苏念冬不是总工。她是一个入职五天的管培生。
她加了这句话。这说明她知道自己在做什么——她在问，不是在断言。她在说"我可能是错的"，而不是"你们都错了"。
这种态度，比结论对不对更重要。
他又看了一遍她的引用来源。三篇引用——厂商白皮书附录、IEEE论文摘要、wiki上一位前员工的文章。三个来源互相印证，逻辑链完整。
她没漏。她甚至标了一行"注：本笔记基于厂商公开技术白皮书及wiki公开资料整理，如有遗漏请补充。"
沈暮白把笔记从头到尾看了第二遍。
然后他看了第三遍。
不是因为他在犹豫要不要回复。他在想怎么回复。
他可以附几个文档链接。就像他以前偶尔做的那样——在别人的wiki笔记下面贴两三个相关文档的URL，然后关掉。不解释，不推导。你想懂就自己去看。
他以前回复新人笔记的方式永远是"链接"——简洁、高效、不带任何多余内容。他的回复像他的性格一样：省电，不浪费。
但这次他想了想。
她的疑问不是"重删是什么"或者"延迟怎么定义"这种基础问题——那种问题甩一个链接就够了。她的疑问是一个工程逻辑问题——两个参数放在一起是否自洽。这种问题不能用链接回答，因为没有任何一篇现成文档直接讨论"在线重删和写入延迟标称值在同一份参数表中的共存合理性"。
这不是一个可以从文档里找到答案的问题。这是一个需要从原理推导的问题。
他打开了笔记的回复框。
光标在空白的输入框里闪烁。
沈暮白的手放在键盘上，停了几秒钟。
然后他开始打字。
他写了一段完整的技术推导。
不是提纲式的，不是要点式的，是一段从原理到结论的完整推导。他用了不到八百字——但对于一个通常用"嗯"和"加班解决不了需求不清晰的问题"就能打发一整段对话的人来说，八百字几乎是演讲级别的输出。
他写了四个层次：
第一层：确认问题成立。
"你的疑问成立。参数表中'在线重删+后压缩'与'<1ms写入延迟'在同一标称条件下不共存。"
第二层：原理解释。
"在线重删的写入路径为：应用写入 → 哈希计算 → 哈希表查找 → 命中则更新指针/未命中则写入新块 → 后压缩 → 落盘。相比不开启重删的路径（应用写入 → 落盘），增加了哈希计算、查表、指针更新三个环节。在典型全闪存配置下，这三个环节的额外延迟约为0.8-2.5ms，取决于哈希表规模（与重删比正相关）和查找算法。"
第三层：厂商做法的行业惯例。
"厂商在白皮书中标注性能数据时，通常采用'最优配置'——即关闭重删和压缩功能，以获得最佳基准测试结果。这是行业通行做法，不算违规，但前提是参数表必须标注测试条件。当前参数表未标注'重删关闭'这一前提，存在误导风险。"
第四层：修正建议。
"建议在参数表第十二行后补充注释：'标称延迟基于重删/压缩关闭条件测得，开启在线重删后写入延迟预计增加0.8-2.5ms。具体增量取决于数据特征和哈希表规模。'
另外，你在参数表中添加的'实际可用并发映射数 = 主机连接数上限 ÷ 多路径数'注释是对的。标称最大值和实际可用值之间的差异在投标方案中经常被忽略，标注出来是正确的做法。"
他停了一下。
最后加了一行：
"笔记本身的分析逻辑清晰，引用来源完整。继续。"
"继续"两个字他打了又删，删了又打。
最后留着了。
然后他点了"回复"。
沈暮白关掉wiki后台，拿起保温杯喝了一口凉美式。
他看了一眼时间。九点四十七分。
从八点打开笔记到九点四十七分回复完——他用了将近两个小时。其中读笔记花了十五分钟，写回复花了四十分钟，剩下的一个多小时——他在想要不要回。
他不知道自己为什么纠结。
他以前不是这样的。以前wiki上有新人发笔记，他扫一眼标题，如果太基础就直接关掉，偶尔心情好甩个链接。从不说多余的话，从不做多余的推导，从不像今天这样把四个层次的解释全部写出来。
他上一次在wiki上主动写长回复是什么时候？
他想了想。
三年前。
三年前他还是一个愿意带团队的人。三年前他还会在wiki上写技术分析长文，会在新人提问后写完整的推导，会在代码审查时留下大段注释解释为什么这样写而不那样写。
三年前那场事故之后，他就不写了。
不是不会写了。是不想写了。
写出来也没人看。或者有人看，但看完也不按你说的做。或者按你说的做了，但出了问题还是你背。信任这种东西，跟RAID 5一样——坏一块盘不会丢数据，但坏两块就全完了。他的信任阵列已经降级运行了三年，坏了两块盘，他不想再往里面加新的盘了。
但今天他写了。
写了将近八百字。
写了"继续"两个字。
他不知道苏念冬会不会看到这篇回复。他不知道她看到之后会怎么想。也许她会觉得"总工居然回复了我"然后受宠若惊。也许她会觉得"这人写的东西好冷"然后有点失落。也许她根本不会在意——一个管培生每天有那么多事要忙，谁会在乎wiki后台一个叫"smubai"的管理员说了什么。
沈暮白把这些想法从脑子里推开。
他不需要知道她怎么想。他只是回答了一个技术问题。
保温杯里的美式已经喝完了。他拧上盖子，放进包里，关灯，锁门，走向电梯。
走廊很安静。他的脚步声在大理石地面上发出清脆的回响——不急不慢，节奏均匀，和往常一样。
电梯门开了。他走进去，按了负一层。
地下车库里停着他那辆银灰色的二手大众。他坐进去，没急着发动，先从副驾的手套箱里拿出一包坚果——他的晚餐替代品。吃了两口，发动车子，开出地库。
深圳的夜风从车窗灌进来。七月的风是热的，带着盐分和潮气。
他打开车载蓝牙，没有放音乐。
安静地开车。
车载屏幕上显示时间：22:14。
他在想一个技术问题——苏念冬笔记里引用的那篇IEEE论文，摘要里提到了一种基于FPGA的硬件加速方案，可以在不增加CPU开销的情况下完成哈希计算。但那篇论文是2019年的，FPGA方案在商业化存储产品中的落地案例很少，成本太高。
所以他在回复里没有提FPGA方案。因为他不想给苏念冬一个"看起来可行但实际上不会用"的答案。
他只给了她实际可用的修正建议。
这是他的习惯——给的东西必须能用。不能用的东西，再漂亮也是坏块。
苏念冬是在第二天早上看到回复的。
周六。她本不用加班，但她想回办公室用打印机——城中村楼下打印店太贵，一块钱一张，公司打印免费。
八点半到办公室，泡了一杯速溶咖啡，习惯性地打开wiki看了一眼。
通知栏："您有1条新回复。"
她的手指悬在触控板上方，停了一秒。
然后点开。
回复者：smubai
她看到了第一行——
"你的疑问成立。参数表中'在线重删+后压缩'与'<1ms写入延迟'在同一标称条件下不共存。"
她的疑问成立。
成立。
她是对的。
她没有大声说出来。办公室里只有她一个人。但她的嘴角不受控制地往上弯了一下，然后又收回去——像是怕被谁看到似的。
然后她继续往下读。
第二层，原理解释。哈希计算、查表、指针更新，额外延迟0.8-2.5ms。她之前推测的"1.5到4ms"偏高了一些，但方向是对的。
第三层，行业惯例。厂商用最优配置跑基准测试是通行做法，不算违规，但必须标注测试条件。她在笔记里写的是"参数表是否应该标注标称延迟基于重删关闭条件测得这一前提"——沈暮白确认了她应该标注。
第四层，修正建议。他给了一段可以直接复制到参数表里的注释文字——"标称延迟基于重删/压缩关闭条件测得，开启在线重删后写入延迟预计增加0.8-2.5ms。具体增量取决于数据特征和哈希表规模。"
然后是最后那行——
"另外，你在参数表中添加的'实际可用并发映射数 = 主机连接数上限 ÷ 多路径数'注释是对的。标称最大值和实际可用值之间的差异在投标方案中经常被忽略，标注出来是正确的做法。"
她的注释是对的。
他看到了。
他不仅看了wiki笔记，还看了她发给项目组的参数表。或者——他看了wiki笔记后去查了参数表？还是他本来就在项目组的邮件列表里，收到了她昨天下午发的那份？
不管是哪种，他都看到了。
苏念冬把目光移到最后一行。
"笔记本身的分析逻辑清晰，引用来源完整。继续。"
继续。
两个字。
她把这两个字读了五遍。
第一遍，她以为看错了——"继续"？继续什么？继续整理参数表？继续写wiki笔记？继续学？
第二遍，她觉得这是客套话——像老师说"继续努力"，对所有学生都这么说。
第三遍，她觉得不像是客套。因为沈暮白不像会说客套话的人。他的回复通篇没有一个多余的形容词，没有"写得不错"没有"加油"没有"你很有潜力"。他只说了事实——"疑问成立""注释是对的""分析逻辑清晰"——然后加了一句"继续"。
第四遍，她觉得"继续"可能就是字面意思。继续问。继续写。继续这样。你在做的事情是对的，继续做。
第五遍，她忽然觉得喉咙有点紧。
不是难过。是一种说不上来的感觉。像是——你一个人在很黑的地方走了很久，不确定方向对不对，然后远处有人打了一下手电筒。不是照向你，只是亮了一下。但那一闪足够让你知道：这个方向有人走过。
她拿起手机，截了一张图。
然后把截图存进了一个相册——相册名叫"记录"，里面存着一些对她有意义的东西。入职通知书的照片、工位第一次整理好的样子、第一篇wiki笔记发布时的页面截图。
现在多了这张。
苏念冬没有马上回复沈暮白。
她不知道该说什么。"谢谢"太轻了，"非常感谢您的详细回复"太正式了，"沈总工您太厉害了"太谄媚了。
她在回复框里打了三个字："收到，谢谢。"
看了两秒。删掉。
又打了七个字："已修改参数表，谢谢。"——不对，她还没改。她得先把沈暮白给的注释加进参数表里。
她关掉回复框，先打开参数表文档，把沈暮白建议的那段注释复制进去。然后重新发了一版给陆星野，在邮件正文里写："更新：已在参数表中补充延迟测试条件注释，详见第十二行后附注。"
做完这些，她回到wiki，在沈暮白的回复下面写了一行：
"已按建议修改参数表，注释已补充。感谢沈总工。"
她看着这行字，觉得"沈总工"三个字太生分了。但叫什么呢？叫"沈工"？太随意。叫"沈老师"？好像也不是。叫名字？不可能。
"沈总工"就"沈总工"吧。
她点了回复。
然后她从抽屉里拿出一颗荔枝味的水果糖，剥开，含在嘴里。
没嚼。
甜味慢慢从舌尖化开。
今天是周六，办公室空空荡荡。窗外深南大道上的车比工作日少了很多，偶尔一辆大巴轰隆隆地开过。空调还是二十四度，但不知道为什么，她觉得今天办公室比往常暖一点。
她从便签本上撕下一张——今天是黄色的，和昨天一样。她在上面写了一行字：
"smubai = 傲慢但厉害 + 认真。"
然后把它贴在显示器边框上，蓝色的那张旁边。
蓝色还是"机房男=傲慢但厉害"。那是第一印象。
黄色是更新。是第二印象。
颜色是心情晴雨表。蓝色是惊讶。黄色是认真。但今天的黄色，好像比昨天的黄更亮一点——像是被什么照过。
同一时间，南山区某小区。
沈暮白坐在客厅的沙发上，面前的茶几上摊着一台旧ThinkPad。屏幕保护程序在跑——NovaStor的存储引擎C代码在屏幕上缓缓滚动，绿色的字符像数字雨一样从上往下流。
他在看手机。
不是在刷微博或者看新闻。他在看wiki的回复通知——苏念冬在他的回复下面写了一行："已按建议修改参数表，注释已补充。感谢沈总工。"
"沈总工。"
他看着这三个字，嘴角没有动。
但屏幕上滚动的代码倒映在他的眼镜片上，绿色的字符流忽然变快了一帧——像是处理器的心跳漏了一拍，然后立刻恢复正常。
他放下手机，拿起保温杯——已经空了。
他起身去厨房烧水。电热水壶嗡嗡地响起来。他从柜子里拿出一袋咖啡豆，用手磨机磨了两勺——手磨，不是机器磨。他坚持手磨，因为机器磨的粗细不均匀，影响萃取。
水开了。他把咖啡粉倒进法压壶，倒入热水，等四分钟，压下滤网，倒进保温杯。
不加糖。
他端着保温杯回到沙发上，ThinkPad的屏幕保护还在跑。
他喝了一口咖啡。
苦的。热的。
比办公室那杯好喝。因为这是刚泡的，不是放了一下午的凉美式。
他重新打开wiki后台，看了一眼苏念冬的笔记。她的回复已经显示在下面了——"已按建议修改参数表，注释已补充。感谢沈总工。"
他没有再回复。
不需要了。她已经按建议改了。事情到此为止。
他关掉wiki，打开终端，开始写NovaStor的代码。
但他发现自己的思绪有一瞬间不在代码上。
他在想：苏念冬在wiki上的用户名为什么叫"smindong"？
s + mindong。苏念冬。拼音首字母加全拼。很直白的命名方式。
不像他会取的用户名。他的用户名是"smubai"——沈暮白的拼音缩写。更简洁。
然后他觉得自己想多了。
这种事不值得想。
他回到代码上。光标在终端里闪烁。他敲下了下一个字符。
客厅很安静。
ThinkPad屏幕上的代码继续滚动。
保温杯里的咖啡慢慢变凉。
沈暮白在写代码。
在瀚海科技的机房里，在全闪存阵列的存储引擎深处，有一段代码注释：
// Rewrite dedup hash table lookup logic
// Date: 2023.06.14
// Author: smubai
这是三年前写的。
三年前的沈暮白还会在代码注释里写自己的名字和日期。三年后的沈暮白不会再写了——不是因为谦虚，是因为他不想在代码里留下太多自己的痕迹。
痕迹意味着存在。存在意味着可以被追溯。可以被追溯意味着——如果出了问题，就是你的问题。
他已经不想再背一次了。
但在今天——2024年7月的某个星期五晚上——他做了一件三年来没做过的事。
他在wiki上回复了一个新人。
一个叫smindong的新人。
他写的不是链接，不是"已阅"，不是"建议查阅XX文档"。
他写了八百字。
他写了"继续"。
【第四章 完】