Appearance
Feature Specs 为新功能构建提供结构化方法，通过需求、设计、任务三个清晰阶段将创意转化为实现。支持两种工作流变体：需求优先（从用户行为出发，自动生成设计）和设计优先（从技术架构出发，推导可行需求）。需求使用 EARS 格式（WHEN...THE SYSTEM SHALL...），确保需求明确可测试、可追踪，适合复杂功能、多任务实现和需要团队协作文档的场景。
什么是 Feature Specs？
Feature Specs 为新功能构建提供结构化方法，引导你完成需求收集、技术设计和实现规划。根据你的出发点——清晰的用户需求或已有的技术设计——可以选择两种适应不同开发过程的工作流变体。
核心优势
结构化流程：清晰的阶段引导你从想法走向实现
灵活性：选择匹配你起始点的工作流
自动文档化：自动生成需求和设计文档
进度追踪：跨离散实现任务监控进度
团队协作：产品与工程团队之间的共享产物
适用场景
最适合：
- 需要结构化规划的复杂功能
- 包含多个实现任务的功能
- 需要团队协作文档的项目
- 需要多轮迭代的需求或设计
不适合：
- Bug 修复（请使用 Bugfix Specs）
- 目标不明确的探索性编码
工作流变体
Feature Specs 提供两种工作流变体，适应不同的开发起点。
需求优先（Requirements-First）
从你希望系统具备的行为出发，以需求形式捕捉，然后生成技术设计和实现任务。
适用场景：
- 你清楚系统需要实现的行为
- 架构灵活，可根据需求来设计
- 由客户反馈驱动的产品功能
- 无技术约束的绿地项目
- 产品主导型团队
流程：需求 → 设计 → 任务
设计优先（Design-First）
从技术设计（架构或底层设计）出发，推导出可行的需求和实现任务。
适用场景：
- 你已有高层架构设计
- 希望通过伪代码和算法先明确实现行为
- 系统需满足严格的非功能性需求（延迟、吞吐量、合规性）
- 将其他工具中的设计文档迁入 Kiro
- 在确定功能范围前先探索技术可行性
流程：设计 → 需求 → 任务
快速对比
| 需求优先 | 设计优先 | |
|---|---|---|
| 起始点 | 系统行为，以需求形式捕捉 | 技术设计、架构或伪代码 |
| 生成内容 | 从需求生成设计 | 从设计推导需求 |
| 最适合 | 产品驱动开发 | 技术约束或设计驱动项目 |
| 确保 | 预期行为被明确规定 | 技术可行性 |
| 灵活性 | 实现可灵活调整 | 需求可灵活调整 |
EARS 需求格式
requirements.md 文件使用 EARS（Easy Approach to Requirements Syntax，简易需求语法）符号，提供结构化、可测试的需求。每条需求遵循以下模式：
WHEN [条件/事件]
THE SYSTEM SHALL [预期行为]示例：
WHEN 用户提交包含无效数据的表单时
THE SYSTEM SHALL 在相关字段旁显示校验错误提示EARS 格式的优势：
- 清晰性：需求明确无歧义，易于理解
- 可测试性：每条需求可直接转化为测试用例
- 可追踪性：各需求可跨实现阶段独立追踪
- 完整性：格式促使考虑所有条件和行为
设计文档
design.md 文件记录技术架构、时序图和实现考量，展示系统整体运作方式，包含组件及其交互关系。
快速开始
- 在 Kiro 面板的 Specs 下点击
+，或在聊天框中选择 Spec - 输入描述你项目想法的初始提示词
- Kiro 询问意图时选择 Feature
- 选择工作流：需求优先 或 设计优先
- 跟随工作流完成各阶段直到实现
你也可以在 Kiro 设置中指定默认工作流，跳过每次的选择步骤。
进一步学习
- 需求优先工作流详解 — 从用户行为出发构建功能
- 设计优先工作流详解 — 从技术架构出发构建功能
- 最佳实践 — Feature Specs 使用技巧
- Bugfix Specs — Bug 修复的结构化流程
常见问题
Q：选错工作流了可以改吗？
不能在已有 Spec 上切换工作流，需要创建新的 Feature Spec 并选择所需工作流。必要时可从原 Spec 复制相关内容。
Q：requirements.md 中必须使用 EARS 格式吗？
强烈建议使用。EARS 格式（WHEN...THE SYSTEM SHALL...）确保需求明确、可测试且可追踪，Kiro 也会据此提取属性用于生成属性测试（PBT）。不使用标准格式会降低自动化验证的效果。
Q：如何处理非功能性需求（如性能、安全性）？
对于有严格非功能性需求（延迟、吞吐量、合规性）的场景，建议使用设计优先工作流，在初始提示词中明确描述这些约束。设计优先确保技术方案在推导需求前已经过可行性验证。