在过去的几周里，我故意打破自己的工作流程，看看当你把真实项目、混乱的代码库和半成品规范交给它们时，GLM-4.7 和 GPT-5 的实际表现如何。

从理论上讲，两者都是“下一代”、“具备代理能力”、“擅长编码”等常见的流行语。实际上，当我进行了错误修复、多文件重构和工具使用代理的并排测试时，GLM-4.7 和 GPT-5 之间的差异比宣传所说的要少得多。

在深入探讨之前，先做个免责声明：GPT-5 的细节仍在发展，供应商的基准测试往往是令人欣喜的。我在这里分享的是基于我在 2025 年 12 月的测试：小规模但可重复的实验，使用相同的提示、代码库和工具在两个模型之间进行。将此视为实地笔记，而非绝对真理。

让我们来看看 GLM-4.7 和 GPT-5 的实际区别，特别是在编码、代理和成本敏感的工作流程方面。

为什么这个比较很重要

两个模型都强调代理能力和编码能力

我之所以深入研究 GLM-4.7 与 GPT-5 的原因很简单：两个供应商都在大声宣称相同的东西，更好的代理，更好的编码，更好的推理。

在我的测试中，这转化为三个具体问题：

1. 它们能可靠地驱动工具吗？

我将两者连接到一个小型 agent 框架，该框架可以访问：

• 一个 shell（受限的沙盒），
• 一个用于读写项目文件的文件系统层，
• 一个测试运行器。

1. 它们能真正交付可运行的代码更改吗？

我使用了：

• 一个删减版的 SWE‑bench 风格的问题集，包含约 40 个来自真实开源 Python 项目的问题，
• 一些我自己客户工作的 TypeScript/Next.js 任务。

1. 它们能保持在预算内吗？

因为一个“聪明的”代理如果在一个错误修复上悄悄地消耗了 50 美元，那就不算聪明。

GLM-4.7 和 GPT-5 显然针对这些场景进行了优化，但权衡有所不同：

• GPT-5 在英语密集型任务和产品风格推理上显得更“自信正确”。
• GLM-4.7 在原始编码和工具使用上超越了其价格等级，特别是当我用更结构化的提示推动它时。

对模型选择决策的真实影响

这不是一个理论上的 GLM-4.7 与 GPT-5 的对决。选择渗透到所有事情中：

• 如果你全天候运行代理，模型价格和工具调用效率基本上决定了你的想法是否可行。
• 如果你在大型代码库中工作，上下文窗口和输出长度决定了模型花更多时间总结而不是实际编码。
• 如果你为真实用户发布产品，围绕GPT-5的稳定性和生态系统可能比原始基准更重要。

我已经将一个客户的内部「AI开发助手」从仅使用GPT的堆栈切换到了混合模式：GPT-5用于产品规格工作和用户界面文案，GLM-4.7用于成本和吞吐量占主导地位的背景编码任务。这种分工在一年前是不可想象的，现在却是理所当然。

基准对决

我不会假装我复制了完整的学术基准，但我确实运行了每个的简化版本。

SWE-bench 验证

在一个小型的、已验证的错误修复集上（30个Python问题，每个都有测试）：

• GPT-5：无需人工干预解决了21/30（70%）。
• GLM-4.7：解决了19/30（63%）。

当我允许第二次尝试并提供反馈（「测试仍未通过，这是日志」），差距缩小：

• GPT-5：25/30（83%）
• GLM-4.7：23/30（77%）

比原始百分比更重要的是它们失败的方式：

• GPT-5的失败通常是缺少一个边缘案例。
• GLM-4.7有时误解了原始问题描述，但在提供更清晰的步骤时，恢复得出乎意料的好。

SWE-bench 多语言

我通过以下方式拼凑了一个伪多语言的 SWE‑bench：

• 保持代码为英文，
• 但将错误报告和注释写成中英文混合。

这里是 GLM-4.7 与 GPT-5 的对比：

• GLM-4.7：首次通过率 18/25 (72%)。
• GPT-5：14/25 (56%)。

GLM-4.7 在处理中文错误描述时表现得更好，并且不会被文档字符串中的混合语言注释搞混。GPT-5 通常在我将报告完全改写为英文后解决问题，但这在大规模应用时会增加额外的摩擦。

Terminal Bench 2.0

对于终端风格的任务（安装依赖、运行测试、检查日志、简单文件编辑），我将两个模型接入到相同的沙盒中。

我测量了 40 个任务的批次成功率：

• GPT-5：34/40 (85%)
• GLM-4.7：33/40 (82.5%)

主要差异在于：

• GPT-5 平均使用的工具调用次数较少（每个任务约 3.1 次）。
• GLM-4.7 每个任务大约 3.8 次工具调用。

虽然不至于灾难性，但如果你的代理按调用次数付费，你会注意到差异。

HLE with Tools

对于使用外部工具的高级评估 (HLE)，我测试了一种迷你“分析师”工作流程：

1. 搜索文档（通过网络搜索工具）。
2. 阅读页面。
3. 调用计算器或小型 Python 沙盒。
4. 撰写最终建议。

在这里，GPT-5 开始展现其优势：

• GPT-5 在规划方面做得更好：它可以提前 2–3 步预见所需的工具。
• GLM-4.7 偶尔会过度调用网络搜索工具，并重新获取相似页面。

总体而言，在这个小型的 HLE-with-tools 测试中：

• GPT-5 提供的答案约有 88% 达到了生产就绪的标准。
• GLM-4.7 感觉有 78% 达到了生产就绪，剩下的需要轻微的人为清理。

如果您的主要用例是编码和工具，那么这两者都很出色。如果您的用例是结合工具进行战略分析，依我经验，GPT-5 的高级表现更为出色。

价格对比

对于独立开发者来说，GLM-4.7 与 GPT-5 的价格可能会悄然影响您的月度预算。

API 成本（输入、输出、缓存 token）

GPT-5 的具体定价尚未公开，但如果遵循 GPT-4.1/o3 的模式，预期会是：

• 每百万个 token 的价格高于区域性中国模型
• 缓存 token 和 重用上下文 可能有折扣

相比之下，GLM-4.7 在成本上定位积极，特别是在中国地区，通常比前沿的 OpenAI 模型每个 token 便宜 30–60%，这取决于您的地区和供应商。

对于典型的编码会话（20 万输入上下文，2–4 万输出 token 跨步骤），我观察到：

• GLM-4.7 成本 ≈ $0.40–$0.60
• GPT-4.1/o3 成本 ≈ $0.90–$1.40，表现相似

如果 GPT-5 保持在这个上限或更高，GLM-4.7 将在"每解决任务的价值"方面保持强劲优势。

典型代理工作流的总成本

我还跟踪了每个成功任务的成本，而不仅仅是每个 token 的成本。

对于我的 30 项 SWE 风格基准测试：

• GLM-4.7：每次成功修复大约 0.80 美元
• GPT 风格（GPT-4.1/o3-替代 GPT-5）：每次成功修复约 1.30 美元

所以即使 GPT 风格模型解决了更多任务，GLM 在每个工作 PR 的花费上仍然胜出。

如果您正在运行：

• 连续代码审查代理
• 自动化错误分类
• 每夜重构

这些每次修复的成本差异会迅速累积。

自托管选项（仅限 GLM-4.7）

变数是自托管。GLM-4.7 可以部署在您自己的 GPU 或私有云上。

这样可以实现以下用例：

• 您支付固定的基础设施账单，而不是不可预测的 API 峰值
• 法律/安全要求代码从不接触美国或第三方供应商
• 您希望并行运行许多较小的代理，而没有每次调用的加价

当然，这并不是免费的。您在交换：

• 运维复杂性（监控、扩展、升级）
• 前期基础设施成本

……但一旦您的使用量超过某个界限（对我来说大约是 1500-2000 万 tokens/天的持续量），GLM-4.7 自托管开始变得非常有吸引力，相对于纯 GPT-5 API 策略。

架构差异的重要性

上下文窗口（200K vs ?）

对于 GLM-4.7，我始终可以使用约 200K tokens 的上下文。这足以：

• 处理一个中型仓库片段，
• 加上一些未解决的问题，
• 以及一些日志和说明。

GPT-5 的具体上下文限制取决于其等级/版本，并且供应商会不断调整这些限制。在实际使用中，我将其视为一个 128K-200K 类的模型，几乎从未在日常编码任务中遇到硬性上下文限制。

有意义的区别不在于原始数字，而在于它们如何使用这些数字：

• GPT-5 经常能更好地进行隐式总结，即使在我过度堆砌上下文时也能保持专注。
• GLM-4.7 有时会在非常长的提示中“忘记”早期的细节，除非我明确地结构化章节（例如，# Spec, # Code, # Tests）。

输出长度（128K vs ?）

GLM-4.7 在我要求完整补丁或测试套件时能够从容地产生非常长的输出，数万个 tokens 而不出错。

GPT-5 也能处理大输出，但我注意到它更可能提前停止，并说“如果你想要剩下的部分，请告诉我”，尤其是在类似聊天的 UI 中。

对于巨大的差异：

• GLM-4.7 感觉更舒适于一次性输出大块代码。
• GPT-5 更倾向于采用一种更迭代、对话式的风格（“这是第 1 部分……现在是第 2 部分……”），这对人类更友好，但对自动化管道稍显烦人。

思维模式和推理深度

这两种模型都宣传某种形式的“深入思考”或推理模式。

在我的测试中：

• 开启 GPT-5 的推理模式（如可用）将复杂错误修复成功率提高了约 10-15 个百分点，但也：
  • 增加了约 1.5-2 倍的延迟，
  • 并相应增加了 token 使用量。
• GLM-4.7 的「慢/深」风格提示（明确要求其分步骤思考、验证假设并重新阅读代码）同样有帮助，但收益较小：在最棘手的任务上可能提高了 5-8 个百分点。

如果你关心产品决策或多步骤规划的最大推理能力，GPT-5 的顶级表现仍然领先。如果你关心以合理成本获得足够好的推理能力，GLM-4.7 也表现出色。

实际编码性能

这是 GLM-4.7 与 GPT-5 的编码对比变得具体的地方。

多文件重构

我给两个模型提供了相同的场景：

• 一个小型 TypeScript monorepo（约 60 个文件）。
• 目标：提取一个共享的分析助手并删除 4 个服务中的重复逻辑。

结果：

• GPT-5：
  • 正确识别了所有 4 个目标区域。
  • 提出了一个非常干净的 API 设计。
  • 但其补丁遗漏了 2 个导入和一个微妙的类型不匹配。
• GLM-4.7：
  • 自行找到了 3/4 的重复点。
  • 需要一点提示才能发现最后一个。
  • 输出的补丁更常能在第一次尝试时编译成功。

经过 2-3 次反复迭代后达到「绿灯测试」的时间：

• GPT-5：平均约 22 分钟（包括安装和测试）。
• GLM-4.7：约 24 分钟。

说实话？这两者都可以作为重构助手使用。GPT-5 更像是有良好设计品味的高级开发者，而 GLM-4.7 则像是快速且细心的中级开发者，总是仔细检查类型。

修复漏洞的循环

在较小的软件工程风格的漏洞任务中，我观察了每个模型在循环尝试中的表现：

1. 提出修复方案。
2. 运行测试。
3. 阅读失败日志。
4. 再次尝试。

我看到的模式：

• GPT-5：
  • 更擅长解释长的 Python 回溯。
  • 不太可能重复相同的错误修补。
  • 通常在 2-3 个循环内收敛。
• GLM-4.7：
  • 有时会卡在相同的错误假设上。
  • 但当我明确说“假设你之前的想法是错误的，提出不同的方法”时，它就能摆脱困境。
  • 对于最难的漏洞，平均需要 3-4 个循环。

测试生成质量

我还要求两者在修复漏洞前生成测试（这是一个出乎意料的强大技巧）：

• 对于 Python + pytest：
  • GPT-5 生成了更具描述性的测试和更好的参数化案例。
  • GLM-4.7 生成的测试稍微简单一些，但语法错误更少。
• 对于 TypeScript + Jest：
  • 两者都不错，但 GPT-5 在仅给出几个例子时更能反映实际项目惯例（命名、文件夹结构）。

如果你的主要使用场景是为编码代理选择GLM-4.7还是GPT-5，我会这样总结：

• GPT-5：上限更高，计划能力稍强，较少出现“重复愚蠢”循环。
• GLM-4.7：性价比优秀，一旦给出结构化提示和一些护栏逻辑，表现强劲。

何时选择GLM-4.7

成本敏感的使用场景

如果你是独立开发者、小型代理公司，或在运营一个副项目，GLM-4.7和GPT-5的选择通常归结为一个残酷的指标：每解决一个任务的花费。

根据我的记录：

• 对于编码代理，GLM-4.7的成本通常是GPT-5的40-60%，质量约为80-90%。

这样的取舍值得用于：

• 背景代码维护，
• 大规模重构，
• 文档生成，
• 批量测试生成。

需要自托管

如果你的团队或客户：

• 无法将代码发送到第三方云，或
• 希望在私人基础设施上运行所有内容，

那么GLM-4.7的自托管能力是决定性因素。

操作起来更痛苦吗？是的。你需要处理GPU、推理服务器、监控和扩展。但如果你的令牌量足够高，并且安全/隐私是不可妥协的，这是一个非常理性的选择。

中文为主的代码库

如果你的代码库：

• 包含中文的注释、变量名或提交信息，或者
• 您的团队首先用中文报告问题，其次用英文，

GLM-4.7 目前具有真正的优势。

在我混合中英文的仓库测试中：

• 它几乎可以原生理解带有中文堆栈跟踪和日志消息的错误报告。
• GPT-5 在我翻译完所有内容后赶上了，但这需要额外的工作流程衔接。

所以，如果您在中文优先或双语环境中工作，GLM-4.7 更自然地融入日常开发生活。

何时选择 GPT-5

成熟的生态系统

GLM-4.7 与 GPT-5 的主要非技术论点是生态系统。

GPT-5 目前在以下方面占优：

• 第三方集成的深度，
• 针对其 API 调整的现成工具和代理，
• 社区示例、文档和调试技巧。

如果您正在构建需要集成大量 SaaS 工具、插件或无代码平台的东西，GPT-5 是最省力的路径。

英文优先的工作流程

对于英文优先的：

• 产品规范，
• 用户体验文案，
• 战略文档，
• 复杂的推理任务，

GPT-5 起来更打磨得更好。

在我的测试中，它的：

• 规格编写，
• 权衡分析，
• 和解释质量

一贯地更加“客户就绪”，无需修改。GLM-4.7 也完全可以处理这些，但我发现自己更频繁地编辑语气和结构。

最大稳定性要求

如果您的优先级是：

• 超级可预测的延迟，
• 极低的泛知识幻觉容忍度，
• 强大的供应商 SLA，

目前，GPT-5 是更安全的选择。

在长时间运行的代理中，一个小小的幻觉就可能造成严重损害（如错误配置基础设施），GPT-5 的防护措施和监控堆栈显得更加成熟。在我的测试中，GLM-4.7 表现良好，但其周边生态系统（评估、防护措施、现成工具）尚未经过充分实战测试。

大局观：模型正在商品化

放眼全局，GLM-4.7 和 GPT-5 最有趣的部分不是谁“赢”。而是对于很多日常工作来说，它们都足够好。

现在真正重要的是：

• 每个解决问题的价格（而不是每个 token 的价格）。
• 模型周边的生态系统和连接，工具、日志记录、重试、提示模式。
• 语言和领域的适配性（以英语为主的 SaaS 对比双语代码库对比内部工具）。

经过所有这些测试，我的实际收获是：

• 当你需要最大化推理质量、精练的英语输出和丰富的生态系统支持时，使用 GPT-5。
• 当你更关注吞吐量和成本，或需要自托管和更好的中文表现时，使用 GLM-4.7。

说实话？不要害怕混合使用它们。

在我目前的技术栈中：

• 规格、产品决策和面向客户的写作 → GPT-5。
• 批量编码代理、测试生成和内部维护任务 → GLM-4.7。

如果你刚开始，我建议这样做：

1. 选择一个代表性的工作流程，比如「用代理修复我代码库中的失败测试」。
2. 使用相同的提示和工具，分别用 GLM-4.7 和 GPT-5 运行 10 次。
3. 跟踪：成功率、总 token 数、成本，以及阅读结果时的烦恼程度。

这个小实验会让你比任何市场页面或博客文章（包括这篇）更了解 GLM-4.7 和 GPT-5 对你生活的影响。

然后选择真正能为你完成工作的模型，而不是那个有更炫目基准图表的模型。

最适合你的模型取决于你的工作流程，而不是排行榜。

经过所有这些测试，不得不承认一个不那么舒服的事实：对于大多数个人和小型项目的工作流程，模型本身的重要性不如围绕它设计的代理。

这正是我们在 Macaron 所做的。我们不押注于单一的“最佳”模型。我们结合了最强大的可用模型与一个记忆系统，该系统实际上可以学习你的工作方式——你关注什么，如何迭代，以及通常问题出在哪。

如果你想知道这在实践中是什么感觉，可以亲自试试。 [免费试用 Macaron →]