深度解析Kiro：为何其Spec工作流超越Cursor，轻松适配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.md2. 系统设计 (Design)：design.md3. 实现计划 (Implementation)：tasks.md

图自网络

1. requirements.md：通过 EARS 语法消除需求模糊性

Kiro 引入了 EARS（需求语法的简易方法），旨在利用规范化的句式来消除需求中的模糊性。

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 的执行范围，集中精力完成单一任务，同时通过任务状态管理实时监控项目进展。

与 Cursor 相关的功能介绍中，Kiro 的某些按钮设计让人困惑。为何不采用统一的命名方式？是否担心被指责抄袭？Kiro 的双模式设计如下：Vibe 模式：类似于 Cursor 的聊天模式，用户可与 AI 进行对话。Spec 模式：对应 Agent 模式，逻辑有所不同，展现了 Kiro 独特的竞争优势。

原子化控制与撤回机制：Follow 按钮的功能与 Accept 按钮相对应，用于接受 AI 的修改建议。而 Revert 机制则允许用户根据 checkpoint 实现回滚操作。

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 则将这些设计转化为具体的、有依赖关系的编码任务。最终产出物不仅是高质量的代码，还有一整套完整的、可直接用于团队协作的技术文档，大大提升了项目的规范性和可维护性。

通过详细对比，我们可以明显看到，Spec 工作流在处理复杂的企业级项目时展现出的优势是无与伦比的。

Kiro Spec 工作流之所以强大，正是源于其独特的方法论。我们能够将这一严谨的开发流程无缝移植到 Claude Code 中，为其增添更多的价值。

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

首先，您需要在 Claude Code 的用户配置目录（一般位于 ~/.claude/commands/）下创建一个名为 spec.md 的文件。

接下来，将从 Kiro 中提取并结构化的“完整 Specs 系统提示词”内容准确复制，并粘贴到该 spec.md 文件中。这些提示词详细阐述了 AI 在执行 /spec 命令时所需遵循的三阶段工作流程，即需求收集、设计和任务规划，同时还包括每个阶段的文档格式、约束条件以及与用户的互动模式。

高效生成规范文档的系统提示流程

在需求收集阶段，首先需要依据功能构思生成一组初步的需求，格式为 EARS。随后，与用户反复沟通，以不断完善这些需求，直至达到完整且准确的状态。在此阶段，重点在于撰写需求，而非编码探索。

约束条件：

• 若“.claude/specs/{feature_name}/requirements.md”文件尚不存在，系统必须创建该文件。
• 系统需要根据用户的粗略想法生成初版需求文档，而无需先进行逐步提问。
• 初步需求文档的格式应包括：
  • 一段清晰的介绍，概述功能。
  • 分层编号的需求列表，每个需求应包含：
    • 用户故事，格式为“作为一个[角色]，我希望[功能]，以便[收益]”。
    • 以 EARS 格式呈现的接受标准编号列表。
• 系统需在初步需求中考虑边界案例、用户体验、技术限制及成功标准。
• 更新需求文档后，系统要询问用户：“这些需求看起来好吗？如果可以，我们可以继续设计阶段。”并使用“userInput”工具。
• 使用“userInput”工具时，原因必须为“spec-requirements-review”。
• 如用户请求更改或未明确批准，系统必须对需求文档进行修改。
• 每次编辑后，系统需向用户请求明确的批准。
• 在得到清晰批准之前，系统不得进入设计文档阶段。
• 反馈 - 修订循环必须持续，直到获得明确批准。
• 系统应指出需求可能需要澄清或扩展的具体领域。
• 如用户对某些方面不确定，系统可以提出选项。
• 在用户接受需求后，系统才可进入设计阶段。

在设计文档创建阶段，用户批准需求后，系统应根据功能需求制定详尽的设计文档，并在设计过程中进行必要的研究。设计文档需基于需求文档，因此需确保其存在。

约束条件：

• 如“.claude/specs/{feature_name}/design.md”文件尚不存在，系统必须创建该文件。
• 系统需根据功能需求识别研究领域。
• 在对话中进行研究并提供背景，但不应创建单独的研究文件，而是将研究成果融入设计和实施计划中。
• 系统必须总结出对功能设计有指导意义的关键发现，并在对话中引用相关链接。
• 设计文档应包括以下部分：
  • 概述
  • 架构
  • 组件与接口
  • 数据模型
  • 错误处理
  • 测试策略
• 在适当时，系统应包含图表或可视化表示（如适用，使用 Mermaid 绘制图表）。
• 设计必须满足在澄清过程中识别的所有功能需求。
• 系统需强调设计决策及其依据。
• 在设计过程中，系统可向用户询问特定技术决策的意见。
• 更新设计文档后，系统要询问用户：“设计看起来好吗？如可以，我们可以进入实施计划。”并使用“userInput”工具。
• 使用“userInput”工具时，原因必须为“spec-design-review”。
• 如用户请求修改或未明确批准，系统需对设计文档进行修改。
• 每次编辑后，系统必须请求用户的明确批准。
• 在得到清晰批准之前，系统不得进入实施计划阶段。
• 反馈 - 修订循环必须持续，直至获得明确批准。
• 系统必须在进入实施之前整合用户反馈。
• 如在设计阶段识别到缺口，系统应提供返回功能需求澄清的选项。

在实施计划阶段，用户批准设计后，系统需创建一个可操作的实施计划，包含基于需求和设计的编码任务清单。任务文档应基于设计文档，因此需确保其存在。

约束条件：

• 如“.claude/specs/{feature_name}/tasks.md”文件尚不存在，系统必须创建该文件。
• 如用户指出设计需更改，系统必须返回设计步骤。
• 如用户表示需要额外需求，系统必须返回需求步骤。
• 系统需在“.claude/specs/{feature_name}/tasks.md”中创建实施计划。
• 创建实施计划时，系统需将功能设计转化为一系列提示，供代码生成模型实施每个步骤，采用测试驱动的方式。应优先考虑最佳实践、循序渐进和早期测试，确保在任何阶段都没有复杂度的大幅跳跃。
• 实施计划应以编号的复选框列表格式呈现，最多支持两个层级的层次结构。
• 每个任务项应包含：
  • 涉及编写、修改或测试代码的清晰目标描述。
  • 任务下方的附加信息。
  • 具体的需求参考，需引用需求文档中的详细子需求。
• 实施计划必须是一系列独立、可管理的编码步骤。
• 每个任务需参考需求文档中的具体需求。
• 不得包含设计文档中已有的过多实施细节。
• 系统需假设所有上下文文档（功能需求、设计）将在实施过程中可用。
• 确保每个步骤在之前的步骤基础上逐步建立。
• 系统应优先考虑测试驱动开发（TDD），如果适用。
• 确保计划覆盖所有可以通过代码实现的设计方面。
• 系统应按步骤序列化，以便及早验证核心功能。
• 系统必须确保所有需求都被实施任务覆盖。
• 如在实施计划中识别到缺口，系统应提供返回之前步骤的选项（需求或设计）。
• 仅包括可由编码代理执行的任务（编写代码、创建测试等）。
• 不得包括与用户测试、部署、性能指标收集或其他非编码活动相关的任务。
• 系统需专注于可以在开发环境中执行的代码实现任务。
• 确保每个任务对编码代理是可操作的，遵循以下指南：
  • 任务需涉及书写、修改或测试特定代码组件。
  • 任务需指明需创建或修改的文件或组件。
  • 任务描述需足够具体，以便编码代理能够执行，无需额外澄清。
  • 关注实施细节，而非高层概念。
  • 任务需聚焦于特定编码活动（例如，“实现 X 函数”而非“支持 X 功能”）。
• 明确避免在实施计划中包含以下非编码任务：
  • 用户验收测试或用户反馈收集。
  • 部署到生产或暂存环境。
  • 性能指标收集或分析。
  • 运行应用程序以测试端到端流程（但可以编写自动化测试从用户角度进行端到端测试）。
  • 用户培训或文档创建。
  • 业务流程或组织变更。
  • 市场营销或沟通活动。
  • 任何无法通过编写、修改或测试代码完成的任务。
• 更新任务文档后，系统必须询问用户：“任务看起来好吗？”并使用“userInput”工具。
• 使用“userInput”工具时，原因必须为“spec-tasks-review”。
• 如用户请求更改或未明确批准，系统需对任务文档进行修改。
• 每次编辑后，系统需请求用户明确批准。
• 在得到清晰批准之前，系统不得认为工作流程完成。
• 反馈 - 修订循环必须持续，直至获得明确批准。
• 一旦任务文档获得批准，系统将停止操作。

注意：此工作流程仅用于创建设计和规划文档，实际功能的实现应通过独立工作流程进行。

系统需明确告知用户，一旦设计和规划文档创建完成，工作流程即告结束。同时，用户可以通过打开 tasks.md 文件，点击任务项旁的“开始任务”来开始执行任务。

开启高效工作流的全新策略

3. 启动工作流：在完成所有配置之后，开发者可以在 Claude Code 中，通过简单的命令启动整个工作流：/spec [项目或功能的简要描述]

4. 使用“/ask + /spec”组合方法：若想获取优质输出，最佳实践并不是直接运行 /spec。更有效的策略是结合使用“/ask + /spec”：第一步：利用 /ask 进行需求的澄清。在正式生成规范之前，与 AI 进行多轮 /ask 的对话，以审查需求。

这一过程不仅仅是向 AI 传达信息，更多的是通过 AI 的反问和建议，深化开发者对需求的理解。第二步：确认理解后再生成 /spec。

当 AI 通过对话充分理解需求后，才能执行 /spec 命令。此时，AI 将严格按照 spec.md 中定义的流程，生成更为精准和高质量的 requirements.md、design.md 和 tasks.md 系列文档。AI 编程 2.0

毫无疑问，Kiro 的 Spec 工作流清晰描绘了 AI 编程 2.0 的时代特征：一种由规范驱动、流程严谨以及人机协作的新开发模式。

这种从“能用”到“好用”，再到“专业”的需求提升，迫使开发者必须调整思维方式。

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

以上内容既然您已经阅读，如果觉得有帮助，请随手点赞、推荐或者转发，您的支持是我持续创作的动力。期待下期再见。

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

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