Kiro 学习指南
- [Kiro 学习指南](#Kiro 学习指南)
- [1. 快速开始](#1. 快速开始)
- [2. 两大开发模式](#2. 两大开发模式)
-
- [2.1 Vibe 模式（自由对话式）](#2.1 Vibe 模式（自由对话式）)
- [2.2 Spec 模式（结构化规划式）](#2.2 Spec 模式（结构化规划式）)
- [2.3 模式对比与选择](#2.3 模式对比与选择)
- [3. Steering 功能](#3. Steering 功能)
- [4. Spec 文档详解](#4. Spec 文档详解)
-
- [4.1 requirements.md](#4.1 requirements.md)
- [4.2 design.md](#4.2 design.md)
- [4.3 tasks.md](#4.3 tasks.md)
- [5. 可直接使用的提示词](#5. 可直接使用的提示词)
-
- [5.1 生成 requirements.md](#5.1 生成 requirements.md)
- [5.2 生成 design.md](#5.2 生成 design.md)
- [5.3 生成 tasks.md](#5.3 生成 tasks.md)
- [6. 其他功能](#6. 其他功能)
-
- [6.1 Hooks（自动化钩子）](#6.1 Hooks（自动化钩子）)
- [6.2 MCP（Model Context Protocol）](#6.2 MCP（Model Context Protocol）)
- [6.3 上下文引用](#6.3 上下文引用)
- [7. 最佳实践](#7. 最佳实践)
Kiro 学习指南
本文档介绍 Kiro 的核心功能和使用方法，帮助你更好地利用 AI 辅助开发。
1. 快速开始
Kiro 是一个 AI 辅助开发的 IDE，核心理念：让 AI 理解你的项目，而不是每次都从零开始解释。
30 秒上手
| 场景 | 做法 |
|---|---|
| 改个 bug、加小功能 | 直接在聊天框输入需求（Vibe 模式） |
| 开发完整功能模块 | 输入"帮我创建一个 Spec，开发 xxx"（Spec 模式） |
| 让 AI 记住项目背景 | 在 .kiro/steering/ 下创建 md 文件 |
2. 两大开发模式
2.1 Vibe 模式（自由对话式）
像和同事聊天一样，直接告诉 AI 你想做什么，AI 立即执行。
适用场景：快速修 bug、小功能调整、代码重构、探索性开发
使用示例：
帮我给这个按钮加个 loading 状态
把这个函数改成 async/await 写法
这个接口报错了，帮我看看什么问题2.2 Spec 模式（结构化规划式）
先规划再执行，将开发过程分为三个阶段，每阶段生成文档并等待确认。
适用场景：复杂功能开发、新项目搭建、团队协作、需要文档留存的项目
核心流程
需求（What）──────► 设计（How）──────► 任务（Do）
│ │ │
requirements.md design.md tasks.md
│ │ │
用户确认 ✓ 用户确认 ✓ 开始执行| 阶段 | 核心工作 | 输出 |
|---|---|---|
| 需求阶段 | 把用户描述转化为用户故事 + EARS 验收标准 | requirements.md |
| 设计阶段 | 生成技术架构、数据模型、API 设计 | design.md |
| 任务阶段 | 拆解为可执行任务，带依赖关系和检查点 | tasks.md |
触发方式
帮我创建一个 Spec，开发[功能名称]文件位置
.kiro/specs/[功能名称]/
├── requirements.md
├── design.md
└── tasks.md2.3 模式对比与选择
| 方面 | Vibe 模式 | Spec 模式 |
|---|---|---|
| 开发风格 | 自由、即兴 | 规划、结构化 |
| 文档产出 | 无 | 需求/设计/任务文档 |
| 可追溯性 | 低 | 高 |
| 质量保障 | 依赖人工检查 | 有验收标准和检查点 |
选择建议：改 bug、加小功能 → Vibe；开发完整模块、搭建新项目 → Spec
3. Steering 功能
Steering = 项目说明书，让 AI "记住"你的项目背景。
注意：Steering 不是开发模式，而是辅助功能，在 Vibe 和 Spec 模式下都会生效。
文件位置与作用
.kiro/steering/
├── product.md # 产品概述（让 AI 理解业务）
├── tech.md # 技术栈（让 AI 生成符合规范的代码）
├── structure.md # 项目结构（让 AI 知道代码放哪里）
└── chinese-language.md # 语言规则（让 AI 用中文回答）包含模式
| 模式 | 说明 | 配置方式 |
|---|---|---|
| 始终包含 | 每次对话都读取（默认） | 无需配置 |
| 条件包含 | 读取特定文件时才包含 | front-matter: inclusion: fileMatch |
| 手动包含 | 用户通过 # 引用时才包含 |
front-matter: inclusion: manual |
示例：product.md
markdown
# 产品概述
## 项目名称
小区超市 - 微信小程序
## 产品描述
社区超市微信小程序，为小区居民提供在线购物服务。
## 核心功能
- 首页：轮播图、商品分类、推荐商品展示
- 购物车：商品添加、数量修改、选择结算
- 个人中心：用户信息、订单管理、收货地址管理
## 目标用户
小区居民4. Spec 文档详解
4.1 requirements.md
markdown
# 需求文档
## 简介
[项目概述：是什么系统 + 基于什么技术 + 给谁用 + 做什么]
## 术语表
- **术语1**: 定义说明
## 需求
### 需求 1：[需求标题]
**用户故事：** 作为[角色]，我希望[功能]，以便[价值]。
#### 验收标准
1. WHEN [条件] THEN [系统] SHALL [行为]
2. THE [系统] SHALL [行为]EARS 验收标准格式：
| 模式 | 格式 | 使用场景 |
|---|---|---|
| 事件驱动 | WHEN [事件] THEN [系统] SHALL [行为] | 用户操作触发 |
| 条件驱动 | IF [条件] THEN [系统] SHALL [行为] | 条件判断 |
| 通用 | THE [系统] SHALL [行为] | 始终成立 |
4.2 design.md
markdown
# 设计文档
## 概述
[技术方案概述]
## 技术栈
- **框架**: Vue 3.4+
- **语言**: TypeScript 5.x
## 架构
[目录结构树 + 说明]
## 数据模型
[TypeScript 接口 或 SQL 建表语句]
## 组件与接口
[核心模块设计 + API 接口列表]
## 正确性属性
### Property 1: [属性名称]
*对于任意* [条件]，[断言]。
**验证: 需求 X.Y**
## 错误处理 / 测试策略
[错误类型 + 处理策略 + 测试方案]正确性属性：系统必须满足的不变量，常见类型：
- 数据一致性：对于任意订单创建，库存应减少相应数量
- 状态流转：对于任意订单，状态只能按 pending→paid→shipping 流转
- 权限验证：对于任意地址操作，只有所属用户才能执行
4.3 tasks.md
markdown
# 实现计划：[模块名称]
## 概述
[实现方案概述]
## 任务
- [ ] 1. [任务组名称]
- [ ] 1.1 [子任务]
- [具体内容]
- _需求: X.Y_
- [ ] N. 检查点 - [阶段名称]
- 确保 xxx
- 如有问题请提出
## 备注
[注意事项]任务组织特点 ：按功能模块分组、大任务下有子任务、通过 _需求: X.Y_ 关联需求、设置阶段性检查点
5. 可直接使用的提示词
以下提示词可以在任何 AI 工具（ChatGPT、Claude 等）中使用，生成与 Kiro Spec 格式一致的文档。
5.1 生成 requirements.md
你是一个专业的需求分析师。请根据我提供的项目描述，生成一份结构化的需求文档。
## 输出格式
严格按照以下 Markdown 格式输出，不要添加任何额外章节：
# 需求文档
## 简介
[用一段话描述：这是什么系统 + 基于什么技术 + 给谁用 + 用来做什么]
## 术语表
- **术语1**: 定义说明
- **术语2**: 定义说明
## 需求
### 需求 1：[需求标题]
**用户故事：** 作为[角色]，我希望[功能]，以便[价值]。
#### 验收标准
1. WHEN [触发条件] THEN [系统名] SHALL [具体行为]
2. WHEN [触发条件] THEN [系统名] SHALL [具体行为]
### 需求 2：[需求标题]
...
## 验收标准编写规则
使用 EARS 模式，只允许以下格式：
- 事件驱动：WHEN [事件/条件] THEN [系统名] SHALL [行为]
- 通用行为：THE [系统名] SHALL [行为]
## 质量要求
1. 每个需求有且仅有一个用户故事
2. 验收标准必须具体、可测试
3. 每条验收标准只描述一个行为
4. 覆盖正常流程和异常流程
5. 术语表中的术语在全文保持一致
---
我的项目描述：
[在这里写你的项目描述]5.2 生成 design.md
你是一个专业的软件架构师。请根据我提供的需求文档，生成一份技术设计文档。
## 输出格式
严格按照以下 Markdown 格式输出：
# 设计文档
## 概述
[一段话描述技术方案]
## 技术栈
- **框架**:
- **语言**:
- **构建工具**:
- **UI 组件库**:
- **状态管理**:
- **路由**:
- **HTTP 客户端**:
## 架构
[目录结构树，每个目录后加注释]
## 数据模型
[TypeScript 接口定义或 SQL 建表语句]
## 组件与接口
[核心模块设计 + API 接口列表]
## 正确性属性
*正确性属性是指在系统所有有效执行中都应保持为真的特性或行为。*
### Property 1: [属性名称]
*对于任意* [条件]，[断言]。
**验证: 需求 X.Y**
## 错误处理
### 错误类型
1. **类型1**: 处理方式
2. **类型2**: 处理方式
## 测试策略
### 单元测试
- 工具：
- 范围：
### 集成测试
- 工具：
- 范围：
---
需求文档内容：
[在这里粘贴 requirements.md 的内容]5.3 生成 tasks.md
你是一个专业的项目经理。请根据我提供的需求文档和设计文档，生成一份可执行的任务清单。
## 输出格式
严格按照以下 Markdown 格式输出：
# 实现计划：[模块名称]
## 概述
[一段话描述实现方案]
## 任务
- [ ] 1. [任务组名称]
- [ ] 1.1 [子任务]
- [具体内容]
- _需求: X.Y_
- [ ] 1.2 [子任务]
- [具体内容]
- _需求: X.Y_
- [ ] 2. [任务组名称]
- [ ] 2.1 [子任务]
- [ ] 2.2 [子任务]
- [ ] N. 检查点 - [阶段名称]
- 确保 xxx
- 确保 xxx
- 如有问题请提出
## 备注
- [注意事项]
## 任务组织规则
1. 按功能模块分组
2. 每个子任务 0.5-2 小时工作量
3. 按依赖顺序排列
4. 关键节点设置检查点
5. 每个任务关联需求编号
---
需求文档：
[粘贴 requirements.md 内容]
设计文档：
[粘贴 design.md 内容]6. 其他功能
6.1 Hooks（自动化钩子）
在特定事件发生时自动触发 AI 执行。
触发时机：发送消息、AI 执行完成、新会话创建、保存代码文件、手动点击按钮
使用场景：保存代码时自动运行测试、更新翻译文件时同步其他语言
配置方式：命令面板搜索 "Open Kiro Hook UI"
6.2 MCP（Model Context Protocol）
连接外部工具和服务的协议。
配置位置：
- 工作区级别：
.kiro/settings/mcp.json - 用户级别：
~/.kiro/settings/mcp.json
配置示例：
json
{
"mcpServers": {
"aws-docs": {
"command": "uvx",
"args": ["awslabs.aws-documentation-mcp-server@latest"],
"disabled": false
}
}
}6.3 上下文引用
在聊天中使用 # 引用特定内容：
| 引用 | 说明 |
|---|---|
#File |
引用特定文件 |
#Folder |
引用特定文件夹 |
#Problems |
当前文件的问题 |
#Terminal |
终端输出 |
#Git Diff |
Git 变更 |
#Codebase |
扫描整个代码库 |
7. 最佳实践
Steering 使用建议
- 项目初期就创建，越早让 AI 理解项目越好
- 保持更新，技术栈或结构变化时同步更新
- 简洁明了，关键信息即可
Spec 使用建议
- 按功能模块创建，每个功能一个 Spec 目录
- 分阶段确认，每个文档生成后仔细审查
- 关联需求编号，保持文档间的追溯性
提示词使用建议
- 项目描述要详细：技术栈、功能列表、用户角色都要写清楚
- 分步骤执行：先生成 requirements，确认后再生成 design
- 迭代优化：如果生成结果不满意，可以追问修改
配合使用
Steering（背景）+ Spec（任务）= 高质量的 AI 辅助开发
Spec 规划大功能 → Vibe 处理小调整