Amazon Kiro 首席工程師 Al Harris 深入介紹了 Spec-Driven Development（規格驅動開發）的核心理念與實踐方法。他展示了如何透過結構化的需求定義、設計文件和 Property-Based Testing，將傳統軟體工程的嚴謹性與 AI Agent 的生產力結合，解決 Vibe Coding 在規模化和程式碼品質上的不足，讓 AI 輔助開發能夠達到企業級的可靠性和可重現性。

原影片連結：https://www.youtube.com/watch?v=HY_JyxAZsiE

影片重點

• Amazon Kiro 是一款 Agentic IDE，已於近期正式 GA（General Availability）
• Spec-Driven Development 將軟體開發生命週期（SDLC）壓縮為需求→設計→任務→執行的緊密迭代循環
• 使用 EARS（Easy Approach to Requirement Syntax）格式定義結構化自然語言需求
• Property-Based Testing（屬性測試）可直接從 EARS 需求轉譯為系統屬性驗證
• Spec 不僅是文件，更是系統在某個時間點的狀態表示和結構化工作流程
• MCP（Model Context Protocol）整合可在 Spec 的任何階段使用，擴展 Agent 能力
• Steering（引導文件）和自訂 Artifact 讓開發者能精細控制 Agent 行為
• Spec 作為活文件（Living Document），支援跨時間的需求變更追蹤

詳細內容

[00:00] Kiro 簡介與 Spec-Driven Development 的起源

Al Harris 以 AWS 首席工程師的身份介紹了 Kiro——一款 Agentic IDE。Kiro 從一個三四人的小團隊起步，目標是改善軟體開發生命週期的體驗。團隊聚焦三大核心挑戰：擴展 AI 開發到更複雜的問題、提升對 AI Agent 的控制力、以及提高輸出程式碼的可靠性。

他們的解決方案就是 Spec-Driven Development。Al 指出，Vibe Coding 雖然好用，但過度依賴操作者本身的能力——你需要自己設定好 Guardrails、讓 Agent 遵循嚴格的工作流程。Spec-Driven Development 則希望尊重軟體工程 25-30 年的經驗，將瀑布式、XP 等方法論的精華融入 AI 開發流程中。

[03:30] Spec 的核心概念：SDLC 的壓縮迭代

Al 解釋了 Spec-Driven Development 的核心思想：將軟體開發的發現與實作壓縮為一個緊密的內部循環。他認為軟體開發有一半是需求探索（Discovery），而最好的方式是快速產出結果並回饋到需求中。

這個流程包含：需求定義（含驗收標準）→ 設計文件（可與團隊和利害關係人審查）→ 任務清單 → 程式碼實作。所有這些都在一個緊密的迭代循環中完成，讓你能及早發現副作用並回饋修正。

[05:30] EARS 格式與 Property-Based Testing

Kiro 使用 EARS（Easy Approach to Requirement Syntax）格式來表達需求。這是一種結構化的自然語言格式，使用 “When… Then… Shall…” 的語法，讓需求既人類可讀又機器可解析。

在 GA 版本中，Kiro 新增了 Property-Based Testing（屬性測試）功能。EARS 需求可以直接轉譯為系統屬性（Properties），也就是你想要交付的不變量（Invariants）。系統會嘗試找出任何能推翻這些不變量的反例——如果找不到，就能以高置信度確認系統符合需求。Al 提到這類似 Python 的 Hypothesis 庫或 Node 的 fast-check。

[08:00] Spec 的三重意義

Al 將 Spec 定義為三個層面：

1. 系統狀態的表示：一組 Artifact，代表系統在某個時間點 t 的狀態，包含功能需求和非功能需求
2. 結構化工作流程：引導你經歷需求定義、設計和執行三個階段，可靠地交付高品質軟體
3. 工具和系統：在上述基礎上提供可重現結果的工具，例如 Property-Based Testing 和需求驗證（掃描需求中的歧義和衝突約束）

[10:30] 用 MCP 擴展 Spec 生成能力（200 Grit 磨砂）

Al 使用磨刀石磨砂粒度（Grit）的比喻來描述工具鏈的精進層次。200 Grit 是基礎層——使用 MCP Server 來擴展 Agent 在 Spec 各階段的能力。

他示範了如何用 Asana MCP 從任務管理工具中拉取需求，直接在 Kiro 中生成 Spec。只要給 Kiro 一個 Asana 任務 URL，它就能自動拉取所有 Metadata 並生成對應的需求文件。MCP 也可以在設計階段使用，例如用 Fetch MCP 從網路上搜尋類似產品作為參考。

[15:00] 自訂 Artifact 提升精細度（400 Grit 磨砂）

進入 400 Grit 階段，Al 展示了如何自訂 Spec 產出的 Artifact。因為所有 Artifact 都是自然語言，你可以要求加入任何你想要的內容：

• UI Wireframe：在設計文件中加入 ASCII 線框圖，在實作前就確認 UI 方向
• 測試案例：在任務中加入明確的 Unit Test 案例，確保 Agent 完成任務時不只是「宣稱完成」而是真正通過所有測試

Al 強調了一個常見痛點：LLM 非常擅長宣稱自己完成了工作（”I’m done, I’m happy”），但實際上測試可能根本沒通過。通過在任務中明確定義測試案例，配合 Agent Hooks，可以有效解決這個問題。

[19:00] 迭代流程與挑戰偏見（800 Grit 磨砂）

最精細的層次是 800 Grit——不僅調整 Artifact，還要質疑和迭代整個開發流程本身。Al 用一個實際範例說明：他要求 Kiro 把對話記錄存到 S3，但這個提示本身就引入了一個偏見——為什麼一定是 S3？

他建議在設計完成後，主動詢問 Agent：「這是實現 Session Persistence 的慣用方式嗎？」讓 Agent 利用 MCP 工具去搜尋文件、查閱資料，提出替代方案。在這個案例中，Agent 發現了 AgentCore Memory 這個更慣用的選項。

核心建議：不要被自己提示中的假設鎖死，主動挑戰 Agent 的設計決策。

[22:00] 現場 Demo：Gramps 專案

Al 現場示範了一個名為 “Gramps” 的專案——一個部署在 Amazon Bedrock AgentCore 上的爸爸笑話產生器。他展示了完整的 Spec-Driven Development 流程：

1. 設定好 CDK Stack 和基礎專案結構（Vibe Coding 階段）
2. 添加 AWS Documentation MCP 和 Fetch MCP 作為知識來源
3. 提出需求：為 Agent 加入 Session Memory，避免重複產生相同笑話
4. Kiro 自動生成需求、設計文件、Properties 和任務清單
5. 執行所有任務，產出包含 S3 Checkpoint Saver 的完整實作

他特別展示了 Steering 文件的作用——記錄了 CDK 部署的特殊參數和注意事項，避免重複踩坑。

[30:00] Q&A：與其他工具的差異

觀眾提問了 Kiro 的 Spec-Driven Dev 與其他工具（如 Cursor 的 Planning Mode）的差異。Al 回應了幾個關鍵區別：

• Kiro 的 Spec 不僅是 LLM 驅動，背後有結構化系統和非 LLM 的推理工具（Neurosymbolic Reasoning）
• Spec 是持久化的活文件，而非一次性的執行計劃
• 支援雙向同步：後續修改會更新已有的 Spec，而非產生新的
• Spec 也成為了團隊的設計審查工具——Kiro 團隊內部已用 Spec Review 取代傳統的 Design Doc Review

[35:00] Q&A：大型既有程式碼庫的處理

關於 Brownfield（既有程式碼庫）場景，Al 坦承效果取決於程式碼的結構品質。如果系統有良好的關注點分離（Separation of Concerns）、模組高度內聚（Cohesive），Agent 表現會很好。反之，技術債越重、模組耦合越緊，Agent 越難有效工作。

Kiro 採用「漸進式揭露」（Incremental Disclosure）策略——不在對話開頭載入大量上下文，而是讓 Agent 自主發現所需的上下文。他們的基準測試顯示，Agent 在提供較少上下文但給予發現工具時表現更好。

[40:00] Q&A：Spec 的組織與演化

關於 Spec 的組織方式，Al 說明每個 Spec 代表一個功能或問題領域。以 Kiro 自身的開發為例，他們有 Prompt Registry、Chat UI Telemetry、Message History Sanitizer 等不同的 Spec。

當新需求涉及已有的 Spec 時（例如為 Chat UI 新增 Telemetry），Agent 會先搜尋是否存在相關 Spec，然後修改現有文件而非創建新的。跨功能需求（如 PII Redaction 涉及 API、Security 和 Logging）則需要開發者決定是修改其中一個 Spec 還是創建跨功能 Spec。

[45:00] Q&A：效能、語言支援與 AWS 整合

最後的 Q&A 涵蓋了幾個實用主題：

• Prompt Caching：Kiro 可達到 90-95% 的 Cache Token 使用率，大幅降低延遲
• 語言支援：官方支援 JavaScript、TypeScript、Java、Python 和 Rust，但理論上可用於任何語言
• AWS 整合：Kiro 刻意不與 AWS 深度綁定，CLI 提供了 use_aws 工具但可替換為任何雲端平台的 MCP
• Steering 的重要性：Agent 預設會「太客氣」試圖滿足所有人，透過 Steering 明確告知優先級（如延遲、成本、程式碼風格）才能得到符合需求的程式碼

我的想法

這場演講讓我對 Spec-Driven Development 有了更具體的認識。Al Harris 的「磨砂粒度」比喻非常精妙——從基礎的 MCP 整合（200 Grit），到自訂 Artifact（400 Grit），再到挑戰流程本身（800 Grit），形成了一個清晰的工具鏈精進路徑。

最讓我印象深刻的是「挑戰你自己的偏見」這個觀點。我們在寫 Prompt 時往往會不自覺地嵌入技術選型偏見（例如直接說「存到 S3」），而好的做法是先描述問題（「我需要 Session Persistence」），讓 Agent 透過工具去探索最佳方案。這和好的工程實踐中「先問 Why 再問 How」的原則完全一致。

Property-Based Testing 的整合也是一個亮點。在 AI 輔助開發中，「Agent 宣稱完成但實際有問題」是個普遍痛點。透過 EARS 需求直接轉譯為屬性測試，建立了從需求到驗證的完整鏈條，這比單純依賴 Agent 的自我評估要可靠得多。

不過我也注意到，Spec-Driven Development 有一個明顯的前期投資成本。Al 自己也承認這點——如果只是 10 秒的 Prompt 做錯了沒什麼損失，但花了一小時做的設計文件就真的希望能做對。這意味著 Spec-Driven Development 更適合中大型功能開發，而非快速原型或小修小補。開發者需要根據任務的複雜度和重要性，在 Vibe Coding 和 Spec-Driven Development 之間做出權衡。