用于设计的 Kimi CLI。

Kimi CLI 究竟是什么

Kimi CLI 是 Moonshot AI 面向终端发布的一款开源（Apache-2.0）AI 智能体。它会读取你的仓库、编辑文件、运行 shell 命令、搜索文件、抓取网页，并根据得到的反馈决定下一步——它从自然语言任务出发去规划和验证工作，而不仅仅是补全代码行。它是一个 Python 工具，用 uv 安装，背后驱动着 Kimi K2 模型家族。

在设计工作中，有两个特性尤为突出。Kimi K2 模型明确针对智能体式、长链路的编码与工具调用做了调优，因此智能体能把一项多步骤的构建任务一直推进到可用的结果。而上下文窗口在近期 K2 版本中可达 256k tokens，足以一次性装下你的整套设计系统、组件库和参考集，而不必把它们压缩概括掉。

• 上下文文件: Kimi CLI 会读取一个 AGENTS.md 文件作为持久的项目上下文——这正是编写你的设计约定、tokens 和评审清单的天然之处。对于尚未配置的项目，运行 /init 即可为其生成一个。
• MCP、ACP + 子智能体: 它通过 /mcp-config 以对话方式管理 MCP 服务器，通过 Agent Client Protocol（kimi acp）把会话暴露给 Zed 和 JetBrains，并能在隔离的上下文中调度内置的 coder、explore 和 plan 子智能体。
• 登录或 BYOK: 首次启动时，/login 让你通过 OAuth（Kimi Code）授权，或输入你自己的 Moonshot API 密钥；Kimi 的平台还提供 OpenAI 兼容和 Anthropic 兼容的端点。

• 厂商：Moonshot AI
• 凭证：Moonshot API 密钥（BYOK），或通过 Kimi Code 进行 OAuth 登录
• 许可证：Apache-2.0，开源

为什么智能体式 K2 模型和超大上下文适合做设计

Kimi CLI 的设计优势来自两项模型特性——但和所有智能体一样，审美品味仍然得由你来提供。

• 智能体式、长链路编码: Kimi K2 模型针对工具调用和多步骤工作做了优化，因此智能体能拿着参考稿和需求说明，真正去构建、运行并打磨 UI，而不是止步于初稿。
• 超大上下文窗口: 近期 K2 版本可达 256k tokens，意味着整套设计系统、tokens 和大量参考状态能一次性装下，于是智能体会复用你真实的基础元素，而不是凭空造出一次性的样式。
• 把约定写进 AGENTS.md: 一份 AGENTS.md（外加一个像 Figma 这样的 MCP 服务器）把智能体指向你的 tokens、组件和真实规范，于是它是在对照某个品牌工作，而不是套用默认外观。

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

从零开始为设计工作配置 Kimi CLI

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

# 1. 安装 Kimi CLI（使用 uv；Python 3.12–3.14，推荐 3.13）
curl -LsSf https://code.kimi.com/install.sh | bash
# 或者，如果你已经装了 uv：
uv tool install --python 3.13 kimi-cli

# 2. 在你的项目中启动它，并在首次运行时完成认证
cd your-project
kimi              # 然后运行 /login：通过 Kimi Code 进行 OAuth，或粘贴一个 Moonshot API 密钥

# 3. 生成项目上下文
/init             # 为该项目生成一个 AGENTS.md

# 4. 接入一个 MCP 服务器（可选，例如用 Figma 做设计交付）
/mcp-config       # 以对话方式添加、编辑和认证 MCP 服务器

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

从参考稿到 UI 的工作流

在 Kimi CLI 上收益最高的设计闭环，就是把参考素材转化为可用的响应式 UI，并不断迭代直到匹配——把参考稿喂给智能体，让它在真实浏览器中把渲染产出与参考稿对照回看。

1. 从你手头最清晰的参考稿出发——并且包含多种状态（桌面端和移动端、悬停态、空状态、加载态），而不只是一张主视觉图。
2. 在提示词里说清楚；含糊的提示词即便配上强大的智能体，也会产出千篇一律的 UI。
3. 把你的设计系统和约定放进 AGENTS.md，并告诉 Kimi tokens 和规范性基础元素位于何处。
4. 运行一个开发服务器，让 Kimi 在真实浏览器中渲染，并调整到各个断点来检查结果。
5. 让 Kimi 把自己的实现与参考稿对照回看来迭代——而不只是确认它能构建通过。

把 Kimi 指向你的参考稿和开发服务器，然后给出具体的约束：

kimi
# 在提示词中：
> 使用 React + Vite + Tailwind + TypeScript 实现 ./references 中的设计
  （reference-desktop.png、reference-mobile.png）。
  复用我已有的设计系统组件，以及 AGENTS.md 中的 tokens。
  匹配间距、布局和层级；做成响应式。
  运行开发服务器，在浏览器中渲染，并不断迭代，
  直到它在各个断点上都与参考稿匹配。

让提示词保持小而聚焦，提交好的迭代、回退差的迭代（回退时告诉 Kimi），这样每一轮都建立在一个干净的基础之上。当某个流程难以用文字描述时，Kimi CLI 也可以接收一段简短的屏幕录制或演示片段。

AGENTS.md、MCP 与子智能体

三个扩展点让 Kimi CLI 能够胜任持续的设计工作，而且这三者都能干净地映射到一套开放的设计工作流上。

• AGENTS.md 上下文: 项目规则存放在仓库根目录的 AGENTS.md 中。它是你设计约定的持久归宿，每次运行都会被读取——而且它是其他智能体也在用的同一种可移植格式。
• MCP 服务器: 用 /mcp-config 以对话方式添加 MCP 服务器——这是引入设计上下文和外部工具的可移植方式，其中最相关的是 Figma MCP 服务器，它们能跨智能体通用，而不只对 Kimi 有效。
• 子智能体与插件市场: 在隔离的上下文中调度内置的 coder、explore 和 plan 子智能体，并从市场或任意 GitHub 仓库安装 skill、MCP 服务器和数据源，用来收集参考稿并跑通验证闭环。

这些都是可移植的、跨智能体的能力——而这恰恰是 Open Design 生来要去编排的东西，而不是每个项目都重造一遍。

做设计时 Kimi CLI 对比 Codex、Claude Code、Cursor 与 Gemini CLI

在设计工作上没有唯一的赢家——每个智能体各有所长，有经验的团队会把它们叠在一起用。一个中肯的总结：

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

常见坑，以及如何避免“AI 味”外观

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

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

注意，每一项缓解措施都是关于给智能体一份精选的设计上下文。逐个项目地用手维护这份上下文，正是 Open Design 帮你免去的苦差事。

在 Open Design 中用 Kimi CLI 做设计

Open Design 正是上面这套工作流一直在呼唤的那个开源设计层。它把 Kimi CLI 当作一等适配器，并用精选的 skill 与设计系统库、一条结构化的渲染流水线，以及一个本地桌面 UI 把它包裹起来——于是让 Kimi 表现出色的那份设计上下文从第一次运行就已就位，无需每次手动拼凑。两者都是开源、本地优先的，这让这对组合成为天然的契合。

1. 安装 Open Design，并选择 Kimi CLI 作为你的智能体。
2. 用你的 Moonshot API 密钥认证（BYOK）——凭证留在你的机器上，绝不经我们代理。
3. 选定一套设计系统和一个 skill，然后以一致的品味生成演示稿、原型和落地页。
4. 每一份产物和 DESIGN.md 文件都存放在你自己的仓库里，而不是托管的云端。

同一个 Kimi CLI 智能体、同一把密钥——外加一套环绕它的、真实可移植的开源设计工作流。它本地优先、采用 Apache-2.0，所以你的工作内容和凭证都不会离开你的机器。

常见问题

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

   能——只要上下文里有一个审美 skill、一套设计系统和真实的参考图，Kimi CLI 就能产出生产级、响应式的 UI，而它智能体式的 Kimi K2 模型还能渲染产出并对照参考稿做验证。缺了这份上下文，它往往会退回到千篇一律的外观，而这正是 Open Design 要填补的落差。

2. 02 用 Kimi CLI 做设计需要付费吗？ +

   你自带凭证：通过 Kimi Code 的 OAuth 登录授权，或粘贴一个 Moonshot API 密钥（BYOK），由 Moonshot 平台计费。无论哪种方式，Open Design 都绝不代理你的凭证。

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

   两点：Kimi K2 模型针对智能体式、长链路的编码与工具调用做了调优，因此智能体能一路构建和打磨直到拿出可用的结果；而上下文窗口可达 256k tokens，足以一次性装下整套设计系统和参考集。两者都有帮助——但品味仍来自你提供的设计系统、skill 和参考稿。

4. 04 前端设计该用 Kimi CLI 还是 Claude Code？ +

   两者都很强。Claude Code 以具体的、理解代码库的设计决策著称；Kimi CLI 的优势在于它智能体式的 Kimi K2 模型，以及带 BYOK 经济性的超大上下文。许多团队两者都用——Open Design 让你在不改变设计工作流的前提下切换智能体。

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

   在 Kimi CLI 内运行 /mcp-config，来添加并认证 Figma MCP 服务器。随后 Kimi 就能拉取真实的设计上下文——组件、变量、布局数据——让生成的代码贴合源头，而不是近似还原。

6. 06 Open Design 隶属于 Moonshot AI 吗？ +

   不。Kimi CLI 是 Moonshot AI 的产品；Open Design 是一个独立的开源项目，把它作为一等适配器来支持。Kimi 是 Moonshot AI 的商标。

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

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