用于设计的 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 和具体的参考——它才会产出好的设计。SankiWork 恰恰把这些输入打包好了，这正是两者契合的原因（下文详述）。

从零开始搭建用于设计工作的 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 能力——正是 SankiWork 旨在编排、而非在每个项目里重造的那类东西。

做设计时 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 一份精选的设计上下文。手工地、按项目维护这份上下文，正是 SankiWork 替你免去的苦差事。

在 SankiWork 中用 Grok Build 做设计

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

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

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

常见问题

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

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

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

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

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

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

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

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

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

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

6. 06 SankiWork 隶属于 xAI 吗？ +

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

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

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