Dex Horthy / Gabe Orlanski · SlopCodeBench · 阅读原文
原始来源：Dex Horthy / Gabe Orlanski · SlopCodeBench
发现渠道：Hacker News · 热点发现
原始来源：相关原始说明 / 公开讨论
真实软件需求会不断追加。SlopCodeBench 让模型接手自己上一阶段留下的代码，再逐步透露新要求，从而观察代码能否继续修改，而不是只做一次性题目。10月15日这轮报告采用固定 v1.0 题库、默认 just-solve 提示、seed 42、Python 3.12 Docker 环境；每个模型设置运行36个问题、共196个阶段检查点，每种设置只完成一轮。
读图要分开两种通过。Strict 要求该阶段各类测试全过，包括回归测试；Core 只表明当前核心功能过关，可能仍损坏旧行为。图中实色段是 Strict，淡色延伸是额外的 Core-only。Astra XHigh 的严格通过为32/196，而核心成功为136/196；差距说明“新增功能看似能用”与“整个既有要求仍成立”之间存在很大距离。196个检查点又来自36条连续问题轨迹，不能视为196个独立项目。
费用与思考强度也没有整齐的单调关系。三个可配对模型中，提高到 XHigh 后只见 Astra 的严格通过数由29升到32；SOL 6 从30降到26，Opus 5.5 从28降到25。作者报告费用增加约2.11至4.22倍。单轮结果不足以证明高强度普遍有害，却足以提醒人们，额外预算是否值得需要按任务验证。
代码风格指标是另一层证据。报告把大函数、冗长和侵蚀等启发式信号用于分析可测量的28个问题，未覆盖全部36题；被标记的代码行也不等于每一行都错。原文有一处把32与29之差写成“两项”，本期按表格核对为三项，不沿用该句。
可信度 65 · 重要性 82 · 新颖度 75
技术与主题
AI 编程 · 评测与基准 · SlopCodeBench · Regression Testing · Sequential Tasks · Reasoning Effort
dhorthy
作者回应读者能否先运行代表性子集。
忠实转述（非原句）：他曾选六道题作为子集，模型得到约33%的成绩；全量结果却接近14%—15%。因此他没有发现那个子集具有代表性。
theodorewiles
同一报告的HN讨论；个人运行报告，没有附可复核数据。
忠实转述（非原句）：他根据 Rich Hickey 的演讲做了一个简化技能，侵蚀与冗长指标改善，并随时间变好。但运行 SlopCodeBench 后，他没有找到测试通过率轨迹也改善的证据；这让他重新思考可维护性指标。
编辑评读
最值得改变的判断，是不要把新需求的成功当作维护能力。连续任务把历史包袱保留下来，回归测试则让模型为此前的承诺负责。对团队来说，可迁移的方法是从已有产品中选择会追加需求的任务序列，保留相同代码状态，分别记录新增功能、旧功能和最终整体通过；这比只比较一次生成的漂亮程度更接近维护工作。
两条评论进一步限制了怎么解释分数。作者尝试过六题子集，结果明显高于全量题库，因此不能假设随手抽取的少数题具有代表性。另一位使用者说，他用简化技能改善了侵蚀和冗长指标，却未找到测试通过轨迹相应改善的证据。这不是已公开的严格复现，但提供了一个有价值的追问：风格分究竟预测未来修改成本，还是只测到了符合某种规则？先分别测可读性、修改耗时和行为正确性，再讨论关联，比把其中一项当作其余两项的替身更稳妥。