Kiro AI: AWS 旗下 代理式整合開發環境 (Agentic IDE)

Published:
  Lastmod: 2025-07-16
Agentic
by Ernest Chiang

(圖說：代理式整合開發環境 (Agentic IDE) 正在重新定義軟體開發的未來。拍攝於 Lac de Neuchatel 湖畔，瑞士。圖片來源：Ernest。)

tl;dr 重點摘要

  • Kiro 1 是一個代理式整合開發環境 (Agentic IDE)，代表從傳統「指令式程式開發 (Imperative Development)」到「意圖導向程式開發 (Intent-Driven Development)」的典範轉移。
  • 透過 Specs 結構化規格、Steering 專案指導、Autopilot 自主執行、Hooks 自動化觸發、串接流程等功能，Kiro 建構了一個完整的人機協作開發環境。
  • 本文嘗試拆解 Kiro 的四層架構（意圖層、知識層、執行層、監督層），探討這對技術組織的戰略影響，嘗試探索未來的人機協作開發模式、與軟體開發流程。
  • 今年五月我在 AWS Summit Hong Kong 2025 分享「重塑程式設計: AI 如何轉變企業的程式開發方式」，從 SDLC 開始拆解，大家有興趣也可以搭配投影片一起閱讀。

1. 從「指令式程式開發」到「意圖導向程式開發」的典範轉移

長久以來，軟體開發的核心是「指令式程式開發」(Imperative Development) 的 — 開發者需要精確地告訴電腦每一步「如何做」(How)。開發者們透過撰寫一行行的程式碼，來指揮機器的運作。然而，隨著軟體系統的複雜度指數級增長，這種模式正在挑戰效率的天花板。

一個新的思維正在興起：意圖導向程式開發 (Intent-Driven Development)。其核心思想是，開發者專注在清晰地表達「為什麼而做」(Why)，以及期待「做到什麼」(What)，而將「如何做」(How) 的繁瑣交給更智慧的系統。這不僅僅是自動化，更是一種更高層次的抽象思維。

Kiro 這類「代理式整合開發環境」(Agentic IDE) 正是此思維的具體實踐者。Kiro 不僅僅是一個程式碼生成工具，而是一個嘗試理解開發者意圖、自主規劃並執行任務的智慧代理角色 (Agent)。讓我們一起來試著拆解 Kiro 的系統設計思路，來探討看看能為我們組織帶來哪些更深層的戰略價值。

我總是會先比較正面地看待新產品與新服務，套用到各種已知的情境，探索各種層面的可能價值。大家也可以試試看用自己的方式拆解看看，我們大家的拆解結果不一定需要相同，這樣討論起來才有樂趣。

2. Kiro 的系統架構 (System Architecture)

對於 Kiro 的能力，我們也許可以將其抽象為四個相互協作的邏輯層：

  • 意圖層、
  • 知識層、
  • 執行層、
  • 監督層。

這四層共同構成了一個完整的人機協作迴圈。

graph TD
    A["Kiro Agentic IDE"]
    
    subgraph Intent["🎯 意圖層 Intent Layer"]
        B["Spec 結構化意圖"]
        C["Vibe 非結構化意圖"]
        D["Terminal 自然語言指令"]
        
        B --> E["requirements.md + EARS"]
        B --> F["design.md + 架構圖"]
        B --> G["tasks.md + 任務列表"]
    end
    
    subgraph Knowledge["🧠 知識層 Knowledge Layer"]
        H["Codebase Indexing 短期記憶"]
        I["Steering 長期記憶"]
        
        H --> J["Project Context"]
        I --> K[".kiro/steering/"]
        K --> L["product.md tech.md structure.md"]
    end
    
    subgraph Execution["⚡ 執行層 Execution Layer"]
        M["Autopilot 自主執行"]
        N["Hooks 事件驅動"]
        
        M --> O["Autopilot Mode"]
        M --> P["Supervised Mode"]
        N --> Q["File Events → Auto Actions"]
    end
    
    subgraph Oversight["👁️ 監督層 Oversight Layer"]
        R["階段性審批"]
        S["指令執行確認"]
        T["程式碼變更審查"]
        U["Human-in-the-Loop"]
    end
    
    subgraph External["🔌 外部整合"]
        V["MCP Protocol"]
        W["External Tools"]
    end
    
    %% Main connections between layers
    A --> Intent
    Intent --> Knowledge
    Knowledge --> Execution
    Execution --> Oversight
    External --> A
    
    %% Cross-layer connections
    G -.-> M
    Knowledge -.-> Execution
    Oversight -.-> Intent
    
    %% Styling
    classDef intentStyle fill:#FFE6E6,stroke:#FF6B6B,stroke-width:2px,color:#000
    classDef knowledgeStyle fill:#E6F3FF,stroke:#4DABF7,stroke-width:2px,color:#000
    classDef executionStyle fill:#E6FFE6,stroke:#51CF66,stroke-width:2px,color:#000
    classDef oversightStyle fill:#FFFFE6,stroke:#FFD43B,stroke-width:2px,color:#000
    classDef externalStyle fill:#F3E6FF,stroke:#9775FA,stroke-width:2px,color:#000
    classDef mainStyle fill:#F8F9FA,stroke:#343A40,stroke-width:3px,color:#000
    
    class A mainStyle
    class B,C,D,E,F,G intentStyle
    class H,I,J,K,L knowledgeStyle
    class M,N,O,P,Q executionStyle
    class R,S,T,U oversightStyle
    class V,W externalStyle

2.1. 意圖層 (Intent Layer)：使用者輸入的解析

意圖層負責擷取並理解開發者的原始意圖。Kiro 提供了多種管道來處理不同形式的意圖輸入。

之前使用 Amazon Q CLI、Claude Code、Cursor、Cline 的時候，遭遇較為零散和臨時的意圖，或是同時交辦兩個以上維度的任務目標時，LLM 常常會深陷到細節而無法自拔（忘了原始目標、或是忘了整體任務）。Kiro 嘗試在結構化意圖與非結構化意圖之間進行人機協作，是個挑戰。

Spec (結構化意圖)

這是 Kiro 最核心的意圖捕獲機制。它將一個模糊的開發需求，透過一個結構化的流程轉化為 AI 可理解的計畫。該流程包含三個核心文件：

  • requirements.md:
    • 使用 EARS (Easy Approach to Requirements Syntax) 234 語法，清晰定義使用者故事與驗收標準。
    • 格式為「WHEN [條件] THE SYSTEM SHALL [預期行為]」。
  • design.md:
    • AI 基於需求與現有知識，生成包含序列圖等的技術設計方案內容。
  • tasks.md:
    • 將技術設計方案拆解成為一系列具體、可執行的程式開發任務。

這個機制，嘗試降低從產品需求到工程執行的意圖傳遞損耗。

Vibe 與 Terminal (非結構化意圖)

  • Vibe
    • 是 Chat 的其中一種模式，
    • 提供了一個對話式介面，用於快速問答、探索性學習和除錯，處理較為零散和即時的意圖。
  • Terminal 則能將自然語言指令（如「安裝專案依賴」）轉換為精確的 Shell 命令，降低開發者的記憶負擔。

2.2. 知識層 (Knowledge Layer)：提供決策的上下文

如果說意圖層是「問題」與「方向」，知識層就是 AI 在回答問題時所依賴的「知識庫」。一個 Agent 的智慧程度，某種程度上取決於其知識的廣度與深度。 （招募團隊成員時也是如此（吧？！））

Codebase Indexing (短期記憶 - 專案內部知識)

Kiro 會自動在背景為整個專案的程式碼建立索引，也可以使用 Command Palette 請 Kiro Re-index。類似 Claude Code 的 /init 指令，但在 Kiro 身為 agent 是自動（主動）幫忙處理。

這使得 AI (LLM + software) 能夠理解專案內部的函式呼叫、類別結構和程式開發模式，提供具有高度上下文感知 (Context-Aware) 的建議。

索引場景包括：

  • 專案匯入：首次開啟工作空間時自動索引所有檔案。
  • 檔案變更：索引新增或修改的檔案。
  • 外部變更：重新索引在 Kiro 外部修改的檔案。

Steering (長期記憶 - 專案指導原則)

這是一個極具戰略價值的功能，大推！

  • 之前與其他開發團隊及朋友們分享如何導入 Amazon Q CLI、Claude Code、Cursor、Cline 等 AI 軟體開發工具時，大部分夥伴都能掌握到比較直觀的工法，例如需要撰寫 README.md、SPEC.md 之類的規格需求描述檔案，但經常忽略了指導原則、限制條件、工作流程等隱性工法。
  • 外商經常有 steering team 或 steering committee 的策略性編制，協助跨部門或跨專案之間設立指導原則、同步策略方向、決策、調度資源等等，有利於讓各種專案更順利順利運作與前進。
  • Kiro 在用於軟體開發的 IDE 中引入 Steering 概念，與我們團隊鼓勵工程師多接觸產品管理 (Dept of Product & Technology Integration) 的概念相似。
  • 我聞到一種味道，也許未來這個 IDE 還可以開發眼鏡、機器人、無人機等具有物理特性的產品。期待。

適當地描述限制條件，將有助於讓 AI 軟體開發工具更能夠聚焦。

題外話：

  • 如果你好奇有哪些指導原則，推薦參考 AWS Well-Architected 這個知識框架。
  • 其實 AWS Well-Architected 不是只在描述如何在 AWS Cloud 進行規劃與建構，更多的是給予我們對軟體開發與商業需求之間各種維度的連結與考量。
  • 鼓勵大家嘗試組織跨部門團隊 (e.g. business operation, product operation, software architect, engineering, testing, infra operation, etc.)，在組織內一起閱讀這個框架文件，然後將適合貴組織的產出物整合到 Steering 檔案中。

開發團隊可以將專案的架構規範、設計模式、首選函式庫、命名慣例等「團隊知識」寫入 .kiro/steering/ 目錄下的 Markdown 檔案中。

預設的 Steering 檔案包括：

  • product.md:
    • 定義產品目的和目標
  • tech.md:
    • 記錄技術架構 (stack) 和限制
  • structure.md:
    • 概述檔案組織和架構決策

AI 在執行任何任務前，都會優先參考這些「指導原則」，確保其產出符合團隊的長期規範。這可以被視為一種「可執行的架構文件」(Executable Architecture Documentation)。

例如我會將「中文字元和英文字元之間，請加上一個半形空白字元，以方便閱讀」、「有疑慮就問我問題，以釐清我沒有說明清楚的地方」5、「請完整處理每一個細節，不要跳過、不要省略，要完整列出所有想法」、「Amazon Working Backward」、「DDD」 之類的原則，堆積進到這類指導原則檔案中。

2.3. 執行層 (Execution Layer)：將意圖轉化為行動

當 AI 理解了「意圖」並擁有了「知識」，執行層便負責將其轉化為對程式碼的實際動作。

Autopilot (自主任務執行器)

在 Specs 被批准後，Autopilot 模式可以接管 tasks.md 中定義的任務清單。它會自主地修改、建立或刪除檔案，並嘗試完成所有任務。這是 Kiro “Agentic” 特性最極致的表現。

提供兩種模式：

  • Autopilot 模式：
    • 預設使用 Autopilot 模式
    • 適合有經驗的使用者，自主完成複雜任務
  • Supervised 模式：
    • 適合新使用者，可逐步審查變更（咬我啊，我就怕 XDD

Hooks (事件觸發執行器)

Hooks 提供了一種事件驅動的自動化機制。

開發者可以設定在特定事件（如 On-Save, On-Create）發生時，觸發一個由 AI 驅動的動作。例如，在儲存一個 TypeScript 檔案時，自動為其新增或更新測試檔案。

2.4. 監督層 (Oversight Layer)：人機協作的介面

在任何一個高風險的自動化系統中，人類的監督都相當重要。或者更抽象的說：在任何系統中，監督都相當重要。

Kiro 的設計確保了開發者始終處於「駕駛座」(Human-in-the-Loop)。（well… 所以不能將 Kiro 放進 Robotaxi 來執行… 因為… :p

主要控制機制包括：

  • 階段性審批：
    • 在 Specs 流程的每一個階段（需求、設計、任務），都需要開發者手動確認
  • 指令執行確認：
    • 自然語言終端機產生的指令，需要使用者點擊「執行」才會生效
  • 程式碼變更審查：
    • 所有由 Autopilot 或 Hooks 產生的程式碼變更，都會以清晰的 Diff 形式呈現，等待開發者最終的審查與提交

3. 對技術組織的戰略影響

引入 Kiro 這類 Agentic 工具，影響的不只是單一開發者的效率，更是整個技術組織的運作模式。嘗試藉由各種角度提問，以下是一些我自己過往筆記曾問過自己的問題們。

也許大家也有類似的想法，可以一起到 Threads 或 X 討論聊聊。

3.1. 生產力模型重塑

  • ROI 的衡量標準有可能新增衡量 意圖實現所需時間 (Intent-to-Production Cycle Time)？
  • 當 AI 能夠生成大量程式碼時，開發者（或產品經理）的價值是否轉移到了意圖表達的清晰度、Steering 規則的設計品質，以及對系統整體架構的理解深度？傳統的生產力指標往往忽略了一些關鍵的隱性成本：團隊需要多長時間才能熟練掌握 Steering 文件的撰寫技巧？當 AI 可以快速產出程式碼時，資深開發者是否會產生「技能貶值」的焦慮？頻繁的 AI 建議審查是否會造成新的認知負擔？
  • 當 Steering 成為組織工作流程的「智慧核心」時，生產力的衡量可能需要包含規則品質指標、知識複用率、意圖傳達效率等新的面向。在您的組織中，什麼樣的開發者會被認為是「最有生產力」的？是寫程式碼最快的，還是最能夠設計出可重複使用的 Steering 規則的？
  • AI 協作可能帶來短期效率的顯著提升，但長期價值創造需要更仔細的考量。技術決策品質、團隊能力建設、創新空間等都是需要在 Steering 文件中明確定義的權衡考量。

3.2. 團隊結構演變

  • 可能會催生新的角色嗎？
    • e.g. 「Steering 架構師」專注於維護和優化指導 AI 的知識庫，「AI 協調員」負責審核和引導 AI 的工作流程，確保其與團隊目標一致。一個管名詞、一個管動詞？（我就愛英文簡單句 XDD （我就感謝我的英文老師當年幫我寫推甄推薦信 :p
    • 但這些新角色的出現，只是組織轉型的表象。更深層的變化在於：既有團隊成員如何 (隨時或週期性地) 重新定義自己的價值？
    • 舊的（名詞）不去，新的（價值）不來？！
  • 「Steering 架構師」不僅是文件維護者，更是組織智慧的策展人：需要將業務需求、技術約束、團隊文化轉化為 AI 可理解的指導原則，確保 Steering 文件的一致性、完整性和時效性，並定義在不同情境下 AI 應該如何優先考量各種權衡。在您的組織中，誰最適合擔任 Steering 架構師？是資深的技術架構師，還是具備跨領域溝通能力的產品經理？
  • 當 AI 或 Agentic something 成為「虛擬團隊成員」時，傳統的團隊動力學將面臨重新調整。責任歸屬變得模糊化嗎？溝通模式需要轉變嗎？決策流程需要重塑嗎？組織文化轉型會如何發生？可以如何發生？應該如何發生？如何讓團隊人類成員在 AI 協作中仍然感到被重視？也許 Multi-agent 之間，agent 也可能歧視另一隻 agent？如何培養「與 AI 協作」而非卡在焦慮「被 AI 取代」的心態？當個人知識需要「餵養」給 AI 時，是否會影響知識分享的動機？
  • Steering 文件不僅是 AI 的指導原則，更是組織學習的載體。它將隱性的團隊知識轉化為可執行的規則，透過文件保存和傳遞最佳實踐，並通過 AI 執行結果的回饋，持續優化組織的工作模式。您認為 Steering 文件應該多久更新一次？誰來決定什麼時候需要更新？

3.3. 技術債管理

  • 這是一把雙面刃。若放任不管，AI 可能會產生大量難以維護的程式碼，累積技術債。（回頭瞧瞧 vibe coding… 然後望向 vibe maintenance…
  • 若善用 Steering 功能，將重構、TDD 等優良實踐寫入規則，AI 可能可以成為償還和預防技術債的強大盟友？
  • 技術債管理在 AI 協作時代面臨的挑戰遠比表面上看起來複雜 (不要相信眼睛看到的)。
  • 傳統的技術債管理往往是反應式的，但 Steering 提供了前瞻性的解決思路。在 Steering 中明確定義可接受的技術債水準，設定自動重構的條件和優先順序，透過規則防止某些已知的反模式出現。（決戰於第一時間？！
  • 嘗試在 Steering 文件中，練習平衡「快速交付」和「程式碼品質」的優先順序？這個平衡點在不同的專案階段是否需要調整？（唉，一直長出新的變數… 但若沒了變數、少了維度，怎麼換得差異化？
  • AI 協作改變了技術債的成本結構？審查 AI 生成的程式碼需要不同的心理模式（或層次、或工具）？
  • 團隊（或客戶）需要時間建立對 AI 生成程式碼的信任度，AI 生成的程式碼可能有人類難以理解的邏輯結構。
  • 除了程式碼層面的技術債，AI 協作可能引入新的「文化技術債」：團隊（經過一段時間後）是否會失去獨立解決複雜問題的能力？AI 生成的程式碼可能造成團隊對某些技術細節的理解空隙？（或是在還沒有 AI 的時候就是這樣了？）
  • 在 AI 協作的脈絡下，技術債的定義可能需要擴展：可能增加需求表達不清楚造成的「意圖債」、指導原則不一致或不完整造成的「Steering 債」、人機協作模式不佳造成的「協作債」。這些新型態的技術債可能比傳統的程式碼債更難識別和量化，但對組織的長期影響可能更為深遠。又或者，這些原本是隔壁棚的守備範圍？那就又回到是哪一棚失業的問題？樂觀一點，是哪一棚優先轉型的問題？

3.4. 知識管理革命

  • Steering 文件庫本身就是一個「活的」知識庫。它不再是與程式碼脫節的 Wiki 文件，而是直接影響產出的、可執行的規範，極大地降低了知識的流失與斷層風險。但這個改變的意義，不止於文件管理的改善：當組織的知識能夠直接「指導」AI 的行為時，知識管理的戰略意義發生了什麼根本性的改變？組織有這些知識嗎？如何引入？
  • 傳統的知識管理往往停留在「記錄」階段（嗯，做筆記，寫文件），而 Steering 推動知識管理邁向「執行」階段。
  • 資深開發者的「直覺」可以如何轉化為 AI 可理解的規則？團隊的工作流程可以嵌入到 AI 的決策邏輯中嗎？組織的價值觀和原則可以透過 Steering 影響每一行程式碼嗎？（應該還是會有疏漏，但就追求百分比的提升，而不追求 100% 吧。）（我就樂觀）
  • 在您的組織中，哪些「只可意會，不可言傳」的知識最值得轉化為 Steering 規則？這個轉化過程中會遺失哪些重要的語境？
  • Steering 文件可能成為組織知識傳承的新載體嗎？既有文件或既有流程中，有哪些是最接近 Steering 文件的呢？
  • 退場員工（中小企業很多吧？！大企業也不少？！）的經驗可以透過 Steering 規則延續嗎？（或是需要嗎？也許不適任的源頭知識就不要灌進去？）
  • 新員工可以透過觀察 AI 的行為學習組織的工作模式，Steering 讓組織的核心知識不再只掌握在少數人手中，妥妥的新人手冊呀！
  • 當資深員工離職時，他們的知識如何有效地轉化為 Steering 規則？這個過程需要多長時間？誰來負責驗證這些知識的準確性？（或是預埋未爆彈？！）（我離職，你爆炸？！
  • Steering 的導入可能改變組織中的知識權力結構。誰的知識被納入 Steering 規則變得更加透明（會吧？會更透明吧？）
  • 技術影響力可能更多地反映在 Steering 規則的採用度上。在您的組織中，誰有權決定哪些知識應該被納入 Steering 規則？這個決策過程是否透明（和公平）？
  • 最後，Steering 驅動的知識管理革命也帶來了一些隱性挑戰：過度依賴 Steering 規則是否會限制思維的多樣性？成功的 Steering 規則是否會抑制進一步的知識探索？當知識被集體化後，個人的知識責任是否會被稀釋？這些挑戰需要組織在享受 Steering 帶來的知識管理效益的同時，保持對知識管理複雜性的敏感度。（專家就是一群訓練有素的…）

4. Bottomline: Single-Agent 到 Multi-Agent 到 Agentic Age 做好準備

當前 Kiro 主要是一個全能的單一 Agent 搭配多種模式運作。但從 AI 領域的發展趨勢看，下一步極有可能是多 Agent (multi-agent) 的系統協作。我們可以想像，未來可能有專門處理報價單的 “Quote Agent”、專門負責前端的 “UI Agent”、專精資料庫的 “DBA Agent”、以及負責安全掃描的 “Security Agent”。它們在一個總協調的 General Agent 指揮下（一個就好吧？），圍繞一群 Specs 進行協同開發。這將是軟體開發領域的又一次巨大飛躍（吧）。

Agentic IDE 如 Kiro，不僅僅是提升效率的工具，它更像是一個新的一層「作業系統」（或 Sandbox），重塑了開發者與電腦之間的互動關係。

對管理者而言，現在的關鍵任務不是去爭論 AI 是否會取代人類，也不是自我焦慮，而是應該思考：如何設計一個能最大化人機協作成效的組織架構與工作流程？（或者講最大化太過於有壓力，可以只講「提升」。）

理解並開始嘗試導入這些工具，並培養團隊「指揮」AI 的能力、而非被 AI「取代」的能力，將是未來這幾年保持技術競爭力的核心。

參考資料 Reference

FAQ

技術架構

  • Q: Kiro.dev 的 Agentic IDE 架構如何與傳統 IDE 不同？
    • 傳統 IDE 主要提供程式碼編輯、編譯和除錯功能，而 Agentic IDE 6 具備自主決策和行動能力，能夠理解目標並規劃行動來完成複雜任務。
    • Agentic IDE 不僅僅是被動的自動完成，而是能夠在開發環境中進行推理、適應和採取行動的自主代理人。
  • Q: EARS 標記法在軟體需求工程中有什麼優勢？
    • EARS 234 使用少數關鍵字和簡單的底層規則集來溫和約束自然語言需求，使需求遵循時間邏輯並保持子句順序一致。
    • EARS 減少或消除自然語言需求中的常見問題，特別適合英語非母語的需求撰寫者。

工作流程

  • Q: 檔案事件觸發的自動化工作流程如何提升開發效率？
    • Kiro 的 Agent Hooks 可以消除手動請求例行任務的需求，（盡可能？）確保程式碼庫的一致性，透過為常見任務設置 hooks 來維持一致的程式碼品質、防止安全漏洞、減少手動開銷並標準化團隊流程。

遇到問題

官方文件

延伸閱讀

  1. Kiro: The AI IDE for prototype to production ↩︎

  2. Easy Approach to Requirements Syntax (EARS) | IEEE Conference Publication | IEEE Xplore ↩︎ ↩︎

  3. Adopting EARS Notation for Requirements Engineering - Jama Software ↩︎ ↩︎

  4. Alistair Mavin EARS - Alistair Mavin ↩︎ ↩︎

  5. 感謝 BobChao 的分享。推薦他的專業服務。 ↩︎

  6. Agentic IDEs: Next Frontier in Intelligent Coding - The New Stack ↩︎