# SWE-bench 高分，为什么在大厂 Kotlin 项目里照样抓瞎？

> 原标题：为什么 SWE-bench 高分，在大厂 Kotlin 项目里依然会打转？

- 来源：Computing Life · Share · 鸭哥调研
- 发布时间：2026-07-27T00:00:00.000Z
- AX AI 日报：https://ai-daily.ax0x.ai/items/47107
- 原文：https://yage.ai/share/jetbrains-kotlin-benchmark-reframe-20260727.html

## 摘要

JetBrains 在 2026 年 7 月 24 日发布了 Kotlin Benchmark，用 8 个开源项目的 105 个真实任务测 AI 编程助手。同样用 Opus 4.7 模型，Claude Code 成功率 85.71%，JetBrains 自家的 Junie 是 81.9%，差了近 4 个百分点。差距不在模型本身，而在外层 Harness...

## 推荐理由

JetBrains 官方基准测试给出了具体数字和工程层面的拆解，不是泛泛抱怨排行榜失真，而是追溯到静态编译开销 vs Python 动态运行反馈的根因。扣分点在于文章本身没披露更多任务细节和失败模式，但作为一条快讯，信息密度和判断力都够。

## 锐评

这条新闻值得点开，因为它把 AI 编程助手选型里最隐蔽的坑讲清楚了：公开榜单测的是 Python 开源项目，模型在动态类型下靠频繁试错就能刷分，但换到 Kotlin 这种静态强类型语言，每次试错都要等 Gradle 完整构建，成本直接爆炸。JetBrains 7 月 24 日发布的 Kotlin Benchmark 用 8 个开源项目的 105 个真实任务做了对比，同样用 Opus 4.7 模型，Claude Code 成功率 85.71%，Junie 是 81.9%，差了近 4 个百分点。差距不在模型智商，而在外层 Harness 怎么处理 Gradle 吐出的几百行构建日志——好的 Harness 会先用 Language Server 在编辑阶段就地抓类型错误，只在关键节点才跑完整构建，并且从日志里只提取阻断编译的那几行，不把垃圾信息塞进上下文窗口。

文章给出的建议很务实：别拿公开排行榜当采购手册，那些榜单为了通用可比性，过滤掉了你公司内部未文档化的架构约束，比如依赖注入作用域或协程调度约定。公开基准的正确用法是当种子，用 Harbor 容器规范把团队过去半年的真实 PR 和 Issue 转成私有微评测矩阵，看 Pass@k 稳定性、Token 消耗和 Patch 是否破坏隐式架构规范。正文没披露这 105 个任务的具体难度分布，也没给出 Junie 和 Claude Code 在 Token 消耗上的对比数据，这点先别太激动。