Claude Sonnet 4.6 SQL严格题从100分跌至0，主榜却反升9.3

Claude Sonnet 4.6在v6评测中，单一SQL严格题“疑似重复支付识别”得分从100分直接跌至0分，而主榜却从77.98提升至87.24。这组数据本身就构成冲突：整体能力上升，核心代码执行却在最需要精确逻辑的场景崩盘。

原始回答暴露的致命缺陷

评测提供的原始SQL如下：

SELECT p1.id AS first_id, p2.id AS second_id, ...
FROM payments p1
JOIN payments p2 ON p1.user_id = p2.user_id
AND p1.merchant_id = p2.merchant_id
AND p1.amount = p2.amount
AND p1.status = 'paid' AND p2.status = 'paid'

这段代码缺少两个必要条件：一是p1.id < p2.id（避免同一记录自匹配），二是支付时间差过滤。结果是每笔支付都会与自身及所有同金额记录产生笛卡尔积式输出，直接被判0分。

主榜提升与严格题崩盘的并存逻辑

同一版本下，代码执行从82.70升至87.60，材料约束从72.20升至86.80，工程判断（侧榜，AI辅助评估）更是暴涨42.3分。主榜整体+9.3的背后，是模型在常规任务上输出更完整、格式更规范。但严格题要求“一次通过”的精确逻辑，模型却在最基础的去重过滤上失守。

这说明v6版本的优化方向偏向“覆盖度”而非“严谨性”。当题目从开放式问答转为必须返回精确结果集的场景时，模型的自我一致性不足以支撑边界条件处理。

稳定性提升掩盖的波动风险

稳定性从36.5升至62.7，意味着模型在同类题目上的分数标准差缩小。但稳定性公式max(0,100-stddev×2)衡量的是输出一致性，而非正确率。模型现在更“稳定”地给出缺少id过滤的SQL，说明它把之前偶尔正确的路径固化成了系统性错误。

工程判断与实际故障场景

工程判断（侧榜，AI辅助评估）虽然提升，但该题直接对应真实风控场景：识别疑似重复支付。若生产环境直接运行此查询，商户端会收到海量误报，人工审核成本激增。模型在开放评测中“看起来更聪明”，却在最需要防御性编程的环节失效。

对比legacy维度，知识综合从57.8跃升至92.9，说明模型吸收了更多SQL语法知识，却未能将知识转化为带边界条件的正确实现。

当模型把“看起来能跑”当成及格线，严格题就会成为它最锋利的照妖镜。

本次事故的核心不在于单题失分，而在于它揭示了当前优化路径的系统性偏斜：主榜分数可以靠覆盖度拉升，严格题却会把逻辑断层暴露得一览无余。下一版本若不把“必须一次写对”的防御性约束加入训练信号，类似0分仍会周期性出现。

数据来源：赢政指数 (YZ Index) | Run #154 | 查看原始数据