用于设计的 Kiro CLI。

Kiro CLI 究竟是什么

Kiro 是 Amazon 推出的智能体式 AI，提供 IDE、命令行界面和网页界面三种形态，旨在借助规范驱动开发把你从原型一路带到生产。Kiro CLI 把这个 agent 带到你的终端：你可以开启一段交互式聊天会话、创建并管理 agent、运行 Model Context Protocol 服务器——全部都在命令行里完成。Kiro 目前处于预览阶段。

对设计工作而言，最关键的特性是它的工作流。Kiro 不会把提示词直接变成代码，而是先写一份规范——需求、一份设计文档和一份有序的任务清单——然后照着它去实现。这让 agent 的计划在任何 UI 被构建之前就可见、可审阅，这恰好契合设计决策应有的方式：先定意图，再去执行。

• 规范: Kiro 在写代码之前先把提示词变成一份结构化规范——需求、一份设计文档和一项项独立的任务——这样计划在一开始就可审阅。
• 引导文件 + 钩子: 引导文件把你的标准、约定和偏好的工具带进每一次运行；agent 钩子在文件保存等事件上触发，自动运行后台任务。
• 免费起步、支持 MCP: 用 Builder ID、Google、GitHub 或你所在的组织登录即可免费开始；Kiro CLI 还会管理 MCP 服务器，以引入外部上下文。

• 厂商：Amazon（AWS）
• 凭证：通过 kiro-cli login 使用 AWS Builder ID、Google、GitHub 或 AWS IAM Identity Center（无需 AWS 账号）
• 状态：预览阶段；提供 IDE、CLI 和网页界面

为什么规范驱动开发契合设计

Kiro CLI 在设计上的优势来自它的工作流——但和每个 agent 一样，审美仍然得由人来提供。

• 先有意图，再有像素: 因为 Kiro 会先写一份规范和一份设计文档，你可以在规划阶段就纠正布局、层级和范围——在 agent 还没落入一种千篇一律的实现之前。
• 引导文件承载你的品牌: 引导文件在每一次运行时都把你的 tokens、组件和约定摆在 agent 面前，于是产出契合品牌，而不是落入默认的样子。
• 钩子强制执行闭环: agent 钩子可以在保存时自动跑检查——这是接入一个验证或评审步骤的好地方，而不必指望 agent 自己记得。

这个教训和每个 agent 教给我们的一样：Kiro CLI 默认并不具备审美。规范能让构建保持诚实，但只有当你给它约束——一套设计系统、一个审美 skill 和具体的参考——它才能产出好设计。Open Design 恰好把这些输入打包好了，这正是两者契合的原因（下文详述）。

从零开始，搭建用于设计工作的 Kiro CLI

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

# 1. 安装 Kiro CLI（macOS/Linux/Windows 的命令见 kiro.dev/docs/cli）

# 2. 认证——会打开浏览器完成登录
kiro-cli login   # 选择 Builder ID、Google、GitHub 或你所在的组织

# 3. 确认你已登录
kiro-cli whoami

# 4. 在你的项目里开启交互式会话
cd your-project
kiro-cli chat

# 5. 接入 MCP 服务器（可选，例如用于设计交付）
kiro-cli mcp add ...

• 把你的设计规则编码进去: 把你的 tokens、基础元素和约定写进引导文件，让 agent 在每一次运行时都读到它们，于是产出契合品牌，而不是落入千篇一律的默认样子。
• 加入浏览器验证: 接入一个 Playwright 或浏览器 MCP 服务器，让 Kiro 在真实浏览器中渲染并跨断点检查其产出，而不是只确认构建能通过。

截图到 UI 的工作流

用 Kiro CLI 做设计时杠杆最大的闭环，是把一张参考图变成可用的、响应式的 UI，并反复迭代直到吻合——让规范先捕捉意图，然后照着它去构建。

1. 从你手头最清晰的视觉参考出发——并且要包含多种状态（桌面端和移动端、悬停、空态、加载），而不只是一张主视觉。
2. 让 Kiro 从你的提示词写出一份规范和设计文档，并在它构建之前审阅计划——这是你及早发现布局和范围问题的地方。
3. 把你的设计系统和约定放进引导文件，并告诉 Kiro tokens 和规范化基础元素在哪里。
4. 跑一个开发服务器，让 Kiro 在真实浏览器中渲染，并调整到各个断点来检查结果。
5. 通过让 Kiro 把它的实现对照参考来迭代——而不只是确认它能构建通过。

开启一段交互式会话，并在一开始就给出具体约束，这样它写出的规范才能反映你真实的意图：

kiro-cli chat
# 在提示词中：
> 这是我的参考图：reference-desktop.png 和 reference-mobile.png。
  先写一份规范，然后用 React + Vite + Tailwind + TypeScript 实现这个设计。
  复用我现有的设计系统组件和 tokens（见我的引导文件）。
  对齐间距、布局和层级；做成响应式。
  在浏览器里渲染它，并反复迭代直到它在各个断点上
  都与参考图吻合。

保持任务小而聚焦，把好的迭代提交、把坏的回退掉（回退时告诉 Kiro），这样每一轮都建立在一个干净的基础之上。

规范、引导文件、钩子与 MCP

四个扩展点让 Kiro CLI 在持续的设计工作中变得实用，而这四个都能干净地映射到一套开放的设计工作流上。

• 规范: 需求、一份设计文档和一份有序的任务清单——记录一个功能本应是什么样的持久档案，在构建之前和构建之中都可审阅。
• 引导文件: 添加 agent 在每一次运行时都会读取的上下文、编码标准以及偏好的工作流或工具——这是安放你设计约定和 tokens 的天然之地。
• agent 钩子: 在文件保存等事件上触发的自动化，运行检查或文档生成等后台任务——这是自动强制执行一个验证步骤的好地方。
• MCP 服务器: Kiro CLI 会管理 Model Context Protocol 服务器，这是引入外部设计上下文和工具的可移植方式，能跨 agent 通用，而不仅限于 Kiro。

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

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

在设计工作上没有唯一赢家——每个 agent 各有不同的强项，经验丰富的团队会把它们叠加使用。一个公允的概括：

社区反复得出的结论是：审美来自人类——它们在缺少 skill、参考和约束的情况下都会默认落入一种千篇一律的风格。那才是真正要解决的问题——而它是设计工具形态的问题，不是模型形态的问题。

常见坑，以及如何避免“AI 流水线感”外观

对 AI 生成设计最常见的抱怨是它显得千篇一律——柔和的渐变、悬浮的面板、过大的圆角、夸张的阴影，一种 Inter 字体加紫色的调调，“一看就是 AI 做的”。其他被反映的问题还包括移动端布局错乱、以及指令泄漏进 UI 文案里。这些都不是 Kiro CLI 独有的；当任何 agent 在没有精选设计上下文的情况下运行时，就会这样——规范能让构建不跑题，但它无法提供审美。

• 加入一个审美 skill: 一个精选的设计 skill 会迫使 agent 投入一个真正的方向，而不是默认的样子。
• 在真实浏览器中验证: 跨断点渲染并自检——能的话把它接成一个钩子——这样布局就不会在移动端悄无声息地崩掉。
• 提供 tokens 和参考: 真实的设计 tokens 和参考截图是对产出质量影响最大的单一杠杆。
• 把规则编码进引导文件: 把“不要主视觉卡片、最多两种字体、品牌优先的层级”这类风格规则放在 agent 每次运行都会读到的地方。

注意，每一种缓解办法都是关于给 agent 一份精选的设计上下文。每个项目手动维护那份上下文，正是 Open Design 要替你省掉的苦工。

在 Open Design 中用 Kiro CLI 做设计

Open Design 正是上述工作流一再呼唤的那个开源设计层。它把 Kiro CLI 当作第一方适配器，并用一套精选的 skill 与设计系统库、一条结构化的渲染流水线和一个本地桌面 UI 来包裹它——于是让 Kiro 变好的那份设计上下文从第一次运行起就在那里，而不是每次都手动拼凑。Open Design 本地优先，这让这对组合保持简单：你的文件和你的登录都留在你自己的机器上。

1. 安装 Open Design，并选择 Kiro CLI 作为你的 agent。
2. 用你的 AWS Builder ID 或其他登录方式认证——凭证留在你的机器上，绝不经我们代理。
3. 挑一套设计系统和一个 skill，然后以一致的审美生成演示稿、原型和落地页。
4. 每一件产物和 DESIGN.md 文件都存在你自己的仓库里，而不是托管云端。

同一个 Kiro CLI agent、同一套登录——再加上围绕它的一套真实、可移植、开源的设计工作流。Open Design 本地优先且采用 Apache-2.0，所以你的工作和凭证没有任何东西会离开你的机器。

常见问题

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

   能——在上下文里配上一个审美 skill、一套设计系统和真实的参考图，Kiro CLI 就能产出生产级、响应式的 UI，而它规范驱动的工作流会让构建对既定意图负责。没有那份上下文时，它往往会落入千篇一律的样子，这正是 Open Design 补齐的短板。

2. 02 使用 Kiro CLI 需要 AWS 账号吗？ +

   不需要——Kiro 允许你用 AWS Builder ID、Google、GitHub 或你所在的组织（AWS IAM Identity Center）登录，使用它无需 AWS 账号。Kiro 目前处于预览阶段且可免费起步。无论哪种方式，Open Design 都绝不代理你的凭证。

3. 03 Kiro CLI 在设计上具体好在哪里？ +

   它的规范驱动工作流：Kiro 在写代码之前先写需求、一份设计文档和一份任务清单，于是你能在构建落定之前纠正布局和范围。引导文件承载你的约定，钩子能强制执行检查——但审美仍然来自你提供的设计系统、skill 和参考。

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

   两者都很强。Claude Code 以具体、理解代码库的设计决策著称；Kiro CLI 的优势在于其规范驱动、可审阅、带引导文件和钩子的工作流。很多团队两者都用——Open Design 让你在不改变设计工作流的前提下切换 agent。

5. 05 我如何把 Kiro CLI 连接到外部设计工具？ +

   Kiro CLI 会管理 Model Context Protocol（MCP）服务器——用 kiro-cli mcp 来添加它们。一个 MCP 服务器能把真实的设计上下文和工具带进 agent，让生成的代码与源头吻合，而不是近似还原。

6. 06 Open Design 是否隶属于 Amazon 或 AWS？ +

   不是。Kiro 是 Amazon（AWS）的产品；Open Design 是一个独立的开源项目，以第一方适配器的方式支持它。Kiro 是 Amazon 的商标。

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

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