Q: 为什么多模态模型与超大上下文如此契合设计

Gemini CLI 在设计上的优势源自两项模型特性——但正如每一个智能体一样，审美仍然得由你来提供。强大的多模态理解：由于 Gemini 模型原生支持多模态，智能体能很好地读懂参考截图——它会把自己渲染出的结果与图像本身进行比对，而不是凭一段文字描述去猜。1M token 的上下文窗口：大上下文意味着整套设计系统、token 以及众多参考状态都能一次性装入，因此智能体会复用你真实的原子组件，而不是凭空发明一次性的样式。GEMINI.md 中的规范：一份 GEMINI.md（再加上 Figma MCP 服务器）会把智能体引向你的 token、组件和真实设计规范，使它围绕某个品牌来工作，而不是套用默认外观。审美来自你提供的三种输入：一套设计系统、一项 skill，以及真实的参考图。这个教训每个智能体都在反复教给我们：Gemini CLI 默认并没有审美。只有当你给它约束——一套设计系统、一项美学 skill 和具体的参考——它才能产出好的设计。OpenDesign 打包的正是这些输入，这正是两者契合的原因（详见下文）。

Q: GEMINI.md、MCP 服务器与扩展

有三个扩展切入点让 Gemini CLI 足以胜任持续的设计工作，而这三者都能干净地对应到一套开放的设计工作流上。GEMINI.md 上下文：项目规则存放在仓库根目录的 GEMINI.md 中（并带有全局层和团队层）。它是你设计规范的长期居所，每次运行都会被读取。MCP 服务器：在 ~/.gemini/settings.json 下配置 MCP 服务器——这是引入设计上下文和外部工具的可移植方式，其中最相关的当属 Figma MCP 服务器，它可以跨不同智能体使用，而不限于 Gemini。扩展与内置工具：Gemini CLI 的扩展及其内置的 Google Search、文件、shell 和网页抓取工具，让它无需离开终端就能收集参考资料并运行验证循环。这些都是可移植的、面向多智能体的能力——正是 OpenDesign 生来就要去编排、而不是逐个项目管理复刻的东西。

Question 1

Gemini CLI 能产出真正的设计作品吗？

Accepted Answer

可以——只要在上下文中提供审美 skill、设计系统和真实参考图片，Gemini CLI 就能产出可用于生产的高质量响应式 UI，其强大的多模态模型会根据参考图核对输出结果。缺少这些上下文时，它往往会退回到通用外观，这正是 OpenDesign 要填补的空白。

Question 2

使用 Gemini CLI 进行设计需要付费吗？

Accepted Answer

不需要——使用 Google 账户登录即可获得较为宽裕的免费额度，你也可以自带 Gemini API key（BYOK）或使用 Vertex AI。无论哪种方式，OpenDesign 都不会代理你的凭证。

Question 3

哪些 Gemini CLI 特性对设计最重要？

Accepted Answer

主要有两点：其模型具有很强的多模态能力，能很好地读取参考截图；同时 1M-token 的上下文可以一次性容纳整个设计系统和参考集。这两点都有帮助——但审美最终仍来自你提供的设计系统、skill 与参考资料。

Question 4

在前端设计中选择 Gemini CLI 还是 Claude Code

Accepted Answer

两者都很出色。Claude Code 以贴合代码库的具体设计决策著称；Gemini CLI 的优势在于多模态理解能力，加上超大上下文和免费额度。许多团队会同时使用两者——OpenDesign 让你在不改变设计工作流的情况下自由切换 Agent。

Question 5

Gemini CLI 如何连接 Figma？

Accepted Answer

在 ~/.gemini/settings.json 的 mcpServers 下添加 Figma MCP 服务器。之后 Gemini 就能拉取真实的设计上下文——组件、变量、布局数据——使生成的代码与源文件保持一致，而不是仅做近似还原。

Question 6

实践中的 Gemini CLI 究竟是什么

Accepted Answer

Gemini CLI 是 Google 为终端发布的一款开源（Apache-2.0）AI 智能体。它能读取你的代码仓库、编辑文件、运行 shell 命令、抓取网页，并可用 Google Search 为回答提供依据——它会从自然语言任务出发进行规划并验证工作成果，而不只是补全代码行。同一套引擎也驱动着 VS Code 中的 Gemini Code Assist 智能体。

对于设计工作而言，有两点特性尤为突出。它的模型原生支持多模态，因此你可以直接递给它一张截图，它就能针对真实布局进行推理。其上下文窗口最高可达 1M token，大到足以一次性容纳你的整套设计系统、组件库和参考素材，而不必将它们概括压缩掉。

上下文文件：Gemini CLI 会读取 GEMINI.md 文件以获取持久化的项目上下文——这是把你的设计规范、token 和评审清单编码进去的自然之所。个人设置与团队设置则在此基础上层层叠加。

内置工具 + MCP：它开箱即自带文件、shell、网页抓取和 Google Search 工具，并支持 MCP 服务器（在 ~/.gemini/settings.json 中配置），以接入诸如实时 Figma 文件之类的外部上下文。

免费起步：用个人 Google 账号登录即可获得相当慷慨的 Gemini 请求免费额度；你也可以自带 Gemini API key，或使用 Vertex AI。

凭证：Google 账号（免费额度），或来自 AI Studio 的 Gemini API key（BYOK），或 Vertex AI

厂商：Google

许可证：Apache-2.0，开源

Question 7

为什么多模态模型与超大上下文如此契合设计

Accepted Answer

Gemini CLI 在设计上的优势源自两项模型特性——但正如每一个智能体一样，审美仍然得由你来提供。

强大的多模态理解：由于 Gemini 模型原生支持多模态，智能体能很好地读懂参考截图——它会把自己渲染出的结果与图像本身进行比对，而不是凭一段文字描述去猜。

1M token 的上下文窗口：大上下文意味着整套设计系统、token 以及众多参考状态都能一次性装入，因此智能体会复用你真实的原子组件，而不是凭空发明一次性的样式。

GEMINI.md 中的规范：一份 GEMINI.md（再加上 Figma MCP 服务器）会把智能体引向你的 token、组件和真实设计规范，使它围绕某个品牌来工作，而不是套用默认外观。

审美来自你提供的三种输入：一套设计系统、一项 skill，以及真实的参考图。

这个教训每个智能体都在反复教给我们：Gemini CLI 默认并没有审美。只有当你给它约束——一套设计系统、一项美学 skill 和具体的参考——它才能产出好的设计。OpenDesign 打包的正是这些输入，这正是两者契合的原因（详见下文）。

Question 8

从零开始为设计工作设置 Gemini CLI

Accepted Answer

配置顺序：安装 → 认证 → 配置 GEMINI.md → 添加 skill → 启用浏览器验证。把你的设计规则写下来：将你的 token、原子组件和规范放进 GEMINI.md 并让 Gemini 指向它们，这样产出就会贴合某个品牌，而不是默认落入泛泛的外观。加入浏览器验证：接入 Playwright 或浏览器 MCP，让 Gemini 在真实浏览器中渲染，并在各个断点下检查输出，而不是只确认构建通过。命令和随版本变化的具体细节请以当前的配置章节为准，这些内容可能会有变动。# 1. Install Gemini CLI (Node 20+)
npm install -g @google/gemini-cli
# or run without installing: npx https://github.com/google-gemini/gemini-cli

# 2. Start it in your project and authenticate on first run
cd your-project
gemini            # sign in with your Google account, or set GEMINI_API_KEY

# 3. Generate project context
/init             # scaffolds a GEMINI.md for this project

# 4. Wire the Figma MCP server (optional, for design handoff)
#    add it under "mcpServers" in ~/.gemini/settings.json这是上一版指南中的历史命令示例；请查阅所链接的厂商文档以核实当前语法。

Question 9

用 Gemini CLI 把截图变成 UI

Accepted Answer

用 Gemini CLI 做设计，杠杆率最高的循环就是把一张参考图变成可运行、可响应的 UI，并不断迭代直到它与之吻合——依靠多模态模型把产出与参考图进行比对。从你手上最清晰的视觉参考开始——并且要包含多种状态（桌面端与移动端、hover、空状态、加载中），而不只是一张主视觉图。提示词要具体；即便模型很强，含糊的提示词也只会产出泛泛的 UI。把你的设计系统和规范放在 GEMINI.md 中，并告诉 Gemini 这些 token 和标准原子组件位于何处。启动开发服务器，让 Gemini 在真实浏览器中渲染，并调整到各个断点尺寸来检查结果。让 Gemini 把它的实现与截图逐一比对来进行迭代——而不只是确认能构建成功。用 @ 引用图片将其附加到提示词中，然后给出具体的约束：让提示词保持小而聚焦，把好的迭代提交、把差的回滚（回滚时告诉 Gemini），这样每一轮都建立在干净的基础之上。gemini
# in the prompt:
> @reference-desktop.png @reference-mobile.png
  Implement this design in React + Vite + Tailwind + TypeScript.
  Reuse my existing design-system components and tokens from GEMINI.md.
  Match spacing, layout, and hierarchy; make it responsive.
  Render it in the browser and iterate until it matches the references
  across breakpoints.这是上一版指南中的历史命令示例；请查阅所链接的厂商文档以核实当前语法。

Question 10

GEMINI.md、MCP 服务器与扩展

Accepted Answer

有三个扩展切入点让 Gemini CLI 足以胜任持续的设计工作，而这三者都能干净地对应到一套开放的设计工作流上。

GEMINI.md 上下文：项目规则存放在仓库根目录的 GEMINI.md 中（并带有全局层和团队层）。它是你设计规范的长期居所，每次运行都会被读取。

MCP 服务器：在 ~/.gemini/settings.json 下配置 MCP 服务器——这是引入设计上下文和外部工具的可移植方式，其中最相关的当属 Figma MCP 服务器，它可以跨不同智能体使用，而不限于 Gemini。

扩展与内置工具：Gemini CLI 的扩展及其内置的 Google Search、文件、shell 和网页抓取工具，让它无需离开终端就能收集参考资料并运行验证循环。

这些都是可移植的、面向多智能体的能力——正是 OpenDesign 生来就要去编排、而不是逐个项目管理复刻的东西。

Question 11

用于设计的 Gemini CLI vs Codex vs Claude Code vs Cursor

Accepted Answer

做设计没有唯一的胜者——每个智能体各有所长，有经验的团队会把它们叠起来用。一个公道的总结：

Gemini CLI —— 强大的多模态图像理解与 1M token 上下文；开源且有免费额度 —— 大量依赖截图的工作，以及把整套设计系统放进上下文

Codex —— 借助前端 skill 实现出色的视觉打磨；沙箱化的异步构建 —— 委托式的异步构建与可移植的 AGENTS.md 规则

Claude Code —— 具体的设计决策（色值、间距、字体）与理解代码库的 UX —— 前端推理与大规模上下文重构

Cursor —— 带实时预览和行内编辑的可视化“构建—查看”循环 —— 在 IDE 内部进行紧凑的迭代—观察式 UI 工作

社区反复得出的结论是：审美来自人。没有 skill、参考和约束，它们全都默认落到一种泛泛的审美上。这才是真正要解决的问题——而这是个设计工具层面、而非模型层面的问题。

智能体 —— 设计强项 —— 最适合

Question 12

常见陷阱以及如何避免“AI 味”外观

Accepted Answer

关于 AI 生成设计最常见的抱怨就是它看起来很泛泛——柔和的渐变、悬浮面板、过大的圆角、夸张的阴影，一股 Inter 字体配紫色的调调，“一看就是 AI 做的”。其他被反馈的问题还包括移动端布局错乱，以及指令渗入 UI 文案。这些问题并不是 Gemini CLI 独有的；任何智能体在没有精心打理的设计上下文时运行，都会出现这些情况。

添加一项美学 skill：一项精心打磨的设计 skill 会迫使智能体认真选定一个真实的方向，而不是沿用默认外观。

在真实浏览器中验证：利用多模态模型渲染并在各个断点下自查，避免布局在移动端悄无声息地崩坏。

提供 token 和参考：真实的设计 token 与参考截图，是影响产出质量最大的那根杠杆。

把规则写进 GEMINI.md：将“不要主视觉卡片、最多两种字体、层级以品牌为先”这类规则，放到智能体每次运行都会读取的地方。

注意，每一种缓解办法说到底都是在给智能体一份精心打理的设计上下文。逐个项目手工维护这份上下文，正是 OpenDesign 要消除的苦役。

Question 13

在 OpenDesign 中将 Gemini CLI 用作智能体

Accepted Answer

OpenDesign 就是上述工作流一直在呼唤的那层开源设计层。它把 Gemini CLI 当作一等适配器，并为其包裹上精心打磨的 skill 与设计系统库、结构化的渲染流水线以及本地桌面 UI——因此让 Gemini 表现出色的那份设计上下文，从第一次运行起就已就位，而不必每次手工拼装。两者同为开源、同为本地优先，这使它们的组合顺理成章。

使用你的 Google 账号或 Gemini API key（BYOK）进行认证——凭证留在你自己的机器上，绝不会经由我们代理。

选一套设计系统和一项 skill，然后生成品味一致的演示文稿、原型和落地页。

每一个产出物和 DESIGN.md 文件都存放在你自己的仓库里，而不是托管云上。

同一个 Gemini CLI 智能体、同一把 key——外加围绕它的真实、可移植、开源的设计工作流。它是本地优先且 Apache-2.0 的，所以你的工作和凭证都不会离开你的机器。

安装 OpenDesign 并选择 Gemini CLI 作为你的智能体。

Question 14

OpenDesign 与 Google 有关联吗？

Accepted Answer

没有。OpenDesign 是独立项目；Gemini 是 Google 的商标。

用 Gemini
在 OpenDesign
做设计。

选择你进入 Gemini CLI 的入口

用 Gemini CLI 生成产品界面

从零开始设置 Gemini

将 Gemini 与其他 Agent 对比

一个 Gemini 任务：从白板简介到渲染完成的界面

1设计 Brief 与约束条件

2谁做什么：你、Gemini CLI 和 OpenDesign

3Gemini 的产物：1440px 与 390px 下的运营仪表盘

4交付前审查

网格与间距

视觉层级

移动端布局

交互检查

Gemini CLI 适合你的设计任务之处——以及不适合之处

Gemini 适合的场景

选择其他工作流的场景

开始使用 Gemini 前的准备事项

工具范围Gemini，由 Google 打造

账户与身份验证Google 账户（免费层级）或 Gemini API

系统与版本桌面应用或源码

连接检查成功的标志

三步完成 Gemini 设置

下载 OpenDesign 桌面应用

准备你的 Gemini 连接

运行一个小型 Gemini 任务

走完 Gemini 设计循环的五个步骤

设计 Brief

设计约束

生成界面

预览

修订与验证

Gemini 设计资源

Gemini 延伸阅读

设计 Skill

设计系统

模板

Gemini CLI 的局限、人工检查与回退路径

关于 Gemini 与 OpenDesign 的常见问题

用 Gemini 在 OpenDesign 做设计。