告別 Vibe Coding：運用 Kiro 實踐規格驅動開發（Spec-Driven Development）

Kiro 簡介

Kiro 與 Visual Studio Code (VS Code) 類似，因為它是以 VS Code 為基礎分支開發而成。Amazon 在此基礎上加入額外功能；由於其代理式程式開發功能仰賴底層的大型語言模型 (LLMs)，因此採用訂閱制服務。

規格模式與規格驅動開發

• 規格模式：Kiro 的獨特功能，稱為規格模式或規格驅動開發（Spec-Driven Development）。
• 傳統 Vibe Coding：多數開發人員習慣使用 Vibe Coding，也就是透過提示詞讓程式開發代理協助撰寫程式碼或除錯。
• 規格驅動開發：這是一種不同的軟體建置方式，從需求、設計、工作規劃開始，最後才進行程式開發。在實際撰寫程式碼之前，會先建立結構化的需求與設計。

代理引導功能

• 代理引導：讓開發人員能指引程式開發助理如何撰寫軟體的功能。
• 產品概覽 Markdown 檔案：開發人員可以提供描述產品的 Markdown 檔案，內容包括產品概覽、工作流程與使用案例。這有助於讓需求和設計與產品概覽保持一致。
• 專案結構定義：開發人員可以在開始撰寫程式碼前，先於 Markdown 檔案中定義專案結構，包括企業標準，或專案檔案與測試檔案的特定組織方式。
• 命名慣例：開發人員可以在 Markdown 檔案中指定命名慣例，確保建立的檔案遵循正確規範。

定義技術堆疊

• 技術堆疊定義：代理引導的第三個範例，是定義專案的技術堆疊。
• 前端：指定 React 等框架。
• 後端：指定後端使用的框架或技術。
• 相依套件：在 Markdown 檔案中定義專案相依套件。

程式開發慣例

• 程式開發慣例：預先定義組織的程式開發慣例，確保程式開發助理遵循這些規範。

支援 agents readme

• 支援 Agents readme：Kiro 最新版本開始支援 agents.readme，這是代理 Markdown 檔案的開放標準。
• 互通性：在 Kiro 中定義 agent readme 檔案，並於 Cursor 等其他程式開發助理中使用，確保符合代理 Markdown 標準。

代理掛鉤

• 代理掛鉤：代理掛鉤與 web hooks 類似，會在特定事件發生時觸發工作流程（例如儲存或更新檔案）。
• 安全標準：
• 範例：定義安全標準，確保程式碼不含寫死的憑證或安全漏洞。
• 儲存時執行安全掃描：定義用於安全審查的代理掛鉤，掃描 API 金鑰、私密金鑰、IP 位址等內容，並自動修正。
• 示範：
• 現有程式碼：一個含有寫死 IP 位址的簡單範例。
• 建立代理掛鉤：定義代理掛鉤，在儲存檔案時執行安全掃描。
• 結果：安全掃描將寫死的 IP 位址識別為高風險，並改為使用環境變數；若環境變數不存在，則預設使用 localhost。
• 安全左移：安全掃描在儲存檔案時執行，將安全檢查提前至開發流程，而非等到 CI/CD 階段才進行。

代理掛鉤的其他用途

• Figma 設計比對：
• 整合：使用代理掛鉤，在儲存檔案時將已開發的元素與 Figma UX 設計進行比對。
• Figma MCP：整合 Figma MCP，確保程式碼符合既定設計。
• 範例：提示系統以 Angular 實作 Figma 設計，直接根據 Figma 設計產生程式碼。

MCP Server 整合（從 Figma 到程式碼）

• 範例：整合 Figma MCP，並提示系統根據 Figma 設計產生 Angular 程式碼。
• 結果：系統直接從 Figma 設計產生程式碼，依照設計建立網站。

MCP Server 整合（最新文件）

• 整合：使用 MCP server 參考最新文件，例如 AWS 文件與知識庫。
• 範例：與 AWS 文件整合，並提示系統檢查本機撰寫的程式碼能否在 AWS Lambda 上執行。
• 結果：系統不僅能找出程式碼部署至 Lambda 時的問題，還會建立遷移計畫，建議採用 S3 預簽章 URL 傳輸檔案等變更。

Kiro 中的規格驅動開發

• 規格驅動開發：被譽為敏捷開發問世以來最出色的進展。
• 敏捷開發的挑戰：由於需求持續演變，加上專案經理、商業分析師與使用者之間溝通不良，使用者提出的需求往往與最終建置成果不同。
• 調適性方法：Kiro 的規格驅動開發正視這些挑戰，在整個開發過程中動態調整。

實際使用案例示範

• 使用者需求：使用者想建立一個檔案分割應用程式，具體而言，是將一個 500 MB 的檔案分割成五個 100 MB 的區塊。
• [ 1 ] 隱含需求：
• 圖形化使用者介面 (GUI)
• 以拖放方式輸入檔案
• 分割設定選項（例如分成五個區塊，或每個區塊 10 MB）
• 可下載個別檔案，以及包含所有分割檔案的 zip 檔
• [ 2 ] 開發時間：
• 傳統估算：兩週
• Kiro 開發：六小時（以一段 10 分鐘的加速影片示範）
• [ 3 ] 影片示範：
• 一段 10 分鐘的影片展示使用 Kiro 完成六小時開發流程的過程，左上角顯示即時計時器。

初始需求與設計

• 使用者輸入：產品負責人輸入初始需求，要建立一個將大型檔案分割成較小區塊的應用程式。
• Kiro 的回應：Kiro 在一分鐘內產生七項使用者需求與驗收條件。
• 使用者回饋：產品負責人檢視並核准需求。

設計調整

• 初始設計：Kiro 建立初始設計，並假設使用命令列介面 (CLI)。
• 使用者修正：產品負責人要求使用圖形化使用者介面 (GUI)，而非 CLI。
• 即時更新：Kiro 即時調整設計，加入 GUI 與後端 API。

反覆迭代的設計流程

• 待辦事項檔案：使用待辦事項檔案，追蹤過程中出現的其他問題與需求。
• [ 1 ] 產品負責人詢問將檔案從前端傳送至後端的機制。
• 設計更新：更新設計，記錄上傳機制。
• [ 2 ] 新需求：產品負責人新增支援最大一 TB 檔案的需求。
• 設計更新：更新設計，以處理一 TB 的檔案。
• [ 3 ] 產品負責人詢問後端如何在分割前得知檔案大小。
• 設計更新：加入更多設計細節，以回答此問題。

工作規劃

• 建立工作計畫：需求與設計定案後，建立工作計畫，將專案拆分為個別工作（工作 1 至工作 10）。
• 所需時間：從初始需求到工作規劃的完整流程不到 20 分鐘。

工作規劃與程式開發

• 工作可追溯性：每項工作都能追溯至需求，確保從需求、設計到工作計畫的端對端可追溯性。
• 單元測試：Kiro 在撰寫程式碼的同時產生單元測試。工作必須通過所有單元測試，才能視為完成。
• 除錯：Kiro 會自動除錯並修正單元測試失敗的問題。
• 錯誤處理與最佳化：Kiro 將錯誤處理、驗證及效能最佳化納入工作的一部分。

測試與錯誤修正

• 初次測試：首次測試應用程式時，發現 UX 問題（例如藍色字體難以閱讀）。
• 找出錯誤：檔案上傳時發生錯誤，並透過日誌訊息找出問題。
• 代理輔助除錯：將錯誤代碼複製並貼到代理中，由代理嘗試修正錯誤。
• 成功上傳：錯誤修正後，成功上傳大型檔案。
• 分割與下載：應用程式成功分割檔案，並可下載個別區塊與 zip 檔。

UX 改善

• 變更顏色：將藍色字體改為青色，以提升可讀性。
• 按鈕外觀：將按鈕的灰色改為較合適的顏色。
• 大型檔案上傳：使用兩 GB 的檔案測試應用程式，確保其能處理大型檔案。

測試自動化

• 手動測試：起初以手動方式測試，包括分割多個檔案及確認 UX 問題。
• 自動化：Kiro 使用 Mermaid 圖表建立設計與文件，並透過 Playwright 將測試自動化。
• 跨瀏覽器測試：在 Firefox、Chrome、Safari 與行動裝置上執行自動化測試。
• 端對端流程：此過程展示了從需求、軟體建置到自動化即時驗證的端對端流程，而且全都在 IDE 內完成。

摘要

• 此流程展示 Kiro 處理規格驅動開發的能力，涵蓋需求、設計、程式開發、單元測試與 UX 改善；相較於傳統方法，所需時間大幅縮短。

結論與敏捷開發的未來

• 敏捷團隊規模：由一位經驗豐富的工程師與一位領域或功能專家組成，兩人在 IDE 中協同作業。
• 時間比較：從需求到自動化測試的完整流程在六小時內完成；相較之下，完整敏捷團隊的估算為兩週。
• 規格驅動開發：本場分享旨在讓大家一窺使用 Kiro 進行規格驅動開發所能實現的成果。