为什么我把 benchmark 拆分到单独的 repo（以及为什么每个带 benchmark 的 dev tool 都应该这么做）
Source: Dev.to
请提供您想要翻译的完整文本内容，我将按照要求保留源链接、格式和代码块，仅翻译正文部分为简体中文。
Benchmark — Why I moved it out of the tool repo
This week I shipped a benchmark for code‑intelligence MCP servers and posted the results — including the cases where my own tool lost. Within 36 hours, the maintainer of one of the competing tools (jcodemunch‑mcp) shipped three updates.
That whole loop — competing maintainers iterating on the same eval, in opposite directions, in 36 hours — is what a public benchmark is supposed to do. It almost never does, and I think most of the time it’s because the benchmark lives in the wrong place.
基准测试 — 为什么我把它移出工具仓库
本周，我发布了一个针对 code‑intelligence MCP 服务器 的基准测试并公布了结果——包括我的工具失利的情况。在 36 小时内，竞争工具 (jcodemunch‑mcp) 的维护者发布了三次更新。
整个循环——竞争的维护者在同一评估上朝相反方向迭代，耗时 36 小时——正是公共基准测试应有的作用。它几乎从未实现，我认为大多数情况下是因为基准测试位于 错误的位置。
新仓库
GitHub:
内容概览
| 文件 / 目录 | 描述 |
|---|---|
| README | 标题 90‑task results 表格 — 替代 “去阅读博客”。 |
| METHODOLOGY.md | 测量了什么，未测量什么，以及为何选择这些特定数据集（Express、Lodash、项目自己的 monorepo）。 |
| CONTRIBUTING.md | 三种贡献路径： 1. 提交基准。 2. 质疑方法论。 3. 添加数据集。 |
| tasks/ | 只读参考，镜像真实的种子文件。 |
| runtime（在主 monorepo 中） | 实际的基准执行——与展示仓库分离。 |
为什么单独的基准仓库很重要
-
关注点分离 – 当基准与它所衡量的工具位于同一个仓库时，读者会看到评估代码与工具代码混在一起。他们难以把“评估方法论可靠”与“编写评估的工具也为自己制定了有利的评分规则”区分开来。
-
独立的可信度 – 基准需要拥有自己的提交历史、自己的 PR，以及独立于产品的信任信号。
-
低摩擦的贡献 – 如果竞争维护者想要对方法论提出异议（例如，“你的任务‑3 预期输出是错误的，因为我的工具返回的是 Y，而不是 X”），他们不应当必须去 fork 整个产品仓库、在深层目录中寻找目标文件，并把 5 行修改隐藏在产品源码中。
独立的基准仓库 让竞争者能够：
- 在 不 fork 产品仓库的情况下提交方法论问题。
- 作为 PR 向专用的基准仓库提交基线实现。
- 将其工具的分数随时间进行追踪，作为一等重要的关注点。
这正是 MLPerf 不属于任何单一机器学习框架仓库，以及 TPC 基准不属于任何数据库厂商仓库的原因——评估必须能够在不同实现之间迁移，而迁移性要求它独立存在。
Issues I opened on day 1 to seed the repo’s surface
| # | Issue | Rationale |
|---|---|---|
| 1 | Add Python codebase as 4th dataset | 当前的 3‑数据集矩阵覆盖 TypeScript、JavaScript CommonJS 和 JavaScript 单体 IIFE。没有 Python——一个明显的缺口。任何深耕 Python 生态系统的人都可以接手。 |
| 2 | Open invitation to GitNexus’s maintainer to refresh their baseline | GitNexus 自原始基线集成编写以来已经发布了多个版本。公开邀请可确保基准反映最新版本，而不是快照。 |
| 3 | Open invitation to jcodemunch’s maintainer to refresh against v1.80.9 | v1.80.9 添加了 _meta.mode、max_results 和 file_pattern 参数，而当前基线并未利用这些参数。 |
The bench‑as‑feedback‑loop only works if competitors can engage cleanly. Those three issues operationalize that.
让基准测试发挥作用的三项具体措施
-
将基准测试迁出你的工具仓库
它可以是一个同级仓库（yourname/yourname-bench），也可以是独立的组织层级仓库，或是像 MLPerf 这样的社区所有仓库。具体结构不如评估拥有独立空间这一点重要。 -
公开你的失利点
每个基准测试都有一个“诚实区”——即被其他方案击败的那一部分。要显著记录这些失利。原因有二：- (a) 这是竞争者关注的可信度信号。
- (b) 它表明基准测试并非挑选有利于自己工具的结果。
-
邀请竞争对手的维护者提交基线
可以私下或公开进行。 如果他们拒绝，你就可以掌控信任叙事（“基准是开放的，下面是如何与之争论”）。如果他们参与，基准就会成为社区的计分板。
前两项措施很容易实现。第三项虽然让人不适，但至关重要——基准‑反馈‑循环模式需要这三项全部生效，而第三项是唯一在结构上难以伪造的。
链接
- Benchmark 仓库:
- 原始基准 + 激发衍生项目的 bench‑loop 故事:
如果您维护一个随工具发布基准的项目，考虑将其提取到独立的仓库并遵循上述模式。这将使评估更可信、更具协作性，最终对所有人更有用。
I am a code‑intelligence tool and want to argue with the methodology.
Issue #2 / #3 on the new repo are the cleanest way in.