规格驱动开发实践 - 使用 Kiro 一气呵成地完成从需求定义到代码生成的全过程
通过需求定义 / 设计 / 任务这三个阶段的规格控制 AI 代理的输出质量，使其生成符合意图的代码。本文讲解规格文件的结构与有效的编写模式。
什么是规格驱动开发
传统的 AI 编码工具以聊天对话和代码补全为主，采用逐一响应开发者指令的方式。这种方式对小型任务有效，但在跨越多个文件的功能开发或架构变更中，AI 无法把握全局，容易生成缺乏一致性的代码。Kiro 的规格驱动开发是针对这一问题的方法。开发者用自然语言描述需求后，Kiro 会（1）在需求文档（requirements.md）中整理功能需求 / 非功能需求。接着，Kiro 会（2）在设计文档（design.md）中定义架构和数据流。此外，Kiro 还会（3）在任务列表（tasks.md）中分解实现步骤。这 3 份文档成为 AI 代理的“规格书”，AI 代理按顺序执行各项任务来生成代码。
通过 Steering 文件进行规则控制
Steering 文件是向 AI 传达项目特有规则和方针的机制。它以 Markdown 文件的形式放置在 .kiro/steering/ 目录中，用来描述编码规范、架构方针、使用的库、禁止事项等。例如，可以定义“必须启用 TypeScript 的 strict 模式”“状态管理使用 Zustand，不使用 Redux”“API 响应必须用 Zod 进行验证”这样的规则。Steering 文件有 inclusion 设置，可以选择 always（始终加载）、fileMatch（仅在匹配特定文件模式时）、manual（仅在手动指定时）。全局 Steering（~/.kiro/steering/）适用于所有项目，工作区 Steering（.kiro/steering/）则用于项目特有的规则。
代理钩子与子代理
代理钩子是以特定事件（文件保存、Git 提交等）为触发器执行自动处理的功能。例如，可以定义这样的工作流：每次保存 TypeScript 文件时运行 ESLint 并自动修复，或在提交时运行测试、失败则中止提交。子代理是在独立于主代理的上下文中运行的专门代理。可以拆分复杂的任务，在文件组彼此独立时通过并行执行提高效率。例如，可以同时推进后端的 API 实现和前端的组件实现。规划代理是只读的特殊代理，专门用于分解需求和制定实现计划。它有助于在实现之前确认设计，并发现遗漏和矛盾。
与 Steering 文件的协同
Steering 文件（.kiro/steering/）与规格相互补充地发挥作用。规格定义的是单个功能或缺陷修复的规格，而 Steering 文件定义的是适用于整个项目的编码规范 / 设计方针 / 质量标准。Steering 文件有 always（始终加载）、manual（需要时加载）、fileMatch（匹配文件模式时）这 3 个 inclusion 级别。借助它们，在减少上下文消耗的同时加载所需的规则。由于执行规格的任务时会自动参照 Steering 文件中的规则，代码质量也就容易保持一致。
需求 / 设计 / 实现流程带来的好处
规格驱动开发的核心在于，不是一上来就开始写代码，而是明确地经过需求定义 / 设计 / 实现这几个阶段。首先把要做什么整理为需求，再把如何实现落实到设计中，在此基础上进入实现。通过把每个阶段留存为文档，AI 和人可以共享相同的理解，并可以减少因认识偏差而导致的返工。如果在含糊不清的状态下进入实现，容易在完成后出现“和想象的不一样”的情况，但如果在前面的阶段确定好意图，就可以在早期减少这种偏差。逐步明确意图的流程有助于提高开发的精度和效率。
总结 - 规格驱动开发的利用指南
Kiro 的规格驱动开发是一种以结构化的工作流推进从需求定义到实现的过程，旨在提高 AI 编码质量与一致性的方法。通过用 Steering 文件明确项目规则、用代理钩子自动化质量检查，有助于保持 AI 生成的代码的质量。我们推荐的方法是：先从小规模的功能添加开始尝试规格驱动开发，再逐步充实 Steering 文件。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。