先讓 AI 把「要什麼」寫清楚，再讓它動手寫程式——Kiro 用規格把 AI 編碼從「猜」變成「實作」。

用 AI 寫程式有個繞不開的問題：你講得越籠統，它猜得越離譜。一句「給部落格加個留言系統」，它可能給你三種風格完全不同的做法，改到最後你已經不記得當初要的是什麼。Kiro 的思路是反過來的——先把需求寫成一份你審得過的規格，再讓 agent 照著規格施工。

Kiro 由 AWS 打造並營運，2025 年 7 月發布，之後正式 GA。它把這件事總結成一句話：從 AI 編碼走向 agentic engineering。它不是一個純聊天式的補全工具，而是一套把需求、設計、任務、實作串起來的工作流。

Spec 驅動：一句話長出三份規格書

核心是規格驅動開發。你只給一句自然語言描述，它會依序產出三份規格書。需求那份把需求拆成使用者故事與驗收標準；設計那份給出架構、技術選型與系統設計；任務那份則是依相依順序排好的清單。這些檔案預設放在專案裡的 specs 目錄下，官方建議跟程式碼一起提交進儲存庫。

需求那部分的寫法值得一提。驗收標準用 EARS 語法來寫，格式大致是「當某個條件成立時，系統應當如何」。這套語法源自航空安全系統，好處是把模糊描述逼成可驗證的斷言，邊界情況不容易被漏掉。

三份規格書每一份都會停下來等你確認。你可以改需求、否決技術方案、調整任務順序，等滿意了再讓 agent 逐個執行。整個過程用差異呈現，可以整批接受，也可以一行一行過。

寫程式之前，先查需求有沒有自相矛盾

Kiro 有個不太常見的動作：在動手寫程式前，它會用自動化推理手段檢查你的需求裡是否存在衝突與缺口。官方的說法很直接——「所有測試通過」不等於程式碼符合你的意圖，所以先把意圖本身驗一遍。

實作之後還有一層驗證，用的是屬性測試（property-based tests，類似模糊測試）。一般單元測試檢查幾個具體案例，屬性測試斷言的則是「對所有輸入都必須成立的規則」，因此更容易抓出那種能通過單元測試、一上生產就出問題的邊界情況。

Steering 與 Hooks：把專案規矩固定下來

每次開新對話都要重講一遍「我們用嚴格型別」「測試檔跟原始碼放一起」，是件很消耗耐心的事。steering 檔案就是為此準備的：放在 steering 目錄下的 Markdown 文稿承載架構決策、編碼規範、命名慣例這類長期知識，Kiro 在生成程式碼、審查改動時會自動參考。載入方式分三種——常駐、按檔案條件載入、手動引用，也相容 AGENTS.md 這類通用約定檔。

agent hooks 則把「我應該養成的習慣」變成自動執行。你可以定義在檔案儲存、建立、刪除等事件發生時，讓 agent 跑一段預設任務：儲存元件時順手補測試檔，改動 API 端點後同步更新說明文稿，提交前掃一遍有沒有洩漏憑證。官方把它比作「跑在本機的持續整合」，差別是判定邏輯用自然語言寫，不必學設定語法。

四種形態，一套設定

Kiro 目前提供 IDE、命令列、網頁端、行動端，以及一個叫 Kiro Crew 的持久化開發工作區。IDE 基於開源編輯器底座，能匯入你現有的編輯器設定、主題與外掛，遷移成本不高；命令列支援 bash、zsh、fish 以及五百多個常用 CLI，也能以無介面方式跑在流水線裡審 PR、修 bug。

網頁端的會話跑在隔離的雲端沙箱裡，關掉筆電它還會繼續跑，變更可以跨儲存庫協調。Kiro Crew 是開源專案（Apache 授權），跑在你自己的機器上，跨會話保持上下文，定位更偏向「長期陪跑的開發工作區」。

模型不用你挑

Kiro 不要求你自己選模型。預設的 Auto 會按任務複雜度，結合模型品質、延遲與成本自動路由；你也可以明確指定，包括 Claude Sonnet 這條線，或者在免費檔裡使用 Qwen3 Coder Next 這類開放權重模型。付費檔會解鎖更多進階模型。

計量單位是 credit，按提示詞消耗，精確到小數點後兩位，簡單請求可能連一個 credit 都用不到。IDE 裡能即時看到每條提示詞花了多少，不用擔心帳單突然失控。

價格與上手

免費檔是長期有效的，每月五十 credits，不需要綁信用卡，也能用上幾款主力模型，適合先把 spec 流程跑一遍試試手感。付費檔每月二十美元給一千 credits，四十美元兩千，一百美元五千，兩百美元一萬。額度不夠時可以按四美分一個加購。團隊與企業版另含集中計費、單一登入、用量看板與權限治理。

登入方式支援 GitHub、Google、AWS Builder ID 或 AWS IAM Identity Center，不需要有 AWS 帳號，這一點常被誤會。桌面端覆蓋 Windows、macOS 與 Linux。

Kiro 想解決的不是「AI 寫程式夠不夠快」，而是「它寫的到底是不是你要的」。把需求先固化成可審閱、可進版本庫的規格，再讓 agent 去實作，返工與爭執的次數會明顯少一些——對需要長期維護的專案來說，這份規矩值得。