方法论 · v1 · 2026-05-29
同题、三工具、一套验收门槛
TripleBench 用同一个具体任务去测 Codex、Claude Code 和 Gemini CLI，并记录发生了什么。这页是规则书。如果以后某篇文章和这页冲突，以本页为准——请来开 issue。
1. 任务怎么选
一个任务能上 bench，需要同时满足四个条件：
- 真实。来自公开开源仓库：真实 issue、真实 PR review、真实重构。不接受合成玩具题。不接受 LeetCode 风格的算法题——三家 agent 训练时几乎肯定见过。
- 可复现。起点 commit 是 pin 住的。仓库是公开的。任何人可以 clone 下来用同一基线重跑。
- 有客观成功门槛。要么有一组 agent 没见过的留存测试集会在它们改完代码后跑过，要么有可记录的手动验证（比如"构建通过且原来失败的那个 case 现在过了"）。
- 有代表性。任务应该长得像本周某个真实工程师真实在做的活——重构、修 bug、接功能、做迁移——而不是为秀肌肉造的场景。
2. 每个 agent 怎么跑
- 固定 agent 版本。每次都记录 Codex、Claude Code、Gemini CLI 的精确 CLI 版本号 / release tag。
- 把工作目录重置到 pin 住的基线 commit。不留前一次跑的残留。
- 粘贴同一个 prompt。逐字一致。不会为某家工具改措辞让它好过一点。
- 让 agent 自己跑。我们不"救场"。除非 agent 主动问，否则不补充上下文。
- 停止条件：agent 自己声明完成；agent 卡住问了我们不会回答的问题；或者撞上 60 分钟的墙钟上限。
- 保存完整 transcript、最终 diff、耗时。跑验收门槛，记 pass/fail。
3. 评什么
每次跑产出 benchmark 表里的一行。列如下：
| 维度 | 测的是什么 | 怎么打分 |
|---|---|---|
| 编码执行 | agent 是否正确地改了代码并自己验证？ | 留存门槛 pass/fail。如果差一个具体 check 就过，给部分分并备注。 |
| 研究质量 | 任务要求理解上下文（issue 线程、文档、相邻代码），agent 是否找到并用对了材料？ | 对照每个任务公开的 checklist 打 0-100 编辑分。checklist 也公开。 |
| 工作流连续性 | agent 是否保留状态、能从阻碍中恢复、能干净地交接？ | 看 transcript 给编辑分：跑到哪里有没有总结，仓库有没有留在可工作状态，阻碍解释清楚没。 |
| 成本透明度 | 能不能从这次跑的信号推算下一次大概要花多少？ | 标"透明 / 部分 / 不透明"。透明意味着工具在跑的过程中报告了 token 数或会话分钟数。 |
4. "适合做什么"那一行
每家工具会得到一句一行的"适合做什么"评语。这是编辑判断，不是定量指标。它捕捉的是这次跑的总体感受，不只是过没过门槛。我们有时会判错；随着跑次累积，这些评语会被修订。
5. 每次跑公开什么
- 精确的 prompt。
- pin 住的 commit hash 和公开仓库链接。
- 每家 agent 的版本号。
- 完整 session transcript（或链接到完整 transcript，太长时）。
- 验收门槛，如果有测试集就一并公开。
- 每家 agent 产生的 diff。
- 耗时和任何报告出来的成本信号。
- 每个维度的得分。
- 简短的编辑结论和"适合做什么"一行评语。
6. 我们刻意不做什么
- 不删失败的跑次。失败的发布详尽程度和成功的相同。
- 不把"主观感受"塞进结论里——除非能锚定到 transcript 里的某个具体时刻。
- 不会把无关任务的分数平均成一个"总排名"。每个任务各自报告。
7. 利益冲突声明
我们独立完成评测，不接受被 benchmark 厂商提供的金钱、免费额度、免费座位、或者发布前预览权限。如果有一天这件事变了，我们会在这页上写清楚——在受影响那篇报告发布之前。这个站靠数字小商品（原始 prompt、CSV 导出、操作笔记）和未来可能的付费订阅赚钱，永远不靠指向被测工具的联盟链接。
8. 为什么我们坦白 AI 协助这件事
这个站由 zgy 运营。AI 工具帮忙组织数据、起草文稿，但实际 benchmark 由真人跑、每个公开分数由真人审、上线前由真人签字。我们说在前面，是因为我们觉得另一种做法——把 AI 策展的站伪装成真人写的——是对开放互联网的污染。AI 擅长把 benchmark 数据组织成可读散文；它不擅长判断哪个 benchmark 值得跑。人在闭环里这件事，才是让这个站值得读、而不是又一个内容农场的原因。
9. 这套方法论的版本
这页是方法论 v1。当我们修改评分表、权重、或发布规则时，会切一个新版本、归档旧的，并在每篇报告里标注它当时遵循的方法论版本。已发布的旧分数不会被悄悄重打。
最近更新：2026-05-29 · 不同意？欢迎在 GitHub Issues 里讨论。