用於設計的 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 伺服器中轉。