在 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 是这样的：
arduino
桌面上的open-webui项目里有一个线上Bug，请你从全库代码中定位可能原因，给出： 1.最可能的问题链路； 2.涉及文件和函数； 3.修复方案； 4.需要补充的测试用例。 不要只看单个文件，请结合调用链分析。GLM-5.2 抓住了一个核心点，也就是 DirectConnection 流式返回的边界不可靠（上下滑动查看）。
它把问题定位到 "前端把上游 SSE 分片后再回传，后端按完整事件解析" 这条链路，并给出前后端两侧修复方向。
这一关很适合看模型有没有真正沿着调用链走。
如果只看单个文件，很容易给出 "加重试"、"加日志"、"检查缓存" 这类通用答案。但这个问题真正藏在前端 chunk、SSE 协议、socket 转发和后端 JSON 解析之间。
新增功能
第三个实测，我们继续用 OpenWebUI，任务是新增 "会话摘要导出为 Markdown" 功能：
arduino
请在open-webui项目中新增一个"会话摘要导出为Markdown"的功能： 1.用户可以选择一个历史会话； 2.系统生成结构化摘要； 3.支持导出Markdown； 4.补充必要测试； 5.不要破坏现有接口。 请先给出实现计划，再分步骤修改。对于这个任务，模型需要先理解会话数据怎么存，权限怎么判断，前端菜单入口在哪里，API 怎么封装，测试应该放在哪里。
GLM-5.2 这一轮更像完整工程交付：
它把 "Markdown 导出" 拆成后端工具、路由、前端 API、UI 入口和测试五层；最后，它跑出了 38 个后端测试全部通过。
这就是 AgenticCoding 真正要看的地方。交付物不能只是一段代码，还要能并入项目。
一口气做多项任务
第四个实测，我们这次尝试让 GLM-5.2 和 CodeX 一口完成多个任务。
Prompt 是这样的：
yaml
基于公开可验证数据，构建一套可追溯、可复现的 2026 年英国 PBSA（学生公寓）行业研究与数据分析包，系统评估学生需求、供给管线、租金走势、运营商格局及投资环境，为内部投资与预算决策提供支持。在片刻之后，GLM-5.2 一口在桌面输出一整个文件夹的内容：
做的图表是这样的（上下滑动查看）：
也同时生成了一份完整的分析报告：
整体来看，GLM-5.2 在文件数量、表格结构、图表覆盖、复现脚本和数据质量控制上更完整，最终更像一套可以拿去内部评审前继续打磨的研究材料包。
什么时候别用 1M
不过有一说一，1M 上下文并不是什么任务都适用。
如果只是改一个小函数、补一个简单脚本、改一个按钮文案，整库上下文的收益并不明显。很多时候，只给必要文件，模型反而更快、更干净，也更不容易过度设计。
真正适合 1M 上下文的，可能是下面这几类任务：
整库理解、跨文件追 Bug、长期重构、复杂功能新增、多交付物研究项目、超长文档审阅、代码和文档一起分析。
也就是说，1M 上下文是为了让它在真实工作里少忘事、少跑偏、少反复问你要背景。
它把长上下文从一个发布参数，拉回了开发者和知识工作者真正熟悉的现场：一个大项目、一堆历史包袱、几个跨模块 Bug、一项不能破坏旧逻辑的新需求，以及一整套必须同时交付的报告、表格、图表和脚本。
模型竞争进入长期工作能力阶段
这轮测完，一个最直接感受或许是这样的：
AICoding 正在换阶段。
过去大家更关注模型会不会写代码、会不会补全、会不会一次性生成一个 Demo。这个阶段比的是单次输出能力。
但现在，开发者开始把模型放进真实工程流里使用。任务不再是写一个孤立函数，而是读完整项目、理解架构、追踪调用链、保持需求约束、修改多处文件、补测试、生成文档，甚至连续十几分钟、几个小时自主推进。
这时候，模型竞争的核心就变了。
上下文长度不再只是参数表上的数字，它开始变成 Coding Agent 的工作内存。一个 Agent 要持续工作，就必须记住项目结构、接口约定、历史决策、工具调用结果、中间修改状态和用户最开始给出的边界条件。只要中途忘掉一项，最后产物就可能偏。
所以长上下文真正重要的地方，在于把 AI Coding 从会写一段代码，推向能做一段工程。
这也是为什么 GLM-5.2 有机会进入 AI Coding 里的 "御三家"。
在全球 CodingAgent 进入硬核的长程工程阶段后，开发者正在形成三类主流选择：ClaudeCode、OpenAICodex，以及以 GLM-5.2 为核心的开源长程 CodingAgent 路线。
-
Claude Code 代表的是闭源 Coding Agent 体验的上限，强在工程体感、工具调用和复杂任务推进；
-
OpenAI CodeX 代表的是 OpenAI 体系下的代码生成和智能体路线，背后有模型、产品和开发者生态的连续投入；
-
而 GLM-5.2 代表的，则是另一条同样关键的路线：开源、长上下文、面向真实工程任务的 Coding Agent 底座。
这条路线的价值，不只在于国产模型也能写代码。
更重要的是，当 AI Coding 进入大工程阶段，开发者需要的不只是一个云端黑盒。很多团队会关心模型能否私有化，能否接入自己的工具链，能否读内部代码库，能否承载长上下文任务，能否在成本可控的前提下稳定工作。
开源长程 Coding Agent 路线，正好补上了这块拼图。
如果说前一阶段的 AI Coding，比的是谁能更快写出一段能跑的代码；那么下一阶段，比的就是谁能更久地待在项目里，理解它、记住它、改动它，并且不把它弄坏。
这也是 GLM-5.2 这次最核心的信号：
国产开源模型的竞争，已经不只是在榜单上追分，而是在进入真实开发者工作流，进入长程工程任务，进入 AICoding 最硬核的牌桌。
而这张牌桌上，GLM-5.2 终于有了一个清晰的位置。
参考链接：
--- 完 ---