规范驱动的 Vibe Coding：Kiro 实践指南

用 AWS 原生的 Agentic IDE，把 AI 代码生成从"氛围抽卡"变成有工程纪律的协作流程。

为什么 Vibe Coding 需要规范？

Vibe Coding 的局限：prompt → code 的单步模式缺乏全局视野，容易在复杂代码库中迷失。

Kiro 的核心观点：规范是超 prompt——把需求写成结构化文档，而不是塞进聊天上下文。规范是版本控制的、可审查的、可执行的。

Kiro 是什么？

Kiro 是一个 Agentic IDE（agentic 指 AI 驱动、能够自主执行任务的智能开发环境），同时提供 CLI 和 Web 界面，帮助开发者从原型到生产。

核心理念

"把工程纪律带到 Agentic 开发中"

Kiro 不是另一个 AI 编码助手，它是让 AI 在结构化的规范框架下工作的环境。

三种界面

界面 说明
Kiro IDE 桌面应用（基于 CodeOSS/VS Code），支持 Open VSX 扩展
Kiro CLI 终端开发体验，支持远程 SSH
Kiro Web 浏览器 AI Agent（需要 Pro+ 订阅）

核心特性

  • 规范驱动：Prompt → Spec → Design → Tasks → Implementation
  • EARS notation：结构化的需求描述方式
  • Hooks：事件驱动的后台自动化
  • Steering：持久化的项目上下文
  • Autonomous Agent：跨会话持续工作，监听 GitHub Issues
  • MCP 支持：连接外部工具和数据源

Kiro vs OpenSpec vs Spec-Kit vs BMad

维度 Kiro OpenSpec Spec-Kit BMad
出品方 AWS Fission AI GitHub 社区
形态 Agentic IDE 轻量 CLI CLI + 模板 Agent 团队
工作流 Spec（三阶段）→ Tasks → Implement propose → apply Constitution → Specify → Plan → Tasks → Implement PM → 架构师 → Dev
需求格式 EARS notation Given/When/Then 自由格式 User Story
自动化 Hooks（事件触发） 无 无 无
Autonomous Agent ✅ ❌ ❌ ❌
多 Agent 单一 Agent 无 无 12+ Agent
适用场景 复杂代码库，单人/团队 Brownfield 项目 中等复杂度 复杂产品

核心概念

1. Spec（规范）

Spec 是 Kiro 的核心概念——把高层想法转化为可执行实现计划的结构化工件。

想法 → Spec（requirements.md）→ Design（design.md）→ Tasks（tasks.md）→ 实现

三阶段工作流

阶段 产出 说明
Requirements requirements.md 用户故事 + EARS 验收标准
Design design.md 技术架构、时序图、数据流
Tasks tasks.md 有序、可执行的任务列表

EARS Notation

Kiro 使用 EARS 格式描述需求，让意图明确无歧义：

常规格式：系统应该做什么
事件格式：當事件发生时，系统应该响应
状态格式：當状态为X时，系统应该做Y

示例（用户登录）：

## Requirement: 用户登录

### 场景：有效凭证登录
- **GIVEN** 用户拥有有效账户
- **WHEN** 用户提交 email 和 password
- **THEN** 系统返回 JWT token
- **AND** 重定向到 dashboard

2. Feature Spec vs Bugfix Spec

类型 用途
Feature Spec 构建新功能
Bugfix Spec 诊断修复 Bug，防止回归

3. Steering（方向引导）

Steering 文件是 Markdown 格式的持久化上下文，替代在每次对话中重复解释项目规范。

内置 Steering 模板

文件 用途
product.md 业务背景和需求
tech.md 技术栈和模式
structure.md 代码库架构
api-standards.md REST 规范、错误格式
testing-standards.md 测试策略
code-conventions.md 命名规范、文件组织
security-guidelines.md 安全实践

Steering 优先级

项目级 .kiro/steering/  > 全局 ~/.kiro/

示例：api-standards.md

## Endpoint 命名规范
- 使用 kebab-case：`/user-profiles`，不是 `/userProfiles`
- 资源名词复数：`/users`，不是 `/user`

## 错误响应格式
{
  "error": {
    "code": "RESOURCE_NOT_FOUND",
    "message": "User with id 123 not found"
  }
}

4. Hooks（钩子）

Hooks 是事件驱动的自动化——当特定事件发生时，AI Agent 自动执行预定义动作。

事件类型 触发条件
File events 创建、保存、删除
Prompt/Agent lifecycle 提交 prompt、Agent 停止
Spec task 任务执行前/后
Manual 手动触发

示例场景：

  • 保存 React 组件时 → 自动生成对应测试文件
  • 创建新组件文件时 → 添加文档骨架
  • 删除文件时 → 更新 import 引用

5. Autonomous Agent（自主 Agent）

Kiro 的 Web 版本包含一个自主 Agent，能力：

  • 跨会话保持上下文
  • 从每次交互中学习
  • 同时在多个代码库工作
  • 协调变更，提交多个 PR
  • 监听 GitHub Issues（通过 /kiro 或 kiro 标签）

6. Powers（能力扩展）

按需加载的专业上下文和工具，扩展 Agent 能力：

  • 领域特定知识
  • 自定义集成

7. MCP（Model Context Protocol）

连接外部工具和数据源：

  • 数据库
  • API
  • 专业搜索工具

工作流详解

Feature Spec 完整流程

1. 创建 Spec
   - Kiro Pane → Spec 按钮 → 描述功能
   - 或聊天中输入 "I need a spec for [feature]"

2. Requirements 阶段
   - Kiro 分析代码库现有结构
   - 生成用户故事 + 验收标准
   - 你审查 → "LGTM" 或反馈修改

3. Design 阶段
   - Kiro 比较需求与现有代码
   - 生成技术架构、时序图、接口设计
   - 你审查 → "LGTM" 或反馈修改

4. Tasks 阶段
   - Kiro 基于需求和设计生成任务列表
   - 任务有依赖顺序，可单独或批量执行

5. 实现
   - 点击 "Start Task" 执行单个任务
   - Kiro 在后台运行，实时更新状态

Bugfix Spec 流程

1. 描述 Bug → Kiro 分析
2. 识别根因（current/expected/unchanged）
3. 设计修复方案
4. 生成任务 → 执行
5. 验证无回归

Quick Plan（快速路径）

对已有清晰理解的功能，不需要逐阶段审批：

1. 输入功能描述
2. Kiro 一次性生成 requirements.md + design.md + tasks.md
3. 立即开始执行

完整示例：构建用户认证

Step 1: 初始化 Steering

在 Kiro 中运行：

Generate Steering Docs

Kiro 自动生成：

  • structure.md：代码库结构
  • tech.md：技术栈和模式
  • product.md：业务背景

Step 2: 创建 Spec

在 Kiro Pane 中点击 + → Spec，或输入：

I need a spec for user authentication with login, logout, and password reset

Step 3: 审查 Requirements

Kiro 生成：

# requirements.md

## User Stories

### Story: 用户注册
- **Actor**: 新用户
- **Want**: 通过邮箱注册账户
- **Reason**: 成为系统用户

#### Acceptance Criteria
- **GIVEN** 邮箱未被占用
- **WHEN** 提交有效注册信息（email, password, username）
- **THEN** 创建账户
- **AND** 返回 JWT token
- **AND** 用户被自动登录

### Story: 用户登录
...

### Story: 密码重置
...

Step 4: 审查 Design

# design.md

## 技术选型
- 后端：Node.js + Express
- 数据库：PostgreSQL
- 认证：JWT（jsonwebtoken）
- 验证：Zod

## 目录结构
```
src/
├── routes/auth.ts      # 认证路由
├── middleware/auth.ts  # JWT 中间件
├── models/user.ts      # 用户模型
└── db/index.ts         # 数据库
```

## API 设计

| 方法 | 路径 | 描述 |
|------|------|------|
| POST | /auth/register | 用户注册 |
| POST | /auth/login | 用户登录 |
| POST | /auth/logout | 用户登出 |
| POST | /auth/reset-password | 密码重置 |

## 数据模型
```typescript
interface User {
  id: string;
  email: string;
  username: string;
  passwordHash: string;
  createdAt: Date;
}
```

Step 5: 审查 Tasks

# tasks.md

## Task 1: 项目初始化
- [ ] 安装依赖（express, pg, jsonwebtoken, zod）
- [ ] 配置 TypeScript
- [ ] 创建目录结构

## Task 2: 数据库层
- [ ] 创建 `src/db/index.ts`
- [ ] 实现 users 表迁移
- [ ] 创建 User 模型

## Task 3: 认证路由
- [ ] 实现 POST /auth/register
- [ ] 实现 POST /auth/login
- [ ] 实现 POST /auth/logout
- [ ] 实现 POST /auth/reset-password

## Task 4: 中间件
- [ ] 实现 JWT 验证中间件

## Task 5: 测试
- [ ] 单元测试：User 模型
- [ ] 集成测试：认证 API

Step 6: 执行 Tasks

点击每个 Task 的 "Start Task"，Kiro 执行并更新状态。

CLI 使用

# 安装 CLI
curl -fsSL https://cli.kiro.dev/install | bash

# 使用
kiro --print "Look at the latest CI failure, find root cause, and fix it"

# Git 集成示例
git checkout -b fix/deploy-issue
kiro --print "Fix the deploy step failure"
git add -A && git commit -m "fix: resolve deploy step failure"
gh pr create --title "fix: resolve deploy issue"

何时用 Kiro？

场景 推荐度
复杂代码库，跨多文件功能 ⭐⭐⭐⭐⭐
需要持久化项目规范 ⭐⭐⭐⭐⭐
事件驱动的自动化任务 ⭐⭐⭐⭐⭐
快速原型验证 ⭐⭐⭐
团队多角色协作 ⭐⭐（用 BMad）
极简流程，Brownfield 增量 ⭐⭐（用 OpenSpec）

参考资源