Kiro 是什麼？AWS 的 spec-driven AI IDE，從三份規格文件到撞上每日額度

8 月 4 日早上十點多，Mac 右上角跳出一則通知：

macOS 通知：Kiro 顯示 Agent Execution Failed，Usage limit reached

切回 Kiro，聊天視窗裡寫著：

Kiro 聊天視窗訊息：You've reached your daily usage limit. Please return tomorrow to continue building.

今天的額度用完了，明天再來。這是 Kiro 在 preview 期間加上的每日上限。一個還在免費試用的 IDE 需要限量供應，也看得出現在有多少人擠在上面用。

這篇把我這陣子記下的 Kiro 筆記整理在一起：它是什麼、跟一般 AI IDE 最不一樣的 spec 流程怎麼運作，還有 preview 期間的每日額度，以及 8 月 1 日公布、比第一版還貴的新定價。

資料截至 2025-08-06。Kiro 還在 preview，功能、額度和價格都還在變，實際以 kiro.dev 為準。

Kiro 是什麼？

Kiro 是 AWS 在 2025 年 7 月 14 日發表的 AI IDE，目前是 preview，免費但有用量限制。官方發表文對它的定位是：幫你從概念一路做到 production 的 agentic IDE。

它的品牌做得很特別。Kiro 有自己的網域 kiro.dev、自己的登入流程，用 Google 或 GitHub 帳號就能登入。About 頁對出身只輕輕帶過一句：它是 AWS 內部「一個小而有主見的團隊」做的（a small, opinionated team within AWS）。

介面一打開就很熟悉。Kiro 建立在 Code OSS（VS Code 的開源版本）上，第一次啟動可以匯入 VS Code 的設定、佈景主題，還有 Open VSX 上的擴充套件。下面是它的 Source Control 面板，除了配色跟左邊那隻幽靈圖示，幾乎就是 VS Code：

Kiro 的 Source Control 面板：紫色 Commit 按鈕，左側活動列有 Kiro 的幽靈圖示，版面和 VS Code 幾乎相同

模型方面，preview 期間可以在 Claude Sonnet 4 和 Claude 3.7 Sonnet 之間選，預設是 Sonnet 4。作業系統支援 macOS、Windows 和 Linux。

冷知識：Kiro 這個名字

About 頁對名字的說明只有一段：

We chose the name “Kiro” (rhymes with “hero”) because, among other meanings, it represents a hardworking person who never gives up.

意思是：Kiro 念起來跟 hero 押韻，而且在其他含義之外，它代表「一個努力不懈、永不放棄的人」。官方接著說，這個名字也代表團隊的北極星：快速前進，不停迭代。

網路上還流傳另一種說法，說 Kiro 在日文裡是「迴路、路徑、路線」的意思，剛好呼應 AI 開發走到十字路口。這是一篇 DEV Community 文章作者自己的詮釋，官方頁面沒這樣寫過。官方那句「among other meanings」留了伏筆，但沒說其他含義是什麼。

開新 session 的兩條路：Vibe 和 Spec

在 Kiro 開新對話時，會先讓你選 session 類型：

Vibe session：對話式，適合快速提問、解釋程式碼、邊聊邊做，也就是大家熟悉的 AI 聊天寫程式。
Spec session：把開發流程正式化，先產出規格文件，再照著規格一步步實作。

Vibe 是大部分 AI IDE 本來就有的東西，Spec 才是 Kiro 真正想賣的。

另外還有一個跟 session 類型無關的開關：Autopilot 和 Supervised。Autopilot 是預設值，agent 可以直接改動整個 codebase、自己把複雜任務做完；Supervised 會把每個動作先攤出來，等你同意才執行。聊天視窗裡隨時可以切換。

Spec：先寫三份文件，再讓 agent 動手

Spec session 會把一個功能拆成三份 markdown，放在專案的 .kiro/specs/<功能名稱>/ 底下：

檔案	內容
requirements.md	使用者故事與驗收條件，用 EARS 格式寫
design.md	技術架構、sequence diagram、實作上的考量
tasks.md	拆成一項項可追蹤的實作任務

流程分成需求、設計、實作規劃、執行四個階段。每份文件產出後，Kiro 會停下來讓你審閱、修改，確認了才進下一階段：

flowchart TB
    A["描述要做的功能"] --> B["requirements.md<br/>EARS 驗收條件"]
    B --> R1{"審過了嗎？"}
    R1 -- "要改" --> B
    R1 -- "OK" --> C["design.md<br/>架構與 sequence diagram"]
    C --> R2{"審過了嗎？"}
    R2 -- "要改" --> C
    R2 -- "OK" --> D["tasks.md<br/>拆成可追蹤的任務"]
    D --> E["逐項執行 task<br/>每項算 1 個<br/>spec request"]
    E --> W["⚠️ 打勾只代表做完<br/>不代表驗證過"]

我覺得這個設計最聰明的地方，是規格跟程式碼放在同一個 repo，而且就是一般的 markdown 檔。你可以 code review 它、用 git 追它的變更，換一個工具也讀得懂。後面會看到，真的有人這樣做。

EARS：用固定句型寫驗收條件

requirements.md 裡的驗收條件用 EARS（Easy Approach to Requirements Syntax）寫。Kiro 文件給的句型是：

WHEN [condition/event] THE SYSTEM SHALL [expected behavior]

套進實際需求，大概長這樣：

WHEN 使用者送出空白的 email 欄位
THE SYSTEM SHALL 顯示「請輸入 email」並阻止送出

每條需求都有明確的觸發條件和預期行為，agent 比較沒有空間自由發揮，你之後要驗收也有東西可以對。

冷知識：EARS 原本是寫給噴射引擎的

EARS 不是 Kiro 發明的。維基百科是這樣寫的：

Developed by Alistair Mavin and colleagues at Rolls-Royce plc while analysing airworthiness regulations for a jet engine control system, EARS was first published at the IEEE International Requirements Engineering Conference (RE’09) in 2009.

也就是說，這套句型是 Rolls-Royce 的 Alistair Mavin 和同事，在分析噴射引擎控制系統的適航法規時整理出來的，2009 年在 IEEE 需求工程研討會（RE’09）發表。這裡的 Rolls-Royce 是做航空引擎的 Rolls-Royce plc，不是做汽車的那家。除了 Kiro 文件示範的 WHEN（事件觸發），EARS 還有 WHILE（狀態）、IF…THEN（例外狀況）、WHERE（選配功能）等句型。

十幾年前拿來約束飛機引擎需求的寫法，現在被拿來約束 AI agent。想想也合理，兩邊要防的都是同一件事：需求寫得太模糊，執行的一方就自己腦補。

EARS 跟 BDD 像嗎？

第一次看到 WHEN…SHALL 這種句型，我直覺想到的是自己比較熟的 BDD（Behavior-Driven Development）。BDD 的情境用 Given／When／Then 寫，一樣有 When，一樣是用固定句型寫驗收條件。

兩者確實是近親，目的都是用結構化的自然語言，把「系統該怎麼表現」講到沒有模糊空間。同一條需求，兩種寫法放在一起看：

WHEN 使用者送出空白的 email 欄位
THE SYSTEM SHALL 顯示「請輸入 email」並阻止送出

Scenario: 沒填 email 就送出
  Given 使用者在註冊頁
  When 使用者沒填 email 就按下送出
  Then 畫面顯示「請輸入 email」
  And 表單沒有被送出

句型大致可以對上：EARS 的 WHILE（前提狀態）接近 Given，WHEN（觸發事件）對應 When，SHALL 後面的系統反應就是 Then。但最根本的差別是：EARS 寫的是一條規則，BDD 寫的是一個例子。

比較	EARS	BDD（Gherkin）
寫的是什麼	一條需求規則	一個具體情境（例子）
句型	WHEN、WHILE、IF…THEN、WHERE，搭配 SHALL	Given、When、Then
出身	需求工程，Rolls-Royce，2009 年發表	從 TDD 演化而來，Dan North，2006 年發表
能不能直接執行	不能，是寫給人（和 agent）讀的	可以，用 Cucumber、Behat 等工具接成自動化測試

能不能執行是關鍵。Dan North 那篇 Introducing BDD 裡有一節標題直接叫 “Acceptance criteria should be executable”（驗收條件應該要能執行）。EARS 沒有這個野心，它出身於分析適航法規，重點是把需求本身寫得沒有歧義。

所以我會把兩者當成上下游，不是二選一。一條 EARS 規則，通常可以展開成好幾個 BDD 情境。而寫情境的過程，常常會反過來逼你回頭補規則。例如「空白的 email」算不算包含只打了空格？

flowchart TB
    R["EARS 規則<br/>WHEN 送出空白 email<br/>SHALL 顯示錯誤"] --> S1["情境 1<br/>完全沒填"]
    R --> S2["情境 2<br/>只打了空格"]
    S2 --> Q{"規則有講到<br/>這種情況嗎？"}
    Q -- "沒有，回頭補" --> R
    Q -- "有" --> T["用 Cucumber、Behat<br/>跑成自動化測試"]
    S1 --> T

EARS 讓 agent 知道要做什麼，BDD 情境負責證明它真的做到了。這剛好補上後面會提到的一個缺口：tasks.md 打勾不代表驗證過，能自動跑的情境才算。

Hooks 和 Steering：把習慣寫成檔案

Spec 管的是「這個功能要做什麼」，另外兩個功能管的是「每次都要記得的事」。

Agent Hooks 是事件觸發的自動化。建立檔案、儲存檔案、刪除檔案，或是你手動觸發的時候，讓 agent 在背景執行事先寫好的指示。像「存檔時順便檢查對應的測試有沒有跟上」這種平常靠人記、又常常忘記的事，就很適合交給 hook。

Steering 是給 agent 的長期記憶，放在 .kiro/steering/ 底下的 markdown。Kiro 可以幫你產生三份基礎檔案：

product.md：產品概觀
tech.md：技術棧
structure.md：專案結構

這三份預設每次互動都會帶入。你也可以自己加 steering 檔，設定成永遠帶入（always）、符合特定檔案路徑才帶入（fileMatch），或是在對話裡用 #檔名 手動引用（manual）。

用過 Claude Code 的人應該會覺得眼熟，這跟 CLAUDE.md 是同一個概念，只是 Kiro 把它拆成多個檔案，還多了依檔案路徑條件載入。

整個 .kiro/ 資料夾大概長這樣：

.kiro/
├── specs/
│   └── user-login/
│       ├── requirements.md
│       ├── design.md
│       └── tasks.md
└── steering/
    ├── product.md
    ├── tech.md
    └── structure.md

另外 Kiro 也支援 MCP，可以接外部的 MCP server 擴充工具，官方文件拿來示範的是 AWS Documentation MCP server。

Preview 爆紅之後：waitlist 和每日額度

Kiro 發表時就講明了：“Kiro is free during preview, with some limits.”（preview 期間免費，但有一些限制。）

問題是用的人太多。7 月 18、19 日開始，Kiro 的 GitHub issue 裡陸續有人貼出那句 “You’ve reached your daily usage limit”。到了 7 月下旬，Kiro 團隊在 Discord 宣布兩項「暫時措施」：新使用者要排 waitlist，既有使用者加上每日用量上限，至於上限是多少，暫時不公開（The Register 有報導）。

更讓人困擾的是，官方也沒說額度幾點重置。社群普遍認為是 UTC 0 點，也就是台灣早上 8 點，但這是大家自己觀察出來的。8 月 3 日還有人開 issue，請官方直接把重置時間顯示在畫面上。

有人乾脆做了一個倒數時鐘

既然大家每天都在等重置，社群就有人做了 Kiro Reset Clock：一個倒數到下一個 UTC 0 點的網頁。瀏覽器分頁標題會變成 👻 加上倒數的時、分、秒，重置前大約 5 分鐘還會響鬧鐘。作者是 hololeo，看起來是粉絲自製，跟官方沒有關係。

它還藏了幾個彩蛋：

按 C：噴彩帶
按 T：直接快轉到歸零，看重置那一刻的慶祝動畫
按 M：切換成大約 5 分鐘的測試倒數

一個 IDE 的額度重置時間，要靠社群自己做時鐘來等，這畫面本身就很說明問題。

大家的反應：拜託讓我付錢

社群裡最常見的抱怨不是太貴，而是沒辦法付錢。Reddit 上甚至有一串的標題直接叫〈Take my money and remove my limits〉。

我還記下一則抱怨，大意是：到底什麼時候才能付費？讓我不要再被每日上限卡住，至少讓我有機會撐完一個工作天。這真的很打斷工作節奏。我只想把錢交給 AWS，而 AWS 平常明明很擅長收錢。

平常是 AWS 想辦法讓你多付一點，這次是使用者追著要付錢。

8 月 1 日的新定價：比第一次公告還貴

這波額度風波，最後的答案是定價。

其實 Kiro 發表後不久就在 pricing 頁公布過一版價格，當時三個方案都標著 COMING SOON：

方案	月費	每月額度
Free	$0	50 次 interaction
Pro	$19	1,000 次 interaction
Pro+	$39	3,000 次 interaction

超量每次 $0.04。這裡的 interaction 算得很寬鬆：你問 Kiro 一次、執行一次 spec、觸發一次 hook，各算一次；Kiro 為了完成任務自己去呼叫工具、重試幾輪，都不另外算。

這版價格在 7 月 19 日之前就從網站上撤掉了，官方改口說要根據開發者實際的使用方式重新調整。

8 月 1 日，官方發了〈Kiro pricing update + waitlist invites coming soon〉。新方案變成下面這樣，額度數字來自 8 月 3 日的 pricing 頁快照：

方案	月費	Vibe requests	Spec requests
Free	$0	50	0
Pro	$20	225	125
Pro+	$40	450	250
Power	$200	2,250	1,250

計費單位拆成兩種：

Vibe request：所有聊天式的互動，包括產生 requirements、寫 design、即時寫程式、解釋程式碼、修 bug、code completion，還有 hook 觸發。大致上你送出一則訊息就算一次。
Spec request：在 spec 流程裡執行一個 task 算一次。

超量費用是 vibe 每次 $0.04、spec 每次 $0.20。Free 方案每月有 50 個 vibe request，spec 則只有新使用者頭兩週的試用額度。

把兩版放在一起比：

Pro：月費 $19 → $20，額度從 1,000 次變成 350 次（225 + 125），少了 65%
Pro+：月費 $39 → $40，額度從 3,000 次變成 700 次（450 + 250），少了 77%
超量費：spec 從每次 $0.04 變成 $0.20，是原本的 5 倍

兩版的計費單位不同，沒辦法完全等價比較：舊版一次 interaction 可能包含 agent 背後好幾輪工具呼叫，新版也說複雜的請求一次可能吃掉好幾個 request。但月費幾乎沒動、額度少了一大截，怎麼看都是漲價。

我看到新價格的第一個反應是：preview 階段被玩爛了，嚇到原廠爸爸了 XD

回頭看 7 月撤價時那句「根據開發者實際的使用方式重新調整」，意思大概就是這樣。受影響最大的是 spec 重度使用者，因為 Kiro 最有特色的那條流程，剛好是最貴的那種 request。

官方說 waitlist 上的人下週開始陸續收到邀請，8 月稍晚也會開放選擇付費方案。

額度用完的時候，還能做什麼？

回到開頭那則通知。撞到上限那天，我第一個念頭是：改用付費的 Amazon Q Developer 會不會比較好？Kiro 的 FAQ 提到，Q Developer Pro 的用戶可以用同一組 IAM Identity Center 帳號登入 Kiro，看起來兩邊是打通的。

結果在 Kiro 的 Discord 看到團隊成員這樣回覆：

Kiro Discord 上團隊成員的回覆：目前擁有 Q Developer Pro 帳號不會讓你在 Kiro 多拿額度，也不會把相同的用量上限套用到 Kiro

可惜了。至少目前 Q Developer Pro 不會幫你在 Kiro 多換到任何額度。FAQ 講的打通只限於登入和資料使用：Pro 用戶可以用同一組身分登入，內容也不會被拿去改進服務。

規格是 markdown，換個工具也能接著做

在 Kiro 的 Discord 上，我看到有人分享另一種做法，蠻有啟發的。

他的額度用完、在等重置，先去研究了一些 spec-driven 的提示詞專案，覺得都比他想要的複雜太多。最後乾脆換個想法：直接把現成的 tasks.md 這些檔案丟給別的模型，看看會怎樣？

先在 Void 編輯器裡用 Claude Sonnet 4，請它讀 .kiro 裡的規格，告訴他下一個 task 該做什麼。結果在它提出第一個修改之前，API 費用就花掉了 3.89 美元。
改用 Amazon Q Developer 的免費方案。外掛雖然顯示了不支援之類的訊息，但靠幾句簡單的提示，還是把 task 做完了，連 bug 也一起修掉。tasks.md 上的勾勾，他印象中是自己手動打的。
等 Kiro 額度重置後，他問 Kiro：「task 3.1 我自己做完了，看起來對嗎？」Kiro 看了一下勾勾就說都完成了，完全沒檢查程式碼。直到他明講「可以檢查一下 task 3.1 的程式碼，確認沒問題嗎？」，Kiro 才真的去讀檔案、跑測試，最後給出的審查結論是實作很出色。

他本來就在用 Amazon Q 和 Gemini Code Assist，覺得 Q 的專業版（每月 19 美元）搭配 Kiro 可能很不錯，而且 Q 免費方案的額度重置得比較快，不用等一整天。

這個分享給我兩個提醒：

Spec 本身是可攜的。requirements、design、tasks 都是純 markdown，Kiro 額度用完，別的工具照樣讀得懂。真正綁在 Kiro 身上的是產生 spec、照 spec 執行的那套流程，不是檔案本身。
tasks.md 的勾勾只是狀態，不是驗證。勾勾誰都能打，agent 看到打勾就當作完成。要它真的檢查，得明確叫它去讀程式碼、跑測試。

整理成一張圖：

flowchart TB
    A["Kiro 跳出<br/>daily usage limit"] --> B{"額度用完了<br/>怎麼辦？"}
    B -- "等" --> C["等 UTC 0 點重置<br/>台灣 8 點<br/>官方未明講"]
    B -- "買 Q Pro" --> X["❌ 不會增加<br/>Kiro 額度"]
    B -- "換工具" --> D["其他 AI 工具<br/>讀 .kiro/specs"]
    D --> F["⚠️ 手動打的勾<br/>要請 Kiro<br/>檢查程式碼"]
    C --> G["回 Kiro 執行<br/>下一個 task"]
    F --> G

我怎麼看 Kiro

Kiro 把「先寫規格、再寫程式」做成 IDE 的一等公民，這是它跟其他 AI IDE 最不一樣的地方。我覺得它最有價值的地方不在 agent 寫得多快，而是逼你先把那三份文件寫清楚。需求模糊的時候，agent 寫得再快也只是更快寫錯。

但它的商業模式還沒定下來。preview 的每日額度沒公布數字，重置時間也沒公布；8 月 1 日的新價格，額度又比第一版少了一大截。最有特色的 spec 流程，偏偏是最貴的那種 request。

好消息是，spec 是 markdown，steering 也是 markdown。就算最後不用 Kiro，requirements、design、tasks 這套寫法也帶得走。

官方說 8 月稍晚會開放付費方案。等價格正式上線，再來看看實際跑一個 spec，一個 task 到底會吃掉多少 request。