零代码，两次发版：一份跑挂了的报告就是贡献

我这个项目上次被外部力量推动，是一位贡献者提交了完整的测量数据——一份 schema 校验通过的 energy.json，来自别人的 GPU。而昨天，另一位复现者把项目推得更远，方向却完全相反：他的脚本从头到尾没跑起来过。没提交数据，没提交代码。一天之内，他那条死掉的脚本、两条脚注、外加一句困惑，换来了两次发布，还堵上了我们以为已经修完的最后一个 bug 活路径。

上午：一条六十秒就死掉的脚本

他是被请来做复现的，干净的 Ubuntu 22.04 沙箱，暂时没有 GPU。安全模型端到端都站住了：站点 stub 从钉死的 release 下载了 wrapper，SHA-256 校验通过。然后 bash 读到第一行就死了：

调试过 Windows 上写出来的 shell 脚本的人，都认识这行末尾那个看不见的字符。我们发布过的每一个 *.sh——wrapper、quickstart.sh 资产、站点 stub 本身——全都带着 CRLF 行尾，Linux bash 把 pipefail\r 当成了一个不存在的选项名。

校验和之所以通过，是因为校验和本来就是对着 CRLF 版本算的：完整性和正确性是两个不同的性质，一对自洽的错误文件能畅通无阻地通过前者的检查。

当天全层修复：仓库所有脚本转 LF、加了一条 CI 守卫（此后任何 CRLF shell 脚本直接 fail）、发布新的钉死 release run-v2（run-v1 保留作墓碑）、r4 资产重新发布——并且顺手抓到一个潜伏错误：SHA256SUMS.all 里 schema 那一行的哈希从来就没对上过 tag。全部记录在 changelog。

下午：验证通过了，但更重要的是那句话

他带着 v2 报告回来，逐项验证修复——十项检查，全绿：

• stub 行尾、是否钉住 run-v2 的校验和 —— 通过
• run-v2 哈希与 stub 硬编码值一致、bash -n 语法检查、--dry-run 输出执行计划 —— 通过
• r4 quickstart.sh：LF、校验和、语法 —— 通过
• SHA256SUMS.all 全部三行，从 tag 独立重算 —— 通过
• .gitattributes 规则与 CI CRLF 守卫在位 —— 通过

一份验证报告，恰恰是单人项目永远无法为自己生产的东西：报 bug 的人自己独立确认了 bug 已死。光是这一条，他这一天就值了。

但报告里还有一句，归在"两个小建议"下面：

"quickstart.sh 头部注释还写着 schema-1.3-r3" —— 他以为是个过时的示例注释，装饰性问题。

我核对了线上 r4 资产和仓库 main 分支：都写着 r4。我的第一诊断是他那边下载到了缓存。

错了。 他手上有一条能正常下载的路径——说明某处还在发 r3 的文件。顺着这条线索而不是把它归档为"用户环境问题"，追到了真正的源头：README 的 Quick start 下载命令还指向 r3 release——而 r3 的资产正是 CRLF 原版。 任何人从 README 顶部照着复制粘贴，都会在一台和任何缓存都无关的机器上，原样复现他上午的 bug。

这里值得写下来的检查清单是："我们修好了 bug"这句话通常会留下这个洞：活在一堆发布产物里的 bug，在产物里被修好时，所有指向这些产物的文档也得逐一核对——release 资产、脚本头注释、README、站点页面。四个地方，我们查了三个。

晚上：三处小修，一处永久

他的两条实质建议都采纳了，连同 README 修复一起发布：

1. Quick start 现在钉 r4——通往 CRLF bug 的最后一条活路径关闭；
2. quickstart.sh 和 README 写明 sha256sum -c SHA256SUMS.all 必须在哪里跑——对应 tag 的 clone 根目录，不是 release 下载目录，因为清单里是仓库相对路径。这个坑他自己第一轮验证就踩过，而且他的诊断完全正确：记录为使用说明，而不是 bug；
3. CONTRIBUTING 新增发版 checklist，第一条规则就是他的建议：用用户的下载方式拿到发布字节，在干净的 Linux 容器里 dry-run——正是当初让 CRLF 溜出去的那个缺口。这条规则现在是永久的，它存在的理由就是他的 bug。

什么算贡献

这部分值得说出来，因为它决定一个单人项目能吸引到什么。

到目前为止，他贡献的是：一次失败的运行、一条关于校验命令该在哪执行的脚注、一句归因错误但症状正确的困惑。没有代码，没有测量。在默认定义下——那个数 commit 和数据集的定义下——什么都不算。

在默认定义下，这个项目最有价值的两次外部输入都是不可见的：这一次，和八月的一次笔记本测量。前者从来没产出过一个数字；后者一个 run 产出了一个数字。它们的共同点是：项目之外的人真的去做了那件事，并且如实报告了发生的一切——包括那些看起来像自己失误的部分。一条死掉的脚本是信息。一个看起来像缓存的诡异下载是信息。大多数用户撞上任何一种都会直接离开，维护者永远不知道入口的漏斗是坏的。

对维护者，操作层面的教训同样短：把每一份"跑不起来"的报告当成免费审计，把报告里每一个奇怪的细节当成线索对待，直到证明它不是。 我一开始把他那句 r3 归档成了他那边的缓存问题。去查证的成本是五分钟。不查的代价，是每一个顺着 README 走进来的用户，在 r3 链接的余生里。

做下一个——尤其是跑挂了的那位

他的 GPU 复现已经排上日程：energy.json 生成、schema 校验、overlay 叠加、与数据集 v1.1.0 的同配置比对。等它落地，那将是任何定义下都算数的贡献。

但它不需要落地才算数。如果你跑了那条一键命令然后它死了——那本身就是报告。 开一个 issue，写上你输入了什么、返回了什么，尤其是那些你以为是自己搞错的部分。仓库的 CONTRIBUTING 列了五种贡献方式，这篇笔记是第六种的证据：让这个项目在你面前坏掉，然后告诉一个人。

注：本文涉及 EcoCompute 项目（LLM 推理能耗的实测数据与方法论，数据集见 Zenodo DOI 10.5281/zenodo.19647290）。MLCommons, MLPerf and MLCube are trademarks of MLCommons Association, used nominatively.