读者拆解我的基准测试：数据修正与开源工具Receipts的反思

当读者比作者更认真

上周，我发布了一项针对181个真实代码变更的研究。里面有一句话是错的。一位读者通过重新加总我的数字发现了它。这篇文章会告诉你：他们发现了什么，我改了什么，以及还有什么悬而未决。

这件事本身并不光彩，但它提供了一个罕见的样本——当一个基准测试的作者愿意被公开纠错时，会发生什么。更有价值的是，纠错过程暴露了一个比原始结论更有意思的统计现象。

那句话错在哪里

我原文写道：在10%的智能体编写的拉取请求（PR）中，所有测试都在旧代码上失败，唯一原因是测试文件导入了变更新添加的名称（导致文件根本无法加载），并且“在我的样本中，没有任何维护者提交看起来像这样”。

读者在阅读文章之前，先重新推导了我的结果文件。所有求和都成立。然后他们指向我跳过的一行：维护者文件列出了212个测试中有9个判定为WEAK（4%），而智能体文件列出了591个中有79个（13%）。所以这个模式在维护者一侧并非不存在。

我去看了。这九个都来自一个marshmallow功能提交，它添加了一个新的关键字参数。它的测试文件加载正常，而且同一个提交中也有确实能证明变更的测试。所以那句话原本是关于“每个测试都是WEAK”的，修正方式是如实描述维护者数据里到底有什么。按变更计，91个智能体PR中有14个包含WEAK测试，而71个维护者提交中只有1个。

文中反复出现的 WEAK / PROVEN 是作者为这项研究设定的测试质量判定档位。PROVEN 指测试在旧代码上会失败、在新代码上通过，即真正“证明”了变更的必要性；WEAK 指测试虽然存在，但失败原因并非指向被测行为本身——例如测试文件因导入一个尚不存在的名称而根本无法加载，测试死在了收集或导入阶段，而不是断言阶段。这种区分很重要：一个 WEAK 测试看似覆盖了变更，实际上没有验证任何逻辑。变更级规则倾向于把整体判定为 WEAK 的变更排除出 PROVEN，这也是读者指出“拆分的一部分是聚合规则的回读”的原因。

拆分后更有意思

读者的下一个问题：导入模式是否只会在没有其他东西证明变更时才出现？还是即使已经有证明测试，它也会出现？

把91个智能体PR按是否包含证明测试拆分：

• 有证明测试：80个中有5个携带WEAK测试（6.3%，95%置信区间2.7到13.8）。
• 没有证明测试：11个中有9个（81.8%，区间52.3到94.9）。

如果WEAK测试在所有地方都以相同的6.3%比率出现，你会预期11个中大约0.7个携带一个。实际是9个。所以大部分恰好落在没有其他东西证明变更的地方。

读者还指出一个关键问题：我的变更级规则从不把携带WEAK测试的变更称为Proven，所以这个拆分的一部分其实是聚合规则的回读。80个中的5个是唯一不受此影响的数字，因为这些PR既提供了证明，又添加了WEAK测试。这是一个编写率，它很小，但不是零。

我亲自核查了他们的统计（Wilson区间、Fisher精确检验）。它们成立。维护者一侧则是另一回事：71个中的1个只是一个事件，无论对比看起来多干净，它都无法告诉任何人基准率。

Wilson 置信区间是一种为二项比例构建区间估计的方法，不需要正态近似假设，因此在样本量小、比例接近 0 或 1 时比常见的 Wald 区间更稳健。本文中“5/80，95% 置信区间 2.7 到 13.8”就是用该方法算出的：它告诉我们若把同样的采样过程重复多次，真实比例大约有 95% 的概率落在这一范围内。样本越小时区间越宽，这正是维护者一侧“71 个中的 1 个”无法支撑任何基准率结论的原因。

Fisher 精确检验用于判断两个二分类变量是否独立，例如“是否携带 WEAK 测试”与“是否有证明测试”是否相关。它基于超几何分布直接计算精确概率，不依赖大样本近似，适合本文这种单元格计数很小的列联表。读者用它来检验 6.3% 与 81.8% 的差异是否可能仅由随机波动造成，结果支持差异真实存在。

具体改了什么

• 研究文档现在写明了以上所有内容，包括区间，并且到处使用同一个“弱仅”定义（此前我的生成器和两个结果文件与文档不一致）。
• 工具Receipts现在会打印每个PROVEN测试在旧代码上是如何失败的。另一位Reddit读者说“它变红了”还不够：你想看到测试到达了断言，而不是死在导入上。工具知道这一点，但之前没有展示。
• 我在运行之前写下了下一步：再收集几百个维护者提交，作为它们自己的一行，对两侧应用同一个选择规则。读者预测维护者比率会向智能体比率移动，因为那一个维护者事件本身就是一个churn形状的提交。这个预测现在记录在文档中，所以无论结果如何，都会对照它来解读。

作者提到“生成器和两个结果文件与文档不一致”，触及了数据流水线中常见的**单一事实来源（single source of truth）**问题：当定义（这里指“弱仅”的口径）散落在生成脚本、多个结果文件和文档中时，任何一处修改都可能造成口径漂移，最终导致正文中的数字与可复现结果不符。将定义统一收回一处并让工具从同一来源读取，是保证基准测试可审计、可复现的前提。这也是为什么读者能够先“重新推导结果文件”再定位到具体那行数据。

我的两点收获

第一：在跟某人的句子争论之前，先重新推导他们的求和，因为句子正是松散之处。第二：一个漂亮的标题数字（“10%的智能体PR”）可能既是关于你的判定规则的事实，也是关于代码的事实，而唯一发现这一点的方法，是一个不预设立场的读者。

工具是开源免费的：https://github.com/syntaxixr/receipts。研究文档中每个变更都有链接：https://github.com/syntaxixr/receipts/blob/main/docs/study.md。

提示：这篇文章是我用AI助手起草的。数字来自仓库中的研究文件和原帖下的评论线程。