Kiro Spec 模式怎麼用：需求、設計、任務三步工作流，Steering 規則與 Hooks 配置

本文根據 Kiro 官方文檔《Specs》《Steering》《Hooks》整理，資料核對於 2026-10-11。Kiro 是 AWS 出品的 AI IDE，產品介紹見本站 AI 應用目錄裏的 Kiro 條目。

適用於誰

• 覺得「一句話讓 AI 直接寫」越寫越亂，想先把需求和設計定下來的人；
• 搜「kiro spec 模式」「kiro spec 工作流」「kiro steering 怎麼用」「kiro hooks」的人；
• 團隊想讓需求文檔、設計文檔和代碼一起進倉庫的人。

結論先說

1. Spec 是 Kiro 的規格驅動流程：把一個想法變成三份文件——requirements.md（修 bug 時是 bugfix.md）、design.md、tasks.md，都放在 .kiro/specs/功能名/ 下。
2. 流程三階段：需求 → 設計 → 任務，每一階段你確認了才進入下一階段。
3. 熟悉的小功能用 Quick Spec 一次生成三份文件；修復雜 bug 用 Bugfix Spec；探索性的隨手改動不必用 Spec。
4. Steering 是 Kiro 的項目規則：.kiro/steering/ 下的 Markdown 文件，四種加載方式；Kiro 也讀 AGENTS.md。
5. Hooks 是事件觸發的自動化：智能體儲存文件、調用工具時自動跑命令或追加提示。

安裝與登入

官方系統要求（IDE）：macOS（Intel 與 Apple 芯片）、Windows 10 / 11、Linux（Ubuntu 24+、Debian 13+、Fedora 40+ 等）。到 kiro.dev 下載安裝包，首次打開時用 Google、GitHub、AWS Builder ID 或組織身份登入；可以選擇導入 VS Code 的設定和擴展。

Spec 的三份文件

步驟：在 IDE 裏跑一個 Feature Spec

1. 在 Kiro 面板的 Specs 下點 +，或在聊天面板裏選 Spec；
2. Kiro 問你是做功能（Feature）還是修 bug（Bug）。選 Feature 後描述功能，並選流程：Requirements-First 或 Design-First；
3. 看它生成的第一份文件，不滿意就直接編輯或在聊天裏要求修改，滿意了進入下一階段；
4. 三份文件都確認後，在 tasks.md 的任務執行介面裏逐個運行或全部運行，狀態會實時更新為進行中 / 已完成。

兩種流程怎麼選：

全部運行時會自動並行：Kiro 分析 tasks.md 建出依賴圖，把互不依賴的任務分成一波一波——同一波內並發執行，波與波之間順序執行。不需要額外設定。

CLI 裏對應的命令是 /spec new 名稱 開始、/spec run 名稱 進入全屏的任務執行視圖。網頁版（app.kiro.dev）可以為一個 spec 選多個倉庫，完成後由智能體開 pull request。官方在這裏有一條警告：只選你信任的倉庫，因為智能體會遵循倉庫代碼裏的指示。

Quick Spec 與 Bugfix Spec

Quick Spec：在開始會話的「Let's build」介面選擇。Kiro 先集中問一輪澄清問題（範圍、約束、邊界情況），然後不設審批關卡地依次生成三份文件，你直接落在任務清單上。官方建議只在兩種情況用：功能你很熟、信得過它的輸出；或者快速做原型。需求還在摸索、評審關卡確實有價值時，用標準 Feature Spec。

Bugfix Spec：模仿有經驗的工程師修 bug 的方式——找根因、明確要改什麼、明確寫出什麼不能變。適合需要根因分析的複雜 bug、關鍵路徑上回歸代價高的 bug、之前修過卻引入了迴歸的情況。

Steering：讓 Kiro 記住項目約定

Steering 文件是 Markdown，放兩個位置：

• 工作區：項目根目錄的 .kiro/steering/，只對這個項目；
• 全局：用戶目錄的 ~/.kiro/steering/，對所有項目。兩者衝突時工作區優先。

Kiro 可以一鍵生成三份基礎文件（Steering 區域點 Generate Steering Docs）：product.md（產品目的、用戶、功能）、tech.md（技術棧與約束）、structure.md（目錄組織、命名、架構決定）。它們預設每次交互都會帶上。

自定義文件通過文件開頭的 frontmatter 決定加載方式（必須是文件最開頭的內容，前面不能有空行）：

markdown
---
inclusion: fileMatch
fileMatchPattern: "app/api/**/*"
---
# 接口規範
- 所有接口返回 { code, message, data } 結構
- 入參用 zod 校驗

AGENTS.md：Kiro 支持這個通用標準，放在工作區根目錄、子目錄或 ~/.kiro/steering/ 都會自動讀取；但它不支持加載方式，始終加載。跨工具的寫法見《AGENTS.md 怎麼寫》。

一個容易漏掉的點：使用自定義智能體（custom agents）時，Steering 文件不會自動帶上，要在智能體配置的 resources 裏顯式加入。

Hooks：事件觸發的自動化

Hook 配置是 .kiro/hooks/ 下的 JSON 文件，每個文件定義一個或多個 hook：觸發事件、可選的匹配模式、動作。動作有兩種：

• command：在項目根目錄跑一條 shell 命令，會話上下文以 JSON 從標準輸入傳入；
• agent：往當前對話裏注入一段提示，引導智能體的行為。

官方的例子——智能體每次儲存 TypeScript 文件後自動跑 ESLint：

json
{
  "version": "v1",
  "hooks": [{
    "name": "Lint on save",
    "trigger": "PostFileSave",
    "matcher": "\\.(ts|tsx)$",
    "action": { "type": "command", "command": "npx eslint --fix" }
  }]
}

儲存為 .kiro/hooks/lint-on-save.json 即自動生效。官方列舉的用途：改完文件自動跑 linter / 格式化 / 類型檢查；用 PreToolUse 在前置條件不滿足時攔住危險操作；新增源文件時自動生成配套的測試或文檔；提交前檢查質素。也可以直接在聊天裏讓智能體幫你創建 hook。Hooks 目前只在 IDE 和 CLI 裏可用。

常見問題

Q：小改動也要走 Spec 嗎？

不用。官方把「沒有明確目標的探索性編碼」列為不適合 Spec 的場景；改一行、問個問題直接在聊天裏做。

Q：三份文件要提交進 Git 嗎？

它們就在倉庫的 .kiro/specs/ 下，是普通 Markdown。官方強調的好處之一就是產品和工程共用同一份文檔，提交進倉庫便於評審和追溯。

Q：Spec 寫好後需求變了？

直接改 requirements.md 或在聊天裏提出修改，讓 Kiro 更新後續的設計和任務。官方還有 Analyze Requirements 功能，用來在進入設計前找出需求裏的矛盾、歧義和缺口（IDE 與 CLI 可用）。

Q：和 Cursor 的 Plan 模式有什麼不同？

兩者都是「先規劃再動手」。區別在於 Kiro 把規劃拆成需求、設計、任務三份長期保留的文件並分階段確認；Cursor 的 Plan 模式產出一份實施方案。見《Cursor Agent 模式怎麼用》。

參考資料

• Specs（Kiro 官方）：https://kiro.dev/docs/specs
• Feature Specs（Kiro 官方）：https://kiro.dev/docs/specs/feature-specs
• Quick Spec（Kiro 官方）：https://kiro.dev/docs/specs/quick-spec
• Bugfix Specs（Kiro 官方）：https://kiro.dev/docs/specs/bugfix-specs
• Steering（Kiro 官方）：https://kiro.dev/docs/steering
• Hooks（Kiro 官方）：https://kiro.dev/docs/hooks