8.0
热点
AI SCORE
工具产品2025-07-16 00:57
Kiro IDE：规范驱动的 AI 开发新范式
DEV Community · Erik Hanchett#Kiro#开发方法论#IDE创新
Editor brief · 编辑速览
介绍新 IDE 工具 Kiro 的 Spec-First 开发方法——先用 AI 梳理需求和规范再编码，显著减少开发迭代。创新方法论对流程优化有参考价值。
作为开发者，我们都遇到过这种情况：你有了一个绝妙的功能或应用创意，打开自己最喜欢的 AI 编程助手，然后……接下来的一个小时都在来回沟通，不断细化需求、澄清边界情况。甚至还没写下一行代码，你的 context window 就已经被探索性的对话填满了。
Kiro 是一款全新的 IDE，它通过 Spec-Driven Development，从根本上改变了我们进行 AI 辅助开发的方式。
当前 AI 编程助手的工作方式往往遵循一种可以预见、但效率低下的模式。当开发者给出一个高层次的 prompt 时，AI 通常还没有完全理解需求，就立即开始生成代码。
这种过早采取行动的做法会导致一个循环：由于最初的需求不够明确，开发者不得不反复用“实际上，我的意思是……”来澄清自己的意图。随着这种探索性对话不断进行，context window 也会被来来回回的讨论逐渐塞满，留给最终代码生成的空间变得非常有限。
受限的 context 空间最终会影响输出结果的质量和完整性，使整个过程远没有达到本应具备的效率。这种方式首先把 LLM 当成了代码生成器，而实际上，在整个开发生命周期中，我们都应该将其视为思考伙伴。
如果你正在开发一项具有挑战性的功能，Kiro 可以充当你的智能讨论伙伴，帮助你理解代码库、清晰定义问题，并高效地找到高质量的解决方案。你可以与 Kiro 协作创建简洁的 specification，其中包括清晰的需求、系统架构、技术栈考量和实现方案。
Kiro 会帮助你明确表达所有需求与约束，然后将这些 specification 作为 context，用更少的迭代、更高的准确率完成任务。这正是 Spec-Driven Development 的力量。下面让我们深入了解 Kiro 这种方式带来的一些核心优势：
在开始新的开发工作之前，Kiro 会分析现有代码，并生成三份基础文档：structure.md（代码库架构）、tech.md（技术栈与模式）和 product.md（业务背景与需求）。这会为你和团队提供一套清晰的基准认知，为后续所有 specification 工作提供依据。现在，现有代码库也可以利用这种新范式了。
当你在 spec mode 中提供项目 prompt 时，Kiro 的 AI 不会立即开始编写代码。相反，它会进行深入分析，以理解你的需求、识别潜在挑战，并创建全面的规划文档。
只需一个简单的 prompt，Kiro 就能创建详细的 specification 文件，包括：
需求分析——将你的 prompt 拆解为具体且可执行的需求
需求分析——将你的 prompt 拆解为具体且可执行的需求
技术设计——架构决策、技术选型和实现方案
技术设计——架构决策、技术选型和实现方案
任务拆解——包含明确验收标准的细粒度开发任务
任务拆解——包含明确验收标准的细粒度开发任务
Kiro 会将 specification 文件以可读的 Markdown 格式保存在项目目录中。在编写任何代码之前，你都可以审查、编辑和完善这些文件。这样便形成了天然的检查点，方便与团队成员或利益相关者进行协作。
当终于需要编写代码时，Kiro 会引用这些 specification 文件，而不是用探索性对话塞满你的 context window。这意味着可以为真正的编码任务保留尽可能多的 context 空间。
Spec-Driven Development 带来了多项关键优势，从根本上改善了团队设计、构建和维护软件的方式。规划不再被视为额外负担，而会成为你的竞争优势。以下是这种方法如何改变开发流程：
Kiro 不会等到开发中途才发现需求问题，而是会预先识别并解决歧义。这样可以避免代价高昂的返工，并在编码开始前确保各方达成一致。
Specification 阶段会形成天然的暂停点。在投入资源进行实现之前，人们可以在这些节点审查、修改并批准开发方向。
如果你在定义需求时犯了错误，也没关系。你可以修改 specification 文件并重新生成实现计划，而不必丢失完整的对话历史。
通过将规划阶段外部化到文件中，Kiro 可以让当前 context 聚焦于眼前的编码任务，从而生成质量更高的代码。
Specification 文件可以充当持续更新的文档，团队成员能够使用标准开发工作流对其进行审查、评论和协作贡献。
每一项决策和需求都会被记录下来，形成清晰的审计轨迹，说明为什么会做出某些技术选择，同时为未来加入的团队成员保留 context。
理解 Spec-Driven Development 的最佳方式，就是看看它在实践中如何运作。无论你是从零开始，还是基于现有代码库进行开发，Kiro 的系统化方法都能让你建立在坚实的基础之上。下面是一个典型工作流如何从最初概念逐步发展到可供实现的 specification。
在深入开发新功能之前，先为项目建立 context：
用户：“为这个项目设置 steering”
Kiro 会分析现有代码库，并生成三份基础文档：
structure.md——当前架构、关键组件和代码组织方式
structure.md——当前架构、关键组件和代码组织方式
tech.md——技术栈、模式和技术约束
tech.md——技术栈、模式和技术约束
product.md——业务背景、现有功能和用户工作流
product.md——业务背景、现有功能和用户工作流
这会让你清楚了解自己正在什么样的基础之上进行构建。
现在，开始梳理你想要构建的项目细节。
用户：“我想为小型团队构建一个带有实时协作功能的任务管理应用”
这正是 Spec-Driven Development 的神奇之处。Kiro 不会直接跳到框架选型或数据库设计，而是先退一步，充分理解你究竟想实现什么。它会结合 steering 文档中的 context 来分析你的 prompt，确定这项新功能如何融入现有架构和约束。
Kiro 会按照先后顺序创建一系列文档，从需求逐步推进到可执行任务：
requirements.md——详细的功能拆解，包括 user story 和验收标准
requirements.md——详细的功能拆解，包括 user story 和验收标准
design.md——架构与技术决策，包括框架、架构图和结构
design.md——架构与技术决策，包括框架、架构图和结构
tasks.md——需要按照先后顺序执行的开发阶段与任务
tasks.md——需要按照先后顺序执行的开发阶段与任务
你会审查这些 specification，或许还会添加：
现在，当 Kiro 开始编写代码时，它会引用这些全面的 specification，而不是尝试从对话历史中推断需求。每一项实现决策，都以文档中记录的需求和设计选择为依据。
Spec-Driven Development 代表着从被动编码向主动 specification 的转变。这不仅是工作流上的改进，更是我们与 AI 合作构建软件方式的一次根本性演进。
Spec-Driven Development 不再把 AI 当成一种高级的自动补全工具，而是将其定位为你的战略思考伙伴，帮助你在决策的变更成本变得高昂之前，做出更好的选择。
结果是什么？更快的开发周期、更高质量的代码、更少的意外，以及真正能够保持更新的文档——因为文档是整个流程不可分割的一部分，而不是事后的补充。
下次需要构建功能时，试着从 specification 开始，而不是从代码开始。未来的你和你的队友都会感谢这种清晰明确的方式。你甚至可能会发现，最好的代码，正是那些在落笔之前就已经规划好的代码。
准备好亲自体验其中的差异了吗？加入 waitlist。