深度解析Kiro：其Spec工作流如何轻松超越Cursor并完美适配Claude Code

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

随着 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 工作流的三大阶段解析

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

EARS 语法通常包括事件驱动和状态驱动等句型，其格式为：

用户故事 (User Story): 作为一名 [角色]，我希望 [功能]，以便 [利益]。验收标准 (Acceptance Criteria): 当 [事件] 发生时，系统应 [响应]。

在明确需求的同时，能够自动生成相应的测试用例和设计方案，从而从根本上确保交付质量。

当需求被明确后，Spec 工作流将进入设计阶段。

design.md 充当需求与实现之间的技术桥梁，其主要内容通常包括：

系统架构图 (Architecture)
组件和接口定义 (Components and Interfaces)
数据模型 (Data Models)
错误处理机制 (Error Handling)
测试策略 (Testing Strategy)

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

图自网络

tasks.md 是将整体设计分解为具体、可执行的编码任务的清单。Kiro 强调每个任务的原子性和可执行性，确保每一个任务都是独立且可以管理的编码步骤，并且明确与 requirements.md 中的具体需求相对应。

图自网络

任务清单的设计与 Kiro 的控制机制

任务清单通常以复选框的形式呈现，支持多层次的结构，有助于确保开发过程的规范性和可追溯性。这种布局让开发者能够精准掌控 AI 的执行范围，使他们能够专注于单一任务，并通过任务状态的管理实时监控项目进度。

在 Cursor 的解释下，Kiro 的一些按钮设计引发了困惑。为何不统一命名？难道是担心被指责抄袭吗？

Kiro 采用了双重模式设计：

Vibe 模式：与 Cursor 的 Chat 模式相对应，允许用户与 AI 进行对话。
Spec 模式：对应 Agent 模式，逻辑上有所不同，展现了 Kiro 的核心竞争力。

深度解析 Kiro：其 Spec 工作流如何轻松超越 Cursor 并完美适配 Claude Code

原子化控制和回滚机制：Follow 按钮相当于 Accept 按钮，用于接受 AI 的修改建议。通过 Revert 机制，可以按 checkpoint 进行回滚。

深度解析 Kiro：其 Spec 工作流如何轻松超越 Cursor 并完美适配 Claude Code

Agent Hooks 自动化系统：Kiro 内置了基于文件事件触发的检查和通知机制。当 AI 需要开发者确认某些步骤（如执行 npm install）时，系统会自动发出提示，有效避免了 AI 编程中常见的“等待阻塞”现象。

深度解析 Kiro：其 Spec 工作流如何轻松超越 Cursor 并完美适配 Claude Code

为了更清晰地展示 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 则将这些设计转化为具体的、有依赖关系的编码任务。

输出结果：不仅生成高质量的代码，还提供了一套完整的、可直接用于团队合作的技术文档，大大提升了项目的规范性和可维护性。

从对比中可以明显看出，针对企业级复杂项目，Spec 工作流展现出了无与伦比的优越性。

五、跨平台实践：在 Claude Code 中重现 Kiro Spec 工作流

Kiro Spec 工作流的卓越之处在于其自身的方法论，因此，我们能够将这一严谨的开发流程完整迁移至 Claude Code，给项目增添不少价值。

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

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

2. 输入核心提示词：把从 Kiro 中提取并进行结构化的“完整的 Specs 系统提示词”内容，完整地复制并粘贴到这个 spec.md 文件中。这个提示词详细说明了 AI 在执行 /spec 命令时必须遵循的三大阶段（需求收集、设计、任务规划）工作流程，以及每个阶段的文档格式、约束条件和与用户的迭代交互方式。

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’处创建实施计划

抱歉，我无法满足该请求。

– 为了测试完整的应用流程，我们可以运行应用程序。然而，我们也能够编写自动化测试，以用户的视角来检验这一流程。

– 用户培训或文档的编写

– 业务流程或组织结构的变更

– 营销或沟通活动 - 任何无法通过编写、修改或测试代码完成的任务

– 在更新任务文档后，模型必须使用‘userInput’工具询问用户：“这些任务看起来还好吗？”

–‘userInput’工具必须以精确的字符串‘spec-tasks-review’作为理由使用

– 如果用户要求更改或未明确批准，模型必须对任务文档进行修改。

– 每次编辑任务文档后，模型必须请求用户的明确批准。

– 只有在收到明确批准（如“是”、“批准”、“看起来不错”等）之前，模型不得认为工作流程已完成。

– 模型必须持续进行反馈和修订，直至获得明确的批准。

– 一旦任务文档被批准，模型应停止操作。

** 此工作流程仅用于创建设计和规划文档。特性的实际实现应通过其他工作流程进行。**

– 模型不得在此工作流程中尝试实现特性

– 模型必须清晰地告知用户，一旦设计和规划文档创建完成，此工作流程即告结束

– 模型应告知用户，他们可以通过打开 tasks.md 文件并点击任务项旁的“开始任务”来开始执行任务。