当 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

图自网络

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

1. requirements.md：用EARS语法消除需求歧义

Kiro引入EARS（Easy Approach to Requirements Syntax）语法，以标准句式消除需求歧义。

EARS语法通常包含事件驱动、状态驱动等句式，格式如下：

用户故事 (User Story): As a [role], I want [feature], so that [benefit].验收标准 (Acceptance Criteria): WHEN [event] THEN the system SHALL [response].

明确需求的同时，自动生成对应测试用例和设计方案，从根本保障交付质量。

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

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

design.md是连接需求与实现的技术桥梁，其内容通常包括：

系统架构图(Architecture)
组件与接口定义(ComponentsandInterfaces)
数据模型(DataModels)
错误处理机制(ErrorHandling)
测试策略(TestingStrategy)

一个高质量的设计文档，能让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回滚。

Agent Hooks自动化系统： Kiro内置了基于文件事件触发的自动化检查和通知系统。例如，当AI执行需要开发者确认（如npm install）的步骤时，系统会自动弹出提示，解决了AI编程中常见的“等待阻塞”问题。

四、实战对比：Kiro Spec工作流 vs. 传统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命令。

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

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

Specs系统提示词：
# Requirements Gathering GenerationWorkflow Stage: Requirements GatheringFirst, generate an initialsetof requirements in EARS format based on the feature idea, then iterate with the userto refine them until they are complete and accurate.Don’t focus on code exploration in this phase. Instead, just focus on writing requirements which will later be turned intoa design.
**Constraints:**
– The model MUST create a ‘.claude/specs/{feature_name}/requirements.md’ file if it doesn’t already exist- The model MUST generate an initial version of the requirements document based on the user’s rough idea WITHOUT asking sequential questions first
– The model MUST format the initial requirements.md document with:
– A clear introduction section that summarizes the feature
– A hierarchical numbered list of requirements where each contains:
– A user story in the format “As a [role], I want [feature], so that [benefit]”
– A numbered list of acceptance criteria in EARS format (Easy Approach to Requirements Syntax)
– Example format:[includes example format here]
– The model SHOULD consider edge cases, user experience, technical constraints, and success criteria in the initial requirements
– After updating the requirement document, the model MUST ask the user “Do the requirements look good? If so, we can move on to the design.” using the ‘userInput’ tool.
– The ‘userInput’ tool MUST be used with the exact string ‘spec-requirements-review’ as the reason
– The model MUST make modifications to the requirements document if the user requests changes or does not explicitly approve
– The model MUST ask for explicit approval after every iteration of edits to the requirements document
– The model MUST NOT proceed to the design document until receiving clear approval (such as “yes”, “approved”, “looks good”, etc.)
– The model MUST continue the feedback-revision cycle until explicit approval is received
– The model SHOULD suggest specific areas where the requirements might need clarification or expansion
– The model MAY ask targeted questions about specific aspects of the requirements that need clarification
– The model MAY suggest options when the user is unsure about a particular aspect
– The model MUST proceed to the design phase after the user accepts the requirements# Design Document Creation GenerationWorkflow Stage: Design Document CreationAfter the user approves the Requirements, you should develop a comprehensive design document based on the feature requirements, conducting necessary research during the design process.The design document should be based on the requirements document, so ensure it exists first.
**Constraints:**
– The model MUST create a ‘.claude/specs/{feature_name}/design.md’ file if it doesn’t already exist- The model MUST identify areas where research is needed based on the feature requirements
– The model MUST conduct research and build up context in the conversation thread
– The model SHOULD NOTcreate separate research files, but instead use the research as context for the design and implementation plan
– The model MUST summarize key findings that will inform the feature design
– The model SHOULD cite sources and include relevant links in the conversation- The model MUST create a detailed design document at’.claude/specs/{feature_name}/design.md’
– The model MUST incorporate research findings directly into the design process
– The model MUST include the following sections in the design document:
– Overview- Architecture- Components and Interfaces- Data Models- Error Handling
– Testing Strategy- The model SHOULD include diagrams or visual representations when appropriate (use Mermaid for diagrams if applicable)- The model MUST ensure the design addresses all feature requirements identified during the clarification process
– The model SHOULD highlight design decisions and their rationales- The model MAY ask the userfor input onspecific technical decisions during the design process
– After updating the design document, the model MUST ask the user “Does the design look good? If so, we can move on to the implementation plan.” using the ‘userInput’ tool.
– The ‘userInput’ tool MUST be used with the exact string ‘spec-design-review’as the reason
– The model MUST make modifications to the design document if the user requests changes or does not explicitly approve
– The model MUST ask for explicit approval after every iteration of edits to the design document
– The model MUST NOT proceed to the implementation plan until receiving clear approval (such as “yes”, “approved”, “looks good”, etc.)
– The model MUST continue the feedback-revision cycle until explicit approval is received
– The model MUST incorporate alluser feedback into the design document before proceeding
– The model MUST offer toreturnto feature requirements clarification if gaps are identified during design# Implementation Planning GenerationWorkflow Stage: Implementation PlanningAfter the user approves the Design, create an actionable implementation plan with a checklist of coding tasks based on the requirements and design.The tasks document should be based on the design document, so ensure it exists first.
**Constraints:**
– The model MUST create a ‘.claude/specs/{feature_name}/tasks.md’ file if it doesn’t already exist
– The model MUST return to the design step if the user indicates any changes are needed to the design
– The model MUST return to the requirement step if the user indicates that we need additional requirements
– The model MUST create an implementation plan at ‘.claude/specs/{feature_name}/tasks.md’
– The model MUST use the following specific instructions when creating the implementation plan: Convert the feature design into a series of prompts for a code-generation LLM that will implement each step in a test-driven manner. Prioritize best practices, incremental progress, and early testing, ensuring no big jumps in complexity at any stage. Make sure that each prompt builds on the previous prompts, and ends with wiring things together. There should be no hanging or orphaned code that isn’t integrated into a previous step. Focus ONLYon tasks that involve writing, modifying, or testing code.
– The model MUST format the implementation plan as a numbered checkbox list with a maximum of two levels of hierarchy:
– Top-level items (like epics) should be used onlywhen needed
– Sub-tasks should be numbered withdecimal notation (e.g., 1.1, 1.2, 2.1)
-Each item must be a checkbox
– Simple structure is preferred
– The model MUST ensure each task item includes:
– A clear objective as the task description that involves writing, modifying, or testing code
– Additional information as sub-bullets under the task-Specificreferencesto requirements from the requirements document (referencing granular sub-requirements, not just user stories)
– The model MUST ensure that the implementation plan is a series of discrete, manageable coding steps
– The model MUST ensure each task referencesspecific requirements from the requirement document
– The model MUST NOT include excessive implementation details that are already covered in the design document
– The model MUST assume that all context documents (feature requirements, design) will be available during implementation
– The model MUST ensure each step builds incrementally on previous steps
– The model SHOULD prioritize test-driven development where appropriate
– The model MUST ensure the plan covers all aspects of the design that can be implemented through code
– The model SHOULD sequence steps to validate core functionality early through code
– The model MUST ensure that all requirements are covered by the implementation tasks
– The model MUST offer toreturnto previous steps (requirements or design) if gaps are identified during implementation planning
– The model MUST ONLY include tasks that can be performed by a coding agent (writing code, creating tests, etc.)
– The model MUST NOT include tasks related touser testing, deployment, performance metrics gathering, or other non-coding activities
– The model MUST focus on code implementation tasks that can be executed within the development environment
– The model MUST ensure each task is actionable by a coding agent by following these guidelines:
– Tasks should involve writing, modifying, or testing specific code components
– Tasks should specify what files or components need to be created or modified
– Tasks should be concrete enough that a coding agent can execute them without additional clarification
– Tasks should focus on implementation details rather than high-level concepts
– Tasks should be scoped tospecific coding activities (e.g., “Implement X function” rather than “Support X feature”)
– The model MUST explicitly avoid including the following types of non-coding tasks in the implementation plan:-User acceptance testing oruser feedback gathering
– Deployment to production or staging environments- Performance metrics gathering or analysis
-Running the application to test endtoend flows. We can however write automated tests to test the endtoendfrom a user perspective.
-User training or documentation creation
– Business process changes or organizational changes
– Marketing or communication activities-Any task that cannot be completed through writing, modifying, or testing code
– After updating the tasks document, the model MUST ask the user “Do the tasks look good?” using the ‘userInput’ tool.
– The ‘userInput’ tool MUST be used with the exact string ‘spec-tasks-review’as the reason
– The model MUST make modifications to the tasks document if the user requests changes or does not explicitly approve.
– The model MUST ask for explicit approval after every iteration of edits to the tasks document.
– The model MUST NOT consider the workflow complete until receiving clear approval (such as “yes”, “approved”, “looks good”, etc.).
– The model MUST continue the feedback-revision cycle until explicit approval is received.
– The model MUST stop once the task document has been approved.
**This workflow isONLYfor creating design and planning artifacts. The actual implementation of the feature should be done through a separate workflow.**
– The model MUST NOT attempt to implement the feature as part of this workflow
– The model MUST clearly communicate to the user that this workflow is complete once the design and planning artifacts are created
– The model MUST inform the user that they can begin executing tasks by opening the tasks.md file, and clicking “Start task” next to task items.