花了300美元实测Grok Build CLI，快爽贵但真能打吗？

迅速的、畅快的、昂贵的, 然而并非是一句“将Claude Code击败”。这算作一篇自计划起始、构建过程、自我检查直至八个款项验收的终端代理实际测试。

先把门票摆出来

不妨先把门票的事儿交代一下。我既不是凭借领来的一个媒体体验码, 也不是仅仅在朋友的机器上随便操作了几下, 就跑来撰写评测的。为了对Grok Build CLI进行测试, 我开启了SuperGrok Heavy。当刷出去300美元的时候, 我的第一反应十分朴实, 那就是最好它真的能有些门道, 要不然这篇文章恐怕就只能叫做《如何优雅地给好奇心交罚款》了。

先把门票摆出来：这次不是媒体码，也不是隔空转述。

5月17日晚间时段之内情形下, 我于终端工具之中键入了grok version这一指令操作, 所返回呈现的内容为grok 0.1.211。此便构成了我此次实际测试Grok Build CLI的起始所在之处。不存在浏览器聊天框呈现场景, 不存在复制粘贴代码相关行为动作, 不存在让模型于网页环境里为我撰写构造一大段“你可以这样做”之类文字情况。它径直直接进入到了项目目录范畴, 读取其中文件内容, 修改调整文件状况, 运行开展测试流程, 进行自我检查检验, 再将最终结果展示摊放在终端工具之中。

我原本对它并未怀有太大的期待, 现今处于终端编码代理众多这般的状况之下, 列举有Claude Code、Codex CLI、Aider、Cursor, 这当中的每一个都声称自己懂得项目、会做计划、能够实现自动修复, Grok Build CLI要是仅仅只是多一个命令行入口, 那么是没有什么值得去书写的, 然而我在运行完一个完整的Weather App以后, 我的第一反应不是给人很专业的感觉的, 不过还算得上是诚实的。

快，爽开云手机入口app下载开云app官方入口网站，贵。顺序不能反，贵是最后才开始疼。

先说结论：快、爽、贵

它的快并非体现在跑分层面的快, 而是给我这样一种感觉, 事情是被连续不断地往前推着走, 先是 inspect 项目, 接着再出 plan, 然后又拿去改代码, 之后跑去跑 verifier, 到这还不算完, 还得依据 verifier 的意见进行二次修, 这几个环节之间不存在那种坐在终端前等它慢慢构思组织语言的烦躁感, 特别是改完之后进行自测, 发现存在小问题, 接着继续去补修这一段, 整体的节奏显得十分顺畅。

确实是真的贵。xAI 官网如今内容清清楚楚, Grok Build 仍处于早期测试阶段, 入口面向 SuperGrok Heavy 订阅者。订阅截图我也已置于前面, 以防后面谈及价格时仿若讲述都市传说。至于价钱是否值得, 无法依据官网文案判定, 要看其能否为开发者省却弯路。

测试起点：终端里真实返回的版本、模型和帮助信息。

看基本功：Weather App

这次我做的, 并非是那种极为花俏的 SaaS, 也未使其生成一堆看似高级的依赖。测试的项目是一款 Weather App。其功能要求极普通, 恰因普通, 适宜用于查看编码代理的基础技能。需求涵盖城市搜索、Open-Meteo API、当前天气、5 日预报、摄氏华氏切换、最近城市、加载状态、空状态、错误状态, 最后还得有 Vitest 测试以及生产构建。

我所看的并非是单次生成, 而是在于它能不能将计划以及构建、验证, 还有修补串联成闭环。

我先让它只做计划。

grok --permission-mode plan \
  --prompt-file prompt-plan-weather-app.md

这一步未曾对文件作出修改, Grok 率先察觉到现如今的项目实际上是 vanilla TypeScript starter, 并非如自己所认为的那般是 React 模板, 这般的细节颇具趣味, 众多工具于此处往往会依照用户的假定持续编写, 以至于写得愈发偏离正轨, Grok 先是将实际状况清晰阐明, 接着给出改造方案, 把 React 入口一一列出, 同时罗列了组件、API 层、weather 工具函数、storage 工具函数、Vitest 配置。

第一轮只让它做计划，先确认项目现状，再谈怎么动手。

批准后，我让它真正开工。

grok --always-approve --check \
  --prompt-file prompt-implement-weather-app.md

真正加分的是自检

它将主体代码予以完成过后, 又去运行了一回verifier, 头一回verifier已然给出了PASS, 然而它自身却依旧指明好几处毛病, pnpm test处在watch模式之下, 并不契合CI的要求, 极为狭窄的移动端forecast卡片会出现挤压的状况, “Feels like”最好运用真实的apparent temperature, README也应当补充一段内容, 此地较之于“它一次所编写的代码数量”更能够阐释问题。有不少模型具备写代码的能力, 然而, 唯有那种在写完代码之后, 还能持续自行挑拣由自身出现的问题环节之终端代理, 方才起始趋向于有如工具！

真正加分的是 PASS 之后仍能继续挑自己的毛病。

我又把这些问题丢回去。

grok --always-approve \
  --prompt-file prompt-fix-verifier-issues.md

第二轮, 它将test变更为vitest run, 补充了test:watch, 对极窄屏样式予以调整, 对apparent_temperature进行确认, 把没用的图标文件删除, 并且撰写了README。最终, 我手动再次跑了一回。

Test Files  2 passed (2)
Tests       18 passed (18)
vite v8.0.13 building client environment for production...
25 modules transformed.
built in 85ms

最后手动复核：测试和生产构建都跑通。

成品不炫技，但没糊弄

成果不存在卖弄技巧的情况, 其制作所依赖的仅仅是 React 和 React DOM , 天气图标借助 emoji 进行映射, API 使用 Open-Meteo , 且无需密钥。它同样未曾引入 Redux , 也没有添加图标库 , 更没有将一个小型天气应用写成类似依赖展示般。对于这种取舍我反倒抱有喜爱之情。一个具备实用性的小工具, 首先是完成其所承担的事务 , 等到实则达到复杂阶段? 再去 deliberating 是否要增添状态库以及 UI 组件库 , 相较于一开始便充斥大量配置的情形呢, 这般状况显得比前者相较于后者更像是常规的工程流程。

最后的界面并未进行糊弄, 默认加载的是San Francisco, 当搜索Tokyo时存在下拉结果, 选中之后会对于主卡片以及5日预报做出更新, 最近城市会被保存在localStorage当中, 摄氏华氏切换能立刻生效, 移动端不会出现挤成一团的情况, 严格来讲它还够不上属于生产级的天气应用, Grok后面的验收也指出了这一情况, 然而作为从空项目开始做出的第一版终端代理来看, 已经超过了“能跑一下”的标准。

成品不炫技，但关键状态和移动端体验都没有糊弄。

最值得看的命令：inspect

Grok Build CLI那命令面可不算小, 我此次真实遇上且核查过的主要就是这类。

grok
grok login
grok version
grok models
grok inspect
grok update --check --json
grok sessions list
grok worktree list
grok mcp list
grok -p "..."
grok --prompt-file task.md
grok --permission-mode plan
grok --best-of-n 8
grok --check
grok trace
grok agent stdio
grok agent serve

这里面我最为中意的是 grok inspect, 它能够把项目里所包含的 AGENTS、skills、plugins、MCP、hooks 以及配置来源通通扫描出来, 并且会将解析遭遇失败以及规则无法识别的那些地方标记为 warning。好多编码代理宣称自己“了解项目”, 实际上仅仅是去查看了 README 和 package.json 而已。inspect 起码能够让人知晓它看到了什么, 又遗漏了什么。

inspect 的价值在于让“它看见了什么”变得可检查。

现实中 inspect 的截屏呈现, 其中的项目规则, 还有相应的技能, 以及插件, 包括 MCP 与 hooks 等俱是有条不紊、有迹可寻的。

8 个任务，别讲歪

最容易被误解的存在是, 8个agent, 官方视频里, 最吸引人的画面, 的确是多个subagents一同跑, xAI的发布页也表明, subagents能够并行进行research、build、review, 并且还支持worktree, 这个能力极具想象力, 不过在实测的时候, 需要分清几件事。

以下这种情况超级拐着弯不直接: best-of-n, 它跟只读验收任务根本不是处于同类现象的事儿。

拿“best-of-n 8”当 “8 个工程师同时干活” 的证据, 会讲歪, 因为它不是 8 个 agent 一起开发, 它更像 8 路候选答案。TUI 里的任务面板, 以及 worktree 才是更接近官方演示的入口, 在翻了本机文档, 又看了几个视频的自动字幕之后, 我最后确认这一点不能混着说。

我于最后之际开展的是一次更为自然的软件验收测试开云真人app,开云真人app地址，未曾再度为其预设要展示的目标。prompt 所提出的要求仅仅是让它去检查 Weather App 是否已然达到了面向真实情况下的用户进行发布会达到的的软件质量标准, 并且将任务划分称为 8 个只读类型的检查项。Grok 运行完毕之后, 在右上角之处显示出有 8 个检查任务已完成, 最后得出或者作出的结论也是十分克制的。能够发布, 不过是需要进行补修的, 特别是 RecentCities 的可访问性、网络边界测试、App 的架构集中化这几方面。

这段我剪出了一个时长为32秒的高光版, 其中, 前10秒是取自于1:00到1:10这样的时间段, 而后22秒则是源自于2:23到2:45这般的区间。

8项只读验收所能够证实的是审阅以及判断, 并非8路同时编写代码。

这条素材能够进行证明的的东西是十分有限的, 恰恰是因为其有限所以才具有可信性。它所证明的内容在于 Grok 能够在于一个 TUI 任务当之中达成 8 项验收检查, 与此同时还能够给出颇为有用的发布判断结论。而它却没有办法来证明 8 个 worktree agent 能够进行同步地写入对应的不同各自功能, 并且它还没办法就相关内容证明它已然能够非常干净地合并 8 路所产生的不同改动。后面所提到的后者在证明时是需要另外去做一项更为繁重且复杂的测试才能够完成的。

然而, 我并不感到这个限制会致使丢分。在诸多情形下, 并行 agent 最为适宜去做的事情, 原本并非是大家一同去修改同一个文件, 最为适宜的乃是进行探索, 开展评审, 查找风险, 比较方案。Grok 在这一事情上已然具备了产品形态, 至少并非属于 PPT 功能。

它和 Claude Code 的位置不一样

相较 Claude Code 而言, Grok Build CLI 当下尚未具备那种成熟工具所拥有的稳定之感。Claude Code 的生态更为扎实, Claude Code 的习惯更为固有, Claude Code 的社区资产更为雄厚, Claude Code 在遇到问题之时更容易于既存经验当中寻觅到解决办法。Grok 的优势却处于另外的一个方向。它的TUI显得更为激进无比, 把Plan、inspect、subagents、worktree、headless、skills、plugins、MCP、ACP这些事物, 放置于同一个终端产品当中, 其野心彰显得十分突显, 极为明显。

Grok Build CLI, 它更像是那种处于终端里的调度台, 并非对于所有工具进行单纯简单的替代。

Cursor适宜留在IDE当中去修改现有的代码, Aider适合那些小步提交行为较为频繁以及Git使用习惯强烈的人, Codex CLI更为类似一个能够承接本地以及云端任务的工作代理, Grok Build CLI此次给予我的感受, 是它更为倾向成为一个处于终端中的调度台 , 而这个方向极具吸引力, 然而却极易遭遇困境, 这是由于调度台越是复杂, 便越需要产品具体细节给予支撑。

目前看，它撑住了一部分。

问题和价格

不仅问题数量众多, 而且首次时, verifier并未将pnpm test的watch模式视作必须修正的错误, 八项验收任务已然完成, 然而却未自动将任务进程整理成美观的、可供引用的报告, 至于 TUI 截图与录屏, 则需要自身去抓取, 若想获取与官方 demo 类似的画面, 还得反复进行试验, 其输出偶尔会提及“演示项目”这般表述, 这表明模型对于项目定位依旧存在摇摆不定的状况, 从而要求prompt撰写得更趋近于实际工作。

最后绕不过去的那一刀是价格。SuperGrok Heavy对于只是偶尔写脚本、做小网页的人来说门槛太高。Cursor, 连同Claude Code、Codex CLI、Aider, 甚至网页聊天加手动复制, 能解决掉很多问题。Grok Build CLI的价值, 需靠高频、长时间、复杂项目去摊薄, 用来摊薄它呀。

若天天于终端之内编写代码, 于项目当中存有AGENTS.md, 存在Claude Code的习惯, 存有MCP, 有自身所积攒的skills以及hooks, 那么它就值得去尝试。它最折服我的之处, 并非在某一回回应相较他人更为聪慧方面, 而是它把钻研项目、策划、付诸行动、自我检验、协作审核这些动作连贯了起来。只要此条链路颇具稳定, 因而省下来除却几分钟的守候, 尚有来回阐释、反复粘贴、手动验收所产生的疲倦。

临时评分：8.3/10

我的临时评分是 8.3/10。

我的临时评分：8.3/10。快、爽、贵开云app官方最新下载地址，都是真的。

说它已将Claude Code击败, 我不会这么讲。如此言论下结论太过仓促, 说得倒是轻巧。Grok Build CLI如今更似一个崭新工具, 其速度甚快, 势头极猛, 还存有beta版的粗糙之感。它使我头一回于Grok这条路径之上有此感受, xAI并非仅空想做个能聊天的模型, 它已然着手触及开发者每日切实为之烦扰的那些事务了。

它还贵。可这次我用下来，至少明白了一件事。

贵有时只是贵，有时是贵得让人骂两句，还想继续用。

标签： GrokBuildCLI 终端代理 编码工具 xAI 评测