Appearance
需求优先（Requirements-First）工作流是 Feature Specs 的传统方法，先用 EARS 格式（WHEN...THE SYSTEM SHALL...）定义系统行为，让 Kiro 生成 requirements.md，然后基于确认的需求生成技术设计（design.md）和实现任务（tasks.md）。适合有清晰用户故事、架构灵活的场景，以及由产品经理或客户需求驱动的功能开发。迭代优先级是先打磨需求，再锁定设计。
何时使用需求优先工作流？
以下场景适合选择需求优先工作流：
- 有明确用户故事：你对用户行为有清晰定义，Kiro 可以据此生成用户故事
- 架构灵活：技术设计可以适应需求，而非反过来
- 绿地项目：从零开始，没有已有技术约束
工作流步骤
第一步：创建 Feature Spec
从 Kiro 面板或命令面板创建新的 Feature Spec，在提示时选择需求优先工作流。
第二步：需求阶段
Kiro 根据你的提示词生成 requirements.md 文档。
文档包含：
- 带清晰验收标准的用户故事
- EARS 格式的系统行为（WHEN...THE SYSTEM SHALL...）
- 功能性需求
- 边界情况和错误处理
你的职责：
- 审查需求的完整性
- 迭代用户故事和验收标准
- 补充缺失的场景或边界情况
- 确认需求满足你的要求
需求示例：
## 用户认证
### 用户注册
WHEN 用户提交有效的注册信息时
THE SYSTEM SHALL 创建新用户账号
WHEN 用户提交已存在的邮箱时
THE SYSTEM SHALL 显示"该邮箱已注册"错误提示
WHEN 用户提交格式错误的邮箱时
THE SYSTEM SHALL 显示邮箱格式校验错误第三步：设计阶段
确认需求后，Kiro 生成描述实现方案的 design.md 文档。
生成内容：
- 系统架构与组件划分
- 展示交互关系的时序图
- 数据模型与接口定义
- 技术栈建议
- 错误处理方案
- 测试策略
你的职责：
- 审查技术方案
- 迭代架构决策
- 验证技术选型
- 确认设计的可行性
第四步：任务阶段
Kiro 生成包含可执行实现任务的 tasks.md 文件。
生成内容：
- 离散、可追踪的任务
- 清晰的描述和预期产出
- 任务间的依赖关系
- 可选任务与必须任务的区分
你的职责：
- 审查任务拆分方式
- 按需调整任务优先级
- 标记可选任务
- 开始实现
第五步：实现
逐个执行任务，或一键运行所有任务实现功能。
最佳实践
从清晰的用户故事开始
明确描述以下内容：
- 用户是谁
- 他们想要完成什么
- 为什么需要这个功能
- 成功标准是什么
示例提示词：
构建一个用户认证系统。用户应能够用邮箱/密码注册、安全登录、
重置忘记的密码，以及退出登录。
系统必须防范暴力破解攻击并验证邮箱格式。在设计之前先打磨需求
需求优先工作流的核心价值在于先把"做什么"搞清楚，再确定"怎么做"。花时间：
- 验证所有用户场景都被覆盖
- 确保验收标准可测试
- 获取利益相关者对需求的认可
- 确认边界情况已被考虑
使用 EARS 格式保持精确性
EARS 格式（WHEN...THE SYSTEM SHALL...）的需求：
- 明确无歧义，易于测试
- 可直接转化为测试用例
- 在整个实现过程中可追踪
- 对技术和非技术利益相关者都清晰易懂
审查设计的可行性
在推进到任务阶段之前，验证：
- 设计满足所有需求
- 技术选型是否合适
- 非功能性需求是否被覆盖
- 方案是否具有可维护性
常见模式
模式一：产品功能开发
场景：产品经理为新功能提供用户故事。
步骤：
- 将用户故事复制到初始提示词
- 选择需求优先工作流
- 让 Kiro 将需求正式化为 EARS 格式
- 与产品经理一起审查和迭代需求
- 生成设计并与工程团队一起验证
- 执行任务完成实现
模式二：客户驱动功能
场景：客户提出具体功能需求。
步骤：
- 在初始提示词中描述客户需求
- 选择需求优先工作流
- 生成捕捉客户意图的需求
- 与客户验证需求
- 生成针对需求优化的设计
- 实现并交付
模式三：绿地应用
场景：从零开始构建新应用。
步骤：
- 定义核心用户旅程和功能
- 选择需求优先工作流
- 生成完整的需求文档
- 从可扩展性和可维护性角度审查设计
- 执行任务构建 MVP
故障排除
生成的设计不满足需求
- 检查需求的清晰度和完整性
- 添加更具体的验收标准
- 从更新后的需求重新生成设计
- 反复迭代直到设计与需求对齐
需求过于模糊
- 在初始提示词中添加更多细节
- 包含具体的用户场景和边界情况
- 定义清晰的成功标准
- 使用 EARS 格式提高精确性
设计生成后需要修改需求
- 编辑
requirements.md文档 - 在
design.md中点击 Refine - Kiro 会更新设计和任务以匹配新需求
- 这是正常的——迭代是流程的一部分
相关资源
常见问题
Q：需求阶段可以迭代多少次？
没有限制，可以反复迭代直到满意。需求优先工作流的核心价值就是在锁定设计之前充分打磨需求。每次修改 requirements.md 后，都可以通过 design.md 中的 Refine 按钮更新设计和任务。
Q：如果不确定某条需求是否必要，应该保留还是删除？
建议通过与利益相关者对话来澄清，而不是随意增减。你也可以在需求文档中将可选功能明确标注，Kiro 在生成任务时会区分必须任务和可选任务。
Q：EARS 格式中的 THE SYSTEM SHALL 是固定写法吗？
是的，THE SYSTEM SHALL 是 EARS 符号中表达强制行为的标准写法，Kiro 会识别这种格式来提取可测试的属性用于属性测试（PBT）。保持一致的格式对自动化验证至关重要。