📚 本系列目录：《Vibe Coding 深度系列》 当前第 4/4 篇 · 上一篇：从"AI 糊弄美学"到生产级交付：Vibe Coding 质量跃升的完整方法论

📚 系列导航

《Vibe Coding 深度系列》共 4 篇，本篇是第 4 篇。

← 上一篇：从"AI 糊弄美学"到生产级交付：Vibe Coding 质量跃升的完整方法论

Kiro 开发指南：用 Spec-Driven 范式把 Vibe Coding 变成"商业级交付"

一份面向中高级开发者的 Kiro IDE 实战手册。结合上一篇《从"AI 糊弄美学"到生产级交付：Vibe Coding 质量跃升的完整方法论》的理念，本文聚焦于 AWS Kiro 这个把 spec-driven 范式产品化的 AI IDE——它如何用 Specs / Steering / Hooks / Agent Skills / MCP 五大支柱，把"凭感觉写代码"的 vibe coding 升级为"按规交付"的工程流程。

写在前面：为什么是 Kiro？

如果你已经读过上一篇 vibe coding 方法论，应该记得一个核心判断：AI 不是缺能力，是缺"判断标准"和"持久化规则"。要让 AI 从"交作业"切换到"商业级交付"，关键在于把人类工程经验结构化成 AI 可执行的规则。

这件事在 Claude Code、Cursor、Cline 里需要你自己维护 CLAUDE.md、.cursorrules、.claude/rules/。配置门槛高、规则散落各处、团队共享靠 git commit。

Kiro 是 AWS 在 2025 年发布的 agentic IDE——它的产品哲学就是：把"spec-driven 开发"这件事做到开箱即用。Specs 用来从需求生成结构化设计文档，Steering 用来持久化团队规范，Hooks 用来在文件事件触发自动化，Agent Skills 用来把社区最佳实践打包成 slash command，MCP 用来连接外部工具和数据源。

本文按笔记原始骨架展开：Vibe Coding 是什么 → 核心技术实现原理 → 如何更好的使用 → 资源参考与推荐 → 常见问题处理技巧。每一节都结合 Kiro 的实际特性给出可落地的玩法。

一、Vibe Coding 是什么

1.1 起源与定义

"Vibe Coding"（凭感觉编程）一词由 Andrej Karpathy（特斯拉前 AI 总监、OpenAI 创始成员）在 2025 年初提出，原话是：

"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."

它的核心含义是：你用自然语言描述意图，让 AI 接管实现细节，自己不再逐行审查代码。这种模式特别适合：

• 快速验证产品想法（MVP / prototype）
• 写一次性脚本、爬虫、自动化任务
• 探索陌生技术栈时让 AI 趟路
• 重复劳动（CRUD 模板、测试用例、文档生成）

1.2 Vibe Coding 的三大流派

1.3 Vibe Coding 的"原罪"：凭感觉 ≠ 不需要工程纪律

很多人误以为 vibe coding 就是"放弃工程标准、纯靠 AI 蒙"。这是对 Karpathy 原话的曲解。Karpathy 强调的是 "forget that the code even exists"——这针对的是实现层的细节接管，不是对架构层、需求层、验证层的放弃。

正确的 vibe coding 姿势：人负责"我要什么 / 怎么验收 / 怎么对齐业务目标"；AI 负责"具体怎么写 / 怎么调用 API / 怎么选库"。

这正是 Kiro 的 Specs 功能要解决的核心问题——让你跟 AI 的对话从"凭感觉"变成"按规对齐"。

二、Vibe Coding 核心技术实现原理

现代 AI IDE（包括 Kiro）背后是多层架构协同的结果。本节结合 Kiro 的官方文档，拆解五层核心技术。

2.1 架构总览

2.2 第一层：LLM 与 Agentic Loop

所有 AI IDE 的底层都是 LLM。区别在于怎么调度 LLM。现代 agentic IDE（包括 Kiro）用的是一个循环执行结构：

Kiro 在 2.1 版本的 CLI 进一步优化了这一点——Real-Time Shell Streaming 让 build、test 这类长命令能边跑边显示结果（不需要等进程结束才返回），避免 agent 在等结果时陷入"以为命令没跑"的空转。

2.3 第二层：Specs（Kiro 独家——spec-driven 工作流）

Specs = 把"凭感觉的需求"变成"结构化的工程文档"。Kiro 的 Specs 会自动生成三个文件：

为什么 Specs 是 Kiro 的杀手锏？ 它把上一篇 vibe coding 文章里反复强调的"先理解、再动手；边界优先于功能"产品化了。design.md 强制 AI 画时序图、写错误处理；tasks.md 强制 AI 拆任务，每步可独立 review。

2.4 第三层：Steering（持久化规则引擎）

Steering = Kiro 的 CLAUDE.md，但更结构化。文件放在 .kiro/steering/（项目级）或 ~/.kiro/steering/（全局级），Markdown 格式。

Foundational 基础三文件（Kiro 可一键生成）：

• product.md：产品目的、目标用户、关键功能、业务目标 → 帮 AI 理解"为什么这么做"
• tech.md：技术栈、关键库、构建工具 → 帮 AI 选择"用什么实现"
• structure.md：项目目录结构、模块划分、命名约定 → 帮 AI 把代码"放对地方"

这跟上一篇讲的 CLAUDE.md 哲学完全一致——只写 AI 猜不到的（你的决策/你的禁忌/你的命令），不写通用知识。

2.5 第四层：Hooks（事件驱动的自动化）

Hooks = Kiro 的"git hooks + ESLint 自动化"，但触发器是 AI 工作流中的事件：

实战价值：把"AI 写完代码 → 自动跑 typecheck / lint / test"做成 hook，AI 就能在交付前自我验证，不需要你每次手动催。

2.6 第五层：Agent Skills & MCP（社区能力扩展）

2.6.1 Agent Skills

Kiro 支持两种 skill 格式：

Skill 本身就是一个结构化的 SKILL.md 文件——包含触发条件、输入参数、执行步骤、验证方式。kiro/skill-name 这种 slash command 形式直接调用。

2.6.2 MCP（Model Context Protocol）

MCP = AI 跟外部世界对话的标准协议。通过 MCP，Kiro 能调用：

• 文件系统：读写代码
• 数据库：直接查 SQL
• API 服务：GitHub / Jira / Slack
• 自定义工具：内部 API、内网服务

Kiro 2.1 CLI 的 Tool Search 优化：传统做法是一次性把全部 tool 定义塞进 context，Kiro 2.1 改为按需搜索——kiro-cli settings toolSearch.enabled true。效果：context 不再被无用 tool 定义撑爆，长任务也能稳定运行。

2.7 五大支柱如何协同

核心哲学：Steering 负责"按什么规"，Specs 负责"做之前想清楚"，Agent Skills 负责"重复套路打包"，MCP 负责"能做什么"，Hooks 负责"完成后自动验证"。

三、如何更好的使用 Kiro

把 Kiro 用到"商业级交付"水平，需要把上一篇 vibe coding 方法论 + Kiro 五大支柱结合起来。下面是一套经过验证的工作流。

3.1 项目初始化：5 步搭好地基

# 1. 在项目根目录初始化 Kiro
kiro init

# 2. 一键生成三个 foundational steering 文件
# Kiro 面板 → Steering → "Generate Steering Docs"
# 会创建 product.md / tech.md / structure.md

# 3. 根据上一篇方法论的 Engineering Charter，编写 .kiro/steering/engineering-charter.md
# 覆盖"别交作业"硬规则

# 4. 配置 hooks：保存代码自动验证
cat > .kiro/hooks/on-save-ts.json << 'EOF'
{
  "trigger": "onFileSave",
  "glob": "**/*.{ts,tsx}",
  "command": "pnpm typecheck"
}
EOF

# 5. 装上你需要的 agent skills（详见第四节）
kiro skill add frontend-design
kiro skill add superpowers

3.2 需求阶段：用 Specs 强制"先想清楚"

/kiro spec "添加用户登录功能，支持邮箱+密码登录，
            失败重试 3 次，记录登录日志，30 天免登录"

Kiro 会自动：

1. 生成 requirements.md（拆 user stories、写 acceptance criteria）
2. 生成 design.md（画时序图、列错误处理）
3. 生成 tasks.md（拆成 8-15 个可追踪任务）
4. 暂停等你 review——你可以指出哪条 acceptance criteria 不对、哪个 edge case 没考虑到

关键反模式：跳过 review 直接点"全部执行"。这是 vibe coding 最常见的"翻车点"——AI 误解了你没明说的边界，生成的代码全跑偏。

3.3 实现阶段：分层规则 + 实时验证

3.4 Steering 的精细化配置（踩坑驱动法）

第一条原则：跟上一篇一样，别一次性写满 500 行。Kiro 的 ~/.kiro/steering/ 也一样，30-50 条关键规则 + 路径限定的子文件最稳。

第二条原则：踩坑驱动。

# .kiro/steering/engineering-charter.md（项目级核心宪章）

## 0. 默认心态
你是一个谨慎的高级工程师：**正确性、可观测性、可回滚性** 优先于"看起来做完了"。
遇到模糊指令：先列假设 → 列风险 → 问问题；**禁止用合理猜测代替确认**。

## 1. 动手之前的"必须项"
对任何涉及 API/数据/write/auth/钱的改动，动手前简短输出：
1) 影响范围
2) 边界 & 失败模式清单
3) 需要我确认的决策点（最多 3 个）

## 2. 禁止项
- ❌ 空 catch / `except Exception pass`
- ❌ 硬编码 secret、host、token
- ❌ 把 mock 数据留在 production path
- ❌ 自行引入新依赖/新 infra 改动

## 3. 边界 & 容错底线
- 校验：类型、范围、长度、格式、鉴权、幂等键
- 失败：timeout / retry / 降级形态
- 一致性：事务、partial success、rollback
- 用户侧：错误文案不泄露实现细节

## 4. 日志 & 可诊断性
- 结构化日志：what / params（脱敏）/ result / duration / requestId
- 不用 console.log；log 级别用对

## 5. 改动纪律
- 优先"最小 diff"
- DB schema 改动先写 migration
- 跑得通 ≠ 完成，能解释 happy/sad/edge 怎么验证

3.5 Hooks 的实战配方

关键心法：Hooks 是"AI 写完后自动验证"的最后一公里——你不用每次说"跑一下测试"，Kiro 自己会跑。

3.6 进阶玩法：MCP 让 Kiro 拥有"超能力"

Kiro 的 Powers 页面预置了常用 MCP，但你可以加任何自定义 MCP。

// ~/.kiro/mcp.json
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "<your-pat>" }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": { "DATABASE_URL": "postgresql://..." }
    }
  }
}

Kiro 2.1 优化：默认 toolSearch.enabled = true——MCP 工具按需搜索，不会一次塞满 context。长任务 / 多 MCP 环境特别有用。

3.7 Specs + Steering + Hooks 协同的"理想一日"

这就是"商业级交付"的真实节奏：你只关心"边界对不对 / 验收过不过"，AI 处理"怎么写 / 怎么调"，机器处理"测了没 / 跑得过"。

四、资源参考与推荐

4.1 界面 / 风格 / 设计类 Skills

这是 vibe coding 方法论里反复强调的"Design Skill 立竿见影"在 Kiro 上的具体落地。

实战建议：前端项目三个都装——frontend-design 管"避坑"、web-design-guidelines 管"框架习惯"、design-md 管"组件设计"。

4.2 功能 / 辅助 / 增强类 Skills

4.2.1 SuperPowers（强烈推荐）

github.com/obra/superpowers 是社区最活跃的 agent skills 集合，本质是"AI 写代码的最佳实践 SOP 库"。

SuperPowers 提供的核心能力：

• TDD 强制：要求 AI 先写测试，再写实现
• Code review checklist：自动跑 review 流程
• Plan mode：复杂任务强制先出方案
• Task management：自动拆任务、跟踪进度

这跟上一篇 vibe coding 文章讲的"3 层 skill 组合"完全对应——SuperPowers 把它们打包成即用工具集。

4.2.2 其他值得装的功能类 Skills

4.3 MCP（Model Context Protocol）

MCP 是 Kiro 连接外部世界的方式，预置推荐：

安装方式：

kiro mcp add github
kiro mcp add postgres --env DATABASE_URL=...

4.4 推荐阅读

五、常见问题处理技巧

本节对应笔记中"常见问题处理技巧"原章节（原笔记只有两张 CLI 2.1 截图，这里把内容补全）。

5.1 Kiro CLI 2.1 的三大性能优化

笔记截图中提到的 CLI 2.1 "保持流畅的交互体验" 来自三处实际改进。这是 Kiro 在 2026 年的关键更新点：

5.1.1 Real-Time Shell Streaming（实时 shell 流）

实际效果：pnpm build、pnpm test 这种动辄几十秒的命令，AI 不再"干等"，一边看日志一边规划下一步。长任务无感、agent 不再误判"命令挂了"。

5.1.2 Tool Search（工具按需搜索）

问题：装 5-6 个 MCP 后，每个 MCP 自带几十个 tool，一次会话光 tool 定义就占几万 token——context 爆炸，模型注意力稀释。

解决：kiro-cli settings toolSearch.enabled true → MCP tool 按需搜索，不常用的不注入 context。

5.1.3 Skills as Slash Commands

新机制：/kiro skill-name 直接调用本地 skill，复用一个 session 不丢失上下文。

实际价值：复杂任务中途想用 skill 验证某一步，不用开新对话。

5.2 五个最常见问题的处理技巧

Q1：AI 写出来的代码跟 specs 里定义的不一致

症状：specs 里 acceptance criteria 明确要求"30 天免登录"，AI 写成了 7 天。

解法：

1. 把 acceptance criteria 当断言：在 tasks.md 每个任务后加上"满足 #AC-3（30 天免登录）"
2. 配置 hook 自动验证：onAgentStop → 跑测试 → 跑 lint
3. 用 Specs 的"Correctness" 章节：Kiro 允许你单独跑一轮"检查代码是否符合 specs"的验证

Q2：Hook 跑得太多拖慢开发

症状：每保存一个文件就触发 pnpm test 全量跑，慢到无法工作。

解法：

1. 缩小 glob 范围：从 **/* 改成 **/src/**/*.{ts,tsx}
2. 用 --findRelatedTests 而不是全量跑：pnpm test --findRelatedTests <changed-file>
3. 改用 onAgentStop：AI 完成任务才跑全量测试，过程中只跑 typecheck

Q3：MCP 装上后 context 暴涨

症状：装 3 个 MCP 后，agent 变得迟钝、回答质量下降。

解法：

1. kiro-cli settings toolSearch.enabled true
2. 拆分 MCP 到不同 session：开发用 GitHub MCP，部署用 Docker MCP
3. 用 kiro mcp disable <name> 临时关闭不用的 MCP

Q4：Steering 文件改了半天 AI 行为没变化

症状：改了 .kiro/steering/engineering-charter.md，AI 还是老样子。

解法：

1. 检查路径：~/.kiro/steering/（全局）vs <workspace>/.kiro/steering/（项目）
2. 检查冲突：项目级 vs 全局级，项目级优先——全局里写的不一定生效
3. 重启 session：Steering 改动只在新建对话时加载，已开的对话不会重新读
4. 检查文件格式：必须是 Markdown，不能是 .txt / .yaml

Q5：Specs 拆出来的 task 太碎或太粗

症状：要么 task 1 就是"完成整个登录"，要么 task 1.1、1.1.1、1.1.1.1 拆得过细。

解法：

1. 明确告诉 Kiro 粒度："把 task 拆到 1-4 小时能完成的颗粒度"
2. 用 Quick Plan：Kiro 提供"快速规划"模式，task 数控制在 5-8 个
3. 手动合并/拆分：生成 tasks.md 后，你自己 review + 调整——AI 给的是参考，不是圣旨

5.3 性能调优 Checklist

5.4 团队协作：把 Steering 变成团队资产

核心思路：把 .kiro/steering/ 提交到 git，全团队共享同一套规则。

# 初始化团队 steering
mkdir -p .kiro/steering
cat > .kiro/steering/team-conventions.md << 'EOF'
# 团队规范
- 所有 PR 必须有 description
- commit message 遵循 conventional commits
- 不用 lodash，统一用 ES2024 内置方法
EOF

# 提交到 git
git add .kiro/steering
git commit -m "feat: add team kiro steering config"

结合 MDM / Group Policy 推全局规则——所有团队成员的 ~/.kiro/steering/ 都从公司中央仓库同步。

5.5 Kiro 不擅长的场景

Kiro 是 spec-driven IDE，不是万能 IDE。下面这些场景它表现一般：

六、总结：把 Kiro 用成"商业级交付"工具的三个心智

心智 1：人是边界制定者，AI 是实现执行者

永远不要把"业务边界"交给 AI 决定。 Kiro Specs 的价值在于——让你跟 AI 对齐的不是"代码长什么样"，而是"成功长什么样"。

• 你定 acceptance criteria
• AI 拆 design + tasks
• Hook 验证 acceptance criteria 是否被满足

心智 2：规则资产化，不要"每次 prompt 重讲"

Steering + 工程宪章 = 团队最贵的资产。花一周打磨出 .kiro/steering/，后续半年 AI 都会自动遵循。这才是 vibe coding 的杠杆率。

心智 3：自动化兜底，AI 也要"code review"

Hooks 才是 AI 时代的 CI/CD。AI 写完代码没人 review？让 hook 跑 test/lint/typecheck。AI 犯的错跟人犯的错一样多——别指望它"自己更靠谱"。

Kiro 不是一个 IDE，它是 AWS 把"AI 编程的最佳实践"打包成产品的尝试。 用好它需要的不是新技能，是把已有的工程纪律产品化。

附录 A：Kiro 项目级 .kiro/ 目录推荐结构

附录 B：5 分钟上手清单

• 安装 Kiro IDE / CLI
• 打开项目运行 kiro init
• 一键生成三个 foundational steering 文件
• 添加工程宪章到 .kiro/steering/engineering-charter.md
• 安装 frontend-design + superpowers skill
• 配 2-3 个核心 hook（on-save / on-agent-stop）
• 第一次用 /kiro spec 生成一个 feature 的三文件
• 关键：review 完三文件再点执行——别跳过这一步
• 30 天后回顾：哪些规则频繁触发？哪些 hook 误报？修剪 + 增补