用于设计的 Grok Build。

Grok Build 究竟是什么

Grok Build 是 xAI 的终端编码 agent，以 Grok Build 之名发布。它读取你的仓库、编辑文件、运行 shell 命令，并依据自然语言任务规划多步工程工作，而不只是补全代码行。它围绕 xAI 的 Grok 模型构建——在 xAI API 上以 grok-build 模型家族的形式暴露——并通过你的 xAI 账户进行身份验证，因此 agent 和模型都出自同一家厂商。

对设计工作来说，有两个特性尤为突出。它有一个计划模式，会先草拟一份结构化方案，供你在任何改动落地之前批准、评论或重写——当你在迭代 UI 时，这是个很有用的关卡。而它的 Grok 模型支持图像输入，所以你可以把一张参考截图交给它，它会对实际布局进行推理，而不是从一段文字描述里瞎猜。

• 上下文文件: Grok Build 会读取 AGENTS.md 文件来获取持久的项目上下文——这正是用来编码你的设计规范、tokens 和审查清单的自然位置。它遵循 Codex 和其他 agent 同样使用的开放 AGENTS.md 约定。
• 工具、MCP + 子 agent: 它能编辑文件、运行 shell 命令，并支持 MCP 服务器来引入外部上下文，比如一个实时的 Figma 文件；对于较大的任务，它可以委派给并行的子 agent，让它们同时进行调研、构建和审查。
• 用你的账户登录: 你通过浏览器以 SuperGrok 或 X Premium+ 订阅登录来完成身份验证；你也可以带上自己的 xAI API key 用于无头运行和 CI 场景。

• 厂商：xAI
• 凭证：xAI SuperGrok OAuth（`grok login`），或用于无头场景的 xAI API key（BYOK）
• 模型：xAI Grok 模型（xAI API 上的 grok-build 家族），支持图像输入

为什么计划模式和能识别图像的模型契合设计

Grok Build 的设计优势来自两个特性——但和所有 agent 一样，品味仍然得由你来提供。

• 能识别图像的推理: 因为 Grok 模型支持图像输入，agent 能读取参考截图——把自己渲染出的产出与图像对照，而不是从一段文字描述里瞎猜。
• 改动落地前的计划模式: 计划模式会草拟一份结构化方案，供你在文件改动前批准，于是设计意图在一开始就被审查，而不是等差异出来之后才发现。
• 写在 AGENTS.md 里的规范: 一份 AGENTS.md（再加上 Figma MCP 服务器）会把 agent 指向你的 tokens、组件和真实规格，让它针对一个品牌来工作，而不是套用默认观感。

这条教训和每个 agent 教给我们的一样：Grok Build 默认并不具备品味。当你给它约束时——一个设计系统、一个审美 skill 和具体的参考——它才会产出好的设计。Open Design 恰恰把这些输入打包好了，这正是两者契合的原因（下文详述）。

从零开始搭建用于设计工作的 Grok Build

下面是从一台干净的机器到一个能构建并验证 UI 的 Grok Build 的完整路径。

# 1. 在 macOS/Linux 上安装 Grok Build（Grok Build）
curl -fsSL https://x.ai/cli/install.sh | bash

# 2. 在你的项目里启动它，并在首次运行时进行身份验证
cd your-project
grok login   # 打开浏览器；用 SuperGrok / X Premium+ 登录
#   或者，对于无头 / CI 场景，设置 xAI API key：
#   export XAI_API_KEY=xai-...

# 3. 添加项目上下文
#    在仓库根目录创建一个 AGENTS.md，写入你的设计规范

# 4. 接入 Figma MCP 服务器（可选，用于设计交付）
#    把它加到你的 MCP 服务器配置里

• 编码你的设计规则: 把你的 tokens、基础元素和规范写进 AGENTS.md 并让 Grok 指向它们，这样产出就会贴合一个品牌，而不是退回到千篇一律的默认观感。
• 加入浏览器验证: 接入 Playwright 或浏览器 MCP，让 Grok 在真实浏览器中渲染，并跨断点检查它的产出，而不仅仅是确认构建通过。

截图到 UI 的工作流

用 Grok Build 时杠杆最高的设计循环，就是把一张参考图变成可用的响应式 UI 并不断迭代直到吻合——靠计划模式就方案达成一致，靠能识别图像的模型把产出与参考对照。

1. 从你手头最清晰的视觉参考出发——并包含多种状态（桌面端和移动端、hover、空态、加载态），而不只是一张主视觉。
2. 在提示里写具体；含糊的提示即使配上强模型也只会产出千篇一律的 UI。
3. 把你的设计系统和规范放进 AGENTS.md，并告诉 Grok tokens 和规范基础元素在哪里。
4. 用计划模式审查方案，然后启动一个 dev server，让 Grok 在真实浏览器中渲染，调整到各个断点来检查结果。
5. 通过让 Grok 把自己的实现与截图对照来迭代——而不仅仅是确认它能构建。

附上你的参考图，并给出具体约束：

grok
# 在提示里（附上 reference-desktop.png 和 reference-mobile.png）：
> 用 React + Vite + Tailwind + TypeScript 实现这个设计。
  复用我已有的设计系统组件和 AGENTS.md 里的 tokens。
  匹配间距、布局和层级；做成响应式。
  先把方案给我看，然后在浏览器里渲染并迭代，
  直到它在各个断点上都与参考吻合。

让提示保持小而聚焦，提交好的迭代、回退差的迭代（回退时告诉 Grok），这样每一轮都能在一个干净的基础上推进。

AGENTS.md、MCP 与子 agent

三个扩展点让 Grok Build 适合持续的设计工作，而这三者都能干净地映射到一个开放的设计工作流上。

• AGENTS.md 上下文: 项目规则写在仓库根目录的 AGENTS.md 里。它是你设计规范的持久归宿，每次运行都会被读取——而且它是其他 agent 也能理解的同一种开放格式，所以这些规则会随你一起迁移。
• MCP 服务器: 配置 MCP 服务器来引入设计上下文和外部工具，其中最相关的是 Figma MCP 服务器——它是把真实规格喂进代码的可移植方式，跨 agent 通用，不只限于 Grok。
• 子 agent 与内置工具: Grok Build 能派生出并行的子 agent 来同时进行调研、构建和审查，而它的文件、shell 和搜索工具让它无需离开终端就能收集参考并跑完验证循环。

这些都是可移植的多 agent 能力——正是 Open Design 旨在编排、而非在每个项目里重造的那类东西。

做设计时 Grok Build vs Codex vs Claude Code vs Cursor vs Gemini CLI

设计工作没有唯一赢家——每个 agent 各有所长，经验丰富的团队会把它们叠着用。一个公允的总结：

社区反复得出的结论是：品味来自人类——没有 skill、参考和约束，它们全都会退回到千篇一律的审美。这才是真正要解决的问题——而它是设计工具形态的，不是模型形态的。

陷阱，以及如何避开“AI 味”观感

对 AI 生成设计最常见的抱怨是它看起来千篇一律——柔和的渐变、悬浮的面板、过大的圆角、夸张的阴影，一股 Inter 字体加紫色的味道，“一看就是 AI 做的”。其他被反映的问题还包括移动端布局崩坏，以及指令文字泄漏进 UI 文案。这些都不是 Grok Build 独有的；任何 agent 在没有精选设计上下文的情况下运行都会这样。

• 加入一个审美 skill: 一个精选的设计 skill 会迫使 agent 承诺一个真实的方向，而不是套用默认观感。
• 在真实浏览器中验证: 跨断点渲染并自检，让布局不会在移动端悄无声息地崩坏。
• 提供 tokens 和参考: 真实的设计 tokens 和参考截图是对产出质量影响最大的那个杠杆。
• 把规则编码进 AGENTS.md: 把“不要主视觉卡片、最多两种字体、品牌优先的层级”这类规则放到 agent 每次运行都会读取的地方。

注意，每一种缓解办法都是在给 agent 一份精选的设计上下文。手工地、按项目维护这份上下文，正是 Open Design 替你免去的苦差事。

在 Open Design 中用 Grok Build 做设计

Open Design 正是上面那套工作流一直在呼唤的开源设计层。它把 Grok Build 当作一等适配器，并在外围包上一套精选的 skill 与设计系统库、一条结构化的渲染管线，以及一个本地桌面 UI——于是让 Grok 表现出色的那份设计上下文从第一次运行起就已就位，而不必每次都手工拼凑。Open Design 是独立的、采用 Apache-2.0 协议，并运行在你自己的机器上，这让二者天然契合。

1. 安装 Open Design 并选择 Grok Build 作为你的 agent。
2. 用你的 SuperGrok 账户或 xAI API key（BYOK）进行身份验证——凭证留在你的机器上，从不经我们中转。
3. 挑一个设计系统和一个 skill，然后以一致的品味生成演示稿、原型和落地页。
4. 每一份产物和 DESIGN.md 文件都存在你自己的仓库里，而不是托管云端。

同一个 Grok Build agent、同一套凭证——外加在外围包裹的一套真实、可移植、开源的设计工作流。它本地优先、采用 Apache-2.0，所以你的工作和凭证全都不会离开你的机器。

常见问题

1. 01 Grok Build 真的能做设计工作吗？ +

   能——只要上下文里有一个审美 skill、一个设计系统和真实的参考图，Grok Build 就能产出生产级、响应式的 UI，而它能识别图像的 Grok 模型还能帮你把产出与参考对照验证。没有这份上下文，它往往会退回到千篇一律的观感，而这正是 Open Design 要填补的缺口。

2. 02 我该如何对 Grok Build 进行身份验证？ +

   你通过浏览器以 SuperGrok 或 X Premium+ 订阅登录（`grok login`），所以无需管理 API key。对于无头或 CI 场景，你可以改用 xAI API key。无论哪种方式，Open Design 都不会中转你的凭证。

3. 03 Grok Build 具体好在哪里、适合设计？ +

   两点：它的计划模式让你在任何改动落地前审查方案，而它的 Grok 模型支持图像输入，所以它能很好地读取参考截图。两者都有帮助——但品味仍然来自你提供的设计系统、skill 和参考。

4. 04 前端设计该选 Grok Build 还是 Claude Code？ +

   两者都很强。Claude Code 以具体的、理解代码库的设计决策著称；Grok Build 的优势在于计划模式审查和能识别图像的 xAI 模型。很多团队两者都用——Open Design 让你在不改变设计工作流的前提下切换 agent。

5. 05 我该如何把 Grok Build 连接到 Figma？ +

   把 Figma MCP 服务器加到你的 MCP 配置里。这样 Grok 就能拉取真实的设计上下文——组件、变量、布局数据——于是生成的代码会匹配源文件，而不是近似模仿。

6. 06 Open Design 隶属于 xAI 吗？ +

   不是。Grok Build 是 xAI 的产品；Open Design 是一个独立的开源项目，以一等适配器的方式支持它。Grok 是 xAI 的商标。

7. 07 我的文件和凭证安全吗？ +

   安全——Open Design 本地优先且采用 Apache-2.0。你的文件、产物和 DESIGN.md 都留在你自己的仓库里，而你的 xAI 凭证由你的 agent 直接使用，绝不会经过 Open Design 的服务器路由。