Appearance
设计优先（Design-First）工作流先定义技术架构（高层设计或底层设计），再由 Kiro 推导出在该架构约束下可行的需求，最后生成实现任务。两种设计粒度：高层设计（完整架构、组件交互、非功能属性）适合复杂系统和团队协作；底层设计（伪代码、接口定义）适合快速原型。需求由已验证的架构推导，天然保证技术可行性，避免需求与设计来回反复的协调成本。
何时使用设计优先工作流？
以下场景适合选择设计优先工作流：
- 快速原型验证：你知道技术栈，想探索可实现什么
- 技术约束严格：系统需满足严格的非功能性需求（延迟、吞吐量、可用性、合规性）
- 已有设计文档：你有架构图或设计文档需要迁入 Kiro
- 可行性探索：想了解给定设计下哪些需求是可实现的
- 技术主见强烈：你有明确的架构偏好或约束条件
工作流步骤
第一步：创建 Feature Spec
从 Kiro 面板或命令面板创建新的 Feature Spec，在提示时选择设计优先工作流。
第二步：选择设计粒度
选择你希望提供的架构细节级别：
高层设计（High Level Design）
完整的架构，包含：
- 系统架构图
- 组件描述与交互关系
- 技术方案和设计模式
- 非功能属性（性能、可扩展性、安全性）
最适合：复杂系统、团队协作、需要完整文档记录的场景
底层设计（Low Level Design）
聚焦实现细节，包含：
- 算法伪代码
- 接口定义与契约
- 关键数据结构
- 非功能属性
最适合：快速原型验证、可行性快速评估、个人独立开发
第三步：设计阶段
Kiro 根据你的提示词和选择的设计粒度生成 design.md 文档。
文档包含：
- 系统组件及其职责
- 数据流与交互关系
- 技术栈与框架选择
- API 契约与接口定义
- 非功能性考量
你的职责：
- 审查架构的准确性
- 通过反馈迭代优化设计
- 按需探索不同的技术方案
- 确认架构满足你的需求
提示：设计文档默认以预览模式打开，便于阅读。点击 Edit 进行修改。
第四步：需求阶段
确认架构后，Kiro 在技术设计的约束范围内推导可行的需求。
生成内容：
- 与架构能力对齐的用户故事
- EARS 格式的系统行为
- 限定在设计范围内的功能性需求
- 边界情况和错误处理
核心优势：由于需求从已验证的架构中推导，天然保证技术可行性。
你的职责：
- 审查需求的完整性
- 补充缺失的用户侧行为
- 确认需求符合你的预期
第五步：任务阶段
与需求优先工作流相同——Kiro 生成可执行的实现任务。
第六步：实现
逐个执行任务，或一键运行所有任务实现功能。
最佳实践
在初始提示词中明确技术约束
清晰描述：
- 必须使用的技术或服务
- 性能要求（延迟、吞吐量）
- 可扩展性需求
- 合规性或安全要求
- 与已有系统的集成点
示例提示词：
为我们的 Redshift 数据湖创建一个 MCP server。
必须使用 FastAPI 和 mcp-python。
目标：95 百分位查询延迟低于 100ms。
不需要 UI 组件——纯 API server。先打磨架构，再锁定需求
设计优先工作流的核心价值在于探索技术方案。花时间：
- 尝试不同的架构方案
- 评估权衡（延迟 vs 成本，复杂性 vs 可维护性）
- 验证非功能性需求的可达性
- 在锁定需求之前把设计做对
团队项目优先选择高层设计
如果多人参与实现，选择高层设计可以获得更完整的文档和共同理解。
快速验证时选择底层设计
当你想快速验证一个想法是否可行时，底层设计以更少的前置工作更快到达验证点。
上传已有设计图
如果你有来自 draw.io、Lucidchart 的架构图或手绘草图：
- 导出为 PNG 或拍照
- 在初始提示词中附上图片
- Kiro 会将可视化设计融入架构文档
常见模式
模式一：迁移外部设计文档
场景：你有来自其他工具的设计文档或会议记录。
步骤：
- 复制设计内容或上传图表
- 选择设计优先工作流
- 选择高层设计
- 让 Kiro 将设计正式化为
design.md - 从正式化的设计中推导需求
模式二：技术可行性探索
场景：你想了解特定约束下某功能是否可行。
步骤：
- 描述技术约束和大致架构
- 选择设计优先工作流
- 选择底层设计，更快迭代
- 查看生成的需求，了解什么是可实现的
- 如果需求不符合预期，调整架构重新推导
模式三：指定技术栈快速原型
场景：客户指定了具体服务（Lambda、S3、DynamoDB），需要快速搭建原型。
步骤：
- 描述技术栈和高层流程
- 选择设计优先工作流
- 按指定服务生成架构
- 推导需求以展示系统能做什么
- 执行任务构建原型
模式四：满足严格非功能性需求
场景：系统必须满足特定的延迟、吞吐量或合规性要求。
步骤：
- 在初始提示词中定义非功能性需求
- 选择设计优先工作流
- 选择高层设计，记录合规性方案
- 验证架构满足所有约束
- 推导在约束范围内可实现的需求
故障排除
生成的需求与预期不符
- 返回迭代架构设计
- 补充关于预期能力的更多细节
- 明确非功能性需求
- 从更新后的架构重新生成需求
架构过于宽泛缺乏具体性
- 在提示词中提供更多技术细节
- 指定确切的框架、库或服务
- 加入性能数据和约束条件
- 选择高层设计以获得更深入的文档
需求生成后需要调整设计
- 编辑
design.md文档 - 要求 Kiro 对照更新后的架构验证需求
- 按需重新生成需求
- 这是正常的——迭代是流程的一部分
示例提示词
高层设计示例
设计一个实时通知系统，使用 AWS 服务。需要支持：
- 10 万并发 WebSocket 连接
- 消息投递延迟低于 50ms
- 离线用户消息持久化
- 与现有用户认证服务集成
使用 API Gateway WebSocket、Lambda、DynamoDB 和 SQS。
包含展示组件交互和数据流的架构图。底层设计示例
为我们的 Express API 构建一个限流中间件。需要：
- 令牌桶算法
- 按用户和按 IP 的独立限制
- 用 Redis 存储分布式状态
- 支持按端点配置不同限额
给出核心算法的伪代码和接口定义。设计优先工作流的核心优势
- 产出可行的需求：需求从已验证的技术设计中推导，天然可行
- 避免协调摩擦：探索设计时无需反复更新需求
- 节省时间：需求与设计之间的迭代次数更少
- 探索技术选项：在确定方案前可尝试不同的技术路径
- 提前验证约束：确保非功能性需求在技术上可达
常见问题
Q：高层设计和底层设计该如何选择？
如果多人协作开发、需要完整文档记录，选高层设计；如果是独立开发、快速验证想法或已有明确实现思路，选底层设计。底层设计到验证点更快，高层设计产出更完整的系统文档。
Q：我已有架构图（PNG 格式），可以直接用吗？
可以，将图片包含在初始提示词中，Kiro 会识别其中的架构信息并融入生成的 design.md。支持从 draw.io、Lucidchart 导出的图表，以及白板照片。
Q：设计优先生成的需求比需求优先少，正常吗？
正常。设计优先推导的需求受架构能力约束，只包含在当前技术方案下可行的功能。这是设计优先的核心特性——需求与设计保持一致，避免出现"需求很好但技术上实现不了"的情况。