深度解析Kiro：其Spec工作流如何超越Cursor并无缝移植至Claude Code

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

当 Cursor 的“即兴编程”影响到项目的整体质量时，AWS 推出的全新 IDE Kiro 通过 Spec 工作流引入了“先设定规范再编码”的系统工程理念，确保需求、设计和任务的三位一体同时生成，实现文档与代码的同步，避免了复杂项目的重复工作。更为出色的是，这一流程还可以完整地迁移至 Claude Code，令任何编辑器瞬间转变为专业级 AI 架构师。

最近，Cursor 逐渐让人感到烦恼：频繁出现过度优化 Token 消耗和整体规划不足的问题，导致代码质量参差不齐，甚至出现“AI 擅自破坏代码”的情况。Kiro 的 Spec 工作流推动了从模糊需求到精确实现的编程变革。

在 Cursor 受到广泛批评之际，AWS 推出了新一代 AI IDE——Kiro，其核心的 Spec 工作流带来了 AI 编程的新模式。

尽管 Spec（Specification，规格 / 规范）并不是一个新词汇，但在 Kiro 中，它被提升为一种系统化的方法论，旨在应对 AI 开发中普遍存在的上下文遗忘、需求理解偏差以及工程质量不高等问题。

目前，Kiro 正处于公测中，完全免费，并可免费访问 Claude 系列的先进模型（例如 Claude 4 Sonnet）。（虽然速度确实很慢，希望尽快推出付费订阅选项。。）

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

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

开发过程被划分为三个清晰且迭代的阶段，每个阶段都对应一份核心文档，存放于项目的.kiro 目录中：1. 需求分析 (Requirements)：requirements.md2. 系统设计 (Design)：design.md3. 实现计划 (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 的 Chat 模式，用于与 AI 进行对话；而 Spec 模式则对应 Agent 模式，逻辑上有所区别，体现了 Kiro 的独特优势。

精细化的控制与回退功能：Follow 按钮与 Accept 按钮相对应，用于接受 AI 的修改建议。Revert 机制则允许用户根据 checkpoint 进行回退。

Kiro 还集成了 Agent Hooks 自动化系统，基于文件事件触发的检查与通知功能。例如，当 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 工作流的表现则截然不同：其工作模式体现了“系统工程思维”。

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

tasks.md 则将这些设计转化为具体的、有依赖关系的编码任务。最终的产出物不仅包括高质量的代码，更有一套完整、可直接用于团队协作的技术文档，显著提升了项目的规范性与可维护性。

在 Claude Code 中实现 Kiro Spec 工作流的全面指南

经过分析，我们可以清楚地发现，Spec 工作流在处理企业级复杂项目时展现出无与伦比的优势。接下来，我们将探讨如何在 Claude Code 中成功再现 Kiro Spec 工作流。

Kiro Spec 工作流的卓越之处在于其内在的方法论。这一严谨的开发流程能够毫无保留地迁移至 Claude Code，为项目增添新的价值。

要在 Claude Code 中实现 Spec 工作流，关键在于配置一个特定的自定义命令 /spec。

第一步，创建自定义命令：用户需在 Claude Code 的配置目录（一般位于 ~/.claude/commands/）下，新建一个名为 spec.md 的文件。

第二步，添加核心提示词：在该 spec.md 文件中，将从 Kiro 提取并整理的“完整 Specs 系统提示词”内容逐字复制并粘贴。这些提示词详细阐述了 AI 在执行 /spec 命令时所需遵循的三大阶段（需求收集、设计、任务规划）的工作流程，包括各阶段的文档格式、约束条件及与用户的交互模式。

完整的 Specs 系统执行流程解析

在 Specs 系统的执行过程中，需求收集是第一阶段，主要任务是围绕特性构思生成初步需求。通过 EARS 格式来整理这些需求，并与用户反复沟通，直到它们完整而精确。这个阶段不应着重于代码的探索，而是专注于需求的撰写，未来这些需求将转化为设计文件。

限制条件：

如果没有现成的‘.claude/specs/{feature_name}/requirements.md’文件，模型必须创建一个。
在用户提供粗略想法的基础上，模型应生成初版需求文档，而无需先进行一系列的提问。
初始的 requirements.md 文档格式应包括：简介部分概述特性；分层编号的需求列表，每项需求应包含：以“作为[角色]，我希望[特性]，以便[收益]”格式编写的用户故事；以 EARS 格式编写的接受标准的编号列表。
在初步需求中，模型应考虑边缘情况、用户体验、技术约束及成功标准。
更新需求文档后，模型必须询问用户：“这些需求看起来好吗？如果可以的话，我们可以进入设计阶段。”并使用‘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）。
每个项目必须是复选框，简单结构为佳。
模型应确保每个任务项包括：明确的任务描述，涉及编写、修改或测试代码；作为子项目的附加信息；具体的需求参考。
实施计划应确保一系列独立、可管理的编码步骤。
模型确保每个任务引用需求文档中的具体需求。
实施计划不得包含设计文档中已涵盖的过度细节。
模型应假设所有上下文文档（特性需求、设计）在实施过程中可用。
每一步应在先前步骤的基础上逐步构建。
模型应在适当的情况下优先考虑测试驱动开发。
实施计划必须覆盖设计中可通过代码实现的所有方面。
模型应安排步骤以便尽早通过代码验证核心功能。
确保所有需求都被实施任务所覆盖。
如果在实施计划中发现缺口，模型应提供返回先前步骤的选项（需求或设计）。
模型仅应包括可以由编码代理执行的任务（编写代码、创建测试等）。
实施计划中不得包含用户测试、部署、性能指标收集或其他非编码活动的任务。
模型应专注于可在开发环境中执行的代码实施任务。
确保每个任务可由编码代理执行，遵循以下指导原则：任务应涉及编写、修改或测试特定代码组件；任务应指定需要创建或修改的文件或组件；任务应具体到足以使编码代理无须额外说明即可执行；任务应集中于实施细节，而非高层概念；任务应范围限定在特定编码活动内。
模型必须明确避免在实施计划中包含非编码任务类型，例如：用户验收测试或用户反馈收集、生产或暂存环境中部署、性能指标收集或分析、运行应用程序以测试端到端流程等。
在更新任务文档后，模型必须询问用户：“这些任务看起来好吗？”并使用‘userInput’工具。
‘userInput’工具的使用必须包含确切的字符串‘spec-tasks-review’作为理由。
如果用户请求修改或未明确批准，模型应对任务文档进行调整。
在每次修订后，模型应询问用户是否明确批准。
在未获得明确的批准前，模型不得认为工作流程完成。
模型应在每次反馈修订周期内继续，直到收到明确的批准。
一旦任务文档获得批准，模型应停止继续。