青石板上雨初收
旧巷苔深记故侯
檐角风铃吟往事
东风不系少女舟
发现没有，如果 cursor 用的久了，就会发现 cursor 也有不少的问题，经常会出现理解不到位，或者过度优化，导致 token 消耗过大。
不得不承认有时候我们对 cursor 的期望还是过大了，亚马逊把这一切都看在眼里，悄悄在背后推出新一代 AI IDE，名 kiro ，凭借其核心的Spec工作流，掀开AI 编程新范式。
什么是 specs 呢，对于这个单词，开发者都不会很陌生，下面就来说说
Spec（Specification，规格/规范）并非新概念，但在Kiro中，它被提升为一套结构化的编程方法论，可以解决AI辅助开发中普遍存在的上下文遗忘、需求理解偏差及工程质量不高等核心痛点。
kiro 与其他 AI IDE 不一样，它提出了一种新的编程策略，而非具体的 AI 编程战术技巧。
kiro 告诉我们，在做任何编码工作之前，必须先通过结构化的文档明确需求、设计与任务。
specs 这个工作其实在做任何一个需求的时候都会做的事情。有的公司并没有把 specs 文档化，比如输出需求文档，详细设计。
当然我也遇见有的公司还是在每做一个需求之前都会让开发自己或者其他人来写这样的文档，然后再开会议讨论确认，最后才开始动手编码。
在 kiro 里面，它把开发过程分为 3 个步骤
-
需求分析 (Requirements)：requirements.md
-
系统设计 (Design)：design.md
-
实现计划 (Implementation)：tasks.md
每个步骤都有对应的文档来体现，并保存在项目的.kiro目录下。
下面来具体说说这 3 个步骤的做法
第一个，需求文档
我们知道面对一份需求文档，每个人的理解都可能有差别，亚马逊也深知这个痛点，为此，kiro 引入了EARS（Easy Approach to Requirements Syntax）语法，以标准句式消除需求歧义。
如下是一个通用格式
用户故事 (User Story): As a [role], I want [feature], so that [benefit].验收标准 (Acceptance Criteria): WHEN [event] THEN the system SHALL [response].
里面不仅包含了需求本身，还说明了交付目标，通过需求文档可以通过 AI 生成对应的测试用例。
第二个，设计文档
设计文档是连接需求和最终实现的重要桥梁。
里面包含的内容是比较多的，包括架构图，组件和接口定义，数据模型，错误处理机制等。
一份好的设计文档可以让 AI 更加准确的去实现最终的代码。
第三个，任务文档
任务文档是把第二步的设计文档进一步细化拆分为可执行的任务，Kiro强调任务的原子性和可执行性，每个任务都应是离散、可管理的编码步骤，并明确关联到requirements.md中的具体需求点。
传统 cursor 模式和 kiro 模式区别
尽管目前所有的 AI IDE 基本上都是 chat 模式和智能体模式。但是 cursor 的思维方式倾向于，开发者提出一个功能点，AI直接生成代码，不过不符合，那么就需要和 cursor 反复沟通，缺乏对整体架构的考量。
kiro 则像一个系统架构师一样，不急着去实现代码，虽然写好像是程序员最有成就感的事，而是着眼于全局视野。按照三部曲来进行，磨刀不误砍柴工！