Cursor、Claude、Codex、GitHub已经够多了，为什么 亚马逊云还要再做一个 Kiro？
要理解 Kiro，最好先看它的出身。
Kiro 是 AWS 内部团队做出来的 AI 开发平台。
2025 年 7 月 14 日，AWS 首次公开 Kiro，最早以 Agentic IDE 的形式推出 Preview。上线前 5 天，就有超过 10 万开发者尝试使用；2025 年 11 月，Kiro IDE 和 CLI 正式 GA。
Kiro 官网对自己的介绍也很直接：
它由 AWS 内部一个规模不大、但产品方向非常明确的团队开发和运营，目标是重新思考一件事——如果今天从头设计一个真正为 AI Agent 服务的开发环境，它应该长什么样？
于是有了 Kiro。
AWS 自己后来解释得很明确：Kiro 吸收了 Amazon Q Developer 的 Agent Mode、MCP、Steering、CLI 等部分技术，但重新做了一套更完整、更强调软件工程流程的开发体验。
到了 2026 年，这条路线就更明显了。
Amazon Q Developer CLI 已经直接更名为 Kiro。
AWS 也宣布，Amazon Q Developer IDE 插件将在 2027 年 4 月 30 日停止支持，并建议用户转向 Kiro 获取新的 Agentic Coding 能力。
简单理解：
Kiro 是一个围绕 AI Agent 重新设计的开发环境。
目前它已经有三个主要入口：Kiro IDE、Kiro CLI、Kiro Web
IDE 用来正常写代码；
CLI 可以直接在终端里调用 Agent；
Web 则可以把任务交给云端 Agent 去做。
2026 年 9 月 1 日，Kiro Web 已经正式 GA。
现在开发者可以连接 GitHub 或 GitLab，把一个任务交给 Kiro。它可以在独立的云端 Sandbox 里面读代码、修改代码、执行任务，最后创建 Pull Request。
甚至还可以设置 Automation，让 Kiro 按照 Cron 定期执行开发任务。
如果今天你再把 Kiro 理解成一个“类似 Cursor 的 AI 编辑器”，那就是把路走窄了。
它总结起来应该是：
IDE + Coding Agent + 软件工程流程 + 云端执行环境。
Kiro 最有辨识度的功能叫：Specs
它背后的思路是 Spec-Driven Development，规格驱动开发。
这是 Kiro 从一开始就在押注的方向。
现在其他很多 AI Coding 工具的体验是这样的：
Agent 收到以后马上开始改代码。数据库、API、邮件、前端页面，一口气往下做。
看起来效率特别高。但真正做项目的人马上会发现问题。
邀请链接多久失效？
管理员能不能邀请另一个管理员？
用户重复接受邀请怎么办？
已经注册的邮箱怎么处理？
一个团队最多多少成员？
邀请撤销以后，原链接还能不能继续访问？
如果你没有提前写，AI 就只能自己判断。
而 AI 最危险的地方恰恰在这里！
它不但会猜，而且能非常快地把自己的猜测写进几十个文件里。
Kiro 想解决的就是这个问题。
Kiro 的一个完整 Feature Spec，通常会经过三个阶段：
Requirements → Design → Tasks
第一步是 Requirements。
先把用户到底想做什么、有哪些使用场景、什么结果才算完成写清楚。
然后进入 Design。
确定技术方案、组件关系、数据结构、接口、错误处理等。
最后再生成 Tasks。
Kiro 希望过程变成：需求 → 设计 → 任务 → Code
它解决了一个很实际的问题：
代码可以由 AI 生成，需求不能永远只存在聊天记录里！
因为 AI Coding 已经进入了一个很尴尬的阶段。
AI 写代码的能力越来越强。但 AI 写得越快，出错时造成的影响也越大。
以前 Copilot 补错一行代码，你删掉就行。
现在 Agent 一次可以：
修改几十个文件；
调整数据库；
新增依赖；
执行 Shell Command；
调用外部工具；
甚至自动创建 PR。
这就是为什么 Specs 看起来没有“一句话生成一个 App”那么酷，但对于真正的项目反而更重要。
它是在给 Agent 增加一个稳定的参照物。
以后不管是开发者还是另一个 Agent，都可以回头知道：
这个功能为什么这样做；
原始需求是什么；
哪些属于验收条件；
哪些任务已经完成。
项目越大，这件事情越有价值。
这里有一点很容易误会。
Kiro并不是要求：改一个按钮都要先写需求文档。
如果只是修一个 CSS、改一个字段、处理一个简单 Bug，完全可以直接跟 Agent 对话。
而对于需求已经比较明确的功能，Kiro 还有 Quick Spec。
它可以一次生成 Requirements、Design 和 Tasks，不需要每个阶段都停下来确认。
现在甚至已经加入单独的 Bugfix Specs，用于分析 Bug 根因、设计修复方案，再验证有没有引入新的问题。
所以它更现实的逻辑其实是：
简单任务直接做，复杂任务先想清楚。
早期很多 AI 编程工具，最大的卖点之一就是：我们接入了 Claude。
但模型现在更新太快了，继续把整个产品绑死在一个模型上，反而会成为限制。
Kiro 现在已经明显转向多模型。
目前付费用户可以使用 Auto，也可以自己选择模型。
包括 OpenAI 的：
GPT-5.6 Sol、Terra、Luna
以及 Anthropic 的：
Claude Opus 5、Claude Opus 4.8、Claude Sonnet 5、Sonnet 4.6 等。
此外还有 DeepSeek、Qwen、MiniMax、GLM 等开放权重模型。
要简单区分的话，可以参考下面：
Cursor 的强项还是：AI原生编辑器
日常写代码、改代码、理解项目，体验很成熟
Claude Code 更偏：终端里的 Coding Agent
适合习惯命令行、愿意把比较完整任务交给 Agent 的开发者
Codex 现在越来越强调：把软件开发任务交给 Agent 执行
而 Kiro 最明显的一张牌还是：Spec-Driven Development。
它强调的不是让 Agent 马上开工。而是先建立需求、设计和任务结构，再执行。
所以现在没有必要简单讨论：
“Kiro能不能干掉Cursor？”
它们正在解决同一个问题的不同部分。
目前 Kiro 使用 Credits 计费。
官方价格是：
Free：$0/月，50 Credits
Pro：$20/月，1,000 Credits
Pro+：$40/月，2,000 Credits
Pro Max：$100/月，5,000 Credits
Power：$200/月，10,000 Credits
付费用户如果额度不够，可以额外购买 Credits，目前是 $0.04 / Credit。
国内用户还有一个很现实的问题：付款
Kiro 有 Free 版本，可以先直接体验。
确定自己确实需要以后，再升级 Pro 一般比较合理。
如果国内银行卡无法完成对应海外 AI / SaaS 平台的付款，也可以考虑使用支持相关场景的虚拟卡。
MXK8 虚拟卡目前可以用于 Kiro 等海外 AI/SaaS 订阅，同时也覆盖 ChatGPT、Claude 等常见海外 AI 服务。
不过不同平台的支付规则和风控策略会调整，实际付款前最好先确认支持的卡段，不建议一次性往卡里存太多余额。
Kiro 最值得讨论的地方，并不是它现在比 Cursor 多几个功能。
而是 AWS 对 AI Coding 下一阶段的判断。
过去两年，大家一直在解决：
怎么让AI写更多代码。
这个问题正在迅速变得没那么难。
下一阶段更麻烦的问题反而是：
当越来越多代码真的由Agent完成以后，软件工程怎么办？
Kiro给出的答案是：
Specs、Steering、Hooks、Permissions、MCP、Skills。
这些名字没有“一句话生成App”那么吸睛。
但实际上都在解决同一件事情：
给越来越自主的AI Agent加上工程结构。
如果只想快速做个小工具，今天已经有很多选择。
怎么让它写出来的代码半年以后还有人敢继续维护，可能才是下一场竞争真正开始的地方。
关于我们
