对比Grok4.5,一名Cursor工程师的Grok4.6月度评测报告

Grok 4.6 发布了！过去几周，我一直把它作为日常主力模型，处理各种常规的编程和知识工作，也专门用它做了几个项目，测试它到底能做到什么程度。

它几乎什么都能做得很好。真正让我印象最深的，与其说是某一项能力有了多大的跃升，不如说是它的沟通方式和速度。

信息密度高的沟通

它很适合协作，和它一起工作很自然。它给出的总结包含大量真正有用的信息，而不是重新复述一遍任务；在运行过程中，它会用简短的更新告诉我当前进展，让我知道是否需要中途打断。

处理小改动时，它基本保持安静；一旦开始涉及大量文件，它才会开始主动说明正在做什么。

把这个界限拿捏好，比你想象的更需要调教。当然，它有时还是会告诉我一些其实不需要知道的事情，我们还在继续改进。

令人愉悦的速度

4.5 本来就很快。4.6 不仅快，而且明显更聪明，这种组合让我开始倾向于一种更加同步的工作方式。

与其一开始塞进去大量上下文，然后等它完成，我现在更倾向于先让它做一件小事，看结果，然后继续推进。如果需要做一个更长期的任务，同一个会话里直接告诉它即可。

我会根据当月不同模型擅长的事情，在同步和异步之间切换。异步工作可以让我离开电脑时也继续推进，但代价是容易丢失上下文，回来后面对一大堆 diff，还得重新理解。4.6 又把我拉回了同步工作方式，而当我真正关心结果时，这其实也是我更喜欢的方式。

我还用 Remotion 分别为它们做了一个发布视频！

这几周的大部分时间其实都是普通工作。它可以替我操作网站，包括通过点击服务商的控制台创建 API Key；可以对正在运行的应用进行功能和视觉 QA；还可以帮我把收件箱清理到只剩下真正需要回复的几个线程——这种感觉总是很好。

它还帮助我起草了 Cursor SDK Bridge 和 /rename-chat 的发布帖子。

短提示词，严格验证

这几周里，我还花了一部分时间比较不同的提示词写法。长提示词和短提示词之间有什么区别，以及像“努力工作”这样的特定措辞到底会不会改变结果。

我的发现是：措辞本身几乎没有影响。

但长度确实有影响，只是和我原本想的不太一样。

长提示词能够提供更多具体信息，所以如果你确切知道自己想要什么，就把它写下来。短提示词则意味着把更多决策权交给模型自己的判断。

过去，这种权衡往往意味着最好把所有东西都写清楚。但 4.6 的判断力已经足够好了，所以现在，一个简短的提示词，加上明确的偏好，通常就能得到不错的结果。

我做过的一个项目是电子表格应用。我分别给两个模型做了两次。

其中一次，我给了它一份两页的规格说明，涵盖我能想到的每一个工具栏项目、键盘快捷键和公式。另一次，我只给了它三句话：

用 Next.js 构建一个精致的、类似 Sheets/Excel 的应用，并加入一个能够分析表格的 AI 聊天功能。所有 AI 功能都使用 Cursor SDK。预加载一个真实感的示例工作簿，让应用一打开就看起来不错。

最终两个应用几乎一模一样。

真正改变结果的，是我多加了一句话：

实现后验证功能和设计，并持续迭代和验证，直到达到生产就绪状态。

这是我那几周里发现的杠杆率最高的一句话！

有了这句话，模型会打开应用，按照真实用户路径点击操作，检查嵌套公式是否正确计算，然后修复发现的问题。

如果没有扎实的浏览器操作能力，这一切都无法实现，而正是浏览器操作让这个验证循环成为可能。

当输出更难直接检查时，同样的原则依然成立。

在一个 3D 场景里，我说“改善纹理”，结果几乎什么都没发生；但如果说“截取当前画面，列出其中存在的问题，然后只修复这些问题”，它马上就能做对。

从这里开始的所有比较，都是让两个模型在相互隔离的工作区里使用完全相同的提示词运行，因此这些结论不是我对上个月结果的主观记忆。

你也不需要告诉它“努力工作”或者“继续推进直到完成”。

它自己就会持续工作相当长一段时间。

真正重要的是告诉它“完成”到底意味着什么，否则这个判断就会由模型自己来做。

继续深入

我小时候玩过多得离谱的《帝国时代 2》。玩了几千个小时。所以，我第一个想尝试的项目就是重现它。

我要求它制作一个浏览器策略游戏，需要包含经济、建造、战斗、战争迷雾、任务目标，以及一个即使新玩家不看说明也能理解的 HUD。

4.5 做出了一个可以运行的扁平化原型。4.6 第一次尝试就做出了一个等距视角的 3D 世界，HUD 和小地图也已经就位。

离真正的游戏更近了！

还沉浸在怀旧情绪里，我接着做了 MSN Messenger。

两个模型显然都知道参考对象，而且都做得不错。但 4.6 的完成度更高，从独立的对话窗口，到“眨眼”等功能，都还原得更细。

我一直在使用 Excalidraw，而且它是开源项目，所以这是一个很适合测试模型如何处理真实代码库的地方，而不是面对一个空文件夹。

我让两个模型都增加一个演示模式：保存命名视图、重新排序，然后把它们作为一个引导式演示逐一展示。

提示词特意没有告诉它应该怎么实现。

两个模型最终都大致做到了同样的结果，这对于如此模糊的提示词来说已经非常令人印象深刻！

只是 4.6 在第一次实现时更加关注细节。实际工作中，这意味着我需要指出问题并要求修改的轮次更少。

这也是跳过验证会带来问题的地方。

在更早的一次运行中，模型的总结看起来已经完成了，但实际上添加视图的功能根本没有正常工作。

我只说了一句“运行它并展示给我”，就发现了那个损坏的 import。

日常工作

我不是每天都做演示文稿和报告，但很多人每天都在做。所以我想看看它处理这类工作的能力。

我给两个模型相同的一份虚构季度数据，让它们制作一份董事会汇报材料。

两个模型都具备足够的能力，差距主要体现在呈现方式，而不是分析能力上。

4.5 基本上是把数字放到幻灯片里；4.6 则真正花时间处理结构和层级关系，所以最终看起来更像是一个人真正制作出来的演示文稿，而不是一份数据倾倒。

用代码制作视频

Remotion 是一种“视频即代码”的方式：每一帧都是一个 React 组件，根据当前帧数进行渲染；整个项目通过无头 Chromium 和 FFmpeg 编译成 MP4。

视频本身存在于 Git 中。这是一种真正有趣的工作方式！

但把这种任务交给模型也很奇怪，因为你不能仅仅通过“它能不能运行”来判断它是否成功。

这一部分值得多说一些，因为我最近花了很多时间在这上面。

我让它基于 Remotion 制作一支 60 到 90 秒的 X TypeScript SDK 发布视频，并把相关文档提供给它。

我主要从两个方面判断结果：有没有故事线，以及节奏是否成立。

大多数模型在这里都会以同一种方式失败：全大写标题、方框文字，然后所有东西同时出现在屏幕上。

这两个视频大部分都避免了这些问题，而 4.6 看起来更有吸引力。

在几天时间里，我用不同模型反复测试这件事后发现，视频是我看到模型之间差距最大的领域。

两个在 Web 应用开发上感觉能力相当的模型，在视频上可能完全不是一个水平。

需要引导的地方

几乎所有我需要引导模型的地方，最终都可以归结为一个问题：模型有多容易验证自己的工作。

网站是最简单的情况。DOM 本身就是文本，所以模型可以读取页面、截图，然后将结果与自己的预期进行比较。

这也是为什么验证循环在 UI 工作中如此有效。

3D 就更难了，因为有一个完整的维度无法通过阅读来检查。

视频更难，因为时间本身又增加了一个维度。验证工作意味着截取一系列画面，并理解它们之间的变化。

物理同样属于这一类问题。

模型对世界应该如何运行有不错的直觉，但要确认世界实际上是否按照预期运行，仅靠一张截图是无法回答的。

实际的解决办法，要么给模型一种“看”的方式，要么接受由你自己来检查。

为什么它成了我的默认模型

那些在某一件事情上极其出色的“尖峰型”模型当然有真正的价值。

但我的大部分工作并不是某一件特定的事情。

我每天真正需要的，是一个我足够了解的模型：我已经对它的行为形成直觉；它足够可靠，可以把工作交给它；同时我也足够了解它的缺点，可以不假思索地绕开这些缺点。

这正是 4.6 对我来说已经变成的东西。

在编程方面，它能够处理交互式和视觉工作——我可以随着它的推进实时做出反应，也可以让它在真实代码仓库里进行长时间工作。

在知识工作方面，它可以处理收件箱、浏览器 QA，以及那些背后没有 API、只能通过点击完成的任务。

它并不是这些事情中任何一项都做到理论上的最好，但它所有事情都做得很好，而且我知道应该对它抱有什么预期。

当然，在输出结果最终要根据“看起来怎么样”来判断时，我仍然会参与其中。

动效、3D 和最终润色，都需要参考对象和截图验证循环，而不是简单的文字描述。

我也会把验收标准写下来，而不是相信一份说“已经完成”的总结。

试试看

Grok 4.6 现在已经可以在 Cursor、SpaceXAI API、OpenRouter，以及其他你获取 token 的地方使用！

试试看，然后告诉我你的感受。

我们会继续改进它，所以无论反馈是好的还是坏的，都欢迎留下来，因为这正是我们判断下一步应该往哪里推进的依据。

很期待看到你最终会用它做出什么！