43%。在一项包含 202 个真实 GitHub 任务的测试中,Qwen3.8 27B 解决了其中 43%,而 Qwen3.6 27B 的解决率只有 17%。我们注意到,这组数据比常见编程榜单更贴近一个现实:模型是否真正可用,往往取决于它在企业冷门语言和遗留系统中的表现。

这是什么

测试团队选取 Elixir、OCaml、Haskell、Clojure、Kotlin、Swift、Julia、R 等 13 种较少进入主流编程基准的语言,并使用真实 GitHub 仓库任务评估模型。Qwen3.8 27B 与 Qwen3.6 27B 参比,测试结果还可与 Kimi K3、DeepSeek、GLM 及闭源模型横向比较。

这类测试考察的是模型在现有代码库中定位问题、修改和交付结果的能力,而不只是写出孤立代码片段。对使用本地部署的团队,它提供了比综合跑分更贴近日常工作的参考。

行业怎么看

我们认为,43% 相对 17% 的提升值得关注,它表明小参数模型在特定技术栈中的代码处理能力可能正在快速改善。测试还允许与闭源模型对照,说明竞争焦点已经从参数规模,转向具体场景中的完成率和部署成本。

但风险同样明确:任务由 Qwen3.8 参与挑选,结果存在一定偏向;项目规模、测试设计和算力预算也会影响结论。43% 的解决率也意味着超过一半任务仍未完成,不能据此判断其已达到可直接替代工程师的水平。更重要的是,社区测试不等于严格、统一的行业基准。

对普通人的影响

对企业 IT:本地模型对小众语言、旧代码维护和隐私敏感项目的价值可能上升。企业可先让模型承担测试补充、缺陷定位等可复核工作,再决定是否扩大使用范围。

对个人职场:非主流语言开发者可更早获得本地代码助手,但选型仍应看真实仓库表现、硬件成本和错误率,而非只看单一跑分。

对消费市场:随着本地模型覆盖更多开发工具,隐私优先、无需持续订阅的智能应用会增多,但现阶段能力提升仍集中在可验证的技术任务中。