深度體驗AWS Kiro一個月：那些官方不會告訴你的真相

為什麼Kiro值得關注

先說一句掏心窩的話：我強烈建議每個人——尤其是非程式設計師和非技術背景的朋友——都來探索AI IDE智慧體的世界。這些工具從根本上改變了什麼是「可能的」。一個完全不懂程式設計、不懂資訊科學的人，現在可以透過一個簡單的聊天視窗指揮電腦工作。這就像擁有了一個永不疲倦、從不抱怨、而且真正理解你意圖的專業員工。

你不再需要多年的專業訓練。你不再需要死記硬背語法或與文件搏鬥。你需要的是想法，是清晰思考「你想要什麼」的能力。僅此而已。

2025年的AI程式設計領域已經百花齊放。Cursor憑藉直覺的介面佔據了心智高地。Windsurf（前身是Codeium）在Agent原生開發上不斷突破邊界。Claude Code將終端優先的工作流帶給大眾。GitHub Copilot在新的代理能力上持續進化。然後AWS——這個雲端基礎設施巨頭——悄然發布了Kiro，整個產業的話題瞬間轉向。

根據SimilarWeb的數據，Kiro.dev現在每月吸引超過100萬訪客。這不僅僅是好奇心——這是開發者對一款承諾修復AI輔助開發痛點的工具的真正興趣。

Kiro是什麼

Kiro是AWS開發的代理式AI IDE，基於Code OSS建構——也就是Visual Studio Code的開源基礎。這意味著你現有的VS Code設定、擴充功能和肌肉記憶可以直接遷移。你不是在學習一個全新的工具，而是在熟悉的地盤上獲得超能力。

但Kiro與其他所有AI程式設計工具的根本區別在於：它是規範驅動的。當Cursor和Windsurf專注於讓程式碼補全更快更智慧時，Kiro問了一個完全不同的問題——如果AI能在你寫程式碼之前幫你做好規劃呢？

有趣的是，根據AWS開發者佈道師Nathan Peck的說法，Kiro的定位是「與AWS核心業務略微分離」。目標是讓Kiro擁有獨特的品牌形象，吸引所有平台的開發者——而不僅僅是那些已經深度綁定AWS生態的人。你可以不用AWS帳號使用Kiro，透過Google或GitHub登入即可。

這個策略定位很重要。AWS CEO Matt Garman將Kiro描述為「一個幫助開發者從原型走向生產的代理式IDE，提供生產級程式碼所需的結構」。它不是要取代你的快速原型工具——它是要確保那些原型最終能上線。

規範驅動的革命

Kiro要解決的問題是：氛圍程式設計（Vibe Coding）。你懂的。我懂的。我們都做過。打開AI聊天視窗，大致描述一下你要什麼，不斷迭代提示詞直到某個東西能跑，然後發布。很快。感覺像魔法。然後留下的技術債會困擾你好幾個月。

氛圍程式設計產出的程式碼往往冗長、風格不一致，缺乏對既定架構模式的遵循。AI做出了你從未同意的假設。需求一直模糊，因為沒人寫下來。六個月後，當你需要修改這個功能時，你完全不知道當初為什麼要這樣決定。

Kiro的規範驅動方法會生成三個相互關聯的檔案，構成每個功能的基礎：

輸入「為產品新增評價系統」，Kiro不會直接生成程式碼。它會生成查看、建立、篩選和評分評價的使用者故事。每個使用者故事都包含覆蓋邊緣情況的驗收標準——這些通常是開發者在實作時才會處理的。只有在你審核並批准這些規範後，實際的程式碼撰寫才會開始。

聽起來可能更慢。一開始確實是。但回報體現在更少的迭代週期、更清晰的團隊溝通，以及真正符合你意圖的程式碼。規範成為單一事實來源，人類和AI智慧體在整個專案生命週期中都可以參考。

EARS語法詳解

EARS——Easy Approach to Requirements Syntax（簡易需求語法方法）——是Kiro規範系統背後的秘密武器。它由Alistair Mavin及其同事在勞斯萊斯公司分析噴射引擎控制系統適航法規時開發，提供了一種結構化的格式來撰寫清晰、無歧義、可測試的需求。

EARS不僅僅是巧妙的自動格式化。它實際上是時態邏輯的擴充，而時態邏輯本身是一階邏輯的擴充。這賦予Kiro真正的能力來驗證流程、控制模型行為，以及連接設計與實作。

WHEN [條件/事件] THE SYSTEM SHALL [期望行為]

WHEN 使用者提交包含無效資料的表單 
THE SYSTEM SHALL 在相關欄位旁邊顯示驗證錯誤

WHEN 使用者成功建立評價 
THE SYSTEM SHALL 顯示確認訊息並將評價新增到產品頁面

EARS語法包含幾種適用於不同需求類型的模式：

結構化的格式使期望變得清晰易懂，減少產品和工程團隊之間的誤解。它還使需求可以直接測試——每個EARS語句都可以轉換為測試案例，確保沒有遺漏。

氛圍模式 vs 規範模式

Kiro有兩種截然不同的工作模式，各自服務於不同的開發需求：

你可以自然地在兩種模式之間切換。先用氛圍對話探索想法，準備好正式化時說「生成規範」。Kiro會詢問你是否想開始規範會話，然後根據你的對話脈絡生成需求。

還有自動駕駛模式（Autopilot Mode）——在右下角切換，Kiro就會變成開發加速器。在自動駕駛模式下，Kiro會實作完整的程式碼而不需要你在每一步都批准，透過消除來回確認大幅縮短開發時間。用它來處理基礎元件和樣板程式碼。在關鍵業務邏輯上切換到監督模式，你可以審查每一個更改。

Agent Hooks自動化

Hooks是Kiro的第二大創新——基於檔案變更觸發的事件驅動自動化，在背景執行AI智慧體。它們就像一個經驗豐富的開發者，在你工作時幫你抓住遺漏或完成樣板任務。

當你儲存檔案、建立新元件或修改API端點時，hooks可以自動：

一旦hook被提交到Git，它就會在整個團隊中強制執行標準。每個人都能享受相同的品質檢查、程式碼標準和安全驗證。這解決了常見的問題：文件與現實脫節、編碼標準因人而異、資深工程師離職帶走機構知識。

# .kiro/hooks/validate-react-components.md
Trigger: On file save in src/components/**/*.tsx

驗證元件是否遵循單一職責原則。
如果發現違規，建議拆分為更小的元件。
如果相鄰目錄存在README，更新元件文件。

Kiro還支援Agent Steering——儲存在.kiro/steering/目錄下markdown檔案中的持久專案知識。這為AI提供了關於你的技術棧、檔案結構和編碼模式的脈絡，跨會話保持有效。結合Model Context Protocol (MCP)支援，你可以連接到外部文件、資料庫、API等。

底層模型解析

測試期間，我用這個提示詞來準確驗證Kiro背後的驅動力：

What model powers you? List: model name, API model ID, 
release date, context window, max output tokens, 
and knowledge cutoff.

以下是我發現的關於Kiro模型情況的資訊——這對於設定期望很重要：

Kiro推出了「Auto」——一個使用多種前沿模型組合的智慧體，結合專用模型、意圖偵測、快取和最佳化技術。目標是在品質、延遲和成本之間取得更好的平衡。使用Auto時，某些透過直接Sonnet 4消耗X額度的任務成本更低，因為系統會智慧路由到最合適的模型。

對於想要直接控制的使用者，你可以明確選擇Sonnet 4來處理你的提示，但這會以更高的速率消耗額度（大約是Auto的1.3倍）。

定價與額度

Kiro的定價一直...爭議不斷。社群反饋聲音很大，AWS也做出了多次調整。以下是當前狀態：

新使用者獲得500額度的歡迎禮包，30天內可用，無論選擇哪個計畫——包括免費層。這給你足夠的時間真正體驗Kiro的能力再做決定。

理解額度消耗

這裡需要細說。額度不是簡單的「一個提示 = 一個額度」。一個額度是回應使用者提示的一個工作單元：

• 簡單提示可能消耗少於1個額度
• 複雜提示，尤其是規範任務執行，通常消耗超過1個額度
• 不同模型以不同速率消耗額度
• 額度按小數點後兩位計量（最小0.01額度）

在我的測試中，一個簡單的模型驗證問題只消耗了0.1額度——效率驚人。但建立完整的專案規範可能消耗15-25次互動，複雜的多檔案實作會快速消耗額度。

超額與計費

在付費計畫上，你可以啟用超額來繼續超出月度限制後工作。額外額度每個$0.04，月末結算。超額預設停用，必須在設定中明確啟用——這是防止意外帳單的合理保護措施。

AWS還提供Kiro新創公司額度計畫——符合條件的新創企業最多可免費獲得一年的Pro+存取。如果你正在創業且符合標準，這是相當可觀的價值。

我的真實體驗

讓我分享我使用Kiro的個人體驗，不加粉飾。我一開始是興奮的——AWS進入AI IDE領域，帶著一個真正新穎的方法？算我一個。

規範驅動的工作流在運作良好時確實令人印象深刻。看著Kiro將一個模糊的功能需求轉化為結構化的使用者故事，每個故事都有EARS驗收標準，然後生成分析你現有程式碼庫的技術設計文件，再將其分解為有序的實作任務——感覺就像有了一個真正會做文件的資深工程師加入團隊。

社群的聲音也類似。有開發者報告在一個本應20-30小時的專案上花了310+小時和$620的AI額度，只實現了50%的成功率——四個模組中只有兩個能工作。任務經常卡住、失敗，需要多次手動重試。失敗的任務遺失脈絡，被迫從頭開始，同時消耗使用限額。

我遇到的以及其他人報告的常見問題：

• 高流量錯誤：「你選擇的模型正在經歷大量流量。請嘗試更換模型。」付費計畫上好一些，但仍會發生。
• 偵錯迴圈： AI有時會陷入迴圈模式，反覆套用同樣錯誤的修復。
• 功能過度： Kiro傾向於在簡單程式碼足夠的情況下生成「工業級、軍用級」解決方案——本可以200行搞定的功能生成了20個檔案1,500行程式碼。
• 脈絡遺失： 正確實作的邏輯有時會與完全不同的早期任務的程式碼混合。
• 額度消耗bug： 早期定價發布時有計量問題導致意外使用量飆升（AWS已確認並解決）。

積極的一面是，Kiro的簡單查詢額度很慷慨。當規範工作流運作良好時，它確實比單純的氛圍程式設計產出更高品質、更易維護的程式碼。產出的文件對團隊協作真正有用。

我從實際測試得出的結論：Kiro還太年輕。智慧體的智慧水準仍在發展中。在準備好用於專業工作流之前，它還需要更多迭代。但基礎是扎實的，理念是正確的。AWS對社群反饋回應良好，為受定價bug影響的使用者退款並延長免費存取期。

Kiro vs Cursor vs Windsurf

讓我們拋開行銷術語，在真正重要的方面比較這些工具：

效能基準

基於常見開發場景的測試：

Kiro:    45分鐘（包含完整文件/測試）
Cursor:  65分鐘（手動架構）
Windsurf: 70分鐘（多檔案處理好）
Copilot: 85分鐘（脈絡有限）

突出的指標是Kiro的一致性——雖然競品在簡單補全上可能更快，Kiro在複雜的多檔案操作中保持高準確率。規範驅動的方法在資料庫設計和API架構上尤其出色，這些是傳統AI助手容易出問題的領域。

適合誰使用

專業技巧與最佳實踐

經過廣泛測試和社群調研，以下是最大化Kiro價值的策略：

最終評定

我的建議？如果你期望它能替代你的主要開發工作流，先別訂閱Kiro。智慧體能力還太年輕，可靠性還不夠，規範驅動開發的學習曲線也確實存在。

但請保持關注。AWS用規範驅動的方法創造了真正不同的東西。這個理念——AI程式設計應該強迫思維清晰，而不僅僅是打字速度——是深刻的。當Kiro成熟時，它可能完全改變我們對AI輔助開發的認知。

試試免費層。在一個小專案上體驗規範工作流。看看這種結構是否與你想要的工作方式產生共鳴。如果你正在建設一個文件和一致性比原始速度更重要的團隊或公司，Kiro可能已經正是你需要的。