Kiro Spec-Driven Development 實戰教學 — 讓 AI 寫出能上線的 Code 的關鍵流程

瀏覽次數: 19

本文大綱

文章資訊

預估字數: ~3,500 字
閱讀時間: 12 分鐘
難度: 中階（需基本 AI coding tool 使用經驗）
SEO 主關鍵字: Kiro, Spec-Driven Development, AI coding, feature spec, AI 寫程式
SEO 長尾關鍵字: Kiro IDE 教學, spec-driven development 流程, AI coding 能上線, requirements.md design.md tasks.md, Kiro vs Cursor vs Claude Code, AI 寫程式品質
目標讀者: 被指派推動 AI 專案的技術主管 / 正在用 AI coding tool 但產出不穩定的開發者

這篇文章適合你，如果你是…

AI 導入推動者: 公司要你推 AI coding，但你發現 AI 寫的 code 常常不能用，需要一套可複製的流程
開發者 / Tech Lead: 已經在用 Cursor、Copilot 或 Claude Code，但覺得 AI 產出品質不穩定，想找更系統化的方法
技術決策者: 需要評估 Kiro 等新工具，判斷哪種 AI coding 流程適合你的團隊

1. 前言：問題場景

從架構設計的角度來看，現在大多數團隊用 AI 寫 code 的流程是這樣的：打開 AI coding tool → 用自然語言描述需求 → AI 生成一大段程式碼 → 複製貼上 → 跑看看能不能動。

能動就上線。不能動就再問一次。

這個流程有個根本問題：AI 不知道你的系統長什麼樣。它不知道你的 API 命名規範、不知道你用的 ORM 是哪一套、不知道你的認證流程是 JWT 還是 session-based。它只知道你那句話。

結果就是：根據 Google 2025 DORA 報告，導入 AI coding tool 的團隊開發速度確實變快了，但交付穩定性反而下降 7.2%。Cranium AI 的研究更直接：AI 生成的程式碼有 48% 含有安全漏洞。ICSE 2026 的同行評審研究也指出：LLM 優化的是功能正確性，而非架構一致性或合規需求。EY 的技術團隊遇到了一模一樣的問題：AI agent 幾分鐘生成幾千行 code，但大部分無法部署。

AI 讓你寫得更快，但「寫得快」跟「能上線」是兩件事。

解決方案預告

這篇文章要介紹的是一個叫 Spec-Driven Development（SDD） 的方法論，以及 AWS 推出的 Kiro IDE 如何把這套流程做進開發工具裡。EY 用類似的方法拿到了 4 倍效率提升；而且是能部署、能上線的 4 倍。

讀者收穫

讀完這篇文章，你將能夠：

理解 Spec-Driven Development 的核心概念，以及它跟「直接叫 AI 寫 code」的根本差異
掌握 Kiro 的三階段 spec 流程（requirements → design → tasks），知道每一步在做什麼
比較 Kiro、GitHub spec-kit、Cursor Rules、Claude Code CLAUDE.md 四種工具的定位差異
拿到一套可以帶回團隊的 SDD 導入建議

TL;DR

Spec-Driven Development 的核心是「先定義規格，再讓 AI 實作」— 把 AI 從「猜你要什麼」變成「照規格書執行」
Kiro 把 SDD 做成 IDE 內建功能：requirements.md（需求）→ design.md（架構）→ tasks.md（工作項），每步都有人類審核
跟 Cursor Rules、Claude Code 的差異不是「誰比較好」，而是解決不同層級的問題，Kiro 管流程，Rules/CLAUDE.md 管規範
EY 用類似方法拿到 4x 效率，關鍵不是工具，是「讓 AI 在動手之前先知道規矩和全貌」
你不一定要用 Kiro；GitHub spec-kit 是開源的，同樣的方法論可以用在任何 AI coding tool 上

2. Spec-Driven Development 介紹

什麼是 Spec-Driven Development？

Thoughtworks 在 2025 年的 Technology Radar 中把 Spec-Driven Development 列為年度重要實踐之一。他們的定義是：

Spec-Driven Development 是一種開發範式，使用結構化的軟體需求規格作為 prompt，搭配 AI coding agent 來生成可執行的程式碼。

不是直接叫 AI「做一個登入頁面」，而是先把登入頁面的所有規格寫清楚（要 OAuth 還是帳密？session 存哪？錯誤訊息要多語系嗎？），再讓 AI 照著規格去實作。

為什麼需要它？— Vibe Coding 的問題

Andrej Karpathy 在 2025 年初創了「vibe coding」這個詞：意思是靠感覺、靠氛圍用 AI 寫 code。聽起來很酷，但 Thoughtworks 直接點出問題：

vibe coding 的問題在於太快、太即興、太隨意。因為 AI 生成 prototype 太容易了，很多人忽略了工程實踐的重要性，結果產出大量不可維護、有缺陷的一次性程式碼。

從系統設計的角度來看，vibe coding 的根本問題是：它省略了「設計」這一步。傳統軟體開發是：需求分析 → 系統設計 → 實作 → 測試。Vibe coding 直接跳到實作，把需求分析和系統設計都壓縮成一句 prompt。

SDD 做的事情就是把「設計」這一步加回來，只是現在設計的對象不只是給人看，也是給 AI 看。

SDD 的核心公式

傳統 AI coding:  模糊需求 → AI 生成 → 人工修正（反覆循環）
SDD:             結構化需求 → 技術設計 → 任務拆解 → AI 執行（一次到位率高）

EY 的實測數據：用結構化 spec 流程，交付時間縮短 50%，缺陷減少 40%。DX 的調查顯示，採用結構化 AI 工作流的開發者平均每週節省 3.6 小時。

3. Kiro 如何把 SDD 做進 IDE

Kiro 是什麼？

Kiro 是 AWS 推出的 AI IDE，基於 Code OSS（VS Code 的開源版本）打造。它最大的特色不是 AI 寫 code 寫得多快，而是把 Spec-Driven Development 的完整流程做成 IDE 的內建功能。

三階段 Spec 流程

Kiro 的核心是三個 Markdown 檔案，形成一條從需求到實作的完整鏈路：

階段一：requirements.md 把需求寫清楚

當你在 Kiro 中建立一個 Feature Spec，它會先生成 requirements.md。這個檔案用的是 EARS 記法（Easy Approach to Requirements Syntax）— 一種結構化的需求撰寫格式。

EARS 記法範例：

## User Stories

### Story 1: 使用者登入
**作為**一位已註冊的使用者
**我想要**透過 Email 和密碼登入系統
**以便**存取我的個人資料和設定

### Acceptance Criteria
- **When** 使用者輸入正確的 Email 和密碼, **the system shall** 發放 JWT token 並導向 dashboard
- **When** 使用者連續輸入錯誤密碼 5 次, **the system shall** 鎖定帳號 30 分鐘並發送通知信
- **If** 使用者的帳號已被停權, **then the system shall** 顯示停權原因並提供申訴連結

為什麼這很重要？ 因為「做一個登入頁面」和上面這份 requirements 給 AI 的資訊量差了十倍。AI 拿到後者，寫出來的 code 會包含錯誤處理、帳號鎖定邏輯、停權判斷；而不是只有一個 email + password 表單。

關鍵：這一步是人類審核的。 Kiro 會自動生成初版 requirements，但你需要逐條檢查、修改、補充。這個 human-in-the-loop 的審核流程，正是 SDD 跟 vibe coding 的根本差異。

階段二：design.md 把架構想清楚

requirements 確認後，Kiro 會生成 design.md 技術架構文件。這個檔案包含：

系統架構圖（Mermaid 格式，可以直接渲染）
Sequence Diagram（關鍵流程的時序圖）
資料模型（Entity 定義和關聯）
API 介面（endpoint、request/response schema）
技術決策（例如：用 JWT 不用 session 的原因）

## Technical Architecture

### Sequence Diagram
sequenceDiagram
    Client->>API: POST /auth/login {email, password}
    API->>DB: 查詢使用者
    DB-->>API: 使用者資料
    API->>API: 驗證密碼 (bcrypt)
    API->>API: 檢查登入失敗次數
    alt 密碼正確
        API->>JWT: 生成 token
        API-->>Client: 200 {token, user}
    else 密碼錯誤且未達上限
        API->>DB: 更新失敗次數
        API-->>Client: 401 Invalid credentials
    else 密碼錯誤且達上限
        API->>DB: 鎖定帳號
        API->>Email: 發送鎖定通知
        API-->>Client: 423 Account locked
    end

從架構的角度看，design.md 解決的是 AI coding 最常見的問題之一：AI 不知道你的系統全貌。當你只給它一個功能需求，它會用最通用的方式實作。但當你給它完整的架構設計：包含資料流、錯誤處理路徑、與現有系統的整合方式；它寫出來的 code 就能直接嵌入你的系統，而不是一個獨立的孤島。

階段三：tasks.md 把工作拆好

最後，Kiro 根據 requirements 和 design 生成 tasks.md，一份結構化的實作計畫：

## Implementation Tasks

### Task 1: 建立 User model 和 migration
- [ ] 建立 `users` 表（包含 email, password_hash, login_attempts, locked_until）
- [ ] 建立 Sequelize model
- [ ] 撰寫 seed data

### Task 2: 實作 POST /auth/login endpoint
- [ ] 建立 route 和 controller
- [ ] 實作密碼驗證邏輯（bcrypt）
- [ ] 實作登入失敗計數和帳號鎖定
- [ ] 實作 JWT token 生成
- [ ] 撰寫單元測試

### Task 3: 實作帳號鎖定通知
- [ ] 整合 Email service
- [ ] 建立鎖定通知 template
- [ ] 撰寫整合測試

每個 task 是獨立的、可追蹤的，而且 Kiro 的 AI agent 會逐個 task 執行，完成一個才進下一個。這比「一次生成整個功能」可控得多。

Kiro 的其他關鍵功能

功能	說明
Steering Files	類似 Cursor Rules / CLAUDE.md，定義 AI 的行為規範（coding style、tech stack、命名規則）
Agent Hooks	自動化觸發器：例如存檔時自動跑 lint，commit 前自動跑測試
MCP Server 支援	可連接外部工具（資料庫、API、第三方服務），擴展 AI 的能力範圍
多模態輸入	可以上傳手繪架構圖，Kiro 會解析並轉換為 spec
雙向 Spec 流程	需求優先（greenfield）或設計優先（既有系統）兩種起點

4. 工具比較：Kiro vs GitHub spec-kit vs Cursor vs Claude Code

四種工具，四個層級

這四個工具不是在做同一件事；它們解決的是 AI coding 流程中不同層級的問題：

層級	問題	工具	做法
流程層	AI 動手前要先想清楚什麼？	Kiro / spec-kit	三階段 spec 流程（需求 → 設計 → 任務）
規範層	AI 要遵守哪些規則？	Cursor Rules / CLAUDE.md	模組化規則檔，按情境載入
執行層	AI 怎麼寫、怎麼改？	所有 AI coding tool	LLM 生成 + 編輯

關鍵理解：流程層和規範層是互補的，不是二選一。

Martin Fowler 的團隊在分析 Kiro、spec-kit 和 Tessl 三個 SDD 工具時也指出了這個區別：CLAUDE.md 或 Cursor Rule 說的是「永遠用 TypeScript strict mode」— 這是通用規範。Kiro spec 說的是「這個功能有 5 個 user story、這是 sequence diagram、這是 12 個 task 和檔案路徑」— 這是任務專屬的實作計畫。

EY 拿到 4x 效率，正是因為他們同時做了流程層（結構化 spec）和規範層（把工程標準接給 AI）。

工具詳細比較

Kiro（AWS）

定位: 流程驅動的 AI IDE
核心: SDD 三階段流程內建在 IDE 中
優勢: 流程完整、有 human-in-the-loop 審核、適合大型專案和企業團隊
限制: 綁定 Kiro IDE、相對較新、生態系還在建立中
適合: 重視流程和規格品質的企業團隊、大型功能開發

GitHub spec-kit（開源）

定位: 工具無關的 SDD 框架
核心: 提供 /specify → /plan → /tasks 三步流程，可在任何 AI coding tool 中使用
優勢: 開源、不綁特定 IDE、有 /analyze 品質檢查、社群活躍
限制: 需要手動設定、沒有 IDE 整合的便利性
適合: 已有偏好 IDE 的團隊、想要 SDD 但不想換工具的團隊

Cursor Rules（.mdc 格式）

定位: 規範層的精細控制
核心: 四種規則類型：Always（全域）、Auto Attached（按檔案類型自動載入）、Agent Requested（AI 自行判斷是否需要）、Manual（手動引用）
優勢: 模組化設計、按情境載入減少認知負擔、Cursor IDE 生態完整
限制: 綁定 Cursor IDE、沒有內建的 spec 流程
適合: 重視開發速度、需要精細規範控制的團隊

Claude Code CLAUDE.md

定位: 極簡的專案級規範
核心: 一個 Markdown 檔案定義專案規範，放在專案根目錄
優勢: 極度簡單、終端機原生、與 git 工作流無縫整合
限制: 單一檔案、沒有按情境載入的機制（但可用子目錄 CLAUDE.md 分層）
適合: 偏好終端機工作流的開發者、小型到中型專案

我的建議組合

最佳組合 = SDD 流程工具 + 規範工具

企業大型專案:  Kiro (流程) + Kiro Steering Files (規範)
混合工具團隊:  spec-kit (流程) + Cursor Rules 或 CLAUDE.md (規範)
個人/小型專案:  spec-kit 簡化版 (流程) + CLAUDE.md (規範)

5. 決策框架：你的團隊該怎麼選？

三個判斷問題

問題一：你的 AI coding 最大痛點是什麼？

「AI 寫的 code 能跑但不符合我們的標準」→ 你需要的是規範層（Cursor Rules / CLAUDE.md）
「AI 寫的 code 跟需求差很遠」→ 你需要的是流程層（Kiro / spec-kit）
「兩個都有」→ 兩層都要做，優先做流程層（效果更顯著）

問題二：你的團隊多大？

1-3 人：spec-kit 簡化版 + CLAUDE.md 就夠了
4-15 人：spec-kit + Cursor Rules，考慮統一 spec template
15+ 人：認真評估 Kiro，flow 的一致性比個人效率更重要

問題三：你們的專案多複雜？

CRUD 為主的應用：規範層足矣，SDD 流程可能 overkill
有複雜業務邏輯的系統：SDD 的 design.md 會大幅降低 AI 寫歪的機率
跨系統整合：SDD 幾乎是必要的，否則 AI 不可能知道系統間的契約和依賴

場景案例

場景	團隊規模	推薦	理由
新創 MVP 快速迭代	2 人	spec-kit + CLAUDE.md	輕量、不拖速度
企業內部系統重構	10 人	spec-kit + Cursor Rules	需要精細規範 + 結構化需求
金融/合規產業新功能	20+ 人	Kiro 全套	需要完整審計軌跡和流程控制
開源專案維護	不定	spec-kit（已有 GitHub 整合）	貢獻者可遵循統一 spec

6. 實戰最佳實踐

常見錯誤 → 正確做法

常見錯誤	正確做法
把所有規則塞進一個大檔案（2,000+ 行）	按關注點拆模組，每個檔案管一件事。LLM 能穩定遵守的指令約 150-200 條。
Spec 只寫一句「做一個 XX 功能」	用 EARS 記法寫 acceptance criteria，包含正常路徑和異常路徑
AI 寫完 → 人工跑 lint → 發現問題 → 手動叫 AI 改	把 lint 結果接進 AI agent 迴圈，讓它自己修正再提交
先寫 code 再補 spec（倒過來做）	先寫 spec、review spec、確認 spec，再讓 AI 動手。順序不能反。
一次叫 AI 實作整個功能	拆成獨立的 task，逐個執行，每個 task 都可驗證

導入建議：三步開始

第一步（今天就能做）： 選一個即將開發的小功能，先不寫 code。打開一個 Markdown 檔案，用 EARS 記法把 requirements 寫下來。感受一下「把需求寫清楚」需要多少思考。

第二步（本週內）： 安裝 GitHub spec-kit（uvx spec-kit init），或者在 Kiro 中建立你的第一個 Feature Spec。跑一次完整的 specify → plan → tasks 流程。

第三步（下個 sprint）： 把 SDD 流程套用在一個真實功能上。比較有 spec 和沒有 spec 的 AI 產出品質差異。用數據說服團隊。

7. 工具與資源推薦

工具/資源	說明	連結
Kiro IDE	AWS 推出的 SDD IDE	kiro.dev
Kiro Feature Specs 文件	官方 spec 流程教學	kiro.dev/docs/specs/feature-specs
GitHub spec-kit	開源 SDD 工具包	github.com/github/spec-kit
Cursor Rules 文件	規則檔設定指南	docs.cursor.com/context/rules
Claude Code CLAUDE.md	專案級指令指南	claude.com/blog/using-claude-md-files
Thoughtworks SDD 分析	SDD 方法論深度解讀	thoughtworks.com
EY 4x 效率案例	企業導入實戰報導	VentureBeat

8. 總結與展望

一張表看完

面向	Vibe Coding	Spec-Driven Development
需求定義	一句話 prompt	結構化 EARS 記法
系統設計	省略	架構圖 + sequence diagram
任務管理	一次生成全部	逐步拆解、逐步執行
品質控制	事後修	事前防
適合場景	prototype、個人 side project	要上線的產品、團隊協作
效率特徵	初速快，但修改成本高	初速慢，但一次到位率高

未來趨勢

SDD 會成為企業 AI coding 的標配： Thoughtworks 已把它列入 Technology Radar，GitHub 推出了 spec-kit，AWS 推出了 Kiro。這不是某個工具的功能，是一個方法論的共識。
工具會融合：未來 Cursor 可能內建 spec 流程，Claude Code 可能加入結構化需求模板。工具邊界會模糊，但 SDD 的方法論會留下來。
「Context Engineering」會取代「Prompt Engineering」：這是 Thoughtworks 的觀察。重點不再是怎麼寫一個好的 prompt，而是怎麼建構完整的 context（spec + rules + codebase + constraints）給 AI。

行動建議

今天：讀完這篇文章，選一個你即將開發的小功能，試著用 EARS 記法寫 requirements
這週：跑一次 spec-kit 或 Kiro 的完整 SDD 流程，體驗「先規格、再實作」的差異
這個月：在團隊中推動一次 SDD 試點，收集數據（開發時間、bug 數、rework 次數）
下一季：根據試點數據決定是否全面導入，選擇適合團隊的工具組合

延伸思考

你目前用 AI 寫 code 時，花在「描述需求」和「修改 AI 產出」的時間比例大約是多少？如果把更多時間投入前者，後者會不會大幅減少？
你的團隊有沒有一份明確的「工程標準」文件？如果有，AI 能讀懂嗎？如果沒有，這是不是該優先建立的？
SDD 要求「先慢後快」— 先花時間寫 spec，後面加速實作。你的團隊文化能接受這種節奏嗎？需要什麼改變？

FAQ 常見問題

Q1: Kiro 是免費的嗎？
Kiro 目前在 Preview 階段，可免費使用。正式定價尚未公布。

Q2: 我已經在用 Cursor，需要換到 Kiro 嗎？
不一定。如果你主要的痛點是「AI 不遵守規範」，Cursor Rules 可能就夠了。如果痛點是「AI 寫的東西跟需求差很遠」，可以先試試 spec-kit（不用換 IDE），有效再考慮 Kiro。

Q3: spec-kit 跟 Kiro 的 spec 格式一樣嗎？
不完全一樣，但理念相同。spec-kit 用的是 GitHub 自己的 template（spec.md → plan.md → tasks.md），Kiro 用的是 requirements.md → design.md → tasks.md。核心都是三階段流程。

Q4: SDD 會不會讓開發變慢？
初期會花更多時間在寫 spec 上。但 EY 的數據顯示，總體交付時間反而縮短 50%，因為大幅減少了返工。可以類比為：花 30 分鐘寫清楚需求，省下 3 小時的來回修改。

Q5: 小型個人專案也需要 SDD 嗎？
看複雜度。如果是簡單的 CRUD，直接 vibe coding 反而更快。如果功能有多個邊界條件和錯誤處理路徑，即使是個人專案，花 10 分鐘寫個簡化版 spec 也很值得。

Q6: EARS 記法很難學嗎？
不難。核心就是用固定句型寫需求：「When [條件], the system shall [行為]」、「If [狀態], then the system shall [行為]」。5 分鐘就能上手，重點是養成習慣。

Q7: 我怎麼說服主管導入 SDD？
用數據：EY 4x 效率提升、交付時間縮短 50%、缺陷減少 40%。另外，SDD 產出的 spec 文件本身就是文件化的副產品；主管通常很喜歡看到有文件。

Q8: Agent Hooks 是什麼？跟 CI/CD 有什麼不同？
Agent Hooks 是 Kiro 的自動化觸發器，例如存檔時自動跑 lint、commit 前自動跑測試。跟 CI/CD 的差異是：Agent Hooks 發生在開發階段（IDE 內），CI/CD 發生在提交後。兩者互補，不是替代。

Q9: 我的團隊成員對 AI 工具的熟悉度差異很大，怎麼辦？
SDD 的一個好處是：spec 本身是人類可讀的 Markdown 文件。即使不熟悉 AI 工具的成員，也能參與 requirements review 和 design review。從 review spec 開始，逐步熟悉 AI 工具。

Q10: Claude Code 的 CLAUDE.md 能不能實現類似 SDD 的效果？
可以部分實現。你可以在 CLAUDE.md 中定義 spec template 和流程規範，讓 Claude Code 在每次新功能開發時先走 spec 流程。但這需要自律，Kiro 和 spec-kit 的好處是把流程固化在工具裡。