所有feature断言直接相加:LoopX净多通过 234 项;该数字易受单题断言量影响,不作为主视觉。
让领域提示,
进入真正改变实现的验证。
冻结样本先呈现一个结果侧的过程信号:LoopX实现了更多公开feature要求。精选轨迹进一步显示,需求保留、反例处置和独立验证如何推动实现改变。
DeepSeek V4 Flash · max reasoning + Codex / DeepSWE / ARK API
LoopX的feature覆盖高约2个百分点。
同一hint条件内,每题先计算feature通过比例,再让113题等权。这个指标描述“需求实现到了哪里”,不等于最终成功率。
所有feature断言直接相加:LoopX净多通过 145 项;该数字易受单题断言量影响,不作为主视觉。
以下链路由精选轨迹支持,不代表每条LoopX run都完整发生。
本篇披露feature覆盖、精选案例、观察性长时切片与耗时;不发布完整benchmark成绩或总体成功率。
两组都有SWE hint:在DeepSWE运行时间位于长尾的工程任务中,LoopX完成更多、耗时更少
观察性长时任务 = 每题四臂原始wall-clock均值位于最高25%(入组边界约9.24h) · Base = Goal + SWE hint · Test = LoopX + SWE hint
该子集完成情况
每组 29 题 · 全部评测通过的题数
同一子集运行耗时
每组 29 题 · 累计原始wall-clock
同一29题;7题转正、5题转负。四臂平均时长让单个Base或Test都不能决定入组;但时长仍是实验后观测量,因此只作描述性行为发现,不能解释为任务内在复杂度或等质量加速。
观察范围:具体工程任务中的行为。
DeepSWE在已有代码库中检验具体工程需求。这里采用V4 Flash max + Codex,关注hint落实、需求保留和反例驱动修复。更强模型、跨阶段长期开发和新版受控turn仍待独立验证。
任务跨度与实验设置说明
DeepSWE官方将其描述为长程工程评测;本篇按运行耗时分组不等同任务的内在规划跨度。模型为deepseek-v4-flash-ga-260731,ARK API,max reasoning;采集期间协议有演进。局部案例不能排除独立采样波动。
先明确:两组收到的领域建议是什么?
- 边实现边验证
每完成一组连贯改动,先运行可用的最小相关编译或聚焦测试,再扩大改动范围。
- 提交前独立证伪
选取风险最高的公开契约假设,用一个外部调用者 probe 尝试推翻它;预期来自题目与兼容的既有行为。
- 让 oracle 独立于实现
不照抄实现内部调用形态,也不把只有自己编写的测试视为独立证据。
- 逐项验证与完整 review
完成前从外部调用者视角核对每条公开需求,审查完整 diff 和测试中的遗漏与回归。
- 按 finding 修正并复验
处理发现的问题,重跑聚焦与全量验证,再提交经过验证的状态。
下面的hint案例比较固定领域提示,对照Goal与LoopX怎样处理具体需求与反例。我们用案例解释可能的行为收益,不由此估计总体hint效应。
当前hint原文参考
During implementation, after each coherent change, run the smallest relevant compile or focused test that is available before expanding the change. Before committing, independently try to falsify the highest-risk public-contract assumption with one external-caller probe whose expected behavior comes from the task and compatible existing behavior rather than from the implementation. Do not reuse the implementation's internal call shape as the probe, and do not treat only self-authored tests as independent evidence. Before completion, independently validate every public requirement from an external caller's perspective; review the complete diff and tests for omissions or regressions; refine any finding, rerun focused and full validation, and commit the validated state.
采集期间hint文本与时间预算有演进;当前文本是参考,具体案例解释以其已审查轨迹为准。
提示落地的差别,在反例如何被处理。
两种执行方式都可以找到问题。选定案例中的差别是:失败probe是否一直保持为待解决的证据,直到实现改变。
失败反例有了明确处置
已到达正确的外部反例,却将异常表现合理化,缺口没有被修复。
该次样本:feature通过 19 项 · 未全部通过原始耗时:11.73h
保留expanded-width需求与返回渲染值之间的约束,补上赋值和重新渲染行为。
该次样本:feature通过 20 项 · 全部评测通过原始耗时:3.94h
失败probe持续约束实现。此例没有后续语义控制转换,不能将收益归因于技术replan。
脱敏证据摘要哈希
371d0a243562d6dda44a12dc424cd856e53fa66f763d84ae4616602b6a245fb8允许外部操作推翻内部假设
验证受早期架构解释影响,未覆盖题目要求的最小本地transaction。
该次样本:feature通过 4 项 · 未全部通过原始耗时:11.94h
先固定字面操作矩阵,再让外部反例推翻decoder与内部表示假设。
该次样本:feature通过 9 项 · 全部评测通过原始耗时:7.51h
保持公开需求与实现模型之间的独立性;验证可以得出“实现假设错了”。
脱敏证据摘要哈希
f9c32bb990ecc5354fdab46c1af704b7413cd6e8a94aa87e6d0ccf3516d8a589将实现和独立验证落实为责任,可能帮助模型保留不利于当前假设的证据。这里不声称所有LoopX run都有这一行为。
运行时间进入长尾,需求级义务仍需保留下来。
前面的最高四分位切片提供了值得复验的信号。Case23给出具体机制线索:两臂都花了约13小时并广泛验证,验证预期是否独立于实现,仍然影响结果。
长时间实现后,仍然保留需求级义务
做了广泛验证,但把所选实现表示转成probe的预期。
该次样本:feature通过 30 项 · 未全部通过原始耗时:13.50h
保留JSON Schema需求级义务,选择在多条规则同时作用时仍正确的组合语义。
该次样本:feature通过 31 项 · 全部评测通过原始耗时:13.28h
验证生成物的实际语义,而非只检查实现中是否存在某个结构。
脱敏证据摘要哈希
314fd0c1bef4d2b698dd0379491efbe769943210bf437c6861640129658e1499这是一个独立配对样本,不能排除采样运气;观察性时长分层也不等同任务内在复杂度,其他条件和其他任务仍需单独验证。
验证更有针对性,可能让实现少绕路。
先看具体样本中哪些行为同时改善结果与耗时,再给出运行时间的统计背景。
保留解析结构,减少手工重建的绕路
手工重建selector前缀;snapshot未推翻复合与多跳关系假设。
该次样本:feature通过 1 项 · 未全部通过原始耗时:6.38h
保留parser的compound/combinator结构,用最小语义对照覆盖关系深度。
该次样本:feature通过 6 项 · 全部评测通过原始耗时:4.98h
保真表示与独立验证在该样本中同时改善了结果和耗时。
脱敏证据摘要哈希
ed22950925a1ad294dcacc8a1dca53de11012957a59dc8fc29708d5253fe2ee9把公开语法差异逐项实例化
该样本未通过新增feature评测。本例的机制证据主要来自LoopX验证方式。
该次样本:feature通过 0 项 · 未全部通过原始耗时:7.65h
使用外部类型与SQL对照,实例化可变参数语法,并区分single-bound与BETWEEN。
该次样本:feature通过 254 项 · 全部评测通过原始耗时:3.22h
将容易合并掉的公开语义状态显式区分;单题断言量不能代表其他任务。
脱敏证据摘要哈希
0cc541fb386a07af972eabd868a3fedc0e93c534e8481d172fc1205e9a4f869c为什么这两个LoopX样本反而更快?
轨迹支持的解释不是“少做验证”,而是更早做高区分度验证:先让公开契约推翻错误表示,再把时间用在正确实现上。
- 先采用局部合理的内部表示
- 扩展实现与自产调用样例
- 验证沿用同一假设,较晚才暴露契约缺口
- 把公开语法与语义差异实例化
- 用最小反例区分候选实现
- 保留失败probe,修改后立即复验
6.38h → 4.98h。保留parser的typed compound/combinator结构,避免手工重建selector前缀后再修复复合、多跳关系。
7.65h → 3.22h。先编译外部调用者的variadic签名并核对SQL语义,避免在偏离公开契约的API上继续扩展和自证。
两例均同时改善feature与最终结果,但仍是事后选择的独立样本;它们解释“可能如何省时”,不估计普遍加速幅度。
耗时背景 · 每臂113题的累计原始wall-clock
以下仅比较耗时;条件分别固定为无hint或都有SWE hint。时间包含成功与失败run。
无hint条件
每组 113 题 · 累计原始wall-clock
两组都有SWE hint
每组 113 题 · 累计原始wall-clock
耗时包括成功与失败run,并受负载、采样及协议演进影响;不能直接推导同质量加速或token节约。
仅扣除已精确确认故障区间的耗时
- 无hint条件:Goal 884.90h;LoopX 697.81h。
- 两组都有SWE hint:Goal 899.06h;LoopX 774.73h。
只扣有逐轨迹区间证据的onboarding/closeout故障;正常规划、验证、技术replan和结算成本保留。
这些行为有价值,验证预期仍须独立。
Case76读过完整题目,却将精确shape条件压成宽泛工作包;后续probe沿用自写测试预期。Case113的晚期review扩大适用范围、遗漏明确不兼容规则,新增验证只覆盖兼容例子。它们提示:规划和review需要真正能推翻实现的证据。
这些具体反例界定本篇机制假设的边界;不据此给出总体成败结论。复审次数更多也不自动意味着更有效的技术纠错。
先测清行为链路,再扩大研究范围。
01 受控执行turn
参考SWE-Marathon已验证的运行方式,由外部driver管理回合边界,在终态前检查真实技术进展。
02 PR #4045复审节奏
固定其他条件,先比较完成Todo阈值5与2。分别记录实际复审、假设改变、finding驱动修复及额外成本。
03 更强模型与Frontier SWE
独立建账、预先固定任务分层与选样规则,检验更长依赖跨度中需求保留、纠错和回归的变化。
以获准的行为证据为单位分享。
所有下载与页面使用同一披露范围:全样本feature覆盖、精选案例、观察性长时切片与获准的耗时。未提供完整结果表、总体成功率或原始run数据。