Grok 4.5 实测：更快更便宜的编码黑马，能否取代 Opus 与 GPT？

Grok 4.5 出人意料的进步

提到 Grok，很少有人会将其与顶级编码能力联系在一起。在此之前，它从未真正跻身 Opus 4.8 或 GPT 5.5 这类前沿模型的行列，尤其在编程任务上表现平平。然而 Grok 4.5 彻底改变了这一印象。

一句话概括：如果你一直想要 Opus 4.8 级别的质量，但追求更快、更便宜，Grok 4.5 基本就是答案。这个判断听起来大胆，尤其考虑到 Grok 此前的起点——但确实有充分依据支撑 4.5 相比前代 4.3 的巨大飞跃。

根据 Cursor 官方说法，Grok 4.5 是与 xAI 相关团队联合训练的"最智能模型"，也是首个不局限于软件工程场景构建的模型。与专注编码的 Composer 2.0 不同，Grok 4.5 更像我们熟悉的通用型 Grok——能处理软件工程、数据科学、金融、法律等各类需要创造性使用工具的长时间任务。

别只看跑分：真实表现才是关键

无论是 xAI 还是 Cursor，都发布了各自的基准测试报告。但正如许多开发者的共识，基准测试并非万能。

SWE-bench 是目前业界最广泛引用的代码能力基准之一，由普林斯顿大学研究团队创建，并于2023年在 NeurIPS 会议上正式发表。它从 GitHub 真实开源项目中抽取 issue，要求模型生成能通过对应测试用例的补丁，以此模拟真实软件工程任务。这一设计比填空式编程题更贴近真实工程场景——它不考查语法补全，而是要求模型阅读 issue、理解完整代码库上下文，并生成能让原有测试套件通过的补丁。

值得注意的是，SWE-bench 的评测任务来自 12 个主流 Python 开源仓库（包括 Django、Flask、scikit-learn 等），每个任务对应一个真实的 Pull Request，模型需要在不借助该 PR 的情况下独立复现修复。在基准发布初期，顶级模型的通过率不足 2%；随着智能体框架与模型能力的快速演进，当前领先系统的通过率已突破 50%，这一急速攀升本身也在引发社区对测试有效性的质疑。

其一，GitHub 上的开源代码和 issue 大量出现在各大模型的预训练语料中，测试集本质上已非"未见题目"，存在数据污染风险；其二，部分团队通过在相似问题上精调或专门优化推理流程来针对性地提升得分，与日常开发中的泛化能力严重脱钩。这促使社区开始探索更难以"刷分"的评测方案，例如使用私有代码库或引入人工验证环节。

值得一提的是，SWE-bench 的评测框架本身也在持续演进——SWE-bench Verified 引入了人工标注的"可验证子集"，SWE-bench Multimodal 则开始纳入 UI 截图等多模态输入，试图进一步逼近真实工程场景的复杂度。这些变体的出现，既是对原始基准局限性的正视，也反映出整个社区对"如何衡量真实编程能力"这一问题的持续探索。

一个典型案例值得关注：Cursor 特意没有在博客中公布自家的 Cursor Bench 成绩——尽管 Grok 4.5 High 在该测试上表现优于 Fable 5.0，且成本低得多。原因在于 Cursor 代码库的一个早期快照被意外纳入了训练数据，导致 Grok 4.5 在该测试上存在先天优势。团队虽无法量化具体影响，但已将这部分数据从未来模型的训练集中移除。这恰恰说明，基准测试不应作为唯一评判标准。

真正值得参考的是 Artificial Analysis 的测评。它的价值不在于绝对数字，而在于清晰呈现了从 Grok 4.3 到 4.5 的跨越——从各项测试（人类基线、Terminal Bench 等）的末尾，一跃至前列，与 Opus 4.8、GPT 5.5 等模型基本持平。

价格与效率：真正的杀手锏

Grok 4.5 的定价极具竞争力：每百万输入 token 2 美元，每百万输出 token 6 美元。

对比来看：

• Opus 4.8：每百万输入 token 5 美元，输出 token 高达 25 美元
• GPT 5.5：每百万输入 token 5 美元，输出 token 30 美元

需要补充的是，GPT 5.5 虽然纸面标价更高，但实际使用中 token 效率较好；Opus 4.8 则相对"费 token"。据称 Grok 4.5 的 token 效率约为同类领先模型的两倍，能用不到一半的步骤完成任务。这意味着它不仅按 token 计价更低，实际消耗更少，响应速度也更快——三重优势叠加，性价比相当突出。

理解这一效率优势的底层逻辑，需要引入"有效成本"（effective cost）的概念：在评估 LLM 的实际使用成本时，单纯比较每百万 token 的标价往往会产生误导，真正重要的是"完成单位任务所需的总 token 消耗 × 单价"。如果一个模型能在 3 次工具调用内完成另一个模型需要 7 次才能完成的任务，即便标价更高，实际账单也可能更低。这也是为什么 Cursor 等 IDE 工具商在评估集成模型时，越来越倾向于用"每任务成本"而非"每 token 成本"作为核心指标。

为什么 Grok 能从垫底跃升到前列？

在其他 AI 实验室普遍只有渐进式改进的当下，Grok 的飞跃显得格外引人注目。答案很大程度上藏在 Cursor 收购案中。

收购 Cursor 的核心价值在于数据。Cursor 拥有可观的营收和顶尖人才，但真正能将模型推向下一台阶的，是它多年积累的海量真实开发者交互数据。官方博客基本证实了这一点：Grok 4.5 采用 MoE（混合专家）架构，训练中包含数万亿 token 的 Cursor 数据，涵盖开发者与代码库、软件工具之间的广泛交互。

MoE（混合专家，Mixture of Experts）架构是近年大模型扩展的核心技术之一。其思想最早可追溯至1990年代 Jacobs 等人提出的"专家混合"神经网络，在大模型时代由 Google 的 Switch Transformer（2021年）重新引爆，并经 Mixtral、GPT-4 等项目广泛验证。与传统"密集"模型对每个输入激活全部参数不同，MoE 将模型划分为大量相对独立的"专家"子网络，每次推理时由一个轻量级的"门控网络"动态选择少数几个专家（通常 Top-2）处理当前 token。这一设计使模型总参数量可以做到极大（提升容量与知识储备），而实际推理时只激活一小部分参数（控制计算成本与延迟）——本质上是以内存换算力。

一个典型的 MoE 模型可能拥有数千亿总参数，但每次前向传播仅激活其中约 20-30%，从而在保持高容量的同时将推理延迟控制在与小模型相近的水平。MoE 架构的另一个工程挑战在于"负载均衡"：如果大多数 token 总是被路由到同几个专家，其余专家就会因欠利用而浪费容量，同时过热的专家也会成为性能瓶颈。为此，Switch Transformer 引入了辅助损失（auxiliary loss）来惩罚不均衡路由，后续工作如 Expert Choice 路由则从根本上改变了路由方向——由专家主动"选择" token 而非 token 选择专家，从而在架构层面保证负载均衡。对于需要同时具备代码、法律、金融等跨域能力的 Grok 4.5，MoE 架构提供了一种相对"低成本"的能力扩展路径，这也是其在推理速度上优于部分密集模型的结构性原因之一。

每当开发者在 Cursor 中使用模型——接受修改、要求微调，或彻底放弃某个建议——只要未选择退出，这些反馈都会被保存下来，成为极具价值的训练素材。这类数据在 AI 训练领域被称为 RLHF（基于人类反馈的强化学习）偏好数据，其价值远超无标注的代码文本。RLHF 由 OpenAI 在 InstructGPT（2022年）中系统化落地，核心流程是：收集人类对模型输出的偏好对比（A 比 B 更好），训练一个"奖励模型"来预测人类偏好，再以此奖励信号通过强化学习（通常是 PPO 算法）微调语言模型。

Cursor 积累的数据尤为珍贵，原因在于它覆盖的不仅是静态的代码文本，还包含了完整的人机交互轨迹：开发者接受了哪些建议、拒绝了哪些、如何要求修改、在何种上下文下放弃了某个方向。这种"隐式反馈"信号在公开互联网上几乎不存在，却是让模型真正理解"什么是好的工程判断"的关键。值得注意的是，这类数据还天然包含了"负样本"——被拒绝或被修改的建议同样携带了丰富的信息，告诉模型哪些思路在实际工程中行不通。近年来研究界也在 RLHF 基础上发展出了 DPO（直接偏好优化）等更高效的替代算法，进一步降低了偏好数据转化为模型能力的工程门槛。模型由此既能从现有软件中学习，也能从真实的人机交互中学习"开发者如何工作"以及"智能体如何与环境协作"。xAI 通过收购 Cursor 一举获得了外部市场中罕见的高质量闭环数据资产。

同时，xAI 的硬件资源同样不可忽视——训练跨越数万块 NVIDIA GB300 GPU 并配合专为大规模训练设计的稳定性技术，共同成就了 Grok 4.5 的能力跃升。GB300 属于 Blackwell Ultra 架构，单卡 HBM3e 显存高达288GB，专为训练超大规模语言模型设计。与上一代 H100 相比，GB300 在 FP8 精度下的峰值算力提升约4倍，同时支持 NVLink 第五代互联，节点间带宽大幅提升，这对于 MoE 架构尤为关键——MoE 的专家路由机制会产生大量跨设备的 All-to-All 通信，互联带宽往往是集群效率的瓶颈。

在超大规模训练集群中，这种通信开销通常占据总训练时间的15%至30%，带宽瓶颈的缓解对整体训练吞吐量有乘数效应。除硬件之外，训练大规模 MoE 模型还需要解决"专家并行"（Expert Parallelism）的调度问题：不同于数据并行或张量并行，专家并行要求将不同专家分布在不同设备上，而动态路由意味着每个 batch 中流向各专家的 token 数量不均等，如何在保证计算效率的同时处理这种动态负载，是系统工程层面的重要挑战。然而 GPU 数量只是门票，真正决定训练效率的是集群互联带宽与稳定性工程——在千卡以上规模的训练任务中，节点故障率乘以训练周期通常意味着必须设计完善的检查点恢复与容错机制，这也正是 xAI 专项投入的方向。

实测代码能力：亮点与不足

完成 Fable 5 反复失败的任务

在一个从 macOS 移植到 Linux 的 Rust + Electron 屏幕录制项目中，Grok 4.5 几分钟内就解决了 Fable 5 连续尝试六七次都无法完成的问题。根源是预览"彩虹屏"的连线 bug，而非采集缺失。

Grok 4.5 的修复方案涉及：将软件预览指向 live.jpg 并以 15 FPS 拉取、在 Linux 上跳过预览直播启动以避免 FFmpeg 覆盖合成器帧、重命名 portal source，以及延迟加载 Electron Updater 以防应用就绪前崩溃。这个修复案例颇具代表性：Linux 下的屏幕采集涉及 PipeWire/XDG Desktop Portal、DRM/KMS 合成器帧缓冲与 FFmpeg 视频管道的三方协调，任意一层的时序竞争都可能导致帧数据损坏——彩虹屏正是 YUV 与 RGB 色彩空间错误混用或帧指针越界的典型症状。Grok 4.5 能够同时在 TypeScript（Electron 主进程）和 Rust（原生采集层）两端定位并修复问题，说明它对跨语言、跨进程边界的异步时序问题有相对完整的理解，而非仅做表层语法修复。虽非完美修复，但确实能跑通，且同时涉及 TypeScript 和 Rust 双端改动。

优秀的工程判断力

在用 Rust 构建一个"Java 版 UV"（管理 JDK、原生解析 Maven 依赖的静态二进制工具）时，Grok 4.5 交出了令人满意的答卷：24 个测试全部通过，首次编译成功，Clippy 检查完全干净。

更值得称道的是它展现出的真实工程理解力。在选择安装哪个 JDK 包时，它主动为包 ID 加入了稳定的 tie-break 排序——因为 Foojay API 不保证返回结果的顺序，若缺少这一行，同一安装命令两次运行可能得到不同的包，而这个工具的核心正是可复现性。这种主动防御性编码（defensive coding）意识尤为难得：在 API 契约不明确的情况下，低质量的 AI 代码通常只处理"快乐路径"，而 Grok 4.5 主动识别了一个隐性的不确定性来源并在代码层面消除了它，这正是经验丰富的工程师在 Code Review 中会重点审查的细节。代码风格也相当地道，没有 AI 惯用的嵌套 if 堆砌。

依然存在的短板

当然，问题也客观存在。在选择"最佳已安装 pin"的函数中，Grok 4.5 将语义化版本当作字符串进行比较，导致 209.9 会被误判为大于 209.11。

语义化版本（Semantic Versioning，SemVer）是软件行业标准的版本号规范，由 GitHub 联合创始人 Tom Preston-Werner 于2013年正式提出，格式为 MAJOR.MINOR.PATCH，三个字段均为非负整数，分别代表破坏性变更、向后兼容的功能新增以及缺陷修复，必须按数值而非字典序比较。将版本号视为普通字符串是 AI 生成代码中的常见陷阱——字符串比较时 '2.9.0' 会被认为大于 '2.11.0'，因为比到第三个字符时 '9' 的 ASCII 码（57）大于 '1'（49），算法立即返回结果而完全忽略了数值语义。

这在包管理器或 JDK 版本选择等场景中会导致静默的错误降级或错误升级——程序不会报错，但实际安装的版本可能与预期完全相反，此类 bug 往往极难在测试中发现，因为功能仍然正常运行，只是使用了错误的版本。这类问题之所以在 AI 生成代码中反复出现，部分原因在于预训练语料中存在大量错误示范：Stack Overflow、教程博客上充斥着用字符串比较版本号的代码片段，模型在统计层面学到了这一模式，却没有学到它在数值意义上是错误的。更讽刺的是，项目里已经引入了专门用于版本比较的 jv-version crate，Grok 4.5 却没有复用。此外在 TypeScript 项目中也留有未使用的 shortDomain 死代码——不过这类问题在 Fable 5、GPT 5.5、Opus 4.8 上同样存在，并非 Grok 4.5 独有的缺陷。

一次性生成测试

测试还包括用 Rust 编译到 WebAssembly 制作割草游戏。

结果颇有意思：Grok 4.5 严格遵循了"纯 Rust 编译到 WebAssembly"的提示词；而 Fable 5 虽然架构更优、成品更美观，却擅自引入了 JavaScript 和 CSS，偏离了原始要求。这个对比恰好揭示了两类模型的不同取向：一个忠于指令，一个更倾向于自主发挥。

值得一提的是，Rust 编译到 WebAssembly 本身是一条相对成熟但工具链要求严格的技术路径——Rust 官方工具链对 wasm32-unknown-unknown 目标提供一类支持，配合 wasm-bindgen 和 wasm-pack 可以生成接近原生性能的浏览器可执行模块。与 Emscripten 将 C/C++ 编译到 WASM 的路径不同，Rust 的 WASM 工具链更接近"原生 WASM"：它不依赖 Emscripten 的 JavaScript 胶水层，内存模型完全由 Rust 的所有权系统管理，与 JavaScript 的互操作通过 wasm-bindgen 的过程宏在编译期生成类型安全的绑定。这要求模型准确理解：哪些标准库功能在 wasm32 目标下不可用（如文件系统、线程）、如何通过 #[wasm_bindgen] 暴露 Rust 函数给 JS、以及如何在不引入 JS 依赖的情况下操作 Canvas API——测试难度不低，Grok 4.5 能够在纯 Rust 约束下完成这一任务，说明其对工具链配置和跨语言边界的理解达到了可用水准。

工作流定位：快速迭代型任务的最佳拍档

Fable 5 属于"循环型"模型——你给它一个明确目标，让它在后台协调多个子智能体长时间运行。而 Opus 4.8、GPT 5.5 与 Grok 4.5 则定位不同，其中 Grok 4.5 的响应速度最快。

它在编码能力上与另外两者基本持平，速度却快得多。你给它一个任务，几乎不用等待，一分钟内即可看到结果。对于喜欢与 AI 频繁来回交互的开发者，Grok 4.5 是理想之选。

以下是几种推荐的使用场景：

• 直接替代 GPT 5.5 或 Opus 4.8，享受更低价格与更快速度
• 作为子智能体，让 Fable 5 负责高层编排，把批量执行任务路由给 Grok 4.5
• 配对编程，与 Opus 4.8 或 GPT 5.5 组成"结对程序员"，互相补位

结语：编码 AI 进入三足鼎立新格局

如今编码模型的第一梯队已演变为 Anthropic、OpenAI 与 xAI（借助 Cursor 之力），Google 暂时未能跻身前三。当然，以上结论来自单一测评者约 24 小时的实际体验，未来是否会遭遇限流、性能是否有所变化，仍有待观察。但可以确定的是，编码 AI 领域又多了一位不容忽视的严肃玩家——而且它来得比大多数人预期的都要快。

核心要点

核心要点