Appearance
当需求超出简单改动范围，涉及多个模块的协同实现时，单靠对话式 prompt 容易遗漏边界情况。Kiro 的 spec 工作流提供了一套结构化路径：先展开用户故事和需求、再生成设计方案、最后拆分为可执行任务。本节以邮箱验证与密码重置功能为例，演示如何通过 spec 驱动一个横跨前端组件和后端路由的完整功能，同时介绍将 spec 文件纳入版本控制作为长期设计文档的价值。
用 spec 处理复杂需求
本节假设你已完成前置模块。之前我们已经：
前几节以小改动和重构为主。但遇到真正复杂的新功能时，Kiro 的 spec 工作流才是正确武器。
理解问题
游戏的登录页没有"忘记密码"链接。当前认证方案基于 Amazon Cognito，但实现比较基础。
要支持密码重置邮件，Cognito 要求邮箱必须先完成验证。因此我们面对一棵任务树：
- 邮箱验证
- 前端：验证流程页面组件
- 后端：服务端路由 + Cognito 集成
- 密码重置
- 前端：重置密码页面组件
- 后端：服务端路由 + Cognito 集成
向 Kiro 请求 spec
用以下 prompt 启动 spec 生成流程：
I need a specification for email verification and password resetKiro 会主动收集项目上下文，并为这个复杂任务生成一份 spec（规格说明）。
审查需求文档
Kiro 会将你的简短描述扩展为基于用户故事的详细需求列表。大多数情况下，这份需求文档会帮助你：
- 将模糊的需求具体化
- 发现你最初没有想到的边界情况
读完需求后，你可以提供具体反馈要求修改，也可以直接输入类似 "LGTM" 的确认词继续。
审查设计方案
Kiro 接着会对比现有代码与需求，规划如何将新功能融入代码库。
设计文档通常包含类似伪代码的示例片段，展示计划中的 API 形态。不必纠结这些代码细节，实际实现可能略有出入——把它当作架构草图来看。
同样，你可以给出修改意见或直接 "LGTM" 进入下一步。
审查任务列表
Kiro 根据需求和设计文档，将实现拆解为一系列有序任务。每个任务代表走向最终功能的一步。
你可以在 prompt 中调整任务列表，或直接确认进入执行阶段。
执行任务
点击任务上方的 "Start Task" 链接，Kiro 开始处理该任务。
Spec 作为长期文档
你可能已经注意到，spec 文件被保存在 .kiro/specs 目录下。这是一个有意为之的设计——应当将这些 spec 文件随代码一起提交到版本库。
随着时间推移，你会积累一批 spec 文档，记录各功能背后的意图和设计决策。这既是未来开发者的参考，也是 Kiro 日后重访这些功能时的上下文来源。
本节小结
- 面对复杂功能时，用 Kiro 的 spec 工作流来规划需求、设计方案和任务步骤，而不是直接写 prompt 堆代码
- steering 文件不只是给 Kiro 介绍项目，还可以调整它的行为，比如改变任务规划的方式
常见问题
Q：spec 流程产出的任务太细或太粗，能调整吗？
A：可以。在 "Review tasks" 阶段，直接在 prompt 中说明你希望合并哪些步骤或拆分哪些任务，Kiro 会重新生成任务列表。也可以在 .kiro/steering 中配置任务粒度偏好。
Q：spec 文件能复用于类似功能吗？
A：可以作为参考，但建议不要直接复制粘贴。不同功能的边界情况不同，让 Kiro 基于新需求重新生成 spec 通常比手动改写旧 spec 质量更高。
Q：如果中途需求发生变化，spec 还有效吗？
A：spec 是活文档。需求变化时，可以更新需求部分并让 Kiro 重新评估设计和任务的影响范围，比在脑子里记住所有改动要可靠得多。