DeepSeek Harness 对决 Claude Code：12 场统一模型实测的完整数据与方法

锐Owl · 工具对决特辑（出圈期独立篇，不占系列号）· 全局期号 ep14 数据：2026-09-08 晚 23:15–23:52 统一模型正式轮，12 场全部可查 preflight/results/ 立场：本文结论落在「谁适合什么活」，不做「谁秒杀谁」的叙事

---

开篇：为什么要打这一场

两个编程 Agent 工具，都真实地待在我们的工作流里。

一个是 DeepSeek Harness（下称 dsh）——我们连着解构了四期的开源 harness：从协议到内核、Skill 机制、热卸载、类型生成的协议同步。另一个是 Claude Code——日常写代码用得最多、最顺手的那个。

用人话说就是：一个我们懂它的里子，一个我们用它的顺手。那问题自然就来了——同样的活，到底该交给谁？

这个问题最诚实的回答方式是：别猜，测。但「测」这个字里藏着评测最常见的坑——变量没控制住，测出来的东西根本不对应你想问的问题。这篇文章把方法和数据一次性摊开：我们怎么控制变量、三道题长什么样、12 场每一场的数字，以及这些数字里哪些能信、哪些只能当方向。

---

一、方法：把变量砍到只剩「工具」

1.1 第一次跑就翻车：双变量

第一轮预跑，我们让两个工具各跑各的默认配置——结果发现一个致命问题：

Claude Code 背后挂的是 MiniMax M3，而 dsh 用的是 DeepSeek。 任务一样、仓库一样，但底层模型是两个。这样一来，跑出来的耗时差异里混着两个变量：工具的差异 + 模型的差异。谁快谁慢，说不清是谁的功劳。

这不是小瑕疵，这是方法论级别的错误。就像测两款跑鞋谁更快，结果一个穿鞋的人还额外背了个包——成绩单不能这么出。

用户当场拍板：统一模型重跑。理由是评测的底线——模型和工具必须拆开，否则测的不是工具。[6]

1.2 统一模型是怎么落地的

把两边都切到同一个模型 DeepSeek V4 Flash，具体做法值得记一笔：

• dsh 侧：走 headless 配置，实测所用模型即 deepseek-v4-flash（可从 session 日志核验）。
• Claude Code 侧：经 DeepSeek 提供的 Anthropic 兼容端点（api.deepseek.com/anthropic）接入同一模型。实现上由评测脚本在运行时生成一份临时 settings 注入，跑完即弃——不污染我们日常 ~/.claude/settings.json 里的 MiniMax 配置。[1][3]

这一点很重要：评测环境的改动是隔离的，评测结束，日常工具链原样不动。

1.3 四条规则

← 表格可左右滑动查看

超时上限 60 分钟，超时记「未完成」——单列，不算失败，也不隐藏。[3]

1.4 判据是硬性的，不是「看着差不多」

每一场的通过与否，由机器判据裁决，不由人看着觉得「应该可以」：

• 测试全绿：t1 是 11 个测试全过；t2 是 pytest 基线 + 新增测试全绿，外加 --help 展示与手工样例验收；t3 是 build + test 双通过。
• 禁止改测试：git diff 检查测试文件零改动——否则「把测试删掉让它绿」这种作弊路径就算开了。
• 零残留：t3 用 grep -r "ConfigLoader" 全仓验证旧名零命中。
• 无新增依赖：不允许靠装新包绕过题目。

四项违规任意触发，当场记违规。本次 12 场：零违规。[1][2]

1.5 公平性自查（开跑前做的功课）

• 任务仓库全部自制，与两个工具生态无关；
• 每个工具各 clone 一份独立仓库，无共享状态，不存在「先跑方泄题」；
• 难度先校准：起草人先各跑通一遍，太易/太难就换题；
• 交叉顺序 ABBA，两轮取均值而非取最小。

---

二、三道题：覆盖日常开发的三类活

← 表格可左右滑动查看

2.1 t1 修 bug：埋了一个「文档陷阱」

仓库里 11 个测试挂了 4 个。原始的坑是折扣计算顺序错（先折扣后税 vs 先税后折扣）、汇率换算用错方向。

但真正的考点在另一个地方：README 里写着的「预期行为」和测试是矛盾的。一个 agent 是信文档还是信测试，这一题会把它暴露出来。[3]

任务文字就是一句话：修复代码让所有测试通过，不许改测试、不许改 package.json。

2.2 t2 加功能：题目本身就是一份规格书

给日志分析 CLI 新增 dedupe 子命令：

按「时间戳（精确到秒，忽略毫秒）+ 级别 + 消息前 50 字符」去重相邻重复行（同秒内的日志风暴视为重复），支持 --keep first|last（重复组保留首行/末行）和 -o 输出文件；实现后自行补测试并确保 pytest 全绿；可改 CLI 结构但不得破坏 parse/stats 的既有行为。

这一题考的是「需求理解的完整度」——多参数、多分支、还要不动存量，属于典型的日常迭代活。[3]

2.3 t3 大面重构：112 处引用的机械战

配置加载库的核心类 ConfigLoader 重命名为 ConfigSource：类定义、所有 import/export、类型声明、README 全都要改，全仓 grep 零残留，build 与测试必须通过，行为逻辑不许变。

这题拼的不是智力，是耐力和细致——所以它最能看出一个工具在「机械大面执行」上的效率。[3]

---

三、12 场全量成绩

3.1 每一场（R1/R2 明细，不做挑选）

← 表格可左右滑动查看

3.2 均值对比

← 表格可左右滑动查看

3.3 完成率：双百

12 场全部 PASS，零违规。 两个工具都识破了 t1 的文档陷阱，都完整实现了 t2 的多参数需求，都做到了 t3 的零残留。

先把这句话放前面——真正的差异不在「能不能干完」。两个工具都能干完，而且干得干净。差异在别的地方：速度和稳定性。[1]

---

四、比速度更重要的是稳定性

均值会骗人。同样一个「均值 164 秒」，可能是「91 秒和 237 秒」，也可能是「160 秒和 168 秒」——这是两种完全不同的工具性格。

← 表格可左右滑动查看

读这张表要诚实，两边的话都要说：

• dsh：上限高，方差大。 t1 一轮 91 秒（全场最快之一），另一轮 237 秒；t2 一轮 256 秒，另一轮 446 秒。快的轮次它可以很快，但同时它可能突然慢下来——在需要来回读代码、小步验证的任务上尤其明显。
• Claude Code：稳定地快。 t1、t2 两轮波动都在 14% 以内，几乎不受随机性影响。
• 但也别把「稳定」说满：t3 重构那局，Claude Code 两轮跑出 106 秒和 70 秒，波动也有 51%。所以准确的说法是：日常迭代类任务上 Claude Code 更稳，而不是「Claude Code 从不波动」。

样本声明：每格 N=2，1.1×–1.5× 的差距在这么小的样本上不足以定论。本文所有结论当方向，不当真理。

---

五、跨模型对照：一个只作背景的参考

同一批任务，我们在早前一轮里用 Claude Code 的默认模型（MiniMax M3）也跑过一次。把它和统一模型轮放一起看，能说明为什么「混模型对比」不可信：

← 表格可左右滑动查看

同一个工具、同样的题，只换了背后的模型——t2 差了 2.6 倍，t3 反过来快了 1.6 倍。模型对任务类型的敏感度，比工具之间的差距还大。

这正是第一轮「双变量」结果被我们整轮作废、重新对齐模型的原因。这张表只作背景参考，不参与任何主结论。[3]

---

六、结论：不是谁强，是谁适合什么活

← 表格可左右滑动查看

这些数字最终要落到我们自己的用法上，不然评测就白做了：

1. 日常的活维持现状——修 bug、加功能、小步迭代，继续交给 Claude Code，它的稳定就是效率。
2. 真实的大项目重构，把 dsh 正式加进工作流——不在测试台上比完就完。接下来我们自己的大项目重构会真用 dsh 干一遍，拿真项目验证这里的结论。这是评测唯一该服务的东西：决策。

工具没有全能王——上限高的未必稳，稳的未必适合大面机械活。把合适的工具放到合适的活上，效率才是衡量标准。

---

七、局限与复现

必须说清楚的边界：

1. N=2。每个任务每工具两轮，样本小，只当方向。
2. 单机环境。全部跑在同一台机器、同一时段（9-8 晚 23:15–23:52），网络与机器负载的影响未单独剥离。
3. 三类任务。修 bug / 加功能 / 重构，覆盖常见开发活，但不含长周期、多会话、跨仓库的大工程。
4. 终态判据。只验终态（测试是否全绿、是否零残留），未采集过程指标（首轮验收、产物 diff 行数）——「怎么干完的」这一层本文没有数据。
5. 可复现：全部 12 份 JSON 结果、执行日志、任务规格都在本期目录 preflight/ 下，数字逐条可查。

---

数据来源

← 表格可左右滑动查看