当所有AI IDE都在比谁生成代码更快时，Kiro说：先停下来写需求文档。
先说结论
Kiro是AWS推出的Agentic AI IDE，2025年7月预览、2026年5月正式版。它基于VS Code (Code OSS)，和Cursor、Windsurf同源。
但Kiro的核心卖点不是"写代码更快"，而是Spec-Driven Development——先规划后执行。这和Cursor的对话式编程、Claude Code的终端式Agent形成了三种截然不同的方法论。
值得试，但不必all-in。Free tier 50 credits够体验Spec模式。
一、Kiro是什么？AWS为什么要做IDE
Kiro（读作 keer-oh）的官方口号是"Move beyond AI coding to agentic engineering"。
翻译成人话：别再vibe coding了，该升级了。
AWS做IDE的战略意图很明确——从云基础设施延伸到开发者工具链。你用Kiro写代码，部署大概率用AWS，形成闭环。
技术栈上，Kiro基于Code OSS（VS Code 的开源版本），和Cursor、Windsurf是同一个底座。如果你用过VS Code，上手零成本。
52+ 个内置集成（Figma、Postman、Datadog、Stripe、Supabase、Terraform等），AWS生态的优势在这里体现得很明显。
二、Spec-Driven Development——Kiro的核心差异
这是Kiro和其他所有AI IDE的最大区别。
什么是Spec？ 就是把"一句话需求"拆成三份结构化文档：
| 阶段 | 产出文件 | 内容 |
|---|---|---|
| Requirements | requirements.md | 用户故事 + 验收标准 |
| Design | design.md | 技术架构 + 序列图 + 数据流 |
| Tasks | tasks.md | 可追踪的离散任务列表 |
两种Spec类型：
- Feature Specs：构建新功能，支持Requirements-First和Design-First两种变体
- Bugfix Specs：系统化诊断和修复bug，防止回归
还有个Quick Spec模式，跳过审批门，一步生成全部三个文件。适合赶工期的场景。
和Cursor的本质区别是什么？
Cursor是"边聊边写"——你和AI对话，AI直接吐代码。快，但容易失控。需求改了，之前生成的代码可能全废。
Kiro是"先规划后执行"——需求锁定、设计评审、任务拆分，然后才开始写代码。慢一点，但每一步都有文档可追溯。
类比：Cursor像直接上手做饭，边做边尝；Kiro像先写菜谱，再按步骤执行。前者灵活但不可复制，后者可复制但缺灵活性。
这个区别对个人hack影响不大，但对团队协作意义重大。Spec可共享，产品经理和工程师可以在同一份文档上协作。
三、并行Agent + 正确性验证
并行Agent执行
Kiro是少数内置并行Agent的AI IDE——它会分析tasks.md的依赖关系，构建依赖图，然后把独立任务分组为Wave。
Wave之间顺序执行，Wave内任务并发。理论上比逐个执行快很多。
Property-Based Testing
这个很有意思。Kiro不只跑单元测试，还用属性测试（property-based testing）做正确性验证。
区别在哪？单元测试是"输入A，期望输出B"。属性测试是"对任意输入，这个规则都应该成立"。
比如一个排序函数，单元测试可能测5个case都过了，但属性测试会随机生成1000个数组，验证"输出是否始终有序"这种不变量。
Kiro甚至在写代码前就用自动推理技术检查需求的矛盾和缺口。这是"测试左移"做到极致的体现。
Agent Hooks
基于触发器自动执行任务。比如提交代码时自动跑单测、更新文档。类似Git Hooks，但由AI执行。
四、多端统一 + 模型生态
四端支持
| 端 | 特点 |
|---|---|
| IDE | 桌面端，macOS/Windows/Linux |
| CLI | 终端工作流，bash/zsh/fish + 500+ CLI 自动补全 |
| Web | 浏览器端，云端沙箱，关机后继续运行 |
| Mobile | iOS |
Web端很关键——云端沙箱意味着你可以在手机上启动一个任务，关掉电脑，让它在云端跑完。这对长时间构建场景很实用。
模型生态
Kiro的模型丰富度在AI IDE里属于第一梯队：
Auto模式（推荐）：自动为每个任务选最优模型，综合考虑质量、延迟、成本。
Anthropic Claude全系：从Haiku 4.5（0.4x credit）到Opus 5（2.2x，实验性），覆盖所有场景。上下文最高1M tokens。
OpenAI GPT-5.6 首次登陆（7/13）：三个变体——Sol（2.4x，最难任务）、Terra（1.2x，日常开发）、Luna（0.6x，性价比）。
开源/开放权重模型：
- Qwen3 Coder Next（0.05x，最便宜）
- DeepSeek 3.2（0.25x）
- MiniMax M2.1/M2.5（0.15x-0.25x）
- GLM-5（0.5x）
开源模型的credit倍率极低，Qwen3 Coder Next只要0.05x，适合 CLI 长时间跑 Agent。
开放标准
支持ACP（Agent Client Protocol）、AGENTS.md、Skills.md、MCP。VS Code 扩展和设置可直接导入。
五、定价与性价比分析
| 计划 | 月费 | Credits | 模型权限 |
|---|---|---|---|
| Free | $0 | 50 | 开源模型 + Claude Sonnet 4.5 |
| Pro | $20 | 1,000 | 全部模型 |
| Pro+ | $40 | 2,000 | 全部模型 |
| Pro Max | $100 | 5,000 | 全部模型 |
| Power | $200 | 10,000 | 全部模型 |
关键细节：
- 超额购买：$0.04/credit（个人版手动购买，团队版可自动超额）
- 新用户首充送$20 credit
- 学生计划：1,000 credits/月，免费1年
- 月度重置，未用credits不累积
和Cursor对比：Cursor Pro也是$20/月，但不按credit计费，按请求次数。Kiro的credit制更透明——你可以精确知道每个操作花了多少钱。
不同模型消耗credit的倍率不同。同一个任务，用Sonnet 4.6是Auto的1.3x，用Opus是2.2x，用Qwen3 Coder Next只有0.05x。
实际体感：Pro $20/月1000 credits，如果主要用Auto模式，日常开发够用。如果频繁用Opus做复杂任务，可能不够。
六、和Cursor/Claude Code的实操对比
方法论差异
| 维度 | Kiro | Cursor | Claude Code |
|---|---|---|---|
| 方法论 | Spec-Driven + Vibe双模式 | Chat-Based + Tab补全 | 纯对话式Agent |
| 形态 | IDE + CLI + Web + Mobile | IDE | CLI |
| 开发流程 | 需求→设计→任务→实现 | 对话→代码生成 | 对话→代码生成 |
| 文档化 | 自动生成三份Spec文档 | 无内置文档化 | 依赖AGENTS.md |
| 并行Agent | 内置依赖图+Wave并发 | 无内置并行 | 无内置并行 |
| 正确性验证 | Property-based testing | 依赖单元测试 | 依赖单元测试 |
| 模型选择 | 多厂商多模型 | 多厂商 | 仅Claude |
| 定价 | $0-200/月，credit制 | $0-40/月 | 按token计费 |
适合场景对比
选Kiro的场景：
- 团队协作，需要结构化开发流程
- 需求复杂，需要先规划再执行
- 重视文档化，Spec可作为项目资产
- 已在AWS生态内
选Cursor的场景：
- 个人开发，快速原型
- 习惯对话式交互，边聊边写
- 预算敏感（$20/月固定，不按量计费）
- 需要Tab补全这种细粒度辅助
选Claude Code的场景：
- 终端党，不想离开命令行
- 只信任Claude模型
- 需要深度理解大型代码库
- 按token计费对轻度用户更划算
七、结论与建议
Kiro的真正价值不是IDE本身，而是Spec方法论。
你完全可以在Cursor里用类似的工作流——先让AI写需求文档，再拆任务，再逐个实现。但Kiro把这个流程产品化了，自动化了，并且加了并行Agent和属性测试。
我的建议：
- 先用Free tier体验Spec模式，看看"先写需求再写代码"是否适合你的工作方式
- 如果你已经在用Cursor且满意，不必急着切换——Spec方法论可以手动在Cursor里实践
- 团队场景值得重点评估——Spec可共享这点是Cursor和Claude Code都没有的
- 开源模型的credit倍率极低（Qwen3 0.05x），预算有限可以主打开源模型
AWS入场AI IDE，最大的意义不是多了一个选择，而是把"Spec-Driven"这个概念推到了台面上。不管最终用不用Kiro，“先规划后执行"这个思路值得每个开发者思考。
作者：varkm