深度解析Kiro：瞬间超越Cursor的Spec工作流，轻松迁移至Claude Code！

共计 6732 个字符，预计需要花费 17 分钟才能阅读完成。

随着 Cursor 的“即兴编程”越来越影响到项目的质量，AWS 最新推出的 IDE Kiro 采用了“先规范后编码”的系统工程理念，通过 Spec 工作流来提升效率：需求、设计和任务三部分一次性生成，确保文档和代码的同步，避免复杂项目的返工。此外，这一流程还能够无缝迁移到 Claude Code，使得任何编辑器都能迅速转变为专业的 AI 架构师。

近来，Cursor 的表现令人失望，频繁出现 Token 优化过度、整体规划不足等问题，导致代码质量严重不均，甚至出现“AI 擅自修改代码”的情况。要从模糊的需求走向精准的实现，Kiro 的 Spec 工作流无疑开启了编程的新革命。

在 Cursor 遭遇批评之际，AWS 推出了其新型 AI IDE——Kiro，借助其核心的 Spec 工作流，开启了全新的 AI 编程模式。

虽然 Spec（规格 / 规范）并不是一个全新的概念，但在 Kiro 中，它被提升为一种系统化的方法论，旨在解决 AI 辅助开发中普遍存在的上下文丢失、需求理解偏差及工程质量低下等关键问题。

目前，Kiro 正在公测阶段，完全免费，并且允许用户使用 Claude 系列的先进模型（如 Claude 4 Sonnet），尽管速度稍显缓慢，希望能尽快推出付费订阅服务。

一、Spec 工作流：AI 编程的系统工程思维

Kiro 的 Spec 工作流强调在编写任何代码之前，必须首先通过结构化的文档来明确需求、设计和任务。

该开发流程被分为三个清晰且可迭代的阶段，每个阶段都有对应的核心文档，保存在项目的 .kiro 目录下：1. 需求分析 (Requirements)：requirements.md 2. 系统设计 (Design)：design.md 3. 实现计划 (Implementation)：tasks.md

图自网络

二、解析 Spec 工作流的三个阶段

1. requirements.md：运用 EARS 语法消除需求模糊性

Kiro 采用了 EARS（Easy Approach to Requirements Syntax）语法，通过标准化的句式消除需求中的模糊性。

EARS 语法一般包含事件驱动和状态驱动等句式，其格式为：用户故事 (User Story): 作为一个 [角色]，我希望 [功能]，以便 [收益]。验收标准 (Acceptance Criteria): 当 [事件] 发生时，系统应 [响应]。

通过这种方式，不仅明确了需求，还能够自动生成相应的测试用例及设计方案，从根本上提高交付质量。

2. design.md：从技术角度构建可行的系统蓝图

一旦需求得以明确，Spec 工作流将进入设计阶段。

design.md 作为连接需求与实现的技术桥梁，通常包括以下内容：系统架构图 (Architecture)、组件与接口定义 (Components and Interfaces)、数据模型 (Data Models)、错误处理机制 (Error Handling) 以及测试策略 (Testing Strategy)。

一份高质量的设计文档能够使 AI 在生成代码时具备全局性的视角，确保各个模块之间的协调和可维护性。Kiro 能够基于 requirements.md 自动创建设计草案，并通过与开发人员的反复沟通，最终形成一份符合生产标准的技术设计文档。

图源网络

3. tasks.md：基于任务清单的精细化执行

tasks.md 是将整体设计分解为具体、可执行的编码任务的文档。Kiro 强调任务的原子性和可操作性，每个任务都应为离散、可管理的编码步骤，并与 requirements.md 中的具体需求紧密关联。

图源网络

任务清单一般采用复选框格式，能够支持多层级结构，确保开发过程的有序性及可追溯性。这种形式让开发者能精确控制 AI 的执行范围，专注于每次一个任务，并通过任务状态管理实时跟踪项目进展。

三、Kiro 的交互与控制机制分析

根据对 Cursor 的说明，Kiro 配备了一些特定的按钮。为何不统一命名？难道是担心抄袭的指责？它采用了双重模式设计：Vibe 模式：与 Cursor 的聊天模式相对应，允许用户与 AI 进行对话。Spec 模式则对应于 Agent 模式，逻辑上存在差异，正是 Kiro 的核心竞争力所在。

原子化控制与回滚功能：Follow 按钮：相当于 Accept 按钮，用于接受 AI 的修改建议。Revert 机制则是通过 checkpoints 实现状态回滚。

Agent Hooks 自动化系统：Kiro 内置了一套基于文件事件的自动化检查和通知机制。例如，当 AI 需要开发者确认某个步骤（例如 npm install）时，系统会自动发出提示，从而有效地解决了 AI 编程过程中的“等待阻塞”问题。

四、实战对比：Kiro Spec 工作流与传统 AI 编程模式

为了更清晰地表明 Spec 工作流的优势，本文以一个企业级的“团队任务管理系统”（简化版 Jira）开发为例，比较 Kiro 与传统 AI 编程工具（如 Cursor）在复杂项目处理上的表现。

该项目的技术栈涵盖了前端（React, TypeScript）、后端（Node.js, Express）、数据库（PostgreSQL, Prisma ORM）以及实时通信（Socket.io），并集成了 AI 功能（如智能工时估算），具备较高的复杂性。传统 AI 编程工具（Cursor）的表现：工作模式偏向于“功能堆砌”。

当开发者提出新功能时，AI 直接生成相应代码，缺乏对整体架构的全面考量。在处理多模块协作时，常常会遗留关键逻辑；数据库 Schema 的设计可能不够完善；第三方 API 的集成则需付出大量的手动调整和返工时间。

成果方面：主要生成的为代码文件，几乎没有团队协作所需的技术文档，导致项目后期的可维护性较差。而 Kiro Spec 工作流的表现则更为出色：工作模式展现出“系统工程思维”。

首先生成全面的需求与设计文档，将项目清晰地划分为用户系统、项目管理、任务流转等多个独立但相互关联的模块。过程中的优势体现在 design.md 中已预设了完整的数据库 Schema、API 接口及 Socket.io 集成的方案。

tasks.md 则将这些设计转变为具体的、带有依赖关系的编码任务。最终的成果不仅包括高质量的代码，还有一整套完整的、可供团队协作的技术文档，显著提升了项目的规范性和可维护性。

如何在 Claude Code 中实现 Kiro Spec 工作流的跨平台应用

通过对比分析，我们不难发现，面对复杂的企业级项目，Spec 工作流展现出了无与伦比的优势。这种工作流不仅高效，还能够确保项目的规范性与可管理性。

Kiro Spec 工作流的卓越之处在于其独特的方法论。我们能够将这一严谨的开发流程完整移植到 Claude Code 中，使其更为完善。

在 Claude Code 中复现 Spec 工作流的关键在于设置一个自定义的 /spec 命令。

1. 自定义命令的配置：首先，需要在 Claude Code 的用户配置目录内（通常是 ~/.claude/commands/）新建一个名为 spec.md 的文件。

2. 核心提示词的植入：接下来，将从 Kiro 提取并经过结构化的“完整 Specs 系统提示词”的内容，完整复制并粘贴到 spec.md 文件中。这些提示词清晰地定义了 AI 在执行 /spec 命令时必须遵循的三大阶段（需求收集、设计、任务规划），并详细描述了每个阶段的文档格式、约束条件以及与用户的迭代交互模式。

系统提示词：需求收集与设计文档生成

在需求收集阶段，首先基于功能想法生成初步的需求文档，采用 EARS 格式，随后与用户进行多次迭代，以确保这些需求内容完整且准确。在这一阶段，重点不在于代码的探索，而是专注于编写需求，这些需求最终将转化为设计文档。

** 约束条件：**

模型必须在‘.claude/specs/{feature_name}/requirements.md’路径下创建需求文件，若该文件不存在。
模型必须基于用户的初步想法生成需求文档的初版，而无需先行提问。
初步的 requirements.md 文档应包含：
- 一个清晰的介绍部分，总结功能概述。
- 一个分级编号的需求列表，每个需求包含：

模型应当考虑边缘案例、用户体验、技术限制及成功标准。

更新需求文件后，模型必须询问用户：“这些需求是否满意？如果可以，我们可以继续进入设计阶段。”并使用‘userInput’工具。

‘userInput’工具的使用理由应为精确字符串‘spec-requirements-review’。

若用户请求更改或未明确批准，模型必须对需求文档进行修改。

每次编辑后，模型必须要求用户的明确批准。

在收到明确批准（如“是”，“批准”，“看起来不错”等）之前，模型不得进入设计文档阶段。

模型应持续进行反馈与修改循环，直至获得明确批准。

模型应建议需求中需要澄清或扩展的特定方面。

模型可以针对需求的特定方面提出有针对性的询问。

若用户对某个方面不确定，模型可以提供选项。

在用户接受需求后，模型方可进入设计阶段。

在设计文档创建阶段，一旦用户批准了需求，接下来应基于功能需求制定全面的设计文档，并在设计过程中进行必要的研究。设计文档应基于需求文档，因此在开始之前需确保其存在。

** 约束条件：**

模型必须在‘.claude/specs/{feature_name}/design.md’路径下创建设计文件，若该文件不存在。
模型必须根据功能需求识别需要研究的领域。
模型必须进行研究，并在对话中建立相关背景。
模型不应创建单独的研究文件，而应将研究结果作为设计和实施计划的背景。
模型必须总结出将影响功能设计的关键发现。
模型应引用来源并在对话中包含相关链接。
模型必须创建详细的设计文档于‘.claude/specs/{feature_name}/design.md’。
模型必须直接将研究结果融入设计过程中。
设计文档应包括以下部分：

概述
架构
组件和接口
数据模型
错误处理
测试策略

模型应在合适时提供图表或可视化表示（如适用，采用 Mermaid 绘制图表）。
模型必须确保设计满足需求文档中识别的所有功能要求。
模型应强调设计决策及其背后的理由。
在设计过程中，模型可询问用户关于某些技术决策的意见。
更新设计文档后，模型必须询问用户：“设计是否合适？如果可以，我们可以继续进入实施计划。”并使用‘userInput’工具。
‘userInput’工具的使用理由应为精确字符串‘spec-design-review’。
若用户请求更改或未明确批准，模型必须对设计文档进行修改。
模型必须在每次编辑后请求用户的明确批准。
在收到明确批准之前，模型不得进入实施计划阶段。
模型必须持续进行反馈与修改循环，直到获得明确批准。
模型必须在继续之前把所有用户反馈融入设计文档。
若在设计阶段发现缺口，模型应提议回到功能需求澄清阶段。

在实施计划阶段，一旦用户批准了设计，应创建一个可操作的实施计划，并列出基于需求和设计的编码任务。任务文档应基于设计文档，因此在开始之前需确保其存在。

** 约束条件：**

模型必须在‘.claude/specs/{feature_name}/tasks.md’路径下创建任务文件，若该文件不存在。
如果用户表示需要更改设计，模型必须返回设计步骤。
如果用户表示需要额外的需求，模型必须返回需求步骤。
模型必须在‘.claude/specs/{feature_name}/tasks.md’创建实施计划。
在创建实施计划时，模型必须遵循以下具体指示：将功能设计转化为一系列提示，供代码生成的 LLM 逐步实现每个步骤，以测试驱动的方式进行。优先考虑最佳实践、逐步进展和早期测试，确保在任何阶段都不会有复杂性的大跃进。确保每个提示建立在前一个提示的基础上，并以连接各部分结束。确保没有孤立的代码未集成到之前的步骤中。仅关注涉及编写、修改或测试代码的任务。
模型必须将实施计划格式化为最多两级层次的编号复选框列表：
- 仅在需要时使用顶级项目（如史诗）。
- 子任务应以小数点编号（例如，1.1，1.2，2.1）。
- 每个项目必须为复选框。
- 简单结构优先。
模型必须确保每个任务项包括：