尝鲜 AWS Agentic IDE：Kiro 一周使用初体验

最近在尝试各种AI编程工具，作为AWS云服务的用户，这款被官方称为"Agentic IDE"的新工具自然也要试用一下。使用一周后，我发现Kiro确实带来了一些与众不同的体验——不是上来就写代码，而是先帮你把“规矩”立好。

一、上手门槛：熟悉外壳下的小遗憾

Kiro 基于 VS Code 开源内核搭建，这让我几乎零成本完成上手，操作逻辑和快捷键体系与日常使用的 VS Code 高度重合，学习成本极低。

但美中不足的是，Kiro 对 VS Code 生态插件的兼容性有限，其中最让我困扰的是Remote SSH 与 WSL 功能失效（对应官方 Issue：Remote SSH & WSL not working · Issue #275 · kirodotdev/Kiro）。我曾尝试安装非官方适配插件kiro-ssh-wsl-extension，但并未达到预期效果，推测仅老版本 Kiro 能支持这类第三方插件。

由于我的开发环境中大量工具部署在 WSL2，为实现 Kiro 与 WSL2 的联动，我做了如下针对性配置：

1. 安装Open Remote - WSL插件；

2. 通过Ctrl + Shift + P唤起命令面板，输入 “Preferences: Configure Runtime Arguments” 打开argv.json文件，手动添加"enable-proposed-api"配置项以解锁插件权限；

3. 再次唤起命令面板，执行 “terminal: Select Default Profile”，将 WSL 设为默认终端，以此打通 Kiro 与 WSL2 的开发链路。

二、核心体验：Spec 模式下的规范驱动开发

本次试用中，我让 Kiro 承接了一个复杂度较高的系统开发需求。输入需求后，Kiro 便智能提示 “当前需求较复杂，建议切换至 Spec 模式”，这一引导恰好切中了传统 AI 编程工具的痛点。

进入Spec 模式后，Kiro 并非直接生成代码，而是分步骤产出了requirements.md（需求文档）、design.md（设计文档）和tasks.md（任务清单），并要求我逐份确认。这正是 Kiro 的核心能力 ——规范驱动开发（Spec-Driven Development），先把 “蓝图” 画清楚，再启动编码环节。

在我完成文档的修改与确认后，就可以在tasks.md中按子任务逐步推进开发，完成一项即可标记一项，进度可视化且可追溯。这种模式彻底解决了我此前用 AI 工具的通病：代码生成快，但因前期需求梳理不清晰，后期返工成本极高。

更让我惊喜的是规格与代码的同步能力：当我手动调整某个 API 接口后，Kiro 会自动更新对应的 Swagger 文档和单元测试用例，从根源上解决了 “文档永远滞后于代码” 的行业痛点。在任务执行阶段，Kiro 还会实时展示开发进度，完成后生成差异报告与执行日志，方便我快速核验成果。

三、双模式切换：兼顾规范与灵活

Kiro 并非只有 “慢工出细活” 的 Spec 模式，还配备了Vibe 模式以适配快速原型开发场景。切换至 Vibe 模式后，只需输入简短需求，就能即时生成可运行代码，体验与主流 AI IDE 趋同，实现了 “规范开发” 与 “敏捷试错” 的双向兼顾。

当然，Kiro 也存在大模型工具的共性局限。在一次测试环节，因本地环境配置问题，Kiro 多次尝试均未解决故障。最终我将错误日志提交给千问，在获取解决方案后反馈给 Kiro，它才基于外部建议完成调整。这也印证了单一大模型存在知识盲区，多工具互补才能最大化开发效率。

四、利弊权衡与价格门槛

优势亮点

1. 规范驱动开发：Spec 模式强制开发者先明确需求与设计，规避了 “边做边想” 的开发混乱，大幅降低后期返工率；
2. 跨会话记忆：相较于同类工具，Kiro 能更好地留存历史对话与决策逻辑，保障开发流程的一致性。

待优化点

1. 响应速度偏慢：对比 Trae 等工具，Kiro 的代码与文档生成速度存在明显差距，一定程度影响开发节奏；
2. 方案回退问题：部分场景下，在已验证某方案不可行后，Kiro 仍会在后续尝试中退回被否决的方案，降低了开发效率。

价格限制

Kiro 免费版仅支持1 个月试用，长期使用需订阅付费版本，这对个人开发者而言存在一定的使用门槛。