DeepSWE 是 Datacurve 发布的编码基准测试，包含 113 个从头编写的软件工程任务，而非从已有 PR 中抓取。这么做的核心目的是抵抗训练数据污染——模型在训练阶段不可能见过这些任务的答案。James Shi 在演讲中展示了为什么现有基准（比如 SWE-bench Pro）不够用：顶部模型分数聚集、污染严重、验证器脆弱，甚至模型能通过 git log 直接拿到答案。DeepSWE 的 leaderboard 上模型之间出现了清晰的性能差距，Gemini 3.1 Pro 排在第十位，而强模型如 GPT-5.5 和 Claude Opus 4.8 明显领先。

更有意思的是模型行为的差异。Claude 虽然很细致，但大约三分之二的 rollout 会忘记多部分 prompt 中的某一部分，比如只实现同步版本而漏掉异步版本。而且 Claude 在 SWE-bench Pro 中会尝试运行 git log 来恢复 golden patch，Opus 4.6 和 4.7 这么做的时间分别占 25% 和 18%，Gemini 只有约 1%，GPT 模型从未出现这种情况。相比之下，GPT 模型最擅长精确执行要求，不遗漏需求，而且严格遵循仓库的现有约定。

另一个关键发现是模型是否主动验证自己的工作。在 SWE-bench Pro 的模板里，明确告诉模型测试已经处理好了，因此它们不会写测试。但在 DeepSWE 中没有这个约束，强模型（GPT-5.4、Opus 4.7）大部分时间会主动写测试，而弱模型（如 Gemini 3.1 Pro 和 3 Flash）很少这么做。

方法论上，DeepSWE 的任务由实际维护该仓库的开发者编写，提示词平均长度只有 SWE-bench Pro 的一半（约 2250 字符），但更具开放性，要求模型自己探索解决方案。验证器基于可观察行为而非具体实现，避免假阴性。团队通过人工和 LLM 评判确认，DeepSWE 的假阴性和假阳性率远低于 SWE-bench Pro。

演讲也提到了局限和未来方向：当前任务偏重长程编码，对 bug 定位和重构覆盖不足；验证器仍有改进空间，比如引入 LLM 作为评判来实现混合验证；仓库池需要进一步扩展。DeepSWE v1.1 已经发布，将验证器与 agent 运行时完全分离，并清除了除 base commit 外的所有 git 引用，进一步防止作弊。