过去几周，我故意破坏自己的工作流程，以观察在实际项目、混乱的代码库和不完整的规范中，GLM-4.7 与 GPT-5 的实际表现。

理论上，这两者都是“下一代”、“自主”、“擅长编码”等常见的流行词。在实践中，当我对比测试错误修复、多文件重构和工具使用代理时，GLM-4.7 和 GPT-5 之间的差异远不像宣传中的那么理论化。

在深入探讨之前需要声明一点：GPT-5 的细节仍在发展中，厂商的基准测试结果通常是较为理想化的。我在这里分享的是基于我自己在 2025 年 12 月进行的测试：小规模但可重复的实验，使用相同的提示、代码库和工具对比这两个模型。将此视为实地笔记，而非绝对真理。

让我们来看看 GLM-4.7 与 GPT-5 在编码、代理和对成本敏感的工作流程中究竟有哪些不同。

为什么这个比较很重要

两个模型都强调自主性和编码能力

我之所以费心深入研究 GLM-4.7 vs GPT-5，原因很简单：两家供应商都在宣称同样的东西，更好的代理，更好的编码，更好的推理能力。

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

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

我将它们接入了一个小型的 agent 框架，该框架可以访问：

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

1. 它们能真正交付有效的代码更改吗？

我使用了：

• 从真实开源 Python 项目中提取的约 40 个 SWE‑bench-风格的问题，
• 来自我自己客户工作的几个 TypeScript/Next.js 任务。

1. 它们能保持预算不超支吗？

因为一个“聪明”的代理在一个 bug 修复上悄悄烧掉 $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 与工具

对于使用外部工具的高层次评估（HLE），我测试了一个迷你“分析师”工作流程：

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

这就是 GPT-5 开始展示实力的地方：

• GPT-5 在规划上更胜一筹：它能够提前 2-3 步预测需要用到的工具。
• GLM-4.7 有时候会过度调用网络搜索工具，并重新获取相似页面。

总体而言，在这个小型带工具的 HLE 测试中：

• GPT-5 给出的答案大约有 88% 是我称之为生产就绪的。
• GLM-4.7 感觉有 78% 的答案是生产就绪的，其余的需要轻微的人为清理。

如果你的主要用例是编码加工具，两者都很可靠。如果你的用例是战略分析加工具，个人经验来看，GPT-5 在高端表现上仍然更干净。

价格比较

对于独立开发者来说，GLM-4.7 和 GPT-5 的定价可能在悄无声息中决定你的月度成败。

API 成本（输入、输出、缓存的 tokens）

GPT-5 的确切定价尚未公开，但如果遵循 GPT-4.1/o3 的模式，我们可能会看到：

• 每百万 tokens 的价格高于中国地区的模型
• 对 缓存 tokens 和 重用上下文 可能有折扣

相比之下，GLM-4.7 的定价在成本上更具攻击性，特别是在中国地区，通常每个 token 便宜 30–60%，具体取决于你的地区和供应商。

对于一个典型的编码会话（20 万输入上下文，20–40K 输出 tokens 跨步骤），我看到的运行成本是：

• 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 万个 token），自托管的 GLM-4.7 开始显得比纯 GPT-5 API 策略有吸引力。

重要的架构差异

上下文窗口（200K vs ?）

对于 GLM-4.7，我能够稳定获得大约 200K 的 token 上下文。这足以容纳：

• 一个中等大小的代码库片段，
• 加上一些未解决的问题，
• 加上一些日志和说明。

GPT-5 的确切上下文限制取决于层级/版本，供应商不断进行调整。实际上，我把它当作一个 128K-200K 类模型来使用，在日常编码任务中几乎没有遇到硬性上下文限制。

有意义的区别不在于原始数字，而在于它们的使用方式：

• GPT-5 通常在隐式总结方面表现更好，即使我过度填充上下文也能保持专注。
• GLM-4.7 有时会在非常长的提示中“忘记”早期细节，除非我明确地结构化章节（例如，# 规格，# 代码，# 测试）。

输出长度（128K vs ?）

当我请求完整补丁或测试套件时，GLM-4.7 可以从容地产生非常长的输出，数以万计的标记不会卡住。

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

对于巨大的差异：

• 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则像是一位快速、细心的中级开发人员，会仔细检查类型。

Bug修复循环

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

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

我观察到的模式：

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

测试生成质量

我还要求两者在修复Bug之前生成测试（这是一个非常强大的技巧）：

• 对于 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 vs 双语代码库 vs 内部工具）。

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

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

老实说？别害怕混搭。

在我现在的工具组合中：

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

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

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

这个小实验会比任何营销页面或博客文章（包括这篇）更能告诉你 GLM-4.7 和 GPT-5 对你生活的影响。

然后选择真正为你完成工作的那个，而不是闪亮的基准图表。

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

经过所有这些测试，不舒服的真相是：对于大多数个人和独立工作流程，模型本身的重要性不如围绕它设计的代理。

这正是我们在 Macaron 打造的。我们不押注于单一的“最佳”模型。我们结合了最强大的可用模型和一个真正学习你如何工作的记忆系统——你关心什么，如何迭代，以及通常在哪里出错。

如果你想知道实际使用的感觉，可以亲自试试。 [免费试用 Macaron →]