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

当 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.md 2. 系统设计 (Design)：design.md 3. 实现计划 (Implementation)：tasks.md

图自网络

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 的按钮功能时，似乎有些命名不统一的情况，不知道是否是出于避免抄袭的考虑。Kiro 采用了双重模式设计：Vibe 模式类似于 Cursor 的聊天模式，用户可以与 AI 进行互动；而 Spec 模式则对应于 Agent 模式，拥有不同的逻辑，这也是 Kiro 的独特优势所在。

原子化控制与回滚机制：Follow 按钮可以理解为接受 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 工作流表现则截然不同：工作模式采用“系统工程思维”。

它首先生成详尽的需求和设计文档，将项目明确分解为用户系统、项目管理和任务流转等相互关联的独立模块。过程中的优势体现在 design.md 中，早已规划了完整的数据库 Schema、API 接口及 Socket.io 的集成方案。

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

对比分析后，我们不难发现，当涉及企业级复杂项目时，Spec 工作流展现出了显著的优势。接下来，我们将探讨如何在 Claude Code 中成功复现 Kiro Spec 工作流。

Kiro Spec 工作流的卓越之处在于其独特的方法论，这一开发流程可以毫无保留地迁移到 Claude Code 平台，为项目增添价值。

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

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

第二步，添加核心提示词：将从 Kiro 中提炼并整理的“完整 Specs 系统提示词”内容，直接复制并粘贴到 spec.md 文件中。这些提示词详尽描述了 AI 在执行 /spec 命令时所需遵循的三阶段工作流程——需求收集、设计和任务规划，以及每个阶段的文档格式、约束条件和与用户之间的迭代互动模式。

在 Specs 系统提示词中，需求收集阶段首先需要根据功能想法生成初步的需求集合，格式采用 EARS。此后，和用户进行多次迭代，以不断完善这些需求，确保其准确和完整。在这一阶段，关注的核心是撰写需求，而非代码探索。

需要注意的是，模型在这一阶段务必创建一个名为‘.claude/specs/{feature_name}/requirements.md’的文件，若该文件尚不存在。同时，初始的需求文档应基于用户的概念生成，且不应先提问以逐步获取信息。文档需要包含以下几个部分：明确的功能介绍、按层级编号的需求列表，每个需求都应包含用户故事和依据 EARS 格式的验收标准。

在需求文档更新后，模型应询问用户“这些需求还好吗？如果可以的话，我们就可以进入设计阶段。”使用‘userInput’工具，且需要使用精确的字符串‘spec-requirements-review’作为理由。若用户提出更改请求或未明确批准，模型需对需求文档作出修改，并在每次编辑后请求用户的明确批准。只有在用户清晰表示同意（如“是”、“批准”、“看起来不错”等）后，模型才能继续进入设计文档部分。

在用户批准需求后，设计文档的创建阶段随之展开。在这一过程中，模型必须基于用户的需求进一步开发全面的设计文档，并在设计过程中进行必要的研究。设计文档的构建需依附于需求文档，因此确保其已有是基本前提。设计文档中应包含概述、架构、组件与接口、数据模型、错误处理和测试策略等多个部分，并在适当时提供图示或可视化表示。

设计文档更新后，模型应询问用户“设计是否令人满意？如果是的话，我们就可以着手实施计划。”再次使用‘userInput’工具，理由为‘spec-design-review’。同样地，若用户对设计提出修改请求，模型需进行相应调整，并在每次编辑后请求明确的批准。

最后，实施规划阶段在用户确认设计后开始，此阶段需要创建一个可操作的实施计划，包含基于需求和设计的编码任务列表。实施计划需格式化为编号的复选框列表，确保每个任务都有明确的目标描述，且包含与需求文档相关的具体参考。在更新任务文档后，模型需再次询问用户“这些任务看起来好吗？”并在得到用户的明确批准后，工作流程方可视为完成。

整个工作流程专注于设计和规划文档的创建，具体的功能实现将通过单独的工作流程进行。模型需明确告知用户该工作流程已完成，并提醒他们可以通过打开 tasks.md 文件开始执行任务。

3. 启动工作流：在 Claude Code 中，开发者在完成配置后，可以简便地通过输入指令来激活整个工作流：/spec [项目或功能的简要描述]

4. 运用“/ask + /spec”的策略组合：为了确保输出质量达到最佳，直接运行 /spec 并不是最理想的选择。更有效的做法是结合“/ask + /spec”的方式来进行：第一步，借助 /ask 进行需求的澄清。在生成 Spec 之前，经过多轮与 AI 的对话，开发者应对需求进行深入评审。

这一过程不仅仅是信息传递，更是通过 AI 的提问和建议，帮助开发者加深对需求的理解。第二步，确认理解后再生成 /spec。

当 AI 在对话中形成全面而深入的需求理解后，便可以执行 /spec 命令。这时，AI 将严格按照 spec.md 中规定的流程，生成更符合实际需求的高质量文档，包括 requirements.md、design.md 和 tasks.md 等。

毫不夸张地说，Kiro 的 Spec 工作流为我们展示了 AI 编程 2.0 时代的轮廓：一个以规范为驱动、流程严谨的人机协作的新开发模式。

这种从“能用”到“好用”，再到“专业”的需求升级，要求开发者必须改变思维方式。

我们不应该再满足于仅用 AI 完成零散的功能，而应学会利用 AI 来构建和管理整个项目的工程体系。

如果您觉得以上内容对您有所帮助，欢迎点赞、推荐并分享，您的支持是我持续创作的动力。期待下次再见。

本文由人人都是产品经理的作者【饼干哥哥】创作，微信公众号为：【饼干哥哥 AGI】。未经授权，禁止转载。

题图来源于 Unsplash，基于 CC0 协议。