说真的，我没想到 xAI 会在这个时间点亮出这张牌。

---

一、故事的开端

事情是这样的。

五月初的一个周末，我正在用 Claude Code 重构一个老项目。这个项目大概 20 万行代码，前后端加在一起，横跨六个模块。

我遇到了一个问题：Claude Code 的上下文窗口不太够用。我需要频繁地把上下文"切片"喂给它，它才能理解全局的架构。这就像你拼一幅一万块的拼图，但眼睛只能看到眼前十块的区域——你做能做，但很累。

就在我烦躁的时候，一个朋友在群里丢了一条消息：

「xAI 今晚发了 Grok Build，200 万 token 上下文，你敢信？」

我看到这条消息，第一反应是：哦？又一个 AI 编程助手？第二反应：200 万？

等一下。Claude Code 不是最大 100 万吗？

你敢信，就这一天的时间——我从一个 Claude Code 的老用户，变成了一个蹲在 Grok Build 文档里出不来的好奇宝宝。

---

二、认识一下这位新朋友

Grok Build 是什么？

简单说，它是 xAI 推出的第一个 AI 编程 Agent。本质上是一个跑在终端里的 CLI 工具，目标用户是"做复杂工程的软件工程师"。

它背后跑的模型是 Grok-4.3 beta——2026 年 4 月发布的，拥有目前西方闭源模型里最大的上下文窗口：200 万 token。

有人说过一段话，我记了很久：评价一个工具，不是看它"能做什么"，而是看它"在什么场景下，解决了什么人的什么问题"。

Grok Build 针对的场景，在我看来非常明确：

维度	实际情况
产品形态	终端 CLI + Agent 架构
底层模型	Grok-4.3，200 万 token
核心理念	先规划后执行，最多 8 个并行 Agent
扩展能力	原生支持 MCP、ACP、Headless 模式
当前阶段	2026 年 5 月刚发，Early Beta

它不是又一个 Copilot 或者 Cursor 那种"在 IDE 里帮你补全代码"的小助手。Grok Build 是那种"你说要重构整个模块，它说好，我先出个方案你审审"的大管家。

这玩法，我还真没见过别的产品做到这个程度。

下面是安装grok build，方式和cc大差不差，执行如下命令

# Install on macOS / Linux
curl -fsSL "https://x.ai/cli/install.sh" | bash

# Environment variable for headless mode (scripts, CI)
export GROK_CODE_XAI_API_KEY="xai-..."

# Start an interactive session in the project
grok

# One-shot run in headless mode
grok -p "refactor the auth module: use JWT instead of sessions"

# Inspect config and discovered resources (skills, MCP, plugins)
grok inspect

---

三、Grok Build 的核心能力

3.1 Plan Mode：先规划后执行

这个是最让我上头的一个功能。

你在终端里丢给它一个任务，比如：「把这个项目的 callback 风格全部改写成 async/await」。

Grok Build 不会立刻开始改——不是它不敢，是它设计如此。

它先生成一个"逐文件、逐步骤"的执行计划。这个计划会列出来：要改哪些文件，每个文件怎么改，先改哪个后改哪个，可能影响哪些模块。

然后，它等你确认。

你可以批准整个计划。你可以对某个步骤提意见。你甚至可以自己改写某个步骤。

只有当你点头之后，它才开始动手。

爱比克泰德在《手册》里说：我们做每一件事都应该既小心谨慎，又充满信心。

Plan Mode 就是这种态度的工程化。小心谨慎——先出方案让你审。充满信心——你审完了它高效执行。

这个"先规划后执行"的设计，解决了 AI 编程的一个核心痛点：AI 闷头跑了半小时，改出来一堆你不想改的东西，你还不知道怎么还原。

有 Plan Mode，你至少知道它要干什么。这太重要了。

3.2 并行 Subagents：最多 8 个 Agent 同时干

Grok Build 支持最多 8 个 Agent 并行工作。

什么意思呢？就是一个大型任务，它可以拆成 8 个小任务，分给 8 个 Agent 同时干。每个 Agent 都遵循"规划 → 搜索 → 执行"的工作流。

为了避免并行改代码时起冲突——你懂的，同一个文件被两个 Agent 改，结果一团糟——Grok Build 深度集成了 Git worktree。每个子 Agent 在独立的 worktree 里工作，合并结果的时候做 diff 审查。

这玩意给我的感觉是：xAI 不是在做一个小工具，他们是在做一个"工程团队"。这个团队有 8 个实习生，你当项目经理，排好计划交出去，他们就各自开工了。

3.3 MCP + ACP 扩展

MCP（Model Context Protocol）是 Anthropic 推的开放协议。Grok Build 原生支持，你可以把你的内部知识库、私有 API、内部 MCP 网关，直接怼进 Grok Build。

ACP（Agent Client Protocol）是给工程平台准备的。外部工具可以直接对接 Grok Build 的 Agent 能力，不需要自己重新包装裸 API。可以方便和最流行的IDE 比如zed和jetbrains 无缝对接。再ACP方面，目前grok build 有比cc，codex都要好。

再加上项目级的 AGENTS.md 指令、插件市场、Arena Mode 自动化评测——Grok Build 形成了一个完整的工程生态。

马奇在《经验的疆界》里说：理论不是真理，而是视角。

Grok Build 的视角就是"不做一个孤立工具，做一个可扩展的工程平台"。这跟某些"用完即走"的 AI 编程工具，完全是两个思路。

3.4 Headless 模式

用 -p 参数启动，CLI 跳过交互界面，直接接受提示词输出结构化结果。

这意味着什么？

意味着你可以把 Grok Build 嵌进 CI/CD。GitHub Actions 里，每次 PR 提交后自动跑 Grok Build 做代码审查、安全扫描、依赖升级建议。结果写回 PR 评论。

意味着你可以把它嵌进 cron job。每天早上自动检查日志、生成异常报告、列出技术负债。

西蒙在《我生活的种种模式》里把迷宫当作探索的隐喻。Headless 模式让你不用每次亲自走迷宫——你设定好路线，Grok Build 自己走。

---

四、价格：说真的，有点贵

好的，到了你我最关心的环节。

SuperGrok Heavy 订阅：300 美元/月。

我看到这个数字时，第一反应是：卧槽。

但 xAI 也提供了 Early Bird 价格：前 6 个月 99 美元/月，大概是标准价的 33 折。

说实话，99 刀每月还是便宜的。但 300 刀每月——对于个人开发者来说，确实需要掂量一下。

但如果你只是想用 Grok-4.3 模型，不想用 CLI 那套功能，还有一个更灵活的方式：通过 API 调用。

---

五、Grok Build vs Claude Code

我必须说，拿 Grok Build 和 Claude Code 对比，是绕不过去的话题。

不是因为别的，而是因为它们实在太像了——都是 Agent + CLI 形态。

但仔细看下来，差异还是很大的：

对比维度	Grok Build	Claude Code
底层模型	Grok-4.3（16-Agent Heavy）	Claude 4.5/4.6/4.7 系列
上下文	200 万 token	最大 100 万 token
定价方式	订阅制 300 刀/月	Token 按量计费
并行 Agent	最多 8 个	支持但配置不同
协议扩展	原生 MCP + ACP	原生 MCP
中大型项目	完胜（200 万上下文是杀手锏）	够用

真正的知识不是你不能不知道什么，而是你能随时调用什么。

对比也是一样。不是能不能对比，而是你知道在什么场景下选什么工具。

如果你经常处理几十万行代码的大项目，Grok Build 的上下文窗口是核武器——别的工具还在"切香肠"式地喂代码，它一口能吞下一个仓库。

如果你是"按需使用"型的——今天改个小 bug，明天加个新功能，后天可能完全不写代码——那 Claude Code 的按量计费更适合你。

这两个工具不互斥。很多团队两个都用。日常编辑用 Claude Code，大活重活用 Grok Build。

---

写到这里，我想说几句实话。

Grok Build 是一个很有想法的产品。Plan Mode、并行 Subagents、200 万 token——这些能力说明 xAI 在认真思考"AI 编程助手下一步该往哪走"。

但它的问题也很明显：

第一，太贵。300 刀月费对个人开发者是一道门槛。

第二，太新。5 月 14 日才发布，社区生态为零。你能找到的教程、插件、踩坑经验，都少得可怜。

第三，设计偏重。它的设计是针对"大型工程团队"的，不是针对"个人开发者写个小脚本"的。如果你只是一个偶尔写代码的人，Grok Build 对你来说太重了。

工具也是。Grok Build 本身不贵不重——它只是为特定场景设计的。你的困扰，来自于你期待它能解决你不属于它的场景的问题。

想清楚你的场景。然后选工具。

---

七、结语：一个轮回

回到开头那个周末。

那个让我烦躁的老项目，我后来没有用 Grok Build 重构。不是因为我不想，而是因为我的使用频率不值得一个月 300 刀。

这种感觉就像是：你以前吃西瓜得切块，现在整个西瓜往嘴里塞。粗鲁，但爽。

Grok Build 会改变 AI 编程的格局吗？

我不知道。

但我知道，200 万 token 的上下文窗口——xAI 已经亮出了一张别人没有的牌。

剩下的，就看他们怎么打了。

做每一件事都应该既小心谨慎，又充满信心。——爱比克泰德

无论你是对 Grok Build 充满期待，还是选择先观望——都是对的。

关键是，用起来。