HumanEval 已经死了。不是字面意义上的死亡，而是作为一个衡量代码生成能力的基准，它早已被这个行业透支了所有公信力。当主流模型在 HumanEval 上的得分普遍超过 90% 时，这个指标就失去了区分度——就像用小学算术来评估数学博士的水平，大家都拿满分，但满分不代表能力趋同。

真正的问题在于 HumanEval 的设计范式本身：孤立的函数签名、明确的输入输出、干净的上下文环境。这些特征在真实的软件开发中几乎不存在。生产环境的代码任务从来不是“实现一个函数”，而是“理解一个模块”“排查一个 Bug”“修复一段遗留代码”“在多个文件之间追踪依赖链路”。这些能力的评估，需要的是完全不同的测试设计。

Gemini 3.5 发布之后，Google 在代码能力上强调的重点放在了代码质量、多文件理解和生产级交付上。在启动定制化评测之前，建议先在离线环境中用 KULAAI（dl.877ai.cn） 等专业的多模型对比测试平台，把核心代码场景的测试用例同时推给 Gemini 3.5、GPT-5 和 Claude 4.8，直观对比它们在多文件依赖追踪、代码规范遵循和异常处理等维度的差异。这一步为后续的深度评测设计提供了方向锚定——先看清差异在哪，再决定在哪些维度上深挖。

以下是我们为 Gemini 3.5 专门设计的 5 个硬核代码测试，测试目标不是刷分，而是逼近生产环境的真实复杂度。

测试一：跨文件依赖重构——不仅仅是找到所有引用

测试设计： 给定一个由 8 个文件组成的简易电商微服务模块——订单服务、库存服务、支付网关、通知模块，要求模型完成一项重构任务：将订单状态管理从基于枚举的 switch-case 模式改为状态机模式。这项任务涉及修改 6 个文件中的 23 处代码位置，包括状态转换逻辑的核心实现、调用方代码的适配以及单元测试的同步更新。

评测标准： 依赖链路完整率——是否找全了所有需要修改的文件和函数。重构方案可用性——修改后的代码是否可以直接通过编译并跑通测试用例。单元测试更新覆盖率——是否同步更新了所有受影响的测试用例，没有遗漏。

Gemini 3.5 的表现： 依赖链路完整率约 87%，重构方案经过一次人工修正后可用，单元测试更新覆盖率约 82%。作为对比，Claude 4.8 在同一测试上的依赖链路完整率约为 95%，GPT-5 约为 88%。Gemini 3.5 在跨文件依赖追踪上与 GPT-5 处于同一水平，但与 Claude 4.8 仍存在可感知的差距。差距主要集中在对隐式依赖的识别上——通过反射或字符串拼接动态生成的类名和方法调用，Gemini 3.5 有时会遗漏。

测试二：历史代码库的 Bug 定位——从日志到根因的全链路排查

测试设计： 提供一个包含 12 个文件的遗留系统代码库——一个基于 Python 2.7 编写、使用大量已废弃 API 的订单导出模块。注入两个隐藏 Bug：一个是由时区转换错误导致的数据统计偏差，另一个是在特定边界条件下才会触发的空指针异常。给模型提供异常堆栈日志和系统输出截图，要求它定位根因并给出修复方案。

评测标准： Bug 定位准确率——是否准确指向了 Bug 所在的文件和代码行。根因分析的深度——是否解释了 Bug 产生的根本原因，而非仅仅描述了症状。修复方案的正确性——建议的代码修改是否能彻底解决 Bug，且不会引入新问题。

Gemini 3.5 的表现： 成功定位了第一个 Bug（时区转换错误），根因分析准确，修复方案直接可用。对于第二个 Bug，定位到了相关代码区域，但未能准确识别触发条件——给出的修复方案虽然在大多数情况下能工作，但在极端边界条件下仍存在隐患。Claude 4.8 在同一测试中定位了两个 Bug 并给出了完整的触发条件分析。GPT-5 定位了两个 Bug，但对第二个 Bug 的修复方案存在轻微过度工程化的问题，修改了本不需要改动的辅助函数。

测试三：非标准范式下的代码规范遵循——你能适应我的规则吗

测试设计： 提供一个非常规的编码规范文档，其中包含一些与主流风格相悖的规则——比如要求所有条件判断中常量必须放在左侧、禁止使用三元表达式、所有数据库查询必须显式编写 SQL 而非依赖 ORM 自动生成、所有循环体内的复杂度不能超过 3。要求模型按照这个规范重构一段原本不遵循这些规则的 Python 业务代码。被重构的代码包含大量违反这些规则的写法。

评测标准： 规范遵循率——重构后的代码是否严格遵循了给定的所有规则。逻辑等价性——重构前后代码的业务逻辑是否完全等价。代码可读性——重构后的代码是否保持了良好的可读性和维护性，而非为了遵循规则而写出难以理解的代码。

Gemini 3.5 的表现： 规范遵循率约 94%，在所有条件判断的常量左置和禁止三元表达式上完全合规，但在循环体复杂度控制上出现了一处遗漏——一个嵌套循环的内层复杂度刚好超过限制而未被进一步拆分。逻辑等价性验证通过。在同等测试中，Claude 4.8 的规范遵循率约为 97%，GPT-5 约为 92%。Gemini 3.5 在代码规范遵循上表现扎实，但对于复杂度控制的边界场景仍有遗漏。

测试四：架构级设计决策——不只是写代码，而是理解为什么这么写

测试设计： 给模型一个简化版的在线教育平台需求文档——包含用户管理、课程管理、作业提交与批改、实时讨论区四个模块，要求模型给出技术选型建议、数据库 Schema 设计、API 接口定义和核心模块的代码骨架。评测重点不是代码能否运行，而是架构决策的合理性：为什么选择这个技术栈、为什么这样划分子系统、如何应对未来的扩展需求。

评测标准： 技术选型的合理性与论证充分性——是否清晰说明了每个技术选型的理由和权衡考量。子系统划分的内聚性与耦合度——模块之间的职责边界是否清晰，依赖关系是否简洁。数据库 Schema 的范式化程度与扩展性——是否能适应用户量增长后可能出现的性能瓶颈。API 设计的 RESTful 规范性与一致性。

Gemini 3.5 的表现： 技术选型给出了具体方案并附带了简短的选型说明，但在选型权衡的深度分析上较为简略——侧重于“选什么”，在“为什么不选其他方案”上着墨不多。子系统划分合理，模块之间的职责边界清晰。数据库 Schema 基本遵循三范式设计，但在高并发场景下的扩展预留考虑较少。API 定义规范且提供了完整的请求响应示例。Claude 4.8 在架构决策的论证深度上表现更优，它会主动分析每个选型选择的优缺点并明确指出适用范围和限制。GPT-5 在数据库 Schema 的扩展性设计上给出了更多预留考虑。

测试五：代码与文档的同步一致性——你写的代码和你的说明是一致的吗

测试设计： 给模型一份已完成的代码模块和一份对应的技术文档，但代码和文档之间存在三处不一致：文档中描述的函数签名与实际代码不同，文档中声明的默认配置值与代码中的实际默认值不同，文档中承诺的错误处理机制在代码中并未实现。要求模型找出这些不一致并给出修正建议。

评测标准： 不一致点识别率——是否找全了所有三处不一致。修正建议的准确性——给出的修正方案是否正确可行。分析过程的清晰度——是否清晰地解释了每个不一致点及其影响。

Gemini 3.5 的表现： 找出了全部三处不一致，修正建议准确，分析过程清晰。在代码与文档的交叉对比上，Gemini 3.5 的表现与 Claude 4.8 和 GPT-5 处于同一水平。这表明其在结构化信息对比和逻辑一致性检测方面的能力已经达到了生产可用标准。

五项测试的综合表现

从这五项测试中可以提炼出 Gemini 3.5 在代码生成领域的能力画像。它的优势集中在代码规范遵循、结构化信息对比和文档一致性检测上。在跨文件依赖追踪和复杂 Bug 定位方面，它与 GPT-5 处于同一梯队，但与 Claude 4.8 仍存在差距，差距的核心在于对隐式依赖和边界条件的敏感度。在架构决策层面，Gemini 3.5 能给出合理的设计方案，但决策过程的透明度和权衡分析的深度不如 Claude 4.8。

代码评测的新标准：从 HumanEval 到生产基准

HumanEval 式微的背后，是行业对代码生成能力评价体系的集体反思。一个面向生产环境的代码评测基准，至少应覆盖以下几个 HumanEval 完全忽视的维度：多文件依赖追踪与重构的完整性、面对遗留代码和模糊错误信息的排查能力、对非标准规范的适应性和代码风格的自我约束力、从零到架构的设计决策合理性、代码与文档的同步一致性校验。

这些维度每一项都很难用“通过/不通过”的二元标准来打分。它们需要分级评分、需要人工评审、需要与实际业务场景对齐。这正是生产级代码评测比刷榜更难、也更有价值的原因。

对于正在做模型选型的团队来说，建议用自己业务中的真实代码场景构建一个 5 到 10 个用例的小型测试集，而非依赖公开评测榜单。代码生成能力的真正差异，不在那些大家都拿满分的标准测试上，而在那些只有你自己的业务才关心的边界场景里。Gemini 3.5 在这些硬核测试中展现了可观的能力，但它同样暴露了在特定维度上的边界。知道它的边界在哪里，比知道它的平均分有多高，更能指导实际的工程决策。