模型在别人的仓库里很强，在你的代码里呢？SelfBench 本地化评测实战
“这个模型在 SWE-bench 上表现很好”，并不等于它能稳定修改你的单体仓库。不同项目的构建脚本、测试习惯、领域术语和隐藏约束差异很大。SelfBench 的思路是把团队自己的合并 PR 变成评测任务，再比较 Agent、模型、Harness 和推理设置在真实代码上的准确率与成本。
它评测的不是一道公开题
SelfBench 的核心素材来自目标仓库已经合并的 Pull Request。系统从变更前的提交重建任务：PR 请求成为 Agent 要完成的指令，作者 Agent 负责生成隐藏测试和参考实现。一个任务需要通过多重检查：没有参考实现时测试应失败，应用原始实现后应通过，重复运行仍应通过，并且还要经过独立审查。通过后，任务会以 Harbor 原生任务的形式进入运行阶段。
这套流程比直接拿公开 benchmark 排名更贴近工程现实。它测试的是“模型是否理解这套代码库的约定”，而不是“模型是否记住某类通用题型”。不过，生成隐藏测试本身也需要审查，不能把自动生成的测试当成绝对真相。
从仓库到结果的完整路径
SelfBench 的使用界面分成几个阶段：
- 用 GitHub 登录并连接一个仓库。
- 在 Batch Generation 中选择要生成的 easy、medium、hard 任务数量，或者在 Dataset 中挑选具体 PR。
- 打开每个任务，检查指令、环境、隐藏测试、参考补丁和流水线产物，然后批准或拒绝。
- 在 Run 中选择模型、Harness 和 sandbox，启动批量执行。
- 在 Results 中比较准确率与每任务成本，并查看单次运行的 transcript 和分数。
- 如果仓库适合公开发布，再把结果发布到公开排行榜。
批量生成可能需要数小时，而且关闭页面后仍会继续运行。因此，第一次试用不必一次导入整个仓库。选择一组已经合并、测试稳定、难度不同的 PR，先验证数据集质量，再扩大规模。
为什么要同时看准确率和成本
只看成功率，容易选出一个“很聪明但很贵”的设置；只看价格，又可能把大量失败转嫁给人工。SelfBench 的结果图同时放置准确率和成本，并绘制 Pareto frontier：如果某个设置在准确率和成本两个维度都被另一个设置超过，它就没有明显的决策优势。
实际比较时，可以把候选配置分成三组：日常修复使用低成本模型，复杂重构使用高准确率模型，最后保留一个失败后人工接管的兜底配置。不要把公开仓库排行榜的结论直接复制到自己的项目中；同一模型在不同代码库上的排序完全可能改变。
本地开发和自托管注意事项
项目 README 给出的开发环境需要 Bun 1.3.14 或更高版本，以及 Docker Compose：
bun install --frozen-lockfile bun run validate
启动包含 API、Worker、Temporal、Postgres 和本地 Docker sandbox 的完整开发栈，可以使用：
cp .env.example .env SELFBENCH_PUBLIC_URL=https://your-tunnel.example docker compose --profile sandbox up -d --build docker compose port api 8080
SELFBENCH_PUBLIC_URL 应设置为浏览器实际打开的 origin，例如隧道或反向代理地址；GitHub OAuth 回调则需要登记对应的 /auth/github/callback。这些命令适合开发和自托管验证，不代表生产部署只需要 Docker Compose。项目的参考部署还涉及 GCP Cloud Run、GKE Autopilot、Temporal、Cloud SQL 和 GCS，生产环境应按基础设施文档配置。
另一个容易忽略的边界是凭据。模型和 sandbox 使用组织自己的密钥，先为测试仓库准备低权限凭据，避免评测任务意外访问生产资源。隐藏测试、参考补丁和运行 transcript 也可能包含私有代码，不应在没有审查的情况下发布到公开排行榜。
适合什么团队
如果团队已经有一批高质量 PR，却不知道 Claude Code、Codex 或其他 Agent Harness 哪个更适合自己的代码库，SelfBench 提供了一条可重复的测量路径。它尤其适合需要回答“准确率提升是否值得额外成本”的工程团队。
它不适合拿来替代单元测试、代码审查或上线前验收。SelfBench 衡量的是 Agent 在一组构造出的任务上的表现；真正的工程质量仍需要维护者检查测试覆盖、权限边界、性能回归和长期可维护性。
更稳妥的落地顺序是：先选十几个代表性 PR，人工审查生成任务；再用两三个模型做小规模 Run；最后根据准确率、成本和失败 transcript 调整 Harness。这样得到的不是一个脱离上下文的模型排名，而是一份对当前代码库真正有用的决策依据。
相关链接