从Cursor到Kiro：AI编程工具的新思路，先规划再编码

我使用 Cursor 大半年了，开启 Composer 功能，丢个需求进去，代码就自动生成。效率确实高，但有个问题一直困扰着我——AI 生成的代码经常出现「第一版能用，第二版就崩」的情况。它没有真正理解项目架构就动手修改，改完 A 模块，B 模块跟着出问题。我花在修复 AI 埋下的坑上的时间，有时候比我自己写还多。

上个月亚马逊推出了一款叫 Kiro 的 IDE，一开始我以为又是个 Cursor 的套壳产品。结果用了两周后发现：它根本不是「让 AI 写代码更快」的思路，而是「让 AI 先把需求想清楚再写代码」。这是完全不同的开发范式。

Kiro 官网的口号——「Move beyond AI coding to agentic engineering」

一句话总结：Kiro = Cursor 的执行速度 + 产品经理的需求拆解能力。

Cursor 的模式是 Vibe Coding——你说啥它就写啥，速度确实快，但它不会停下来问你「你确定要这么做吗？」。Kiro 则不同，它有个叫 Spec 模式的功能：你给它一个需求，它不会直接写代码，而是先拆分成用户故事、技术设计文档、实现步骤，等你确认了它才动手。

这个区别就像：Cursor 是那个特别勤快但经常干错活的实习生，Kiro 是那个先跟你对需求、确认方案再动手的高级工程师。前者适合小活儿，后者适合大项目。

底层技术栈方面，Kiro 也是基于 VS Code 改的（跟 Cursor、Windsurf 一样），模型默认用 Claude Sonnet 5（已支持最新版本），所以代码生成质量本身不是问题——关键差异在于写代码之前的那个「思考」环节。

Kiro IDE 界面——Spec 驱动开发的核心交互

场景：我有一个 FastAPI 的微服务项目，需要把原本的单体接口拆成三个独立服务。之前用 Cursor 干过一次，结果它直接动手改，改完三个服务互相调不通，花了半天修复。

这次用 Kiro 的 Spec 模式，我输入需求后它先干了一件事——生成了一份 Spec 文档：

// Kiro 自动生成的 Spec 摘要 User Stories: 1. 作为调用方，我需要独立访问用户服务 2. 作为调用方，我需要独立访问订单服务 3. 作为调用方，我需要独立访问支付服务 Technical Design: - 拆分路由层 → 独立 main.py 入口 - 共享模型层抽取 → common/models - 服务间通信 → HTTP + 优雅降级 Implementation Steps:(12步，从依赖拆分到测试)

我看到这份 Spec 的时候，第一反应是：第二步「共享模型层抽取」方向不太对，我们项目用的是独立数据库，不需要共享模型。我把这一步改成了「各服务独立建模」，然后点了确认。

Kiro 就按修改后的方案开始执行。最终三个服务独立运行、互调通过、测试全绿。整个过程我只改了 Spec 的两步，后面的活儿全是它自己干的。

这个体验太不一样了——以前是我给指令，AI 执行，出了问题回头改；现在是 AI 先给我看方案，我点头了它才执行。方向对了，执行反而快。

Kiro Spec 模式——需求拆解与技术设计文档自动生成

Kiro 有个让我惊喜的功能叫 Hook。你可以在 Spec 里定义约束条件，比如「所有接口必须有错误处理」、「新增代码必须通过 lint 检查」。

AI 每次改完代码，Hook 会自动跑一遍检查。如果违反了约束，它会自己修——不是告诉你「这里有个问题」，而是真的自己改掉再验证，直到全部通过。

这个能力在团队协作里特别有用。以前我们代码审查，50% 的时间在检查「有没有加 try-catch」、「有没有写 docstring」这种低级问题。现在 Hook 帮你守住了底线，人只审逻辑和架构。

不过有个缺点：Hook 检查只覆盖你在 Spec 里明确定义的规则。如果你忘了写某条约束，它不会自动帮你发现。所以 Spec 写得越细，Hook 越有效——这有点像给自己挖坑，但习惯了就好。

这个功能是我用了 Kiro 之后才意识到的刚需。拆微服务的时候，三个服务的代码改动是互相独立的，完全可以并行。

Kiro 支持并行 Agent——你确认 Spec 之后，它会同时启动多个 Agent 分头干活。我那个项目，三个服务的框架搭建是并行完成的，实际开发时间从串行的 2 小时压缩到了 40 分钟。

需要注意的是，并行 Agent 之间目前不会主动协调——如果你两个 Agent 改了同一个文件，可能产生冲突。所以 Spec 拆分的时候要确保任务边界清晰，别让两个 Agent 抢同一块地盘。

当前 AI 编程工具的核心矛盾是什么？AI 写代码很快，但改 AI 写错的代码很慢。

Cursor、Copilot、TRAE 都在解决「写代码更快」的问题，但没人解决「写对代码」的问题。Kiro 的 Spec-Driven Development 本质上是在说：写代码之前先对齐认知。这个思路来自亚马逊内部的大工程实践——在 AWS，任何大功能上线前都要写 PRFAQ（新闻稿+FAQ）和技术设计文档，确认方向再动手。

多了一步「确认」，看起来慢了，实际上因为方向对了，返工少了，整体反而更快。这就是 Spec-Driven 的精髓——先做对，再做好。

Kiro 定价——免费版含 50 次/月 Agent 会话

免费版每月 50 次 Agent 会话，轻度使用够了。但如果你想体验并行 Agent 和完整的 Hook 检查，需要 Pro 版。$19/月 跟 Cursor 同价，但多了 Spec 和 Hook 这两个独有能力，我觉得值。

✅ 优势

• Spec 模式先对齐需求再动手，返工少

• Hook 自动验证代码质量，守住底线

• 并行 Agent 大幅缩短独立任务耗时

• Claude Sonnet 5 模型，代码质量在线

• AWS 生态深度集成，Lambda/S3 直接部署

❌ 短板

• Spec 模式对小需求偏重，杀鸡用牛刀

• 并行 Agent 不主动协调，可能文件冲突

• 国内访问需要魔法，无国产模型支持

• 生态和插件还不如 VS Code 成熟

谁应该立刻用：做中大型项目重构的团队、经常被 AI 代码返工折磨的开发者、AWS 生态用户、有代码审查需求的团队。

谁不用凑热闹：日常写小脚本的——Spec 模式反而增加步骤；国内纯中文场景且不想折腾网络的——Qoder CN 更合适。

AI 编程的瓶颈从来不是「写得不够快」，而是「想得不够清楚」。代码是需求的影子——需求模糊，代码就是一摊模糊的影子。Kiro 做的事，就是让 AI 在写代码之前，先把影子描清楚。