一句话总结

亚马逊出了个 AI IDE 叫 Kiro，和 Cursor、Claude Code 最大的区别是：它让你先写需求文档，再让 AI 写代码。我花了一个周末把它装上，跑了两个项目，说说真实感受。

Kiro 是个什么东西

Kiro 是亚马逊今年推的 AI IDE，底层是 VS Code 改的（和 Cursor、Windsurf 一样）。它有两种模式：

• Vibe 模式：和 Cursor 差不多，对话式写代码
• Spec 模式：Kiro 独有的，先把需求拆成用户故事和技术设计，再一步步生成代码

Spec 模式是 Kiro 的卖点。官方管这叫"Spec-Driven Development"——用规格文档驱动开发。说白了就是先做产品经理的活，再做程序员的活。

目前 Kiro 免费用，底层跑的是 Claude Sonnet 4.5 和 Opus 4 模型。亚马逊累计往 Anthropic 投了 80 亿美元，所以用 Claude 不心疼。

安装过程（5 分钟搞定）

去 kiro.dev/downloads 下载安装包，macOS、Linux、Windows 都有。

安装完打开，界面和 VS Code 几乎一样。登录支持 Google 和 GitHub 账号。

第一次打开会问你要不要导入 VS Code 的配置和插件。我原来 VS Code 里装了 RooCode 和 AMP，都能直接导过来。Augment 导不进来，得手动装 VSIX。

# 也可以用命令行安装
curl -fsSL https://cli.kiro.dev/install | bash

装完之后终端里也能用 kiro 命令，功能和 Claude Code 类似——在终端里跟 AI 对话写代码。

Spec 模式实战：做一个待办事项 API

我拿一个简单的待办事项 API 来试 Spec 模式。

第一步：输入需求

在 Kiro 里新建一个 Spec，输入需求描述：

做一个待办事项 REST API，用 Node.js + Express。
功能：增删改查待办事项，每个待办有标题、描述、状态（未完成/已完成）、创建时间。
用 SQLite 存数据。

就这么几行，够模糊的。

第二步：Kiro 生成需求文档

点了"Generate Requirements"之后，Kiro 在 .kiro/specs/ 目录下生成了一个 requirements.md。它把我的三行描述拆成了 4 个用户故事，每个故事都带验收标准。比如：

### 需求 1
**用户故事：** 作为用户，我想创建待办事项，记录我需要完成的任务。

#### 验收标准
1. POST /api/todos 接收 title 和 description 字段
2. title 为空时返回 400 错误
3. 创建成功返回 201 和新建的待办对象
4. status 默认值为 "pending"
5. created_at 自动填充当前时间

比我自己写的需求文档靠谱多了。它补了很多我没想到的边界条件——比如标题为空怎么办、批量删除需不需要确认。

第三步：生成技术设计

点"Generate Design"，Kiro 又生成了一份 design.md，里面有：

• 技术栈选择（Express + Prisma + SQLite）
• 数据库表结构
• API 接口定义（请求格式、响应格式、状态码）
• 一张 Mermaid 架构图

CREATE TABLE todos (
  id TEXT PRIMARY KEY,
  title TEXT NOT NULL,
  description TEXT,
  status TEXT DEFAULT 'pending' CHECK(status IN ('pending', 'completed')),
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
  updated_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

这一步我改了一个地方：它默认用 UUID 做主键，我改成了自增 ID。在 Kiro 里直接编辑 design.md 就行，下一步生成代码时会按修改后的设计来。

第四步：生成任务列表并执行

最后一步，Kiro 生成了一个 tasks.md，列出了 8 个开发任务，每个任务带具体的实现步骤。然后可以让 Kiro 一个一个执行这些任务。

我选了"全部执行"。大概 3 分钟跑完，生成了完整的项目代码：

├── prisma/
│   └── schema.prisma
├── src/
│   ├── index.ts
│   ├── routes/
│   │   └── todos.ts
│   ├── controllers/
│   │   └── todoController.ts
│   ├── services/
│   │   └── todoService.ts
│   └── middleware/
│       └── validation.ts
├── tests/
│   └── todos.test.ts
├── package.json
└── tsconfig.json

代码质量比我预期的好。分层清楚，controller 不直接操作数据库，service 层做业务逻辑，validation 中间件单独抽出来。测试文件也生成了，覆盖了主要的增删改查场景。

跑了一下 npm test，8 个测试用例全过。npm run dev 启动服务，用 curl 试了几个接口，都正常。

和 Cursor、Claude Code 对比

用了两天之后，我的感受是这样的：

Kiro Spec 模式适合什么场景：

从零开始做一个新项目的时候，Spec 模式很有用。它帮你把需求理清楚了再动手，生成的代码结构比较规范。特别是做 CRUD 类的后端服务，Spec 模式一步到位。

Kiro 不如 Cursor 的地方：

改已有代码的时候，Spec 模式太重了。我想改一个函数的逻辑，不需要先写需求文档。这时候 Vibe 模式更合适，但 Vibe 模式和 Cursor 差别不大，而 Cursor 的上下文管理更成熟。

Kiro 不如 Claude Code 的地方：

终端体验。Kiro CLI 也能在终端里用，但指令集和交互体验和 Claude Code 比还有差距。Claude Code 的 SubAgent、Hooks 系统更灵活。

真正的区别在思路上：

Cursor 和 Claude Code 的思路是"你告诉我做什么，我直接做"。Kiro 的思路是"你告诉我做什么，我先帮你想清楚要做什么，然后再做"。前者效率高，后者质量稳。

Hooks：保存文件自动跑任务

Kiro 还有个 Hooks 功能——你可以设置触发规则，比如"每次保存 .ts 文件时，自动更新对应的测试文件"。

配置方法是在 .kiro/hooks/ 目录下创建一个 hook 文件：

# 自动更新测试

## 触发条件
当 `src/` 目录下的 TypeScript 文件被保存时触发

## 执行动作
检查对应的测试文件是否需要更新，如果源文件有新增的函数或修改了函数签名，自动更新测试用例

用 Markdown 写 hook 规则，这个设计挺有意思的。实测下来，简单的场景能用，比如自动补测试、自动更新 README。复杂场景还是会出错，比如我改了一个函数的返回值类型，它更新测试的时候把原来好的断言也改了。

几个踩坑记录

1. 插件兼容性：Kiro 基于 Code OSS，大部分 VS Code 插件能用，但有些依赖 VS Code 私有 API 的插件装不上。我常用的 GitLens 能用，Augment 暂时不行。

2. Spec 文件别删：.kiro/specs/ 目录下的文件是 Kiro 的上下文来源。我有一次不小心删了 design.md，后面让 Kiro 改代码时它找不到设计文档，生成的代码和之前的风格不一致。

3. 模型切换：Kiro 支持 Claude Sonnet 4.5 和 Auto 模式（混合多个模型）。我测下来 Sonnet 4.5 生成代码更稳定，Auto 模式偶尔会在设计阶段和编码阶段用不同的模型，导致前后不一致。

4. 中文支持：需求文档用中文写没问题，生成的代码注释也是中文的。但有时候中英文混排的需求会让它搞混。比如我写"用 Express 框架"，它偶尔会理解成用 Express 的中文文档去写。

我的建议

如果你满足这些条件，可以试试 Kiro：

• 经常从零开始新建项目
• 项目是后端 API 或全栈应用
• 团队里有人不写代码但需要参与需求定义

如果你主要做以下事情，继续用 Cursor 或 Claude Code：

• 在现有大型代码库上改代码
• 需要终端里灵活操作
• 项目类型多样（不只是 Web 开发）

Kiro 现在免费，装一个试试不亏。等它收费了再决定要不要长期用。

安装地址：kiro.dev/downloads 文档地址：kiro.dev/docs

humanizer-zh 五维评分：