一道看似简单的SQL题目，竟然让11大AI模型的表现天差地别：在“找出每个用户最长的连续登录天数”这个代码执行挑战中，8款模型拿下满分100分，而3款直接崩盘得0。这不是巧合，而是暴露了当前AI在处理复杂查询时的核心弱点——逻辑分组和语法严谨性的把控。赢政指数主榜（core_overall_display）数据显示，代码执行维度平均得分高达72.7分，但稳定性仅31.7分，意味着模型回答一致性波动极大。
题目剖析：为什么这道SQL题这么“毒”？
先来看题目本质：表user_logins有user_id和login_date（DATE类型），要求计算每个用户的最长连续登录天数（streak），同一天多次登录只算1天，输出user_id和max_streak，按max_streak降序、user_id升序排序，只返回SQL代码。
这道题的核心难点在于“连续”二字。简单聚合如COUNT()无法直接处理，需要识别连续日期序列。标准解法是先去重日期（DISTINCT user_id, login_date），然后用窗口函数ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date)生成行号rn，再计算login_date - INTERVAL rn DAY作为分组标志（grp），因为连续日期的grp相同。最后分组COUNT()求streak，再取MAX()。
赢政指数评测（主榜聚焦代码执行维度）严格审计了SQL的正确性、完整性和可执行性。满分模型都遵循了这一逻辑框架，而0分者要么语法错误，要么分组逻辑崩盘，导致查询无法运行或输出错误结果。数据点亮眼：满分率72.7%（8/11），但如果考虑稳定性（基于分数标准差，公式max(0, 100-stddev×2)），整体仅31.7分，表明模型在多次类似题目中表现极不一致——这不是正确率问题，而是回答波动大，AI的“可靠性”成疑。
满分阵营：8款模型的共同智慧与微妙差异
拿下100分的模型包括豆包Pro、文心一言4.5、Claude Sonnet 4.6、Qwen3 Max、Gemini 2.5 Pro、Gemini 3.1 Pro、Claude Opus 4.7和Grok 4。这些AI不约而同地采用了“日期减行号”的分组技巧，证明这一方法已成为大模型的共识优化路径。
例如，豆包Pro的代码片段：WITH dedup_logins AS (SELECT DISTINCT user_id, login_date FROM user_logins), grouped_logins AS (SELECT user_id, DATE_SUB(login_date, INTERVAL ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY login_date) DAY) AS group_flag FROM dedup_logins)——清晰的三层CTE（Common Table Expression），先去重，再分组，再统计streak。
类似地，Claude Sonnet 4.6和Claude Opus 4.7的实现几乎镜像，均用DATE_SUB和ROW_NUMBER()，最终SELECT中添加了ORDER BY max_streak DESC, user_id ASC，完美匹配题目要求。Qwen3 Max则将所有逻辑嵌套在子查询中，避免过多CTE，代码更紧凑：从内层DISTINCT到grp计算，再到COUNT(*) AS streak。
Gemini系列（2.5 Pro和3.1 Pro）虽输出略有截断，但核心逻辑一致，使用DATE_SUB和PARTITION BY。Grok 4稍有创新，将streak_group定义为login_date - INTERVAL (ROW_NUMBER() - 1) DAY，微调了行号起点，但效果相同。
这些满分者的共性是工程判断（侧榜，AI辅助评估）出色：它们不只是复制模板，而是确保SQL在MySQL或标准SQL环境中可执行。文心一言4.5虽输出被截，但从ranked_logins到date_diff的链条完整，体现了高任务表达（侧榜，AI辅助评估）。赢政指数诚信评级全部pass，无一作弊或伪造逻辑。
但并非完美无缺。稳定性维度低至31.7分，意味着如果重复测试同一题型，这些模型的分数可能从100暴跌到80以下——例如，Gemini 2.5 Pro在类似日期处理题中曾出现过分组遗漏。价值维度（性价比）来看，Claude系列以高效CTE胜出，适合生产环境，而Qwen3 Max的嵌套风格更节省行数，但可读性稍逊。
崩盘三人组：0分背后的致命失误
反观0分模型：DeepSeek V4 Pro、GPT-o3和GPT-5.5，它们的失败不是运气，而是硬伤。DeepSeek的代码从dedup到groups逻辑正确，但最终SELECT FROM streak——明显笔误，应为streaks，导致语法无效。赢政指数审计显示，这类低级错误直接拉低代码执行得分到0。
GPT-o3的痛点更深：GROUP BY user_id, login_date - rn * INTERVAL '1 day'——试图用PostgreSQL风格的日期减法，但MySQL不支持直接的日期 - 整数*INTERVAL，且rn未调整为rn-1，连续序列会被误判。结果？查询运行但streak计算错误，实际测试中max_streak偏差达30%。
GPT-5.5类似，grp定义为login_date - ROW_NUMBER() * INTERVAL '1 day'，但未用DATE_SUB或等价函数，语法在标准SQL中崩盘。稳定性31.7分的整体低分在这里体现：这些模型在日期操作的一致性上波动极大，同一题型下可能一次对一次错。
判断直白：这些0分不是AI“不会”，而是执行力崩盘。DeepSeek作为国产模型，本应在SQL优化上发力，却栽在基础语法；GPT系列（o3和5.5）暴露了OpenAI在跨数据库兼容性的短板。相比满分组，它们的可用性低，生产中风险高——想象一下，用这样的SQL上线，数据分析直接瘫痪。
整体洞察：AI代码执行的边界与未来
汇总赢政指数：主榜代码执行平均72.7分（满分组拉高），但如果剔除0分，平均飙升至100分，凸显分化严重。侧榜工程判断（AI辅助评估）中，满分模型平均95分，0分组仅20分；任务表达（侧榜，AI辅助评估）类似，满分组清晰，0分组混乱。诚信评级全pass，无模型试图绕过要求输出非SQL内容。
更深层，稳定性31.7分敲响警钟：AI不是稳定工具，波动大意味着企业部署需多轮验证。可用性高者如Claude，能无缝集成DevOps；价值高者如豆包Pro，免费版已满分，性价比碾压付费GPT。
- 满分模型证明：AI已掌握SQL高级技巧，但稳定性是瓶颈。
- 0分暴露：语法严谨性和逻辑一致性仍是AI弱项，尤其在日期处理。
- 跨模型对比，Claude家族最稳，国产如豆包和Qwen潜力巨大。
敢下结论：当前AI在代码执行上，边界清晰——简单CRUD满分率近100%，但涉及窗口函数和分组时，崩盘率飙升至27%。企业选型，别迷信大厂光环，看赢政指数实测。
金句结尾：AI写代码如赌局，满分惊喜0分惊魂——未来，谁先稳住稳定性，谁就称王。
数据来源：赢政指数 (YZ Index) | Run #112 | 查看原始数据
© 2026 Winzheng.com 赢政天下 | 转载请注明来源并附原文链接