我每次看到有人往 GLM 5.2 里传截图却毫无反应，都会见到这个问题冒出来。这种困惑情有可原——GLM 5.2 刚刚登上 Design Arena 第一名，被称作当前最强的开放权重编程模型，而且 Zhipu AI（Z.ai）的产品线里确实有多模态产品。那么：GLM 5.2 是多模态的吗？它有视觉能力吗？
没有。GLM 5.2 仅支持文本进、文本出。没有图像输入、没有截图分析、没有视觉推理。这一点由 Z.ai 自家开发者文档确认，其中把它的输入模态简单列作「Text」。
但一个干巴巴的「没有」会错过更有用的答案——因为 Z.ai 确实有真正的视觉模型，因为关于 GLM 5.2 的困惑来自三件被反复混为一谈的具体事情，也因为今天确实有实用办法给 GLM 5.2 工作流加上视觉能力。
GLM 5.2 实际支持什么
GLM 5.2 是一个文本模型。它能处理的是：
- 输入：文本（含代码、结构化数据），最多 100 万 token
- 输出：文本、代码
- 推理模式：High 和 Max，用于困难任务的扩展思考
- 架构：MoE，745B 总 / 44B 激活参数，MIT 开放权重
它不能处理的是：图像、截图、视频帧、音频，或任何视觉输入。
这是刻意为之。GLM 5.2 的架构专门为文本和代码优化——结果也摆在那里。它在 Terminal Bench 2.1 上拿 81.0、FrontierSWE 74.4、SWE-bench Pro 62.1。如果模型的能力被分散到多个模态上，这些数字会完全是另一个样。
为什么人们以为 GLM 5.2 有视觉能力
三件事造成了这种困惑。它们值得被直接点名，因为网上不准确的报道里它们不断出现。
困惑一：Design Arena 第一不等于图像理解。
GLM 5.2 目前在 Design Arena 排名第一，Elo 1360——这是一个让模型比拼设计、编写用户界面的基准。但这是文本进、代码出的任务。模型读文字版 UI 规格，产出 HTML、CSS 和 JavaScript。从文字指令里做出优秀设计，与接收或理解图像输入毫无关系。至少有一篇被广泛引用的文章把这两件事混为一谈，错误地声称 GLM 5.2「支持包括图像在内的多模态输入」。它不支持。
困惑二：Z.ai 平台包含图像生成，但不是 GLM 5.2 在干。
使用 glm5.app 时，图像生成是可用的。那是由 Seedream——Z.ai 专属的图像生成模型——驱动的。GLM 5.2 负责文本和代码任务，Seedream 负责图像。它们共享一个平台，但是架构各异的独立模型。
困惑三：GLM 家族确实有视觉模型——只是不叫 GLM 5.2。
Z.ai 于 2026 年 4 月发布了 GLM-5V-Turbo。它是一款原生多模态模型，架构里就内置了图像和视频理解。GLM 5.2 与 GLM-5V-Turbo 是服务不同用例的不同产品。
Z.ai 真正的视觉模型：GLM-5V-Turbo
如果你需要多模态能力、又想留在 Z.ai 生态里，GLM-5V-Turbo 就是那个产品。它于 2026 年 4 月 1 日发布，在架构上为视觉任务量身打造。
| 属性 | GLM-5V-Turbo |
|---|---|
| 输入模态 | 图像、视频帧、文本 |
| 输出 | 文本 |
| 视觉编码器 | CogViT（原生，不是后装） |
| 上下文窗口 | 202,752 token |
| Design2Code 分数 | 94.8 |
| 架构 | MoE，744B 总 / 40B 激活 |
| 开放权重？ | 否——仅闭源 API |
| API 定价 | $1.20/M 输入，$4/M 输出 |
Design2Code 的 94.8 分外亮眼。该基准衡量的是模型把设计截图转成可用代码的能力——一个真正困难的视觉任务，需要理解布局、颜色、层级和组件关系。GLM-5V-Turbo 在该基准上胜过 Claude Opus 4.6（77.3）、GPT-5.5 和所有其他闭源模型。
代价是：它闭源、仅 API。不能自托管、没有 MIT 协议。这与 GLM 5.2 是实实在在的差别。
GLM 5.2 vs GLM-5V-Turbo：你需要哪个？
| GLM 5.2 | GLM-5V-Turbo | |
|---|---|---|
| 输入模态 | 仅文本 | 文本、图像、视频 |
| 协议 | MIT（开放权重） | 闭源 API |
| 上下文窗口 | 1M token | 202K token |
| Design Arena | #1（Elo 1360） | — |
| Design2Code | 不适用 | 94.8 |
| 可自托管？ | 是 | 否 |
| 最适合 | 智能体编程、长文档、大上下文推理 | 截图转代码、图像理解、视觉问答 |
这个决定分得很干净。需要视觉输入 → GLM-5V-Turbo。需要规模化文本、开放权重或自托管 → GLM 5.2。
如何给 GLM 5.2 工作流加上视觉能力
如果 GLM 5.2 是你的主力模型，又遇到需要处理截图或图像的任务，绕行方案是两步管线。
第一步：把图像路由给视觉模型。 用 GLM-5V-Turbo、GPT-4o、Claude 或任何接受图像输入的模型，把视觉内容转成详细的文字描述。对 UI 截图，就是描述布局、组件类型、配色方案和层级。对图表，就是描述所展示的数据。
第二步：把文字描述交给 GLM 5.2。 现在 GLM 5.2 可以用它完整的 1M token 上下文和智能体能力对图像内容做推理。对那些视觉解析步骤简单、但下游推理很深的复杂编程任务，这条管线往往表现不错。
BetterStack 的开发者指南说得很直接：GLM 5.2「只接受文本输入；无法直接处理截图」——所以绕行方案是先转换、后推理。
这个办法的局限：它会增加延迟，不适合实时视觉任务，对视觉复杂的输入会丢失保真度。在必须原生多模态的任务上，GLM-5V-Turbo 才是正确的工具。
多模态版 GLM 5.2 会来吗？
GLM 5.2 的 HuggingFace 社区讨论帖里，多位开发者明确要求视觉版本，并把这一差距与 Kimi K2.7-Code、MiniMax M3、Nex N2 Pro（都带原生多模态输入）做不利对比。截至 2026 年 7 月，Z.ai 没有就为 GLM-5.2 产品线添加视觉能力做出任何公开承诺。
他们实际做的是拆分产品线：GLM 5.2 管文本、GLM-5V-Turbo 管视觉。未来的 GLM 5.3 或下一个大版本是否会统一两者，是未定之数。
常见问题
GLM 5.2 能分析图像吗？
不能。GLM 5.2 无法处理图像、截图或任何视觉内容。它是纯文本模型。如果你在 Z.ai 工作流里需要图像分析，用 GLM-5V-Turbo。
GLM 5.2 支持视觉吗？
不支持。GLM 5.2 的输入模态仅限于文本。Z.ai 支持视觉的模型是 GLM-5V-Turbo，2026 年 4 月发布——一个独立的闭源 API 产品。
GLM 5.2 能生成图像吗？
不能，不直接生成。Z.ai 生态里的图像生成由 Seedream——一个专门的图像生成模型——负责。GLM 5.2 生成文本和代码。它们在同一平台上可用，但架构上彼此独立。
我能用 GLM 5.2 做截图转代码任务吗？
不能原生做。截图转代码方面，GLM-5V-Turbo 在 Design2Code 上拿 94.8，是为该任务量身打造的。如果你想用上 GLM 5.2，模式是：GLM-5V-Turbo 解析截图，GLM 5.2 负责下游的代码生成或推理。
GLM 5.2 和 GLM-5V-Turbo 有什么区别？
GLM 5.2：开放权重（MIT）、1M token 上下文、仅文本、可自托管。GLM-5V-Turbo：闭源 API、202K 上下文、原生图像和视频输入、Design2Code 94.8。架构不同、用例不同，同一个 Z.ai 生态。
结论
GLM 5.2 不是多模态的。它不理解图像，也不能分析截图。这正是这模型被设计来做的事：规模化处理文本和代码，带开放权重和同级别里无人能敌的 1M token 上下文窗口。
Z.ai 真正的视觉产品是 GLM-5V-Turbo——闭源 API、原生图像和视频输入、Design2Code 全模型最高分。如果你的工作流需要截图理解，那才是正确的工具。
而对所有在文本里干活的事——长上下文编程、智能体任务、复杂推理——GLM 5.2 是当下最强的开放权重选择。看看它要花多少钱、怎么本地运行，或者它跟 Fable 5 怎么比。上手无需 API key：在 glm5.app 免费试用 GLM 5.2。
