赢政指数 v6 代码执行测试中，这道「SQL：月度留存 Cohort」直接把 11 个模型的真实水平拉开。最终结果残酷：9 个模型得 0 分，只有 DeepSeek V4 Pro 和 Grok 4 拿到 66.7 分。
核心失败模式：CTE 写到一半就断
豆包 Pro、Qwen3 Max、Claude Sonnet 4.6、文心一言 4.5、Gemini 2.5 Pro、Gemini 3.1 Pro、Claude Opus 4.7、GPT-5.5、GPT-o3 这 9 个模型的回答，几乎都卡在同一个位置——WITH 语句写到一半突然截断，或者 SELECT 只写出前两列就没了。典型的如豆包 Pro 的 month_offset_map 只 UNION 了三行就直接结束，Qwen3 Max 的 active_months GROUP BY 写到 e.u 就没了。
这种「半成品」在真实工程里等于直接报错。它们不是逻辑方向错误，而是连把完整、可执行的 SQL 拼出来都做不到。
日期计算与 cohort 隔离的系统性混乱
即使能写完的模型，也普遍在两个关键环节翻车：一是 cohort_month 的精确过滤，二是 month_offset 的正确生成。
Claude 系列和 GPT 系列反复出现 EXTRACT(YEAR FROM ...) 减法，却没有处理好跨年场景；Gemini 2.5 Pro 用 DATE_PART 计算偏移，但最终没有把 active_month 真正映射回 0/1/2 这三个固定 offset；文心一言则直接用 DATEDIFF(MONTH...) 这种近似写法，明显缺乏工程严谨性。
相比之下，DeepSeek V4 Pro 和 Grok 4 的方案虽然仍有小问题，但至少完成了「先找出 2025-01 cohort，再 CROSS JOIN 三个 offset，最后 LEFT JOIN 统计」的正确骨架。这也是它们能拿到 66.7 分的根本原因。
0 分不是因为题目太难，而是模型在「把思路完整翻译成可执行 SQL」这一步集体失能。
为什么只有两家能及格？
DeepSeek V4 Pro 的写法把 cohort 筛选和 offset 生成彻底分离，用 CROSS JOIN 硬性生成 0/1/2 三行，再用 LEFT JOIN 统计 retained_users，思路最干净。Grok 4 虽然在 TIMESTAMPDIFF 的写法上略显冗余，但同样完成了 cohort_users + user_activity 的双 CTE 结构。
其余模型要么过度依赖 DATE_TRUNC 却没处理好 HAVING 过滤，要么把精力放在计算偏移公式上，反而忽略了「必须输出三行固定 offset」这个最基本的需求。
对工程落地的直接启示
在真实数据仓库场景里，留存分析是最常见的分析需求之一。这道题暴露的问题不是模型不会 SQL，而是当需求需要「精确控制输出行数 + 多步 CTE + 日期偏移」时，当前多数模型仍处于「能写出看起来像 SQL，但跑不起来」的阶段。
对于依赖 AI 辅助写 SQL 的团队，这意味着必须保留人工 review 环节，尤其在 cohort 分析、留存、漏斗这类多步聚合场景。
赢政指数的代码执行维度，本质测的不是模型「懂不懂 SQL」，而是「能不能一次性把正确、可运行的 SQL 交出来」。这次测试给出的答案是：目前能做到的，只有少数。
数据来源：赢政指数 (YZ Index) | Run #122 | 查看原始数据
© 2026 Winzheng.com 赢政天下 | 转载请注明来源并附原文链接