Kiro 规范驱动开发：Specs、Steering、Hooks 与 MCP 完整教程¶

最后核验：2026-07-24

适用范围：Kiro IDE 当前稳定版；部分功能也可在 Kiro CLI / Web 中复用

预计用时：15～30 分钟

← 返回教程目录

1. Kiro 与普通 AI 编辑器有什么不同¶

Kiro 是一款 Agentic IDE，核心能力包括 Specs、Steering、Hooks、Agentic Chat 和 MCP。它最有代表性的工作方式不是“直接让 AI 改代码”，而是先生成可审查的需求、设计与任务，再按任务实施。

适合：

中大型功能，需要先明确验收标准；
需求容易变化，希望设计和任务同步更新；
团队需要把 AI 的实现依据保存在仓库中；
想用 Hooks 自动执行重复检查；
需要通过 Steering 固化项目约定。

很小的改动不必强行使用完整 Spec。改一个文案、调整一行配置时，普通 Chat 更直接。

2. 安装与首次启动¶

打开 Kiro 下载页；
选择 Windows、macOS 或 Linux 版本；
使用官方安装包完成安装；
登录后打开一个测试仓库；
确认 Kiro 面板中能看到 Chat、Specs、Steering、Hooks 等入口。

第一次不要直接打开包含生产密钥或客户数据的仓库。先用临时项目熟悉审批、文件编辑和终端行为。

3. 第一个 Feature Spec¶

在 Specs 面板创建 Feature Spec，输入清晰需求，例如：

为现有博客增加评论功能。

要求：
- 登录用户可以发表评论和回复；
- 作者可以删除自己发布的评论；
- 每篇文章显示评论数量；
- 后端必须校验权限；
- 补充单元测试和接口测试；
- 不修改现有登录流程。

Kiro 的标准产物保存在：

.kiro/specs/功能名称/
├── requirements.md
├── design.md
└── tasks.md

三个文件分别解决“做什么”“怎么做”“按什么顺序做”。它们可以直接编辑，Kiro 会在后续阶段参考你的修改。

4. 审核 requirements.md¶

需求阶段重点看：

用户角色是否完整；
正常流程和异常流程是否都写到；
权限、数据边界和不可变行为是否明确；
验收标准能否测试；
是否混入了尚未确认的技术方案。

不要只看文字是否流畅。建议逐条追问：

分析当前 requirements.md 中的歧义、遗漏和冲突。
重点检查权限、并发、删除行为和兼容性。
先提问题，不要进入设计阶段。

复杂功能可以使用 Kiro 的 Requirements Analysis，让它跨需求寻找冲突。分析结果仍需人工判断。

5. 审核 design.md¶

设计阶段至少核对：

数据模型和迁移策略；
API 输入、输出和错误状态；
权限校验位置；
前端组件和状态流；
与现有模块的边界；
测试方案；
失败与回滚方式。

如果设计引入了仓库中不存在的框架，或绕开现有服务层，应在执行前修改。不要等代码生成后再推翻架构。

可以这样要求：

根据当前代码结构复核 design.md：
1. 优先复用现有模块；
2. 不新增无必要依赖；
3. 标出数据库、鉴权和兼容性风险；
4. 每条需求必须能映射到设计组件。

6. 拆分 tasks.md¶

好的任务应该：

一项只完成一个可验证结果；
明确修改哪些区域；
包含测试或验证步骤；
依赖顺序清楚；
失败后容易回退；
不把“完成整个功能”塞进一个任务。

任务过大时，让 Kiro继续拆分：

把任务 3 拆成数据库、服务层、接口、前端和测试五个可独立验证的步骤。
每一步写明完成标准，不要执行。

执行时优先逐项运行，而不是第一次就 Run all Tasks。每个任务完成后检查 git diff、测试结果和实际行为。

7. Steering：给项目提供长期规则¶

Steering 文件位于：

.kiro/steering/

适合记录：

技术栈和版本；
目录结构；
测试命令；
代码风格；
安全要求；
禁止事项；
领域术语。

示例：

# 项目开发约定

- 使用 pnpm，不运行 npm install。
- 所有 API 输入必须在入口校验。
- 修改业务逻辑时补充对应测试。
- 不提交 .env、Token、证书或生产数据。
- 数据库迁移必须可回滚。
- 完成后运行 pnpm test 和 pnpm build。

规则要具体、短小、可执行。长篇 API 手册不适合每次都加载，可放在普通文档中按需引用。

8. Hooks：自动触发重复任务¶

Kiro IDE 的 Agent Hooks 可在文件事件或手动触发时运行 AI 任务。入口位于 Kiro 面板的 Agent Hooks。

常见用途：

保存测试文件后检查遗漏场景；
修改 API 文件后提醒更新文档；
手动触发代码审查；
新建组件时生成基础测试；
对指定文件类型执行格式或规范检查。

创建 Hook 时应限制文件范围和任务权限。不要设置“每次保存任何文件都扫描整个仓库”，这会增加延迟和消耗。

推荐先建一个手动 Hook：

审查当前 Git diff，只报告安全、正确性和测试缺口。
不要修改文件，不要执行写入命令。

验证输出可靠后，再考虑自动触发。

9. MCP 连接外部工具¶

MCP 可以让 Kiro 访问外部数据和工具，但同时扩大权限边界。配置前先回答：

它能读取什么；
它能写入什么；
是否能访问网络或数据库；
凭据存在哪里；
哪些动作需要人工确认。

首次只连接只读、低风险 MCP。数据库、文件系统、云资源和消息发送类 MCP 应使用最小权限账号，并保留审批。

完整安全方法可参考 MCP 入门与安全配置。

10. 模型与自定义 API 的边界¶

Kiro 官方当前文档明确介绍的是内置模型、Specs、Steering、Hooks 和 MCP，没有提供一个稳定、通用、可填写任意 OpenAI-compatible Base URL 的官方流程。

因此：

不把社区实验入口写成官方能力；
不通过网络劫持或证书替换强行改端点；
不提取网页登录令牌；
模型可用性和额度以 Kiro 当前模型选择器、账户页和官方文档为准。

如果核心需求是连接自定义 API，可选择本仓库中明确支持该能力的 Cline、Continue、TRAE 或 Zed。

11. 完整验收流程¶

建议在临时分支完成：

创建一个小型 Feature Spec；
人工修改一条需求；
确认设计同步反映需求；
把任务拆成可独立验证步骤；
只执行第一个任务；
检查 git diff；
运行相关测试；
手动触发只读 Review Hook；
确认没有读取或修改范围外文件；
不满意时回到 Spec 修订，而不是用更多提示词掩盖设计问题。

12. 常见问题¶

现象	处理
Spec 过于空泛	补充角色、约束、不可变行为和可测试验收标准
design.md 脱离项目结构	要求先分析现有模块，再按现有边界重写设计
tasks.md 一项太大	拆成数据、后端、前端、测试和验证步骤
Hook 频繁触发	缩小文件 pattern，或改为手动触发
Hook 修改了不该改的文件	先停用 Hook，收紧指令、范围和审批
Steering 不生效	检查文件位置、内容是否冲突，并新建会话验证
找不到自定义 Base URL	当前官方流程未承诺通用端点，不使用非官方绕过方案
MCP 权限过大	换只读凭据、限制目录和工具，保留人工确认