用 Mistral Vibe CLI 做设计。

Mistral Vibe CLI 究竟是什么

Mistral Vibe CLI 是 Mistral AI 为终端推出的开源（Apache-2.0）编码代理。它提供一个交互式对话界面，配有文件操作、代码搜索、版本控制和命令执行等工具，并会自动扫描你项目的文件结构和 Git 状态，为代理提供相关上下文。它由 Mistral 的 Devstral 编码模型驱动——根据自然语言任务进行规划和验证，而不只是补全代码行。

对设计工作而言，有两个特性尤为突出。它运行在 Mistral 开放权重的 Devstral 家族上（Devstral 2 以及更小的 Devstral Small 2），因此你既可以让代理对接云端的 Mistral API，也可以对接本地模型——这对于注重隐私或离线的设计工作很有用。它还支持 Agent Client Protocol，因此同一个代理可以驱动编辑器和各类工具，而不只是一个终端会话。

• 配置文件: Vibe CLI 通过 config.toml 文件配置（项目级 ./.vibe/config.toml，并以 ~/.vibe/config.toml 作为回退）。这是个很实用的地方，可以把你的服务商、模型选择和项目设置都写进去。
• 内置工具 + MCP: 它自带文件、搜索、版本控制和命令执行工具，并支持 MCP 服务器（在 [[mcp_servers]] 区段下配置），以引入外部上下文，比如一个实时的 Figma 文件。
• BYOK 或本地: 用 Mistral 控制台的 Mistral API 密钥进行认证，或把它指向本地/兼容模型，让它完全离线工作。

• 厂商：Mistral AI
• 凭据：Mistral 控制台的 Mistral API 密钥（BYOK），或本地/兼容模型
• 许可证：Apache-2.0，开源

为什么开放权重的编码代理适合做设计

Vibe CLI 在设计上的优势来自它开放权重的模型家族和广泛的协议覆盖——但与每一个代理一样，审美仍然得由你来提供。

• Devstral 编码模型: Vibe 运行在 Mistral 的 Devstral 家族上，这是为代理式、多文件工作打造的编码调优模型——因此代理是在一个真实的前端代码库中跨文件编辑，而不是产出孤立的代码片段。
• 开放权重且对本地友好: Devstral Small 2 足够小，可以跑在消费级硬件上，因此设计工作可以完全保持在本地和离线状态——参考素材和代码永远不必离开你的机器。
• config.toml 中的约定 + 上下文: 项目配置和你自己的指令会把代理引向你的 tokens、组件和真实规范，于是它是面向一个品牌工作，而不是套用默认外观。

这条教训和每个代理给出的如出一辙：Vibe CLI 默认并不具备审美。当你给它约束时——一个设计系统、一个审美 skill 和具体的参考素材——它才能产出好的设计。Open Design 恰好把这些输入打包好了，这也是两者能契合的原因（下文详述）。

从零配置 Vibe CLI 做设计工作

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

# 1. 安装 Mistral Vibe CLI
uv tool install mistral-vibe
# 或：pip install mistral-vibe

# 2. 运行配置向导以注册你的 API 密钥
vibe --setup     # 将配置保存到 ~/.vibe/config.toml 和 ~/.vibe/.env
#    或直接设置：  export MISTRAL_API_KEY=...

# 3. 在你的项目中启动 Vibe
cd your-project
vibe

# 4. 接入 Figma MCP 服务器（可选，用于设计交付）
#    在你的 config.toml 中添加一个 [[mcp_servers]] 条目

• 把你的设计规则写进去: 把你的 tokens、基础元素和规范约定放在代理能读到的地方，并让 Vibe 指向它们，这样产出就会匹配一个品牌，而不是退回到千篇一律的外观。
• 加上浏览器验证: 接入一个 Playwright 或浏览器 MCP，让 Vibe 在真实浏览器中渲染，并跨断点检查产出，而不只是确认构建通过。

从参考素材到 UI 的工作流

用 Vibe CLI 做设计时收益最高的闭环，是把一份清晰的参考素材变成可用的响应式 UI，并反复迭代直到匹配为止——借助代理自身的工具来渲染、检查并修正它自己的产出。

1. 从你手头最清晰的参考素材出发——并描述多种状态（桌面和移动端、悬停、空态、加载中），而不只是一张主视觉。
2. 提示词要具体；含糊的提示即便配上强大的模型也只会产出千篇一律的 UI。
3. 把你的设计系统和规范约定放在 Vibe 能读到的地方，并告诉它 tokens 和标准基础元素在哪里。
4. 运行一个开发服务器，让 Vibe 在真实浏览器中渲染，并调整到各个断点来检查结果。
5. 通过让 Vibe 把它的实现回头对照参考素材来迭代——而不只是确认它能构建通过。

用 @ 引用文件（Vibe 会自动补全文件路径），用 / 调用斜杠命令，然后给出具体的约束：

vibe
# 在提示词里：
> @design-spec.md @tokens.css
  Implement this design in React + Vite + Tailwind + TypeScript.
  Reuse my existing design-system components and tokens.
  Match spacing, layout, and hierarchy; make it responsive.
  Run the dev server, render it in the browser, and iterate until
  it matches the references across breakpoints.

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

config.toml、MCP 和 ACP

有三个扩展点让 Vibe CLI 适合做持续性的设计工作，而且这三个都能干净地对应到一套开放的设计工作流上。

• config.toml: 项目规则以及服务商/模型设置都存放在 config.toml 中（项目级，并以 ~/.vibe 作为回退）。它是代理如何接入你项目的持久化归宿，每次运行都会被读取。
• MCP 服务器: 在你的 config.toml 中配置 MCP 服务器（[[mcp_servers]]，支持 HTTP、可流式 HTTP 和 stdio 传输）——这是引入设计上下文和外部工具的可移植方式，其中最相关的就是 Figma MCP 服务器，并且这些在各类代理间通用，不只限于 Vibe。
• Agent Client Protocol: Vibe 支持 ACP，因此同一个代理可以从编辑器和其他 ACP 客户端来驱动。Open Design 正是这样集成它的——通过 vibe-acp 二进制文件经由 ACP 接入。

这些都是可移植、跨代理的能力——恰恰是 Open Design 旨在编排的那类东西，而不是在每个项目里重新造一遍。

做设计时 Vibe CLI 对比 Codex、Claude Code、Cursor 和 Gemini CLI

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

社区反复得出的结论是：审美来自人类——若没有 skill、参考素材和约束，它们都会默认走向千篇一律的风格。这才是真正要解决的问题——而它是设计工具形态的，不是模型形态的。

陷阱，以及如何避开「AI 味」外观

对 AI 生成设计最常见的抱怨，就是它看起来千篇一律——柔和的渐变、漂浮的面板、过大的圆角、夸张的阴影，以及那种「一看就是 AI 做的」的 Inter 字体加紫色调调。其他被反映的问题还包括移动端布局错乱，以及指令文字泄漏进 UI 文案。这些都不是 Vibe CLI 独有的；只要任何代理在缺乏精选设计上下文的情况下运行，就会出现这些问题。

• 加上一个审美 skill: 一个精选的设计 skill 会迫使代理给出一个真正的方向，而不是套用默认外观。
• 在真实浏览器中验证: 让 Vibe 跨断点渲染并自查，这样布局就不会在移动端悄无声息地崩掉。
• 提供 tokens 和参考素材: 真实的设计 tokens 和参考截图，是对产出质量影响最大的单一杠杆。
• 把规则写进配置和上下文: 把「不要主视觉卡片、最多两种字体、品牌优先的层级」这类风格规则放在代理每次运行都能读到的地方。

注意，每一项缓解措施都是在给代理一份精选的设计上下文。逐个项目手工维护这份上下文，正是 Open Design 替你省掉的苦工。

在 Open Design 中用 Vibe CLI 做设计

Open Design 正是上面这套工作流一直在呼唤的那个开源设计层。它把 Mistral Vibe CLI 当作一等适配器——通过 vibe-acp 二进制文件经由 ACP 来驱动它——并为它配上精选的 skill 与设计系统库、一条结构化的渲染管线，以及一个本地桌面 UI。于是，让 Vibe 变好用的那份设计上下文从第一次运行起就已就位，而不必每次手工拼凑。两者都是开源且本地优先的，这让这对搭配水到渠成。

1. 安装 Open Design 并选择 Mistral Vibe CLI 作为你的代理。
2. 用你的 Mistral API 密钥（BYOK）进行认证，或把 Vibe 指向本地模型——凭据留在你的机器上，绝不经我们代理转发。
3. 挑选一个设计系统和一个 skill，然后以一致的审美生成演示稿、原型和落地页。
4. 每一个产物和 DESIGN.md 文件都存在你自己的仓库里，而不是某个托管云端。

同一个 Vibe CLI 代理，同一把密钥——外加一套围绕它的真实、可移植、开源的设计工作流。它本地优先且采用 Apache-2.0，因此你的工作内容和凭据没有任何一项会离开你的机器。

常见问题

1. 01 Mistral Vibe CLI 真的能做设计工作吗？ +

   能——只要上下文里有一个审美 skill、一个设计系统和真实的参考素材，Vibe CLI 就能产出生产级的响应式 UI，而它的 Devstral 模型会在一个真实的前端代码库中跨文件编辑。缺了这份上下文，它往往会退回到千篇一律的外观，而这正是 Open Design 要补上的缺口。

2. 02 我该如何认证 Vibe CLI？ +

   运行 vibe --setup 启动配置向导来注册一个 Mistral API 密钥（来自 Mistral 控制台），或在你的环境中设置 MISTRAL_API_KEY。它也可以对接本地或兼容模型，完全离线运行。无论哪种方式，Open Design 都绝不会代理转发你的凭据。

3. 03 Vibe CLI 具体好在哪里、为什么适合做设计？ +

   它是一个 Apache-2.0、原生支持 ACP 的代理，由 Mistral 开放权重的 Devstral 编码模型驱动——因此你可以在本地运行它来处理注重隐私的工作，并在一个真实的代码库中跨文件编辑。但审美仍然来自你提供的设计系统、skill 和参考素材。

4. 04 做前端设计，选 Vibe CLI 还是 Claude Code？ +

   两者都很强。Claude Code 以具体的、理解代码库的设计决策著称；Vibe CLI 的优势在于可在本地运行的开放权重 Devstral 技术栈以及 Apache-2.0 许可证。很多团队两者都用——Open Design 让你可以切换代理而无需改变你的设计工作流。

5. 05 我该如何把 Vibe CLI 连接到 Figma？ +

   在你的 config.toml 中以 [[mcp_servers]] 条目的形式添加 Figma MCP 服务器。Vibe 随后就能拉取真实的设计上下文——组件、变量、布局数据——从而让生成的代码匹配源文件，而不是近似地凑出来。

6. 06 Open Design 与 Mistral AI 有关联吗？ +

   没有。Mistral Vibe CLI 是 Mistral AI 的产品；Open Design 是一个独立的开源项目，以一等适配器的形式支持它，并通过 ACP 来驱动。Mistral 是 Mistral AI 的商标。

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

   安全——Open Design 本地优先且采用 Apache-2.0。你的文件、产物和 DESIGN.md 都留在你自己的仓库里，你的 Mistral 凭据由你的代理直接使用，绝不经由 Open Design 的服务器转发。