第八十一章 现场复核
周四上午十点，林博文到了。
他带了一个助手，进来的时候就在翻手机，进门跟项磊点了个头，然后扫了一眼会议室，眼神在麦景行的笔记本上停了一下。
项磊向他介绍：「这是星汇云技术负责人，林博文，负责我们整个开发侧。林总，这边是云帆的负责人陆衍，还有我们对接的工程师乔木。」
林博文和他握了手，握法很快，算点到即止：「昨天项磊发了你们的测试报告，有几个地方我想当面问一下。」
「好，」他说，「请坐。」
他在陪林博文过来之前，让乔木把会议室提前准备好，桌上只摆了水，没有多余的东西。这种复核性质的会，东西越少越好，让对方看到你愿意被问。
会议室里，林博文把手机放平，打开一张截图，推到桌子中间。
「第一轮91%，第二轮84.7%。」他说，「你们的解释我看了，说测试集不同。但我们验收要签字的，91到84这个差值，我需要能在内部解释清楚。如果解释不清楚，验收不签。」
他没有立刻开口。这句话说得很直接，把压力放在桌子上了。这是条件，不是问题。
他在等麦景行进来。两分钟前他让乔木去接，这会儿麦景行推门进来，把笔记本放在桌边打开。
「脚本在这里，」他向林博文说，「可以当场运行，结果可以复现。我们工程师今天在，让他演示一遍，你来判断这个差值的来源合不合理。」
他转头看了麦景行一眼：「运行一遍。」
麦景行打开终端，把脚本跑了一遍，命令行里逐行输出：从 Git 日志里提取最近三十天有注释修改的 commit，按提交时间戳排序，用顺序编号做下标，用固定种子生成二十个随机索引，提取对应的 commit hash。
「种子是多少？」林博文问。
「42，」麦景行说，「固定的，这样任何人跑一遍都能复现同样的结果。」
他看着屏幕，没有说话，示意麦景行继续。
麦景行把这二十个 commit hash 列出来，打开其中三个，逐一展示提取到的注释内容。前两个是正常的函数级注释，第三个是一段多行注释里夹了参数说明。
「三种都进了测试集？」林博文问。
「对，」麦景行说，「不筛，不改，从 commit 里提取出来什么样就用什么样。」
他靠回椅背，停了大概三秒：「脚本逻辑没有问题，抽样过程可以复现。」
他把这句话记下来。助手在一旁快速记了什么，头没抬。
边上，她一直拿着笔记本在记录。这是今天的分工：会议里他来回答，她做完整记录，方便事后整理进正式文档。
「我还有一个问题，」林博文说，「你们的测试集是随机抽的，代表整个仓库的平均水平。但我们验收要看的不只是平均，是几个核心模块的表现。这几个模块的代码量是最大的，也是业务最关键的，开发团队每天都在改。」
「哪几个？」他问。
他让助手查了一下，报出了路径。三处：billing、order、gateway，都在 core 和 api 顶层目录下。
「这几个路径，」他说，「我想单独跑一轮，单独出结果，验收报告里要单独列，不能用整体平均数代替。」
他想了一下。这个要求是合理的。这几处路径每天改动量大，注释密度和复杂度可能高于平均，单独列项有利于验收时精准评估，也给了星汇云向内部说话的依据。
「可以，」他说，「我们需要这三个模块的只读权限，跑完一轮，独立出报告。时间上，两天内能给你们。」
他点了点头：「那就这样。项磊，权限今天内开好。」
项磊在旁边迅速记了下来，发消息给他们的技术侧。
他站起来，看了看桌上的截图，沉默了几秒钟。项磊没有说话，麦景行还盯着屏幕，助手的笔停下来了。
「84.7%这个数字，方法是可信的。三个追加路径的结果出来之前，我不做最终评估。」他顿了顿，「但方法通过了。」
这最后三个字说得很平，用词像在记录一个事实，听不出夸奖。
他把这句话收进去。林博文说这句话，是在开门。这套做法过了他的门槛，后面的数字他才愿意坐下来讨论。少了这句话，接下来的所有结果都是待议状态。
他们送林博文到门口。项磊把他们送进电梯，在走廊里多说了几句，他没有跟过去，转身回会议室，把桌上的水杯收起来。
她跟进来，把笔记本合上，在他旁边站定：「他最后那句话是什么意思，他们内部会怎么用？」
「意思是他认可我们的测试逻辑，」他说，「他来这里，是要确认整套流程经得起追问。今天问完了，答复通了，他就走了。」
「那追加的三个模块，是加分还是减分？」
他想了一秒：「可能两种都有。如果这三处跑出来和平均水平相当，那是额外背书。如果低很多，就要在验收之前解释清楚。」
「你觉得会是哪种？」
「要跑了才知道，」他说，「但今天他来，真正想确认的是这套做法能不能信。84.7%只是他进来的理由，不是他真正在问的东西。这个问题今天答了。」
她想了想，走回去发邮件确认权限清单。
船坞里，下午。
「周四：林博文来了，复核了抽样脚本，确认方法可复现，没有异议。追加要求：三个业务核心路径单独跑一轮，两天内出报告，验收单独列项。Sprint第九天，单项实测待跑。」
豆包那道暖橙的光：
> 林博文今天来了，走的时候最后那句是"方法可信"，这比数字好看更重要。他认可的是这套工作方式，后续那几处模块出什么结果，工作逻辑本身已经站住了。
「对，这是今天最值钱的东西。」
Claude那道蓝紫光：
> 追加核心模块单独报告，建议格式和主报告保持一致：模块路径、测试集规模、触发率、典型样例、与整体均值的对比。这样林博文拿回去向上汇报，不需要再让你们补材料。
「告诉麦景行，报告格式今天定好模板，两天内跑完填进去。」
Codex那道翠绿光：
> `/api/gateway` 是接口层，注释密度可能低于业务模块，触发率可能也低一些。如果这一块结果偏低，建议在报告里加注：接口层注释形式不同，触发率差异在预期范围内，不代表模型能力问题。提前埋好解释。
「重要，让麦景行跑之前先看一下那几处的注释密度。」
窗口合上，他把手机放下。
消息来了，麦景行发的：「我刚粗扫了一下 gateway 的目录，注释行数比 billing 和 order 少将近一半。接口层有大量代码是完全没有注释的，只有函数签名和变量名，注释触发率可能会跌得很厉害。」
他看着这条消息，没有立刻回。
gateway 触发率低，这件事刚才 Codex 就提到了可能，但"可能偏低"和"可能跌很厉害"是两回事。如果跌到 65%以下，林博文今天给出的那个认可，明天就会被一个新问题覆盖："接口层为什么这么低"。
他给麦景行发了一条：「先把三处的覆盖数字给我，今晚看，明天我来决定怎么跟项磊说。」
回复：「好，一小时内发你。」
第九天。林博文来了，走了，留下一个追加需求。这件事从昨晚的消息开始，到今天下午结束。
整个过程比他预期顺一些。他原来预计林博文会直接质疑84.7%的数字，要求用91%作为基准，或者要求补充额外的测试样本来拉高分数。结果林博文问的是方法，不是结果高低。一个技术出身的负责人，通常更在意的是"这个数字怎么来的"，而不是"这个数字够不够高"。
这也是他们没有提前隐瞒91%的原因。如果只给一个84.7%，林博文可能反而会觉得哪里有问题。两个数字都给，解释清楚差异，方法论本身经得起追问，这件事就过了。
他给麦景行发了一条：「今天报告格式我们对一下，你先把 gateway 扫一遍，预估一下结果在什么范围。」
回复来了：「好，晚上给你。」
放下手机，他把今天的会议记录看了一遍。项磊全程基本没有说话，林博文主导，这说明这次复核的决定是林博文自己提出来的，不是项磊组织的。这种情况说明林博文在内部对结果有过问，没有拿到满意的解释，才绕过项磊直接来问。
这不是坏事，林博文直接来问，比他在内部传话质疑要干净。
两天。那三个路径。