一句话结论把「分阶段改需求」当考卷时前沿 Agent 的严格通过率只有 12.2%–16.3%——也就是说绝大多数检查点上它们没能做到「新功能做对、旧功能全不挂」。而把这套题跑满十遍之后最反直觉的一条是推理档位effort开满花的钱多 2.1–4.2 倍通过数却没有跟着涨。Opus 5.5 甚至从 Medium 的 28 个降到 XHigh 的 25 个。披露本文编译自 HumanLayer 仓库advanced-context-engineering-for-coding-agents的公开记录《SlopCodeBench update 10/2026》Dex Horthy 撰写2026-10-15Gabe Orlanski 与 SlopCodeBench 团队参与。基准本身由 SlopCodeBench 团队维护论文见 arXiv:2603.24755。该仓库长期发布 agent 上下文工程相关实践作者与所测模型厂商无隶属关系文中成本均为估算值而非发票作者也明确写了「单次运行不能归因」。本文未做独立复测数字以原文为准。一、这份考卷到底在考什么多数代码基准是「给一个题目看能不能写出来」。SlopCodeBench 换了个更接近真实开发的方式分阶段给需求。Agent 先写一版程序然后需求变了它要在已有代码上改再变再改。后一个检查点既测新行为也测前面所有行为有没有被改坏。原文的比喻是这对应软件真实的样子——需求在建设过程中不断变得清晰、也不断变化。于是分数分成两档这两档的差距是全文的骨架口径判定这轮区间Strict严格通过每个测试类别全过含 Regression12.24%–16.33%Core核心通过非空 Core 类别全过即可前面检查点挂了也不影响后面算分65.8%–74.0%一句话读法core 高、strict 低说明「这一步要做的事」经常能做出来但「之前做对的事」在改需求的过程中被弄坏了。作者的原话是——「Agent 把主行为做对的次数远远多于它把所有已测行为在需求变化中保持可用的次数」。对比一下时间线也有意思2026 年 5 月gpt-5.5 的 strict 是14.8%9 月这轮最高的 gpt-6 astra 是16.3%。四个月涨了 1.5 个百分点。二、这轮怎么跑的复现口径想反驳或复现先对齐这几项36 道题、196 个检查点每个设置下每个检查点等权计入通过率所以检查点多的题权重更大每个检查点基于上一个检查点留下的代码继续改不是每题从零开始10 个完整campaign完整跑完 36 题另外两个Opus Max、GPT-6.1 XHigh在采集时未跑完被排除固定v1.0题库、官方just-solve提示、seed 42、any-case运行器判定、Docker Python 3.12 uv每个「模型 × 档位」只跑一次最后这条要先记住后面所有关于档位的结论边界都在这里。作者自己写得很清楚——「一个设置只跑一次区分不了多少是运行间的波动」。三、结果十次完整 campaign图 1strict 24–32 / 196core 129–145 / 196。浅色段不是额外的严格通过。原图见文末来源。CampaignStrictStrict 率Core 率估算成本GPT-6 AstraXHigh32/19616.33%69.39%$758.62GPT-6 SOL 6Medium30/19615.31%67.86%$245.69GPT-6 SOL 6.1Medium29/19614.80%65.82%$178.51GPT-6 AstraMedium29/19614.80%66.33%$261.05Opus 5.5Medium28/19614.29%73.98%$193.47GPT-5.6 SOLXHigh28/19614.29%70.92%$753.30Fable 5.1XHigh26/19613.27%72.45%$1,550.07GPT-6 SOLXHigh26/19613.27%68.37%$517.32Opus 5.5XHigh25/19612.76%71.94%$817.04GLM 5.3XHigh24/19612.24%66.33%$365.13两个值得记住的细节榜首的领先幅度很小。Astra XHigh 是 32 个比 SOL 6.1 Medium 只多2 个检查点。core 榜首和 strict 榜首不是同一个。Opus 5.5 Medium 的 core 最高145/196但 strict 只有 28/196——它「该做的常做对」但「不该坏的容易坏」。四、发现一档位开满不保证更准三个模型同时跑了 Medium 与 XHigh这是全文最有价值的一组对照图 2三对完整 campaign 的成本与 strict 通过数。XHigh 在三对里都更贵只有 Astra 的 strict 上升。模型StrictMedium → XHighCoreMedium → XHigh成本倍数Opus 5.528 →25145 → 1414.22×GPT-6 SOL30 →26133 → 1342.11×GPT-6 Astra29 →32130 → 1362.91×三个模型里只有一个Astra在提档后变好Opus 5.5 和 GPT-6 SOL 都变差了且 Opus 的代价最高——贵 4.22 倍少 3 个检查点。作者对这条结论的措辞很克制值得照抄这不能证明「更多推理会伤害编程」。它说明的是在这几轮里更高的档位不是买严格通过率的可靠手段。同时他也留了口子单轮运行区分不了涨跌是模型效应还是波动不同档位是不同日期、不同 agent 版本跑的因此不能当成因果实验。五、发现二成本与分数几乎无关十次 campaign 的估算成本横跨$178.51–$1,550.07而 strict 通过率只横跨12.24%–16.33%。最便宜的一次GPT-6.1 SOL Medium$178.5129 个 strict——和 Astra Medium$261.05同分最贵的一次Fable 5.1 XHigh$1,550.0726 个 strict——是前者的8.68 倍成本少 3 个检查点这也解释了为什么「换更贵的档位试试」通常不是解法它买到的确定性远低于直觉。反过来说把档位当默认值而不是调优旋钮在这个基准上更容易复现出稳定结果。六、发现三检查点过了≠ 最后代码能跑这一节最容易被排行榜忽略。作者只统计每道题的最后一个检查点图 336 个题面快照里最后一步仍在失败的测试用例数1,435–2,831 个右列是「最后一步 strict 通过」的题数0–3 个。Campaign最后一步 strict共 36 题最终失败用例其中 RegressionGPT-6 Astra XHigh31,4351,178GPT-6 Astra Medium11,7471,516GPT-6 SOL XHigh11,6511,366GPT-6 SOL Medium12,8312,479GPT-6.1 SOL Medium32,7572,404GPT-5.6 SOL XHigh22,7272,376Fable 5.1 XHigh12,4632,126Opus 5.5 Medium02,5082,206Opus 5.5 XHigh12,4462,123GLM 5.3 XHigh12,7482,311三个读法没有一个 campaign 能让多数题「最终全绿」——上限 3/36。失败的大头是回归。每行里 Regression 占七到九成意味着「新需求做完了旧行为塌了」。作者提醒失败用例数不是独立 bug 数skip 单列不同题权重也不同别横向当排行榜用。七、为什么回归是主战场这不是靠猜。把三档分数摆在一起因果链其实很直每个检查点都要求 Agent 在上一版代码上继续改而不是重写需求变化往往动的是数据流新字段、新分支、新的切换条件不是孤立函数只要它顺手重构了一下「看起来该整理」的部分旧断言就有机会挂而 core 只统计本步的 Core 类别这部分损失在 core 里根本看不见。所以 core 65.8%–74.0% 与 strict 12.2%–16.3% 之间的那道 50 多个百分点的沟基本就是「改需求时把旧行为弄坏」的量。这也解释了为什么作者把结论压在那一句上Agent 把主行为做对的次数远多于它把所有已测行为保持可用的次数。对工程团队的直接含义是验收口径要写「旧的全过 新的做过」不能只写「新的做过」。前者才是用户感知到的「没坏」后者只是「这次做完了」。八、代码质量slop 覆盖率 78%–94%除了「过没过」这轮还量了「留下了多少垃圾」。先说方法上的一个决定这个决定本身值得学作者的第一反应是把随机临时文件从质量分里剔掉。Gabe 反驳得很到位——基准应该量模型在代码库里留下多少垃圾如果我们不读这些代码那就更该把它量出来。测试、草稿代码、生成副本不该因为「不是主程序」就免费放行。统计口径扫描器在每个文件里标记 slop 模式与重复代码「覆盖率」 被标记的源码行占比同一行被多条规则命中只算一次对 28 道可测题8 道因扫描器测不全被排除所有模型统一排除按SLOC 加权汇总——这一点与本系列前两篇「按题平均」不同。结论一覆盖率差异比想象大Opus 5.5 XHigh 最低77.75%Opus 5.5 Medium 最高94.25%把固定的临时目录过滤掉_work、tmp、temp、scratch、generated、build、dist以及*_pb2.py这类生成文件之后Opus Medium 降到92.90%仍是最脏这次过滤只命中了一处Opus Medium 的dynamic_buffer里45 个文件、41,265 行总量从 216,881 行降到 175,616 行对其它模型没有任何影响结论二更反直觉同一个模型XHigh 写出的代码干净约 5 倍strict 却更少25 vs 28。作者没有把这条当因果只提出一个可能解释新模型会产出新的可维护性反模式而论文那套 200 linter 是在 2026 年 3 月/5 月基于当时的 agent PR 手工整理的还没覆盖到它们。结论三关于复杂度Fable 5.1 的平均圈复杂度最低3.578,967 个可调用体GPT-6 SOL Medium 最高11.701,083 个。但作者提醒——把代码拆成更多小函数可以拉低平均复杂度并不等于更好改代码更少也不等于更好。九、这轮复盘在方法上改了什么这篇文章真正的价值不在排名而在它承认并修正了什么把残留垃圾计入评分而不是「不算主程序就不算」。理由不读代码就必须量代码。覆盖率改成 SLOC 加权。此前是「每题算一个百分比再平均」会让小题和小文件获得不成比例的权重。只报 28 道题的一致子集。8 道测不全的题在所有模型上一起排除宁可缩小样本也不引入偏差。每次结论都写明「单轮不能归因」。这条最容易被排行榜搬运时删掉。十、拿回自己仓库怎么用这五个数不上排行榜只做工程决策的话我会这么用默认档位从 Medium 起。这轮唯一稳定的模式是「提档更贵」而不是「提档更准」。要提档用自己的题量出依据。选模型看 strict不看 core。core 高只说明「这次要求的事做到了」strict 才是「没把旧行为弄坏」。把「最后一个检查点」当验收。检查点连胜不等于收尾可用这轮 0–3/36 就是证据。单次运行不下结论。至少要重复 3 次或者同设置跑两次看波动再决定换不换模型。成本是约束不是目标。8.68 倍成本换来 3 个检查点的反向差距足以说明「贵」和「准」是两个独立的轴。三句常见说法用这组数据校一下「档位拉满就完事了」三对完整对照里只有一对变好最贵的那一对Opus 5.5是 4.22 倍成本、少 3 个检查点。正确姿势是先定 Medium 跑基线再用自己的题量决定要不要提。「贵的就是好的」$1,550.07 的 Fable 5.1 XHigh 拿 26 个 strict$178.51 的 GPT-6.1 SOL Medium 拿 29 个。在 12%–16% 这个窄带里成本几乎不携带信息。「榜一就能用」榜首 Astra XHigh 与第五名的 SOL 6.1 Medium 只差 2 个检查点而后者便宜 4 倍多。这种量级的差距换一个随机种子、换一天跑都可能翻转——所以原文才坚持写「单次运行不能归因」。十一、在自己仓库搭一个小号版本半天到一天不需要 36 道题也不需要跑十个模型。想验证「我的 Agent 是不是也在回归上翻车」最小可行版本是这样挑 6–10 个已经合并的真实 PR每个都从「改之前的提交」出发把每个 PR 的意图拆成两段需求先做 A再说「另外还要 B」第二段必须碰到第一段的代码每段跑完都执行仓库现成的测试套件记录新需求的断言过没过、旧断言挂了几条、花了多少 token只报两个数strict新旧全过与core新过两者之差就是回归损失同一设置至少重复 3 次否则你无法区分模型效应和波动——这也是原文反复强调的边界。这套东西的价值不在于得出「哪个模型第一」而在于用你自己仓库的代码形状回答三个决策问题默认档位定在哪、验收要不要卡回归、换模型前需要多少重复次数。原文的 36 题之所以有说服力靠的也是这三件事做得干净题库固定、口径固定、把不能测的题一起排除。十二、边界每个「模型 × 档位」只跑了一次所有档位对比都受此限制作者本人也这么写。估算成本按推理用量推算不是发票不同日期、不同 agent 版本之间不可直接横比。题库是 36 道合成题面覆盖的是「分阶段需求 回归」这一类能力不等于你仓库里的真实任务。质量分只对 28 道题有效slop 规则集是 2026 年上半年的手工整理版本对新模型可能漏检。本文为 Part ISlopCodeBench 团队关于 slop 模式的定性分析Part II尚未发布。对做 Agent 工具的人来说最该带走的一句是作者自己的总结「我们在维护代码库这件事上确实在变好14.8% → 16.3%但没有宣传里那么快。」原文链接AI 编程评测复盘推理档位开满36 题 196 个检查点 - 汇智网
一句话结论把「分阶段改需求」当考卷时前沿 Agent 的严格通过率只有 12.2%–16.3%——也就是说绝大多数检查点上它们没能做到「新功能做对、旧功能全不挂」。而把这套题跑满十遍之后最反直觉的一条是推理档位effort开满花的钱多 2.1–4.2 倍通过数却没有跟着涨。Opus 5.5 甚至从 Medium 的 28 个降到 XHigh 的 25 个。披露本文编译自 HumanLayer 仓库advanced-context-engineering-for-coding-agents的公开记录《SlopCodeBench update 10/2026》Dex Horthy 撰写2026-10-15Gabe Orlanski 与 SlopCodeBench 团队参与。基准本身由 SlopCodeBench 团队维护论文见 arXiv:2603.24755。该仓库长期发布 agent 上下文工程相关实践作者与所测模型厂商无隶属关系文中成本均为估算值而非发票作者也明确写了「单次运行不能归因」。本文未做独立复测数字以原文为准。一、这份考卷到底在考什么多数代码基准是「给一个题目看能不能写出来」。SlopCodeBench 换了个更接近真实开发的方式分阶段给需求。Agent 先写一版程序然后需求变了它要在已有代码上改再变再改。后一个检查点既测新行为也测前面所有行为有没有被改坏。原文的比喻是这对应软件真实的样子——需求在建设过程中不断变得清晰、也不断变化。于是分数分成两档这两档的差距是全文的骨架口径判定这轮区间Strict严格通过每个测试类别全过含 Regression12.24%–16.33%Core核心通过非空 Core 类别全过即可前面检查点挂了也不影响后面算分65.8%–74.0%一句话读法core 高、strict 低说明「这一步要做的事」经常能做出来但「之前做对的事」在改需求的过程中被弄坏了。作者的原话是——「Agent 把主行为做对的次数远远多于它把所有已测行为在需求变化中保持可用的次数」。对比一下时间线也有意思2026 年 5 月gpt-5.5 的 strict 是14.8%9 月这轮最高的 gpt-6 astra 是16.3%。四个月涨了 1.5 个百分点。二、这轮怎么跑的复现口径想反驳或复现先对齐这几项36 道题、196 个检查点每个设置下每个检查点等权计入通过率所以检查点多的题权重更大每个检查点基于上一个检查点留下的代码继续改不是每题从零开始10 个完整campaign完整跑完 36 题另外两个Opus Max、GPT-6.1 XHigh在采集时未跑完被排除固定v1.0题库、官方just-solve提示、seed 42、any-case运行器判定、Docker Python 3.12 uv每个「模型 × 档位」只跑一次最后这条要先记住后面所有关于档位的结论边界都在这里。作者自己写得很清楚——「一个设置只跑一次区分不了多少是运行间的波动」。三、结果十次完整 campaign图 1strict 24–32 / 196core 129–145 / 196。浅色段不是额外的严格通过。原图见文末来源。CampaignStrictStrict 率Core 率估算成本GPT-6 AstraXHigh32/19616.33%69.39%$758.62GPT-6 SOL 6Medium30/19615.31%67.86%$245.69GPT-6 SOL 6.1Medium29/19614.80%65.82%$178.51GPT-6 AstraMedium29/19614.80%66.33%$261.05Opus 5.5Medium28/19614.29%73.98%$193.47GPT-5.6 SOLXHigh28/19614.29%70.92%$753.30Fable 5.1XHigh26/19613.27%72.45%$1,550.07GPT-6 SOLXHigh26/19613.27%68.37%$517.32Opus 5.5XHigh25/19612.76%71.94%$817.04GLM 5.3XHigh24/19612.24%66.33%$365.13两个值得记住的细节榜首的领先幅度很小。Astra XHigh 是 32 个比 SOL 6.1 Medium 只多2 个检查点。core 榜首和 strict 榜首不是同一个。Opus 5.5 Medium 的 core 最高145/196但 strict 只有 28/196——它「该做的常做对」但「不该坏的容易坏」。四、发现一档位开满不保证更准三个模型同时跑了 Medium 与 XHigh这是全文最有价值的一组对照图 2三对完整 campaign 的成本与 strict 通过数。XHigh 在三对里都更贵只有 Astra 的 strict 上升。模型StrictMedium → XHighCoreMedium → XHigh成本倍数Opus 5.528 →25145 → 1414.22×GPT-6 SOL30 →26133 → 1342.11×GPT-6 Astra29 →32130 → 1362.91×三个模型里只有一个Astra在提档后变好Opus 5.5 和 GPT-6 SOL 都变差了且 Opus 的代价最高——贵 4.22 倍少 3 个检查点。作者对这条结论的措辞很克制值得照抄这不能证明「更多推理会伤害编程」。它说明的是在这几轮里更高的档位不是买严格通过率的可靠手段。同时他也留了口子单轮运行区分不了涨跌是模型效应还是波动不同档位是不同日期、不同 agent 版本跑的因此不能当成因果实验。五、发现二成本与分数几乎无关十次 campaign 的估算成本横跨$178.51–$1,550.07而 strict 通过率只横跨12.24%–16.33%。最便宜的一次GPT-6.1 SOL Medium$178.5129 个 strict——和 Astra Medium$261.05同分最贵的一次Fable 5.1 XHigh$1,550.0726 个 strict——是前者的8.68 倍成本少 3 个检查点这也解释了为什么「换更贵的档位试试」通常不是解法它买到的确定性远低于直觉。反过来说把档位当默认值而不是调优旋钮在这个基准上更容易复现出稳定结果。六、发现三检查点过了≠ 最后代码能跑这一节最容易被排行榜忽略。作者只统计每道题的最后一个检查点图 336 个题面快照里最后一步仍在失败的测试用例数1,435–2,831 个右列是「最后一步 strict 通过」的题数0–3 个。Campaign最后一步 strict共 36 题最终失败用例其中 RegressionGPT-6 Astra XHigh31,4351,178GPT-6 Astra Medium11,7471,516GPT-6 SOL XHigh11,6511,366GPT-6 SOL Medium12,8312,479GPT-6.1 SOL Medium32,7572,404GPT-5.6 SOL XHigh22,7272,376Fable 5.1 XHigh12,4632,126Opus 5.5 Medium02,5082,206Opus 5.5 XHigh12,4462,123GLM 5.3 XHigh12,7482,311三个读法没有一个 campaign 能让多数题「最终全绿」——上限 3/36。失败的大头是回归。每行里 Regression 占七到九成意味着「新需求做完了旧行为塌了」。作者提醒失败用例数不是独立 bug 数skip 单列不同题权重也不同别横向当排行榜用。七、为什么回归是主战场这不是靠猜。把三档分数摆在一起因果链其实很直每个检查点都要求 Agent 在上一版代码上继续改而不是重写需求变化往往动的是数据流新字段、新分支、新的切换条件不是孤立函数只要它顺手重构了一下「看起来该整理」的部分旧断言就有机会挂而 core 只统计本步的 Core 类别这部分损失在 core 里根本看不见。所以 core 65.8%–74.0% 与 strict 12.2%–16.3% 之间的那道 50 多个百分点的沟基本就是「改需求时把旧行为弄坏」的量。这也解释了为什么作者把结论压在那一句上Agent 把主行为做对的次数远多于它把所有已测行为保持可用的次数。对工程团队的直接含义是验收口径要写「旧的全过 新的做过」不能只写「新的做过」。前者才是用户感知到的「没坏」后者只是「这次做完了」。八、代码质量slop 覆盖率 78%–94%除了「过没过」这轮还量了「留下了多少垃圾」。先说方法上的一个决定这个决定本身值得学作者的第一反应是把随机临时文件从质量分里剔掉。Gabe 反驳得很到位——基准应该量模型在代码库里留下多少垃圾如果我们不读这些代码那就更该把它量出来。测试、草稿代码、生成副本不该因为「不是主程序」就免费放行。统计口径扫描器在每个文件里标记 slop 模式与重复代码「覆盖率」 被标记的源码行占比同一行被多条规则命中只算一次对 28 道可测题8 道因扫描器测不全被排除所有模型统一排除按SLOC 加权汇总——这一点与本系列前两篇「按题平均」不同。结论一覆盖率差异比想象大Opus 5.5 XHigh 最低77.75%Opus 5.5 Medium 最高94.25%把固定的临时目录过滤掉_work、tmp、temp、scratch、generated、build、dist以及*_pb2.py这类生成文件之后Opus Medium 降到92.90%仍是最脏这次过滤只命中了一处Opus Medium 的dynamic_buffer里45 个文件、41,265 行总量从 216,881 行降到 175,616 行对其它模型没有任何影响结论二更反直觉同一个模型XHigh 写出的代码干净约 5 倍strict 却更少25 vs 28。作者没有把这条当因果只提出一个可能解释新模型会产出新的可维护性反模式而论文那套 200 linter 是在 2026 年 3 月/5 月基于当时的 agent PR 手工整理的还没覆盖到它们。结论三关于复杂度Fable 5.1 的平均圈复杂度最低3.578,967 个可调用体GPT-6 SOL Medium 最高11.701,083 个。但作者提醒——把代码拆成更多小函数可以拉低平均复杂度并不等于更好改代码更少也不等于更好。九、这轮复盘在方法上改了什么这篇文章真正的价值不在排名而在它承认并修正了什么把残留垃圾计入评分而不是「不算主程序就不算」。理由不读代码就必须量代码。覆盖率改成 SLOC 加权。此前是「每题算一个百分比再平均」会让小题和小文件获得不成比例的权重。只报 28 道题的一致子集。8 道测不全的题在所有模型上一起排除宁可缩小样本也不引入偏差。每次结论都写明「单轮不能归因」。这条最容易被排行榜搬运时删掉。十、拿回自己仓库怎么用这五个数不上排行榜只做工程决策的话我会这么用默认档位从 Medium 起。这轮唯一稳定的模式是「提档更贵」而不是「提档更准」。要提档用自己的题量出依据。选模型看 strict不看 core。core 高只说明「这次要求的事做到了」strict 才是「没把旧行为弄坏」。把「最后一个检查点」当验收。检查点连胜不等于收尾可用这轮 0–3/36 就是证据。单次运行不下结论。至少要重复 3 次或者同设置跑两次看波动再决定换不换模型。成本是约束不是目标。8.68 倍成本换来 3 个检查点的反向差距足以说明「贵」和「准」是两个独立的轴。三句常见说法用这组数据校一下「档位拉满就完事了」三对完整对照里只有一对变好最贵的那一对Opus 5.5是 4.22 倍成本、少 3 个检查点。正确姿势是先定 Medium 跑基线再用自己的题量决定要不要提。「贵的就是好的」$1,550.07 的 Fable 5.1 XHigh 拿 26 个 strict$178.51 的 GPT-6.1 SOL Medium 拿 29 个。在 12%–16% 这个窄带里成本几乎不携带信息。「榜一就能用」榜首 Astra XHigh 与第五名的 SOL 6.1 Medium 只差 2 个检查点而后者便宜 4 倍多。这种量级的差距换一个随机种子、换一天跑都可能翻转——所以原文才坚持写「单次运行不能归因」。十一、在自己仓库搭一个小号版本半天到一天不需要 36 道题也不需要跑十个模型。想验证「我的 Agent 是不是也在回归上翻车」最小可行版本是这样挑 6–10 个已经合并的真实 PR每个都从「改之前的提交」出发把每个 PR 的意图拆成两段需求先做 A再说「另外还要 B」第二段必须碰到第一段的代码每段跑完都执行仓库现成的测试套件记录新需求的断言过没过、旧断言挂了几条、花了多少 token只报两个数strict新旧全过与core新过两者之差就是回归损失同一设置至少重复 3 次否则你无法区分模型效应和波动——这也是原文反复强调的边界。这套东西的价值不在于得出「哪个模型第一」而在于用你自己仓库的代码形状回答三个决策问题默认档位定在哪、验收要不要卡回归、换模型前需要多少重复次数。原文的 36 题之所以有说服力靠的也是这三件事做得干净题库固定、口径固定、把不能测的题一起排除。十二、边界每个「模型 × 档位」只跑了一次所有档位对比都受此限制作者本人也这么写。估算成本按推理用量推算不是发票不同日期、不同 agent 版本之间不可直接横比。题库是 36 道合成题面覆盖的是「分阶段需求 回归」这一类能力不等于你仓库里的真实任务。质量分只对 28 道题有效slop 规则集是 2026 年上半年的手工整理版本对新模型可能漏检。本文为 Part ISlopCodeBench 团队关于 slop 模式的定性分析Part II尚未发布。对做 Agent 工具的人来说最该带走的一句是作者自己的总结「我们在维护代码库这件事上确实在变好14.8% → 16.3%但没有宣传里那么快。」原文链接AI 编程评测复盘推理档位开满36 题 196 个检查点 - 汇智网
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
