SlopCodeBench：Fable 5、GPT‑5.6 Sol 与 Kimi K3 的长程编码复现实验

测试环境

• 基准：SlopCodeBench，任务不会一次性公开全部需求，而是在多个 checkpoint 逐步追加要求，测试代码库随时间退化的风险。

• 规模：6 个 challenge、30 个 checkpoint，每个 checkpoint 使用新上下文；四个模型各跑一次。

• Harness：Fable—Claude Code 2.1.219；Sol—Codex CLI 0.145.0；Kimi K3（Baseten/Modal）—OpenCode 1.18.0。

• 评分：strict pass；当前 checkpoint 及继承自此前 checkpoint 的所有黑盒测试都通过才算通过。

输入/配置

• xjq：5 个 checkpoint，从 XPath/XML/HTML/JSON 查询扩展到 selector、结构化输出和 union。

• file_backup：4 个 checkpoint，从 YAML 备份调度扩展到 archive、verify、目标和增量状态。

• dag_execution：3 个 checkpoint，任务流水线 DSL、缓存、动态缓存覆盖。

• circuit_eval：8 个 checkpoint，电路解析、向量、三值逻辑、格式、统计、等价性和优化。

• code_search：5 个 checkpoint，多语言文本/正则/结构化搜索、AST 选择器和修复。

• etl_pipeline：5 个 checkpoint，JSON ETL、分支、定义、参数化调用、命名空间组合。

• 作者公开了全部 30 个 checkpoint 的压缩版要求、模型顺序、隔离上下文和黑盒判定机制。

结果数据

• 作为平局打破条件，Fable 16 个 isolated pass，Sol 14 个。

• Sol 在最终快照触发至少一个 slop 规则的代码行比例约 95%，Fable 86%，Kimi K3 为 82%/79%；作者认为规则可能过于激进。

• Sol 在持久 Python 测试文件中留下 1,318 SLOC；其他 Agent 使用 shell、fixture 或临时文件，不能直接横比。

• 作者强调这是每个模型/提供商一次运行的方向性结果，不能当统计显著排名。

结论

在逐步泄露需求、继承旧缺陷的长程编码任务上，Sol 与 Fable 处于同一严格通过率，但所有模型都随 checkpoint 累积缺陷。Sol 的代码量/测试产物指标也提示“更完整的测试”不等于更少的复杂度，应同时运行黑盒回归和复杂度审计。

局限

• 每个模型和 Kimi 提供商只有一次运行，样本量不足以做显著性推断。

• Sol、Fable、Kimi 使用不同 harness；成本和工具差异会影响结果。

• slop 指标与“代码是否易维护”的关系尚未验证，作者自己也指出规则可能过度惩罚。

• 文章没有公开每个 checkpoint 的全部原始仓库快照和完整 token/时延日志。

复现步骤

1. 获取 SlopCodeBench paper、runner、problem catalog，并固定六个 challenge 的版本。

2. 为每个 checkpoint 创建干净上下文，只暴露当前需求；保留前一 checkpoint 的代码。

3. 固定各模型的 harness 版本和工具权限，记录每次代码提交、测试输出和工具调用。

4. 对当前及所有继承 checkpoint 运行隐藏黑盒测试，按 strict pass 计分。

5. 同时统计缺陷累积、代码增长、重复度、认知复杂度和测试文件类型。

6. 至少重复多次并交叉运行不同 harness，才可讨论统计差异。

原始证据与数据

• 文章给出 6 个 challenge 的任务形状、30 个 checkpoint 的压缩输入、harness 版本和严格评分规则。

• Sol/Fable/Kimi 的严格通过数和部分代码质量统计均直接公开，且作者明确说明赞助和一次运行限制。

适用边界

• 最适合评估长程编码、需求逐步追加和回归缺陷传播，不等于普通单轮代码生成。

• 不能因为 Sol 与 Fable 33.3% 平局，就推断两者在创意、写作或知识工作上同质。

• “slop”结果只能作为待验证信号，不能直接当作工程质量结论。

来源摘录或观察（仅做合规短引）

作者把该实验定位为 “directional, not exhaustive”，并强调所有新模型都持续累积缺陷。