Kiro

Kiro 是什么

Kiro 是 AWS 推出的 AI 原生 IDE（集成开发环境），基于 VS Code 的架构，在 2025 年发布预览版。它的核心理念叫"spec-driven development"（规格驱动开发）：你描述你想要什么功能，Kiro 先帮你生成需求文档和技术规格，经过你确认后，再据此生成代码。

这和直接让 AI 写代码的工具不同。Kiro 的流程更接近专业软件工程里的规范流程：需求→规格→实现，而不是跳过前两步直接写代码。

核心功能

从 Prompt 到规格文档

你用自然语言告诉 Kiro 你想要什么功能（可以很粗略，比如"给这个电商应用加一个购物车功能"），Kiro 生成几份结构化的文档：

• 需求文档（Requirements）：把你的想法翻译成正式的功能需求，列出用户故事、功能点、非功能性要求
• 设计文档（Design）：技术架构设计，包括数据模型、API 设计、组件结构
• 任务分解（Tasks）：把实现拆成一个一个可执行的具体任务

你在这个阶段可以审查和修改这些文档——调整需求、修改技术方向、增减功能点。确认之后，Kiro 开始根据这些规格生成代码。

这个流程的价值在于：在写代码之前先对齐"要做什么"，避免写完之后发现方向错了要大幅返工的情况。

Steering（方向引导）文件

Kiro 支持一种叫"Steering"的配置文件，让你可以给 AI 设定持久的项目上下文和约束：

• 这个项目用什么技术栈
• 代码风格和命名规范
• 哪些目录是不允许修改的
• 项目的架构原则和设计决策

这些 Steering 文件在整个项目的 AI 交互里持续生效，让 AI 生成的代码始终符合项目的既有规范，而不是每次都要重新告诉 AI"我们用的是什么框架、什么风格"。

对于长期项目或者团队协作，Steering 文件可以作为 AI 的"项目记忆"和"规范约束"，解决 AI 工具"上下文健忘"的常见痛点。

Agent Hooks（自动化触发）

Kiro 支持设置在特定事件发生时自动触发 AI 操作，称为 Agent Hooks：

• 保存文件时自动更新相关文档
• 添加新功能时自动检查安全漏洞
• 代码变更时自动更新单元测试
• 提交代码前自动运行代码规范检查

这让一些原本需要手动触发的 AI 辅助工作变成了自动发生的流程，减少了"记得在做完这件事后让 AI 检查一下"的心智负担。

基于 VS Code 架构

Kiro 基于 VS Code 的代码基础构建，这意味着：

• 你熟悉的 VS Code 界面和快捷键基本可以延续
• 大量 VS Code 扩展可以在 Kiro 里使用
• 对于已经在用 VS Code 的开发者，迁移成本低

这是和 Cursor 类似的策略，Cursor 也是基于 VS Code 的 AI IDE。

AWS 生态整合

作为 AWS 的产品，Kiro 和 AWS 服务的整合更深：

• 可以直接在 IDE 里管理 AWS 资源
• 和 Amazon CodeWhisperer（AWS 的代码补全服务）整合
• 对于用 AWS 作为云平台的团队，部署和运维流程的 AI 辅助更顺畅

对于已经深度使用 AWS 的企业用户，这个生态整合是实质性的价值。

和其他 AI IDE 的比较

vs Cursor：Cursor 是目前最成熟的 AI IDE，Tab 代码补全、Composer 多文件编辑、Codebase 索引都很完善，有大量用户基础和社区资源。Kiro 的差异化在于规格驱动开发的流程，以及 Steering 文件的持久上下文设计。Cursor 更侧重代码层面的 AI 辅助，Kiro 更侧重从需求到代码的全流程。

vs Windsurf（Codeium）：Windsurf 的 Cascade Agent 强调深度的项目理解和多步骤执行，定位和 Kiro 有重叠。价格上 Windsurf 的 Pro 版本（$15/月）比 Cursor 便宜，Kiro 的价格在预览期间有免费额度。

vs Claude Code / Gemini CLI：这些是命令行工具，不是 IDE，工作方式不同。Kiro 提供的是完整的图形界面 IDE 体验。

vs GitHub Copilot：Copilot 主要是代码补全工具，集成在 VS Code 等多种 IDE 里。Kiro 是一个完整的 IDE，规格驱动开发是 Copilot 没有的概念。

谁适合用 Kiro

重视软件规范和流程的团队：如果你的团队认为"先想清楚再写代码"是好的实践，Kiro 的规格驱动开发流程是对这个实践的有效支持。

AWS 用户：已经在 AWS 生态里工作的开发者和团队，Kiro 的 AWS 整合是其他工具没有的优势。

需要给 AI 建立长期项目记忆的团队：Steering 文件解决了"每次都要重新告诉 AI 项目上下文"的问题，对于长期维护的项目很有价值。

从 VS Code 迁移：已经熟悉 VS Code 的开发者，Kiro 的迁移成本低于其他 AI IDE。

想探索规格驱动开发的开发者：对"需求→规格→代码"这个流程有兴趣，但以前觉得写规格文档太麻烦的开发者，Kiro 让这个流程的前两步由 AI 来完成，大大降低了执行成本。

局限

相对较新：Kiro 在 2025 年才发布预览版，功能完善度和稳定性还在持续提升，早期用户可能遇到 bug 或者功能不完整的情况。

规格驱动流程有学习成本：如果你习惯了"直接让 AI 写代码"的工作方式，适应 Kiro 的规格驱动流程需要一段时间调整工作习惯。

中文支持待验证：作为美国公司产品，中文开发场景的支持质量需要实际验证。

社区资源少：相比 Cursor 有大量的教程、视频、社区讨论，Kiro 的社区资源目前还很有限。

实际建议

先试用规格驱动流程：Kiro 最独特的地方是规格驱动开发，不要跳过这个流程直接让它写代码，先体验完整的从 prompt 到规格到代码的流程，才能感受到它和其他工具的真实差异。

认真设置 Steering 文件：花时间把项目的技术栈、代码规范、架构原则写进 Steering 文件，这个投入在整个项目周期里会持续有回报。

适合新功能，慎用于遗留代码：Kiro 的规格驱动流程对于新功能开发很顺畅，对于修改复杂的遗留代码，效果可能参差不齐。

Kiro 代表了 AI IDE 领域里一个有意思的方向：不是让 AI 更快地写代码，而是让软件开发的上游环节（需求、规格）也有 AI 参与。对于认为"先想清楚才能做对"的开发者和团队，这个方向有真实的价值。