10天前Amazon发布了他们自己的开发平台，Kiro IDE，其中有一个很厉害的交互功能“Spec（Specification）”，强调的是规范的文档，说明书，以一套非常结构化的方法确保开发过程的系统性、可控性和质量，堪称现代软件工程的最佳实践。让vibe coding有一个规范的范式。
总体设计思想：关注点分离与用户控制
Kiro的Spec工作流完美体现了软件工程中的“关注点分离”原则。它强制AI将一个复杂问题分解为三个独立但又环环相扣的阶段，确保每一步都足够专注和深入：
- 需求阶段：只关心 “做什么 (What)”。
- 设计阶段：只关心 “如何做 (How)”。
- 规划阶段：只关心 “怎么一步步实现 (How to implement step-by-step)”。
同时，整个流程以用户审批为核心，AI在每个阶段完成后都必须停下来，用 userInput 工具请求用户审核，并得到明确批准后才能进入下一阶段。这保证了用户始终处于主导地位，AI不会偏离方向。
第一阶段：需求收集 (Requirements Gathering)
这个阶段的目标是与用户一起，将模糊的想法变成明确、无歧义的需求。
- 核心任务：AI必须主动创建 requirements.md，并根据用户的初步想法直接生成第一版需求文档，而不是通过一连串问题来引导。这能快速为用户提供一个讨论和反馈的基础。
- 产出要求：需求必须遵循两种严格格式。用户故事 (User Story) 采用 “As a [角色], I want [功能], so that [价值]” 格式；验收标准 (Acceptance Criteria) 采用 EARS 语法以避免歧义。AI也被鼓励预先考虑边缘情况。
- 交互模式：文档完成后，AI必须使用 userInput 请求用户审核。整个阶段是一个“反馈-修改-请求批准”的循环，直到获得用户明确同意才能进入下一阶段。
第二阶段：设计文档创建 (Design Document Creation)
在完全理解了“做什么”之后，这个阶段专注于设计一个技术上可行的解决方案。
- 核心任务：基于已批准的需求，AI需要创建 design.md 文件。如果需要技术调研，其结论和上下文会直接融入设计中。
- 产出要求：设计文档必须全面，至少包含 Overview, Architecture, Components and Interfaces, Data Models, Error Handling, Testing Strategy 这几个部分。同时，鼓励使用 Mermaid.js 图表来增强可视性。
- 交互模式：与需求阶段类似，设计文档完成后必须通过 userInput 寻求用户批准。AI会不断迭代，直到用户满意。若发现需求问题，AI会主动提议返回上一阶段。
第三阶段：实施计划 (Implementation Planning)
当用户批准了设计方案后，最后一步是将其分解为具体、可执行的编码任务。
- 核心任务：基于已批准的设计，创建 tasks.md 文件。最关键的一点是，这些任务是写给“代码生成LLM”的一系列提示 (prompts)，最终读者是另一个AI，而非人类。
- 规划原则：任务必须遵循测试驱动（TDD）、增量演进的原则，避免大的复杂性跳跃，并确保每一步都建立在前一步的基础上。
- 严格限制 (非常重要)：
- 只包含编码任务：严禁包含用户测试、部署、性能分析等任何非编码活动。
- 任务必须是AI可执行的：任务描述必须具体到函数和文件层面（如“实现X函数”），而不是模糊的功能描述。
- 工作流终点：tasks.md 经用户批准后，Spec 工作流便结束。AI会明确告知用户它不会在此流程中执行编码，并引导用户前往 tasks.md 文件，通过点击 "Start task" 来逐一启动实际的编码工作流。
说白了，这个 Spec 系统提示的作用是：将用户一个模糊的功能想法（feature idea），通过一个包含“需求 -> 设计 -> 任务规划”三个阶段的结构化流程，转变成一份清晰、详尽、且可被AI直接执行的编码任务清单。感兴趣您可以看下《亚马逊的Kiro，免费Sonnet 4，让Vibe coding更规范》
Kiro的现实困境：理想与现实的差距
但实际使用中却暴露出几个关键问题。第一个是Kiro目前还无法联网搜索，mcp功能还不完善，这对现代开发来说简直是致命伤，您想想，哪个开发者能离开项目相关的官方文档？第二个问题最要命，AI对话窗口有上下文限制，一旦超出就全部作废，而spec工作流恰恰需要长时间的上下文记忆，这个目前在不少开发者群已有很多人讨论，但官方的回应是暂时无法解决。第三，Kiro目前还处于预上线阶段，很多功能都不完善，就像是一辆设计精美但还没装好引擎的跑车。
意外发现：顶级系统提示词的"泄露"
后来有人在Github上“开源”了一些东西，其中就包括Spec的System Prompt，这个发现就像是拿到了顶级软件公司的内部开发秘籍，让我们得以一窥Amazon是如何将复杂的软件开发过程标准化、工程化的。因此为何不能将将Kiro的spec工作流移植到Claude Code中？用Claude Code更强的AI能力和更长的上下文支持，以及更完善的工具链和文件操作能力，可以充分利用Kiro优秀的工作流设计，同时避开其当前的技术限制，"强强联合"一下，来Vibe Coding呢？
实战验证：HITL Agent的完整开发
为此我立即实践了一下，我在Claude code中立即部署了spec系统提示词，并基于简单的需求描述用spec创建了一个商业文档撰写的HITL（Human-in-the-Loop）工作流Agent，要求有UI界面、流程可视化、支持用户意图变更等。我会在我的Agent开发群里分享这个代码和Spec的System Prompt，欢迎您来一起讨论！您也可以看下这篇《连不上Gemini CLI，试下DeepSeek-R1接入Claude code》
第一阶段-需求收集
自动创建生成了102行的详细需求文档 涵盖9大功能模块的完整需求规格 使用了标准的用户故事格式和EARS验收标准
第二阶段 - 设计文档
创建了299行的综合设计文档 包含了系统架构图、组件设计、数据模型等框架的技术选型 详细的API集成方案（Deepseek-reasoner）
第三阶段 - 实施计划：
生成了190行的任务清单tasks.md文件 分解为12个主要模块，44个具体开发步骤 每个任务都有明确的编码目标和需求引用。另外，在任意阶段对细节不满意都可以要求Claude code重写，就像在kiro里一样
最后阶段 开始执行实施
按照tasks.md的指引逐步实现 创建了单文件的完整解决方案（business_doc_agent.py，387行） 包含了所有核心功能：数据模型、AI集成、Gradio界面等 还生成了requirements.txt依赖文件
最终一键交付了一个完整Python应用，支持中文界面、实时HITL交互、多格式导出等复杂功能。
写在最后
这次实践最大的价值在于证明了优秀的软件工程方法论具有跨平台的普适性。Amazon设计的spec工作流不仅适用于Kiro，同样可以在Claude Code、甚至其他AI开发工具中发挥作用。这种方法论的核心是结构化思维和质量控制，而不是特定的技术实现。感兴趣您也可以去实践一下。
文章来自于微信公众号“AI修猫Prompt”。
