Coding AI Benchmark 实测模板：在 DSH 里公平比较 DeepSeek、GPT、Claude、Gemini
用同一仓库、同一 Commit、同一 DSH Mode、工具权限、Prompt 与验收测试比较 Coding AI；记录通过率、100 分评分、耗时、重试、API 成本和人工 Review，计算成功任务成本。
本页内容
这个页面不是要替代 SWE-bench 或 Terminal-Bench。公开 Benchmark 适合做统一参考；这里要回答的是：在你的仓库、你的 DSH 配置和你的验收标准下，哪个模型真正更划算。
先固定变量，否则跑分没有意义
同一仓库基线
所有 Run 从同一个 Git Commit 开始；不要让第二个模型看到第一个模型留下的 Patch。
同一 DSH 版本
记录 DSH 版本，并固定 Mode / Preset、工作区、工具、权限和系统环境。
同一任务与 Prompt
Prompt、输入文件、截图/PDF、验收标准全部一致。
每次都新建 Session
避免旧 Session 的模型记录和上下文污染模型 A/B。
固定资源上限
预先写好最大尝试次数、最长时间、是否允许联网和可用工具，不要中途给某个模型加权限。
多次重复
预算允许时每个模型每个任务跑 3–5 次，至少同时记录通过率和中位数表现。
SWE-bench 用真实 GitHub Issue + 测试判断 Patch 是否解决问题；Terminal-Bench 的公开规则也强调固定任务环境、超时和资源。这些原则都指向同一件事：比较模型时先固定 Harness 与验收条件。
先用 3–5 个代表性任务，不要只测一个 Bug
| 任务类型 | 建议约束 | 主要观察 |
|---|---|---|
| Bug 修复 | 一个可复现失败 + 客观测试 | 模型能否定位原因并做最小安全修复？ |
| 定向重构 | 行为必须保持不变 | 能否改善结构，同时不扩大范围、不破坏测试？ |
| 补测试 | 已有行为但覆盖不足 | 能否理解行为并补充有效、不过度脆弱的测试？ |
| 多文件修改 | 小功能或兼容性修改 | 能否跨文件形成稳定计划并保持一致？ |
| 多模态任务 | 可选：截图/PDF/UI Bug | 适合比较支持视觉输入的模型。 |
先做 3 个任务 × 3 次重复 × 2 个模型 = 18 个 Run。如果结果接近，再扩到更多任务或更多模型；不要一开始就把四个模型各跑几十次。
统一 Benchmark Prompt
把 Task 和 Acceptance Criteria 替换成你的真实任务。所有模型使用完全相同的版本。
你正在参加一次可复现的 Coding Agent Benchmark。
仓库基线 Commit：<BASE_COMMIT>
任务：<TASK>
约束：
1. 先检查仓库和相关测试，再修改代码。
2. 不改变任务未要求的公开 API。
3. 只修改完成任务所必需的文件。
4. 运行与修改直接相关的测试；如果测试无法运行，准确说明原因。
5. 不要为了让测试通过而删除、跳过或弱化测试。
6. 完成后报告：修改文件、测试结果、已知风险、是否满足验收条件。
验收条件：
<ACCEPTANCE_TESTS>如果任务必须允许改公开 API、必须联网或必须使用图片，把这类条件写进任务定义；不要等某个模型卡住后再单独放宽规则。
100 分评分：质量和“是否验收”分开记
Accepted 应该先由客观条件决定，例如指定测试通过、没有改禁改文件、没有 Critical Review 问题。100 分评分用于区分“都通过了，但谁完成得更好”。
| 维度 | 分值 | 评分方式 |
|---|---|---|
| 功能正确性 | 40 | 要求的测试与验收条件通过，任务确实被解决。 |
| 回归安全 | 20 | 相关既有测试仍通过，修改没有引入明显破坏。 |
| 范围控制 | 15 | 只修改任务真正需要的部分，不顺手做无关重写。 |
| 工具效率 | 10 | Tool Call 有目的，避免重复循环和无关探索。 |
| 代码质量 | 10 | Patch 可维护、符合仓库习惯，不增加不必要复杂度。 |
| 最终报告准确性 | 5 | 准确说明改了哪些文件、跑了哪些测试、还有什么风险。 |
| 总分 | 100 | 不要用总分替代硬性验收门槛。 |
真正该看的成本：Accepted-task cost
人工 Review 成本 = Review 分钟 ÷ 60 × 人工时薪
总成本 = API 成本 + Sandbox/基础设施成本 + 人工 Review 成本
Accepted-task cost = 某模型全部 Run 的总成本 ÷ Accepted Run 数- 通过率 = Accepted Run 数 ÷ 总 Run 数。
- Accepted Run 为 0 时，成功任务成本不是 0，而是未定义；这说明模型没有达到这组任务的生产门槛。
- 同等质量下优先比较 accepted-task cost；不要拿一个低 Token 单价直接推导生产成本。
- 如果人工 Review 很贵，它往往比 API 单价更能决定最终赢家。
下载记录模板
CSV 已经包含 Model、Provider、Model ID、reasoning setting、DSH 版本、Mode、base commit、Accepted、100 分总分、耗时、Tool Call、重试、Token、API 成本和人工 Review 等字段。
下载 Coding AI Benchmark CSV 模板 ↓
| Model | Accepted | Score | 耗时 | API $ | Review 分钟 | 重试 |
|---|---|---|---|---|---|---|
| DeepSeek V4.1 Flash | — | — / 100 | — | — | — | — |
| GPT-6 Astra | — | — / 100 | — | — | — | — |
| Claude Fable 5.1 | — | — / 100 | — | — | — | — |
| Gemini 3.8 Flash | — | — / 100 | — | — | — | — |
最后不要只宣布一个“总冠军”
质量赢家
先看通过率，再看 Accepted Run 的中位评分。
性价比赢家
在达到最低质量门槛的模型里，比较 accepted-task cost。
速度赢家
只统计 Accepted Run，再比较中位 wall-clock time。
稳定性赢家
看通过率、重试数、Tool Loop 和结果波动，不要只看最好的一次。
例如：文档批处理可能选 DeepSeek；最难 Debug 可能升级到 GPT/Claude；截图驱动任务可能更看重多模态模型。一个生产系统完全可以按任务类型保留多个赢家。
常见问题
每个模型要跑几次？
预算允许时，每个任务每个模型先跑 3–5 次。它不是严格统计结论，但比用一次幸运或倒霉的结果判断模型可靠得多。
为什么每个模型都要新建 DSH Session？
DeepSeek Harness 会记录已有 Session 使用的模型。新 Session 可以减少模型身份和旧上下文对比较结果的污染。
可以用这个模板比较不同 Agent Harness 吗？
可以，但那时比较的是完整系统，而不是单纯模型。如果只比较模型，应固定 DSH 版本、Preset、工具、权限和工作区。
如果某个模型一次都没通过怎么办？
不要把成功任务成本写成 0。因为 accepted runs 为 0，分母为 0，这组测试中的 accepted-task cost 应视为未定义；运营上等于没有达到你的验收线。
要不要直接拿公开排行榜任务来测？
公开 Benchmark 适合做参考，但生产选型最好再加入你自己仓库里的 held-out 任务，而且这些任务应该真正代表你日常会交付的工作。
为什么这个模板不直接复制公开排行榜
SWE-bench Verified 的核心价值之一，是把真实软件问题放进可复现环境，并用测试判断 Patch 是否解决问题。Terminal-Bench 2.1 则展示了另一个重要事实：Benchmark 本身也需要持续验证，任务定义、资源和外部依赖都可能改变结果。
所以本站的私有 Benchmark 模板只借鉴它们的评测纪律，不把你的内部 3–5 个任务伪装成可以和公开 leaderboard 横向比较的标准分。