Name	Name	Last commit message	Last commit date
parent directory ..
README.md	README.md
prompt.md	prompt.md

Kiro: 规范驱动的 AI 开发工作流

🎯 一言以蔽之

本工作流的核心目标是：将用户一个模糊的功能想法（feature idea），通过一个包含“需求 -> 设计 -> 任务规划”三个阶段的结构化流程，转变成一份清晰、详尽、且可被另一个 AI 直接执行的编码任务清单。

本工作流完美体现了软件工程中的“关注点分离 (Separation of Concerns)”原则。它强制 AI 将一个复杂问题分解为三个独立但又环环相扣的阶段，确保每一步都足够专注和深入：

同时，整个流程以用户控制 (User Control)为核心。AI 在每个阶段完成后都必须停下来，请求用户审核，并在得到您的明确批准后才能进入下一阶段。这保证了您始终处于主导地位，AI 不会偏离方向。

这个阶段的目标是与您一起，将模糊的想法变成明确、无歧义的需求。

核心任务: AI 必须主动创建 requirements.md，并根据您的初步想法直接生成第一版需求文档，而不是通过一连串问题来引导。这能快速为您提供一个讨论和反馈的基础。
产出要求: 需求必须遵循两种严格格式：
- 用户故事 (User Story): “As a [角色], I want [功能], so that [价值]”
- 验收标准 (Acceptance Criteria): 采用 EARS 语法以避免歧义。
交互模式: 文档完成后，AI 必须请求您的审核。整个阶段是一个“反馈-修改-请求批准”的循环，直到获得您的明确同意才能进入下一阶段。

在完全理解了“做什么”之后，这个阶段专注于设计一个技术上可行的解决方案。

核心任务: 基于已批准的需求，AI 需要创建 design.md 文件。如果需要技术调研，其结论和上下文会直接融入设计中。
产出要求: 设计文档必须是全面的，至少包含 Overview, Architecture, Components and Interfaces, Data Models, Error Handling, Testing Strategy 等部分。鼓励使用 Mermaid.js 图表来增强可视性。
交互模式: 与需求阶段类似，设计文档完成后必须寻求您的批准。若发现需求问题，AI 会主动提议返回上一阶段。

当您批准了设计方案后，最后一步是将其分解为具体、可执行的编码任务。

核心任务: 基于已批准的设计，创建 tasks.md 文件。最关键的一点是，这些任务是写给“代码生成 LLM”的一系列提示 (prompts)，最终读者是另一个 AI，而非人类。
规划原则: 任务必须遵循测试驱动开发 (TDD)、增量演进的原则，避免大的复杂性跳跃，并确保每一步都建立在前一步的基础上。
严格限制:
- 只包含编码任务: 严禁包含用户测试、部署、性能分析等任何非编码活动。
- 任务必须是 AI 可执行的: 任务描述必须具体到函数和文件层面（如“实现 X 函数”），而不是模糊的功能描述。
工作流终点: tasks.md 经您批准后，本工作流便宣告结束。AI 会明确告知它不会在此流程中执行编码，并引导您前往 tasks.md 文件开始实际的编码工作。

来源说明: 本工作流的灵感和部分内容来源于 kingkongshot/prompts。README 的撰写思路深度借鉴了文章《上下文工程难吗？试下Claude Code写入Kiro的Spec，自动搞定上下文》。