刚刚，Fable-5之下，智谱开源的GLM-5.2拿下AI编程第一！

< img id="wx_img" src="https://www.qbitai.com/wp-content/uploads/imgs/qbitai-logo-1.png" width="400" height="400"> 刚刚，Fable-5之下，智谱开源的GLM-5.2拿下AI编程第一！ 十三 2026-06-17 10:42:10 来源： 量子位 1M上下文 金磊 发自 凹非寺 量子位 | 公众号 QbitAI 在 Coding 这件事上，国产AI又famous了一下。 因为刚刚，在Claude Fable 5之下，开源界里拿下了 AI编程第一 （全球第二）： 不仅Arena官方用 “令人难以置信的里程碑” 来形容GLM-5.2取得的成绩，很多网友也是直呼 “疯狂” ： 不仅如此，在专门评测模型品味（taste）的 Design Arena 上，GLM-5.2取得全球第一的表现。 以及，在八项权威基准测试中，GLM-5.2的表现也是比较亮眼： 从结果上来看，国产、开源的大模型，可以说在Coding这件事上，首次跻身模型 全球御三家 （Claude、OpenAI和智谱）。 要知道，此前提到AI界的御三家，那大概率指向的是Claude、OpenAI和谷歌，不过这一次，从实打实的榜单能力来看，谷歌的Gemini实实在在地被GLM淘汰掉了。 而且这几天国外各大博主陆陆续续开始了各种实测。 当然，实测的主角不只是GLM-5.2，他们还把GPT-5.5 High、Opus 4.8 High和Kimi K2.7 Code拉来一起同台竞技。 先说结论： GLM 5.2表现得极其出色。 实际的 对比效果 是这样的： 这位博主认为这类测试是在X上比较能体现AI实力的那种，而GLM-5.2的表现已经接近Claude Opus 4.8。 无独有偶。 另一位外国博主同样做了类似的实测，GLM-5.2依旧是稳稳输出，让他直呼道： This is crazy. 但体感和口碑还只是一方面。 若是深挖一下GLM-5.2，它的亮点还包括： 支持真正可用的1M上下文，并在长程任务中继续保持领先。 换句话说，现在的GLM-5.2可以一口气“吃”下大项目级上下文、跨数小时自主推进。在很长一段时间里，Opus 级别的长任务与大型开发任务，是国产模型与海外旗舰之间很大的gap。 那么当它走进真实工作环境，效果如何？ 一波实测，走起~ 是真记得，还是只装得下？ 完整代码库理解 首先我们要测试的是GLM-5.2的 记忆力 。 因此，我们特意准备了GitHub上的 Appsmith 项目。 之所以选这个项目，是因为它是一个开源低代码平台，用于构建dashboard、admin panel、IT自动化等内部应用，天然包含前端、后端、插件、部署、权限等复杂模块。 然后我们直接“喂”给GLM-5.2这样的Prompt： 你是资深软件架构师。桌面上的Appsmith是一个完整项目代码库，请先不要修改代码。 请完成三件事： 1.梳理项目整体架构，输出核心模块、调用关系和数据流； 2.找出跨模块耦合最重的3处，并说明原因； 3.给出一份可执行的重构路线图，要求不破坏现有接口和测试。 这项任务的重点看模型能否把前端、后端、插件、Git服务、运行时和部署关系串起来。 先来看GLM-5.2的结果（上下滑动查看）： 可以看到，GLM-5.2先把Appsmith拆成monorepo结构，前端、后端的定位，以及拆分目录也是非常精准。 更关键的是，它把几条主链路串了出来。并且在耦合点判断上，GLM-5.2也抓到了3个关键位置。 接下来是CodeX的表现（上下滑动查看）： 从输出的效果来看，CodeX的结果更加清爽一些，它直接画出了Appsmith的整体架构图，并且对核心模块的拆解也准确。 两者的判断有不少交集，都抓到了前端Redux/Saga中心化、后端ActionExecutionSolutionCEImpl.java过重，以及CE/EE继承结构的问题。 不过虽然Codex的可读性更强一些，但更像一份结构清晰的技术备忘；而GLM-5.2覆盖更深，文件、链路、风险点和迁移阶段给得更多，像是在给项目做一次工程体检。 跨文件追Bug 第二项实测，我们换成 OpenWebUI ，测试一个真实工程里常见的问题，跨文件追Bug。 Prompt是这样的： 桌面上的open-webui项目里有一个线上Bug，请你从全库代码中定位可能原因，给出： 1.最可能的问题链路； 2.涉及文件和函数； 3.修复方案； 4.需要补充的测试用例。 不要只看单个文件，请结合调用链分析。 GLM-5.2抓住了一个核心点，也就是DirectConnection流式返回的边界不可靠（上下滑动查看）。 它把问题定位到“前端把上游SSE分片后再回传，后端按完整事件解析”这条链路，并给出前后端两侧修复方向。 这一关很适合看模型有没有真正沿着调用链走。 如果只看单个文件，很容易给出“加重试”、“加日志”、“检查缓存”这类通用答案。但这个问题真正藏在前端chunk、SSE协议、socket转发和后端JSON解析之间。 新增功能 第三个实测，我们继续用OpenWebUI，任务是新增“会话摘要导出为Markdown”功能： 请在open-webui项目中新增一个“会话摘要导出为Markdown”的功能： 1.用户可以选择一个历史会话； 2.系统生成结构化摘要； 3.支持导出Markdown； 4.补充必要测试； 5.不要破坏现有接口。 请先给出实现计划，再分步骤修改。 对于这个任务，模型需要先理解会话数据怎么存，权限怎么判断，前端菜单入口在哪里，API怎么封装，测试应该放在哪里。 GLM-5.2这一轮更像完整工程交付： 它把“Markdown导出”拆成后端工具、路由、前端API、UI入口和测试五层；最后，它跑出了38个后端测试全部通过。 这就是AgenticCoding真正要看的地方。交付物不能只是一段代码，还要能并入项目。 一口气做多项任务 第四个实测，我们这次尝试让GLM-5.2和CodeX一口完成多个任务。 Prompt是这样的： 基于公开可验证数据，构建一套可追溯、可复现的 2026 年英国 PBSA（学生公寓）行业研究与数据分析包，系统评估学生需求、供给管线、租金走势、运营商格局及投资环境，为内部投资与预算决策提供支持。 在片刻之后，GLM-5.2一口在桌面输出一整个文件夹的内容： 做的图表是这样的（上下滑动查看）： 也同时生成了一份完整的分析报告： 整体来看，GLM-5.2在文件数量、表格结构、图表覆盖、复现脚本和数据质量控制上更完整，最终更像一套可以拿去内部评审前继续打磨的研究材料包。 什么时候别用1M 不过有一说一，1M上下文并不是什么任务都适用。 如果只是改一个小函数、补一个简单脚本、改一个按钮文案，整库上下文的收益并不明显。很多时候，只给必要文件，模型反而更快、更干净，也更不容易过度设计。 真正适合1M上下文的，可能是下面这几类任务： 整库理解、跨文件追Bug、长期重构、复杂功能新增、多交付物研究项目、超长文档审阅、代码和文档一起分析。 也就是说，1M上下文是为了让它在真实工作里少忘