Amazon 的 Kiro 先写规格说明再写代码——这改变了一切

每个开发者都有一个不愿承认的秘密：我们讨厌写规格说明。我们宁愿直接跳进代码里，边写边想，然后事后补文档——如果我们还记得补的话。而每一次，毫无例外，这都会反噬我们。一个在脑子里觉得很简单的功能，变成了三周的重构噩梦，就因为没人坐下来先想清楚边界情况。

Amazon 的 Kiro 是我用过的第一个直面这个问题的 AI 编码工具。它不是帮你更快地写代码（像 Cursor 或 Copilot 那样），而是坚持先写规格说明——需求、设计文档、边界情况、验收标准——然后生成符合规格的代码。听起来很教条，听起来很慢。但在实践中，这是我体验过的最接近生产质量的 AI 编码体验。

我使用 Kiro 大约五周了，主要用于一个与 AWS 深度集成的 Node.js 微服务项目。以下是规格驱动方法在日常工作中的真实面貌——它在哪里大放异彩，在哪里让人抓狂，以及为什么我认为它代表了 AI 辅助开发未来的一种根本不同的押注。

01 Kiro 是什么，从哪里来

Kiro 是由 Amazon Web Services 开发的一款 AI 驱动的 IDE。它在 2025 年中发布了预览版，是那个月 Product Hunt 上讨论度最高的发布之一——部分因为 Amazon 的品牌效应，部分因为它的方法与主导 AI 编码工具领域的 Cursor/Copilot 范式截然不同。

核心理念：大多数 AI 编码工具优化的是速度——更快地写代码、更快地补全行、更快地生成模板。Kiro 优化的是正确性。它的论点是，专业软件开发中最大的瓶颈不是打字速度，而是开发者意图与实际构建结果之间的差距。通过将意图强制纳入结构化的规格说明流程，Kiro 旨在让第一次生成的代码就更接近生产可用。

Kiro 建立在熟悉的基础上——它是一个基于 VS Code 的编辑器，支持标准扩展——但 AI 工作流是它独有的。当你开始一个新功能时，Kiro 不会打开一个空白文件等你打字。它会打开一个规格面板，开始向你提问。

💡 想亲自试试？你可以在 Acccup 购买AI 编程订阅，享受折扣价和即时交付。

02 规格驱动开发：实际运作方式

来看一个具体的操作演示。我需要为现有应用添加一个通知服务——用户在特定事件发生时（下单、发货、支付失败等）应该收到邮件和应用内通知。

在 Cursor 里，我会打开 Composer 说"创建一个支持邮件和应用内通知的通知服务"。90 秒就能拿到代码。在 Kiro 里，流程完全不同。

我用简单的语言描述了功能。Kiro 回应的不是代码，而是一份结构化的规格说明文档，包含：

• 功能需求：服务必须做什么的要点清单——通过多个渠道发送通知、支持基于模板的内容、允许用户偏好管理、带重试逻辑处理投递失败。
• 边界情况：如果邮件服务宕机了怎么办？如果用户禁用了通知但有一条管理员级别的通知必须送达呢？防止通知轰炸的限流怎么做？
• 数据模型：通知、用户偏好、投递日志和模板的建议 schema。
• API 设计：端点定义，包含请求/响应结构、错误码和认证要求。
• 验收标准：定义功能"完成"的具体、可测试的条件。

这份规格说明的生成大约花了 30 秒。但关键是：Kiro 然后让我审查和细化它。"你想包含短信作为渠道吗？通知应该持久化还是临时的？预期的量级是每小时几十条还是每分钟几千条？"我回答的每个问题都会进一步细化规格。

只有在我批准规格之后，Kiro 才开始生成代码。而它生成的代码与"直接写"提示得到的代码有显著不同——它为我们确定的每个边界情况都包含了正确的错误处理，数据模型与规格完全匹配，API 端点对每个字段都有验证，重试逻辑也是可靠的，不是简单的指数退避。

从"我想要一个通知服务"到可工作代码的总时间大约是 25 分钟——比 Cursor 的 90 秒代码生成要长，但代码几乎不需要生成后的修复。如果加上我通常在快速 AI 生成后需要做的调试和重构，到生产可用的总时间实际上用 Kiro 更短。

03 Hooks 系统：尊重你工作流的自动化

Kiro 的 hooks 系统是那种在功能列表上看起来不起眼、但在实践中变得不可或缺的功能。Hooks 是在开发工作流特定节点触发的自动化动作——文件保存时、规格批准时、代码生成时、测试完成时。

我是这样用的。我有一个在每次代码生成事件时运行的 hook：它自动对生成的代码运行 ESLint 和 Prettier，执行相关的测试套件，如果有测试失败，把失败输出反馈给 Kiro 进行自动修正。另一个 hook 在规格批准时触发：它从规格文档创建 PR 描述草稿，将验收标准添加为检查清单，并根据将被影响的文件标记相关的审查者。

Hooks 系统通过项目根目录中的一个简单 YAML 文件配置。你定义触发事件、要运行的命令，以及可选的触发条件。概念上类似 Git hooks 或 GitHub Actions，但专门为 AI 编码工作流设计。

让 hooks 真正有用的是反馈循环。当 hook 在代码生成后运行测试并且有些失败时，Kiro 不只是展示失败信息——它把失败作为下一次迭代的上下文。"通知服务的测试失败了，因为重试逻辑没有处理邮件提供商返回 429 状态码的情况。让我更新重试处理器以包含限流感知。"这个自我修正的循环意味着代码到达我审查时，已经经过了一轮自动化验证。

Product Hunt 上一位早期采用者评论道："Kiro 的 hooks 把 AI 代码生成从老虎机变成了流水线。"我完全同意。可预测性才是关键。

04 Kiro 与 Cursor、Copilot 等工具的区别

我谈到 Kiro 时最常被问的问题是："这和让 Cursor/Copilot 先写规格有什么不同？"这是个合理的问题，答案在于区别不在于能力——而在于执行力和集成度。

你当然可以提示 Cursor 的 Composer "先写规格，再实现"。但工具本身没有任何东西会强制执行这个流程。你第一个功能会这么做，第二个赶时间就跳过了，第三个就完全放弃了。Kiro 不给你跳过的选项。规格步骤是工作流的一等公民，有自己的 UI、自己的细化流程、自己的版本控制。这就像"我们应该写测试"和"CI 流水线在没有测试覆盖率时阻止合并"之间的区别。

• vs. Cursor：当你知道自己想要什么、只需要快速搞定时，Cursor 更快。当正确性比速度更重要时——新功能、API 契约、其他服务将依赖的东西——Kiro 更胜一筹。
• vs. Copilot：Copilot 在行/函数级别操作。Kiro 在功能级别操作。它们在不同的尺度上解决不同的问题。
• vs. Windsurf：Windsurf 的 Cascade 在多步推理方面是最接近的竞争者，但 Cascade 仍然遵循"先生成、后验证"的模式。Kiro 反转了这一点——先验证设计，再生成代码。

Hacker News 上关于 Kiro 发布的一个帖子里有条评论说得很到位："其他每个 AI 编码工具都在试图让开发者更快。Kiro 在试图让开发者更正确。在微服务和 API 契约的世界里，我不确定速度还是不是绑定约束了。"你是否同意这个前提，决定了 Kiro 是否适合你。

05 AWS 集成：低调的优势

鉴于 Kiro 来自 Amazon，你会期待深度的 AWS 集成，它确实做到了——但不是你可能担心的那种强硬方式。Kiro 不会把你推向 AWS 服务。但如果你已经在 AWS 生态系统中，它对这个生态系统有原生的理解。

当我构建一个由 SQS 队列触发的 Lambda 函数时，Kiro 的规格说明包含了通用 AI 工具不会想到的 AWS 特定考量：DLQ（死信队列）配置、可见性超时设置、针对预期消息量的批处理大小优化，以及遵循最小权限原则的 IAM 角色权限。这不只是通用的云知识——是具体的、实用的 AWS 知识，通常需要阅读三四页文档才能获得。

集成延伸到了部署。Kiro 可以生成与其产出代码的基础设施需求相匹配的 CloudFormation 或 CDK 模板。当我生成通知服务时，它还提出生成一个 CDK 栈，包含 SES 配置、用于通知存储的 DynamoDB 表以及 Lambda/API Gateway 设置——全部与我们批准的规格一致。

对于全面使用 AWS 的团队（在我的经验中，这样的团队很多），这种原生理解是相比那些把云基础设施当事后考虑的工具的一个重大优势。

06 真实的吐槽

Kiro 并不完美，规格驱动的方法有实实在在的取舍：

• 小任务的速度：当我只需要写一个工具函数或修一个快速 bug 时，Kiro 的规格流程就过重了。它给本应很快的任务增加了摩擦。我现在的做法是用 Kiro 做功能级的工作，小编辑则用一个轻量级的扩展。
• 规格质量取决于你的输入：垃圾进，垃圾出。如果你给 Kiro 一个模糊的描述，它会生成模糊的规格，产出的代码也会反映这种模糊。规格步骤的好坏完全取决于你清晰表达自己真正想要什么的能力——讽刺的是，这恰恰是大多数开发者最薄弱的技能。
• 生态成熟度：Kiro 比 Cursor 或 Copilot 更新，这一点很明显。社区更小，文档有缺口，某些工作流感觉还比较粗糙。Hooks 系统很强大但文档不够——我不得不通过实验来摸索一些配置。
• 非 AWS 项目：虽然 Kiro 在任何技术栈上都能正常工作，但它的深度知识明显偏向 AWS 服务。如果你在 GCP 或 Azure 上，就不会获得同等深度的基础设施理解。核心的规格驱动工作流仍然有效，但你会失去部署生成的优势。
• 预览版限制：在我写这篇文章时，Kiro 仍处于预览阶段。一些功能还比较粗糙，高峰时段的速率限制可能令人沮丧，正式版的定价模式也尚未完全公布。

在 AWS 开发者博客上，团队对路线图保持了透明——多云对等是计划中的功能，hooks 系统将获得可视化配置 UI。但就目前而言，Kiro 最吸引的是以 AWS 为中心、做功能级开发、且看重正确性的团队。

07 我使用 Kiro 的日常工作流

• 01 用规格说明做功能规划 — 每个新功能都从 Kiro 的规格会话开始。我用 2-3 段话描述功能，让 Kiro 生成结构化规格，然后花 5-10 分钟细化。这取代了我以前那种"边写代码边想"的非正式方式。
• 02 与团队审查规格 — 我在代码生成之前把生成的规格分享给技术主管做快速审查。这在代码还不存在的时候就能发现理解偏差。它已经成为我们轻量级的设计评审流程。
• 03 代码生成与 hooks — 规格批准后，我触发代码生成。Hooks 自动进行代码检查、格式化和运行测试。如果测试失败，Kiro 自动迭代。我审查最终输出。
• 04 基础设施即代码 — 对于需要新 AWS 资源的功能，我让 Kiro 在生成应用代码的同时生成 CDK 模板。这从一开始就保持了基础设施和代码的同步。
• 05 用其他工具做快速修复 — 对于 bug 修复、单行代码和小调整，我会切换到更轻量的工具。Kiro 的规格流程不是为五分钟的任务设计的，我不会硬套。

最终效果：我的功能部署后 bug 更少（根据我们五周的 Jira 跟踪数据，大约少了 40%），pull request 获批更快，因为审查者可以先看规格了解意图，再深入代码。

08 开始使用 Kiro

Kiro 目前处于预览阶段，早期采用者可以免费使用，不过正式版的定价尚未完全公布。如果你在 AWS 生态系统中工作，构建正确性比原始编码速度更重要的生产服务，Kiro 值得认真评估。

Kiro 没有试图成为最快的 AI 编码工具。它试图成为最可靠的。在每个其他 AI 工具都竞相在毫秒内生成代码的世界里，Kiro 坚持"先思考、后编码"的做法几乎显得激进。但在五周以来交付了更少 bug、更干净 PR 和更好的意图文档之后，我确信这种规格驱动的方法将在一两年内影响每个 AI 编码工具的工作方式。Amazon 可能在这件事上走在了前面。