三大模型代码生成横评：同一道LeetCode Hard，谁的通过率更高？

最近做代码生成能力测试，我选了一道 LeetCode Hard 题，分别让三类主流大模型生成解法，并记录一次性通过情况。为了减少切换环境的时间，我通过 AI模型聚合平台 t.877ai.cn 统一调用不同模型，测试过程更接近普通用户的真实使用方式。本文不做绝对排名，只分享一次偏实战的横向体验。

这次测试题选的是“最小覆盖子串”这类典型 Hard 题。它不算冷门，但很能考察模型的边界处理能力。题目要求在字符串中找到包含目标字符集的最短子串，难点不在思路本身，而在窗口收缩、重复字符统计、空结果处理等细节。

测试方式比较简单：同一段提示词、同一种编程语言、每个模型独立生成 10 次代码，不额外提醒错误点。生成后直接提交，统计是否一次通过。为了更贴近日常使用，我没有使用特别复杂的“专家提示词”，只要求模型给出思路、代码和复杂度分析。

先看结果。GPT 系模型一次通过 7 次，Claude 系模型一次通过 8 次，Gemini 系模型一次通过 6 次。这个结果不能代表所有题目，但能说明一个现象：现在主流模型写代码都不弱，差距更多体现在细节稳定性，而不是会不会做题。

GPT 系模型的特点是解法比较标准，代码结构清晰。大多数情况下，它会使用滑动窗口和哈希表，变量命名也比较容易读。问题在于有两次生成的代码对重复字符处理不够严谨，比如目标字符串里有两个相同字符时，窗口判断逻辑容易提前成立。

Claude 系模型这次表现最稳。它生成的代码通常更谨慎，会主动考虑边界输入，比如空字符串、目标长度大于原字符串、字符重复等情况。它的解释也更接近人工题解，适合学习算法思路。不过它有时会写得偏长，对只想快速提交的人来说，阅读成本稍高。

Gemini 系模型的优势是思路表达很快，整体框架也正确，但代码细节波动更明显。有几次它能准确讲出滑动窗口思路，真正落到代码时却在计数更新上出现小问题。这类错误很隐蔽，肉眼看起来像是正确答案，提交后才会暴露。

如果只看通过率，Claude 系模型在这次测试里略占优势。但如果从实际开发角度看，GPT 系模型的综合体验也很均衡，尤其适合快速生成可读代码。Gemini 系模型更适合用来做思路启发和多方案对比，直接拿去提交时最好多跑几组用例。

这里有个很关键的结论：代码生成能力不能只看“能不能写出来”，更要看“能不能稳定处理边界”。LeetCode Hard 对模型的考验，不是让它背出经典模板，而是看它在重复字符、数组越界、状态更新顺序这些地方是否可靠。

从趋势看，大模型写代码正在从“生成片段”走向“参与完整开发流程”。未来更有价值的能力，不只是刷题通过率，而是结合需求文档、已有代码、测试用例一起完成修改。也就是说，模型会越来越像一个初级开发助手，而不是单纯的代码补全工具。

不过，开发者也不能完全依赖模型。我的建议是：让模型先给思路，再要求它补充边界用例，最后自己跑测试。对于 Hard 题或业务核心代码，最好再让另一个模型做代码审查。多模型交叉验证，比单次生成更靠谱。

总体来看，这次横评中 Claude 系模型一次通过率更高，GPT 系模型综合表现稳定，Gemini 系模型在思路组织上有优势但代码细节需要复核。对普通开发者来说，真正高效的用法不是问“哪个模型最强”，而是根据任务选择合适模型，并保留必要的人工判断。