編輯 | 伊風

出品 | 51CTO技術棧（微信號：blog51cto）

作為 Claude 背后的金主，亞馬遜終于在 AI 編程領域終于出手了！

昨日，他們推出了自家的 Agentic IDE —— Kiro，一款由 Claude Sonnet 4 驅動的開發工具，目標明確：解決 vibe coding 應用難以上線的“最后一公里”問題。

乍看之下，Kiro 有些像 Cursor，但本質上，它走的是另一條路線。

但最大的不同在于：Kiro 默認內置了“規格驅動開發”（spec-driven development）。

它不是簡單幫你寫代碼，而是圍繞需求文檔、設計流程和任務拆解進行自動化組織。換句話說，它希望從一開始就把你的 prompt 引導進一個可以交付、可協作、可維護的開發流程。

因此，這個工具的核心理念，是讓那些“vibe coding”出來的 APP 更容易轉入生產環境——這是目前很多平臺都難以做到的事。

目前 Kiro 已開放公開預覽、免費試用，相關討論也開始在 Reddit 上逐漸升溫。一位開發者試用后直言：

 “氛圍編程的游戲規則，可能又要被改寫了。”

這位體驗者提到，"很多人之前在 Claude Code 里用的那些技巧，都可以絲滑遷移到 Kiro 里。"

更驚艷的是，Kiro自動把軟件工程的最佳實踐應用到 vibe coding 工作流里，讓 APP 開發變得更有結構、更有條理。

舉個例子：他在沒有任何額外 prompt 的情況下，Kiro 自動為他的項目生成了完整的規格說明，包括：

•  需求文檔（Requirements Document） 
•  設計文檔（Design Document） 
•  任務列表（Task List）

他強調：這些并不是我讓它生成的，而是它默認內置的功能。

Kiro想讓你的氛圍編程不止步于“造玩具”，這款AI編程工具能做到嗎？

是否值得你上手試玩？別急，先來我們來一起看看。

Kiro下載地址：https://kiro.dev/downloads/

1、氛圍編程的下一步：從“造玩具”到搭建穩固、可維護的應用

kiro的blog寫得很真實：

“你或許經歷過這樣的場景：不斷 prompt、prompt、prompt，一個能跑的應用就出來了。的確好玩，甚至像魔法。但要真正投入生產，卻遠不止于此。”

這就是所謂的 vibe coding：靈感來了，AI 一頓猛生成，一個 demo 就能跑，然而問題來了：

• 模型生成時做了哪些假設？你根本不知道。 
• 整個過程你引導編程智能體修改代碼無數次，卻沒有任何“過程記錄”或設計文檔可查。 
• 最終功能是否符合初始目標？沒人能確定。 
• 開發者無法快速理解系統設計的方式，以及這些設計會如何影響你的環境和性能。
  

更不用說，后續誰來維護 prompt 邏輯，測試覆蓋了沒有，代碼是否符合團隊規范？

Kiro想讓你通過氛圍編程，從做原型變成真正可交付的系統，這件事該如何解決？

2、Kiro：創新的“規格”+“鉤子”機制

Kiro 開發流程中引入了兩種核心機制——Specs（規格）和 Hooks（鉤子），用來配合 AI Agent更好地“打工”。

Specs（規格） 是在你深入思考某個功能、提前規劃重構、理解系統行為時非常有價值的中間產物。本質上，它是一組由 Kiro 自動生成的結構化文檔，包括偽代碼、流程說明、用戶故事等。

在傳統開發中，團隊會在項目初期手動編寫以下內容：

•  功能需求說明（Requirements） 
•  技術設計文檔（Design Docs） 
•  用戶故事與驗收標準（User Stories + Acceptance Criteria）

而現在，Kiro 會自動根據你的 prompt 輸出這類規格文檔，幫助 AI 更準確地理解任務、拆解目標、生成代碼。

Hooks 是一套自動觸發器系統，綁定在文件保存、創建、提交等事件上。

他像是一個經驗豐富的開發者，悄悄幫你完成遺漏的任務或重復性的工作。當你保存、創建、刪除文件，或手動觸發事件時，這些事件驅動的自動化就會在后臺執行。

值得一提的是，Hooks 會在發布前按照開發者的方式檢查代碼，在每次保存或修改文件時自動完成檢查。例如：

•  保存 React 組件時，自動更新測試文件 
•  修改 API 時，自動刷新 README 
•  準備提交時，自動掃描是否有敏感信息泄露

例如：你希望所有新建的 React 組件都遵循“單一職責原則（SRP）”，Kiro 可以根據你的 prompt 創建一個 hook，在每次添加新組件時自動進行驗證，只需一次設置。

3、案例：用Specs 和 Hooks 構建一個網購頁面功能

為了能更好地感受Kiro的改進，不妨來看blog中的一個例子。

以下是一個構建電子商務應用中“用戶評論系統”的三步流程示例：

1. 一個 prompt → 明確的需求

輸入一句話：“為商品添加評論系統”，Kiro 會生成用戶故事，涵蓋查看、創建、篩選和評分評論等功能。

每條用戶故事中都含有 EARS（Easy Approach to Requirements Syntax） 格式的驗收標準，覆蓋了常見邊緣情況。

 → 這樣，prompt 中的假設會被明確表達，確保代理真正構建你想要的內容。

2. 基于需求自動生成技術設計

Kiro 分析你的代碼庫和確認的規格說明，生成完整的設計文檔，包括：

•  數據流圖 
•  TypeScript 接口 
•  數據庫結構 
•  API 端點（如 Review 接口） 

→ 避免因規格不清而導致的反復溝通，大幅提升效率。

3. 任務落地，實現每一步

Kiro 會自動生成任務與子任務，按依賴關系正確排序，并與需求一一對應。每個任務都包括：

•  單元測試 
•  集成測試 
•  加載狀態 
•  移動端響應式支持 
•  無障礙要求 

→ 你可以逐步檢查工作進展，而不是最后才發現哪里沒做。

任務面板中，支持逐個觸發任務并查看執行狀態，還能查看代碼差異和代理的執行記錄。

Kiro 還能讓規格和代碼庫保持同步。你寫代碼時可以要求 Kiro 自動更新規格，也可手動編輯 specs 來刷新任務——解決了開發中“文檔沒更新”的常見問題。

4、趨勢：AI 編程的“疆域”，還遠沒卷到底

AI 編程工具早已不滿足于當一個“代碼生成器”了。

AI編程工具正在不斷擴展自己的能力邊界，從代碼助手邁向“開發流程指導者”，甚至“準項目經理”。

歸根到底，即便 Claude Code 的交互能力再強，它依然難以從頭到尾執行一份完整的開發計劃。哪怕你寫了再精簡的 claude.md 文件、設定了再完整的 specs，一旦進入執行階段，跑偏的事情時有發生。

正如評論區一位網友說的那樣，成千上萬個基于 Claude Code 的 GUI 和 IDE 正在推出，他還提到了一個同樣走規格驅動路線的競品應用“ BearClaude”。

地址：https://bearclaude.specstory.com/

這個評論也炸出了BearClaude的開發者，他提到：

團隊正在為 BearClaude 開發一個更具“主觀性”的 Planner 模式。它會為頭腦風暴、梳理用戶關注點、做需求分析、應用準備度（例如“完成定義”）、界定核心功能、云服務和關鍵包設定提供引導。

這個beta版本可能在近期上線。

看來，值得AI編程去卷的地方還有很多。誰能在混亂的 prompt 生成背后，補齊規劃、協作、測試、上線這些工程環節，誰就有可能主導下一階段的開發范式。

5、寫在最后

Kiro 提出的愿景并不小：解決構建軟件時最根本的難題。

比如——

• 不同團隊如何對齊設計
• 沖突需求如何協調
• 如何減少技術債
• 代碼審查如何更嚴謹
• 如何保留團隊核心知識，防止經驗流失
  

這些問題，Kiro 希望通過智能體編程工具，一步步給出新的答案。

它能做到嗎？它的“規格驅動”路線，會成為 AI 編程的主流范式，還是又一個曇花一現的嘗試？

看完介紹，你會考慮用用看 Kiro 嗎？