一、Kiro 是什么?
Kiro 是一款智能型集成开发环境(IDE),借助规格说明(specs)、向导(steer)、钩子(hooks)帮助你高效完成工作。
二、Specs 规格说明
规范(Specs)或规格说明(specifications)是结构化的工作,用于将应用程序中复杂功能的开发过程形式化。他们提供了一种系统的方法,可以将高层次的想法转化为详细的实施计划,并具备清晰的追踪和问责机制。
借助Kiro 的规格说明,你可以:
- 将“需求”分解为带有验收标准的用户故事
- 使用序列图和架构图创建设计文档
- 跟踪各个离散任务的实施进度
- 再产品和工程队之间进行高效协作
三、快速入门
准备好创建你的第一个规格说明?以下是开始的方法:
- 从 Kiro 窗格中,点击 规格 下的 + 按钮。或者,从聊天窗格中选择规格。
- 描述你的项目构想。
- 按照从需求 → 设计 → 实施 三阶段工作流程进行。
四、概念
规格说明 弥合了概念性产品需求和技术实施细节之间的差距,确保两者保持一致并减少开发迭代。Kiro 生成三个关键文件,这些文件构成了每个规格说明书的基础:
- requiremnets.md - 以机构化的 EARS 符号就用户故事和验收标准
- design.md - 记录技术架构、序列图和实施注意事项
- tasks.md - 提供一份详细的实施计划,其中包含独立且可追踪的任务
五、工作流程
该工作流 遵循逻辑顺序,各阶段之间设有决策点,以确保每一步在进入下一步之前都已妥善完成。
- 需求阶段(第一部分): 使用结构化的 ERAS 符号定义用户故事和验收标准
- 设计阶段 (第二部分): 记录技术架构,序列图和实施注意事项
- 实施规划(第三部分):将总做分解为独立且可追踪的任务,并明确描述和预期成果
- 执行阶段(第四部分):在任务完成时跟踪进度,并能够根据需要更新和完善规范
六、requirement
requirements.md 文件采用用户故事的形式编写,其中的验收标准采用 EARS 符号表示。这正式你希望该产品经理给你提需求的方式!
EARS(需求语法建议方法)表示法为编写清晰、可测试的需求提供了一种结构化格式。在规范的 requirements.md 文件中,每个需求都遵循一下模式:
WHEN [condition/event]
THE SYSTEM SHALL [expected behavior]
比如:
WHEN a user submits a form with invalid data
THE SYSTEM SHALL display validation errors next to the relevant fields
这种结构化方法有几个好处:
- 清晰性:需求明确且易于理解
- 可测试性:每个需求都可以直接转化为测试用例
- 可追溯性:单个需求在实施过程中可被追踪
- 完整性:该格式有主意全面思考所有条件和行为
Kiro 帮助你将模糊的功能需求转化为这些结构清晰的要求,使开发过程更高效,并减少产品团队和工程团队之间的误解。
七、Design
design.md 文件用于记录技术架构,序列图和实施注意事项。这是一个很好的地方,可以概述系统的整体运行方式,包括各个组价及其交互。
Kiro 的 spec 为设计文档提供了一种结构化的方法,使人们更容易理解复杂系统并在其上展开协作。design.md 文件是一个很好的载体,可用于概述系统的运行方式,包括各个组件及其相互作用。
八、Tasks
tasks.md 文件用于提供详细的实施计划,其中包含离散且追踪的任务及子任务。每个任务都有明确定义,包括清晰的描述、预期结果以及任何必要的资源或依赖项。kiro 的 spec 为 tasks 提供了一种结构化的方法,使人们更容易理解复杂系统并展开协作。
tasks.md 文件提供了任务执行接口,可实时显示更新状态。任务会更新为进行中或已完成,使您能够高效跟踪实施进度,并随时了解最新的开发状态。
九、最佳实践
如何导入现有需求?
如果您的需求或设计已经存在于其他系统中,您有两种选择:
- 使用 MCP 集成:如果您的需求工具配备支持标准输入输出(STDIO) 的MCP 服务器,您可以直接连接,将需求导入到规范回话中。
- 手动导入:只需要将您现有的需求(例如 foo-prfaq.md) 复制到您仓库中的一个新文件中,然后开启一个 spec 对话 session, 并输入 #foo-prfaq.md 从中生成一个 spec。 Kiro 将读取你的需求,并生成需求和设计规范。
如何迭代 Spec?
Kiro 的规格设计旨在不断完善,是您能够随着项目的推进,对其进行更新和优化。这种迭代方法可确保规格与不断变化的需求和技术设计保持同步,为开发提供可靠的基础。
- 更新需求:可直接修改 requirements.md 文件,或启动一个spec 对话并指示 Kiro 天啊家新需求或设计元素。
- 更新设计:导航到规范对应的 design.md , 然后选择优化。此操作将跟新设计文档和相关任务列表,以反应修改后的需求。
- 更新任务:导航到 tasks.md 文件,然后选择更新任务。这将创建与新需求对应的新任务。
如何在的多个团队之间共享规范?
可以通过git子模块或者包引用来在多个团队之间共享规范。一下是在团队管理共享规范的一些最佳实践:
- 创建一个中央规范存储库- 建立一个专用的存储库,用于存放多个项目可以引用的共享规范
- 使用git 子模块或者包引用 - 根据你的开发环境使用git子模块、包引用或者符号链接将你的核心规范链接到各个项目。
- 实施夸存储库工作流程 - 指定用于提议、审查和更新影响多个项目的共享规范的流程。
能从 vibe 回话启动 spec 会话吗?
是的,可以进行一次氛围回话,然后说 Generate spec 。 Kiro随后会询问你是否需要开始一个规格说明回话。如果你回答是,它将根据你的氛围回话上下文继续生成需求。
能一次性执行规范中的所有任务吗 ?
是的,可以通过要求Kiro智能体”执行规范中的所有任务“来执行 tasks.md 文件中的所有任务。Kiro 将开始执行你的所有任务。注意:我们不建议这样做。因为我们建议逐个任务执行以获得更好的结果
如果有些任务已经实现了怎么办?
在处理现有代码库时,你可能会发现规范中的某些任务已经完成,因为同时或者你自己在其他时段完成了这些任务。处理这种这情况有相中方法:
选项一:点击tasks.md 中的”更新任务“
- 打开 tasks.md 文件
- 点击 更新任务
- kiro 将自动标记已完成的任务。
选项二:让 Kiro 在特定聊天回话中为扫描
- 在规格讨论环节中,询问Kiro:”检查哪些任务已完成“
- Kiro 将分析你的代码库并识别已实现的功能
- Kiro将自动标记已完成的任务。
这能确保你的任务规范准确无误。
一个仓库能有多少个任务说明?
在单个代码库中,你可以根据需要创建任意数量的规格说明。我们建议为项目的不同功能创建多个规格说明,而不是试图为整个代码库只创建一个。
例如,在一个电子商务应用程序中,你可以像这样组织你的规格说明:
.kiro/specs/
├── user-authentication/ # Login, signup, password reset
├── product-catalog/ # Product listing, search, filtering
├── shopping-cart/ # Add to cart, quantity updates, checkout
├── payment-processing/ # Payment gateway integration, order confirmation
└── admin-dashboard/ # Product management, user analytics
这种方法使你能够:
- 独立开发功能,避免冲突
- 维护重点突出、易于管理的规范文档
- 对特定功能进行迭代,而不影响其他方面
- 与团队成员同时就不同功能展开协作