# 没截跑分图，直接挂了一天真活——Grok 4.5 够格当我默认引擎了 - 发布日期: 2026-07-11 · 分类: AI Grok 4.5 放出来那天，我没截跑分图发朋友圈。我干的事更笨：直接把它塞进我手头的日常——写代码、拆任务、跑 agent、改多文件项目、走内容链路，从早到晚全是真活，没有一条是"演示场景"。 跑完这一天，我的判断很干脆：它够格顶替 Claude Opus，坐到我默认引擎的位置上。 我说的不是"某个场景偶尔好看一点"。是整条工作流能长期挂着跑、不用频繁手动换挡的级别。有些时段的手感，甚至比我平时在 Bedrock 上调 Claude API 还顺，摩擦感很低。更关键的是，它把接近 Gemini Flash 的速度和接近 Opus 的输出质量塞进了同一个模型里。这种配置，不认真测一轮说不过去。 ![Grok 4.5：默认引擎换位](https://aicyber.de5.net/sites/blog-252d6582/shared/images/cover-20260711-grok45-default-engine.webp) ## 先把基本盘摆清楚 官方定位很直白：Grok 4.5 是 SpaceXAI / xAI 目前最强的模型，主攻 coding、agentic 任务和知识工作。7 月 8 日上线，训练阶段跟 Cursor 有深度协作，服务速度大约 80 TPS，上下文约 500K，定价 $2 / $6（每百万 input / output tokens）。 公开基准里有几条数字我觉得挺有信息量：
维度 Grok 4.5 对照
Terminal Bench 2.1 83.3% 与 GPT-5.5 xhigh（83.4%）、Fable max（84.3%）同档
SWE Marathon pass@1 29.0% 高于 Opus 4.8 max（26.0%）、Fable max（24.0%）
SWE Bench Pro resolve 64.7% 介于 Opus 4.8 max 与 Opus 4.7 max 之间
服务速度 约 80 TPS 官方强调达到 fast / flash 档吞吐
Token 效率 SWE Bench Pro 平均约 1.6 万 output tokens 约为 Opus 4.8 max（约 6.7 万）的 1/4.2
价格 $2 / $6 明显低于多数旗舰档位的体感账单
这些数字不用死记。它们拼在一起只说明一件事：Grok 4.5 是冲着真实工程和 agent 工作流去的，不是"又一个会答题的大模型"。 训练阶段它把大量算力压在了多步软件工程任务和长时程 agentic rollout 上，还明确以"单位 token 的智力密度"做优化。我理解这句话的意思是：同一件活，它尽量用更少的输出、更短的路径收工。 对天天跑 agent 的人来说，这点比榜首排第几更要紧。我踩过一次坑——某个模型 benchmark 排名很靠前，但实际跑多步任务时车轱辘话特别多，token 烧得吓人，最后我把它从主力位上撤了。那次之后我就认准一个标准：别光看它答得漂不漂亮，看它收工时烧了多少 token。 ![Grok 4.5 的关键数字](https://aicyber.de5.net/sites/blog-252d6582/shared/images/illust-20260711-grok45-numbers.webp) ## 真正让我点头的不是分数，是"摩擦" 过去一年我换过不少模型：Claude 各代、Codex / GPT 系列、Gemini 的快慢档，还有各种中转通道和 Bedrock 线路。分数肯定要看，但决定一个模型能不能被我设为默认的，往往是另一组更土的问题： - 慢不慢？等到心焦，你就不会常开它。 - 贵不贵？一次调用心疼，你就会下意识地降配。 - 接不接得进现有工作流？接口拧巴、工具调用别扭、跟 harness 对不齐，再强也当不了主力。 - 输出稳不稳？写出来的东西能不能直接进项目迭代，免得每次都大修。 它快。快得接近 Flash 的使用习惯，不是"旗舰里勉强算快"那种。我丢一个中等复杂度的改动进去，不会陷入泡了杯茶还在转圈的状态。 它省。官方数据里，SWE Bench Pro 任务的平均输出 token 大约只有 Opus 4.8 max 的四分之一。我的体感也差不多：同一个子任务跑完，它绕圈更少、废话更少，账单压力小了一截。 它顺。这点最难量化，也最关键。我现有的项目迭代方式——拆任务、改多文件、接工具、自检一轮再交付——几乎不用为它重写。模型换了，工作流原样保留。有些时候，这种低摩擦带来的实际交付，比我在 Bedrock 上调 Claude API 还顺。 这跟 Claude 突然变差没有关系。是把速度、成本、兼容性、输出质量放进同一张账本之后，Grok 4.5 已经够格坐上主驾驶位。 ![真正拉开差距的是摩擦](https://aicyber.de5.net/sites/blog-252d6582/shared/images/illust-20260711-friction-gap.webp) ## 把"快"和"强"塞进同一个默认选择 不少人选模型习惯了二元对立：图质量就上 Opus / 旗舰慢档，图速度就上 Flash / mini / haiku。结果是工作流被撕成两半，简单活丢给快模型，难活再切回慢模型。来回切换本身就有成本，你得判断什么时候该升档，还得同时接受两套不同的输出风格和失败模式。 Grok 4.5 的价值，恰恰是把这个矛盾压进同一个默认选择里：日常速度贴着 Flash，输出质量贴着 Opus。 这对一个人做产品、一个人带一串 agent 的人来说尤其重要。你没有专职的"模型调度员"，你需要的是大多数时候扛得住的默认引擎，别是一台要频繁手动换挡的车。 我这一天粗粒度的感受，压成三条： - 写代码 / 改项目：能直接进迭代，而不只是拿来看看； - agent 长链路：工具调用和多步推进更干脆，无效展开少了一大截； - 内容与知识工作：结构清楚、返工轮次少，配得上"主力"这个位置，而不只是尝鲜。 ![速度与质量的交叉点](https://aicyber.de5.net/sites/blog-252d6582/shared/images/illust-20260711-speed-quality-cross.webp) ## 我测的不是聊天窗口，是项目迭代 很多人测新模型，测的是聊天窗口。我这次测的是项目迭代。差别很大。 聊天窗口比的是单次回答漂不漂亮。项目迭代比的是另一组东西： - 你敢不敢让它动一组真实文件； - 改完之后的 diff 是否可控； - 它懂不懂你现有的目录、约定和历史坑； - 多轮之后会不会把架构越改越脏； - 跟你外面那圈 harness（工具、记忆、验收、预算）是否合拍。 过去两年我反复说过一个观点：真正拉开产品差距的，常常是模型外面那圈壳，而非模型本身。但壳再好，发动机太慢、太贵、太拧巴，壳也会被拖累。Grok 4.5 的意义，在于让那圈壳终于能转得更轻快。 也正因为这样，我不建议"为了用 Grok 把整套系统推倒重来"。我走过的更合理的路径是这样： - 先在现有工作流里把默认模型换掉； - 挑最重的 5～10 个真实任务做对照； - 盯住返工率、耗时、费用、可合并率四个指标； - 再决定它是当主引擎、副引擎，还是特定场景专用。 ## 代价和边界，我得说透 凡是"可以当默认"的判断，只讲爽点就不完整。 第一，默认不等于唯一。复杂长推理、高度依赖某个模型风格的写作、你已经为特定模型深度调过的专用链路，可能仍会留在 Claude / GPT / Gemini 上。默认引擎管 80% 的日常，管不了全部场景。 第二，效率红利跟任务形态有关。token 更省，主要体现在那些它少废话、少无效探索的任务上。如果你的 harness 本身就在狂打日志、狂刷上下文，模型再省也救不了上层的浪费。 第三，生态和地区策略仍要盯紧。目前官方在 Grok Build、Cursor、API console 可以直接用，部分地区的可用性还在滚动放开。企业接入时，合规、开票、路由、额度管理，归根到底都是产品问题，而非模型问题。 第四，别拿"跑分第一"替代"业务验收"。Terminal Bench、SWE 系列很有参考价值，但你的业务上下文、代码规范、交付标准，只能由你自己的回归集说了算。谁能进默认位，最终取决于你的合并率和事故率。 我现在的用法不复杂：Grok 4.5 先接主链路，旧旗舰留作对照和兜底，每周拿真实任务复盘一次，避免被某一次惊艳绑定。 ![默认引擎的边界](https://aicyber.de5.net/sites/blog-252d6582/shared/images/illust-20260711-default-boundary.webp) ## 红利怎么收进来 模型强只是起点，能不能变成稳定生产力，看你怎么接。 我这边的路径分三层： 个人 / 小团队层：先把默认换掉，再谈重构。别一上来就重写 agent 框架。先把日常编码、评审、文档、内容生产的默认模型切到 Grok 4.5，跑一周真实任务，谁该留下，数据会替你回答。 产品层：把"快且强"做成交付层面的东西，别停留在体感。 企业层：关键在开箱即用，避免每人自建一套。企业要的，是能嵌进现有工作流的服务：额度、路由、审计、稳定性、账单。一个孤立的模型名远远不够。 ## 收个尾 Grok 4.5 最值得认真对待的地方，不在于又一次"榜上有名"。而在于它把过去被迫拆开的两件事重新合在了一起：旗舰级可用的输出质量，配上 Flash 级别可接受的速度与成本。 我跑了一整天：工作流不用推倒重来，项目迭代对得上，摩擦低到我愿意把它设为默认，有时甚至比 Bedrock 上的 Claude API 更顺手。 这就够构成一条行动建议了：别再只把 Grok 4.5 当备用模型。拿你手里最重的真实任务测一轮，看它配不配坐主驾驶位。分数可以参考，截图可以看看，但真正决定换不换引擎的，是你那条天天在转的工作流，能不能因为它变得更轻、更快、更稳。 我这边已经开始动手换了。模型会轮番发布，但我真正关心的，始终是哪一个能低摩擦地扛起默认工作流。如果你也在测 Grok 4.5，欢迎聊聊你真实任务里的手感。