最近,随着一纸收购协议的尘埃落定,曾经备受瞩目 AI 编程工具 Windsurf,终于迎来了其曲折卖身之路的最终结局。
创始人和少数核心成员带着 24 亿美金并入了 Google,而剩下的大部分员工则连同空壳公司被打包卖给了 Cognition。
作为 Windsurf 最早的一批用户,我曾不遗余力地在社区里为它奔走相告。如今,我只能说哀其不幸,怒其不争。
只是,市场还不及我们唏嘘,新的搅局者便已入场,这次是云计算巨头亚马逊带来的「Kiro」。
Kiro 主打两大核心亮点:
- 规范驱动开发(Spec) :强调先规划后编码的严谨开发模式。
- 主动触发任务(Hook) :通过事件钩子实现开发流程的自动化。
在深入体验之后,我的初步评价是:
对于 Spec 模式,我认为其想法非常出色,但在具体的实施层面,还有很大的优化空间。无论是任务执行的稳定性、状态处理的准确性,还是多任务队列管理和上下文共享,都亟待改善。
对于 Hook 功能,我承认其形式足够新颖。它用自然语言替代了复杂的脚本配置,在一定程度上能帮我们更好地遵循规范、完成琐事。但就目前来看,它更多只能作为提效的辅助工具。
总而言之,现阶段的 Kiro 就好比一个刚刚得到绝世武功心法的人。虽有心法在手,但因为招式的基本功还很拙劣,导致无法将心法的威力真正施展出来。
它或许适合从零到一的氛围编程(Vibe Coding),但要用它来维护现有的大型代码库,恐怕还为时过早。
Vibe Coding 的随性与混乱
Vibe Coding 是当下很流行的一种编程模式。
这种模式鼓励我们,当脑海里有了一个初步想法时,即可与 AI 编程工具(如 Cursor)展开探索性的对话,并忽略代码实现细节,直接通过查看 AI 生成的结果来验证和持续迭代。
我们只需沉浸在这种编码氛围里,然后享受代码量指数级增长的快感即可。
但这种模式有一个明显的缺点:大部分 AI 编程工具并不会主动向我们澄清需求。它们会在还没有完全理解你的意图之前,就匆忙开始编写代码。
这就导致了,由于最初的需求不够清晰,我们需要花费大量精力,反复纠正和调整 AI 的生成内容。
这不仅让整个对话历史变得杂乱无章,充满了大量无用的信息,还严重挤占了宝贵的上下文空间。
而我们都清楚,当会话内容越来越长时,AI 生成结果的质量和完整性往往就会随之下降。
真正的编程不是发散式的,而是约束式的。 要理解这一点,我们不妨来看看专业程序员是怎么做的。
专业程序员的约束式编程
规范是对程序「应该做什么」、以及「应该满足哪些要求」的精确描述。专业程序员每天都在与规范打交道,从反馈工单到需求文档、再到测试用例等等。
这些规范的形式也各不相同:可以是一段简单的文本描述,也可以是交互原型图和视觉设计稿,还可以是一系列明确的性能指标定义。
整个项目正是依靠着这些具体而清晰的规范,一步步稳健地向前推进的。
首先,它能让产品、开发、测试等不同角色的成员,就"应用要实现什么目标"达成共识。这种高度的一致性可以极大提升团队的协作效率,避免因理解偏差导致的重复返工。
其次,程序员本身也遵循着各类编码规范,确保团队成员用统一的方式实现代码。这不仅降低了不同代码风格带来的理解成本,也有效减少了潜在的代码合并冲突。
简单来说,规范就是对目标的对齐,对结果的约束。
接下来,我们通过实际体验,来看一下 Kiro 是如何实现这种"规范驱动开发"的。
Spec:规范驱动开发的新模式
Kiro 内置了两种截然不同的工作模式:Vibe 和 Spec。
- Vibe 模式:先沟通,再构建。适合快速探索和测试各种想法,在需求尚不明确的情况下进行迭代开发或执行简单的任务,与其他 AI 编程工具的 Agent 模式差别不大。
- Spec 模式:先规划,后构建。要求在开始编码之前,先创建明确的需求并进行系统设计。它更适合用来深入思考功能细节,或者以结构化的方式构建需要前期规划的复杂项目。

在 Spec 模式下,Kiro 会将你的一个简单提示,转化为一套明确的需求文档、系统设计方案和具体的开发任务列表。

我们以一个简单的需求为例:"让 Kiro 为自己画一幅'自画像'",即创建一个介绍 Kiro 自身的网页。
Kiro 会创建以下几个详细的规范文件:
- 需求分析
Kiro 首先会将你的模糊提示,分解成具体的、可操作的需求点。

- 技术设计
接着,它会基于需求,给出一套包含架构决策、技术选型和实施方法的完整技术方案。

- 任务分解
最后,Kiro 会根据需求和设计规范,生成一系列具有明确验收标准的、细粒度的开发任务。这些任务会根据依赖关系进行正确排序,并将每个任务与最初的需求关联起来。

在这个过程中,如果对任何环节有不满意的地方,你都可以直接像编辑 Markdown 文件一样,对这些规范进行修改和调整。
但它与普通 Markdown 文件最大的区别在于,这个任务界面是可操作的。你可以逐个手动触发任务,

Kiro 会开启一个新的会话来执行它,并通过状态指示器直观地显示执行状态。

任务执行过程也允许随时中断或进行调整:

你甚至可以将 IDE 置于后台,让任务异步完成,只在需要你手动确认或操作时,才会通过通知来提醒你:

你也可以一次性开启多个任务,它们会自动进入队列,按顺序依次执行:

任务完成后,你可以查看完成状态,并通过检查代码差异(Diff)和回顾执行历史,来审核它的全部工作流程。

这种模式的好处是显而易见的:
- 透明度更高:模型的操作不再是一个完全的黑盒。你可以清晰地看到系统是如何被设计的,以及这些设计将如何影响你的项目。当然,实际的实现与最初的规划仍可能存在偏差。
- 参与感更强:用户不再是那个只会傻傻提要求的角色。通过深度参与从构思、设计到实施的每一个阶段,并仔细考量所有决策,理论上你最终会得到一个质量更高、更易于维护的应用程序。
最终它产出的是这样一个"自画像"网页:

Hook:用自然语言搞定自动化
在介绍 Kiro 的 Hook 功能之前,我们首先要理解,在编程领域中的「Hook」概念指的是什么。
它就像在墙上预先安装一个挂钩,你可以把任何自己的东西挂上去。
在程序运行的某些"关键时刻",系统或框架会提前留出一个这样的"钩子"。开发者可以在这个点上挂上自己的逻辑(比如一个函数或回调),从而让程序在那个时刻,按照你期望的方式去执行特定操作。
理解了这一点,我们再来看 Kiro 中的 Hook 可以用来做什么:
- 将任务委托给 Agent,这些 Agent 会在特定事件发生时(比如"文件保存时")被触发。
- Agent 会根据你预先定义的提示词指定的任务,在后台自主执行。
- 你可以利用 Agent Hook 来自动生成文档、编写单元测试,或者优化代码性能,扩展你的工作。
简单来说,就是你可以使用 Hook 来自动执行各种任务。
它可以帮你检查遗漏的内容,比如保持项目文档的实时更新;
也可以在后台完成那些重复的样板任务,比如为新函数编写单元测试。
甚至,你还可以让 Hook 强制团队执行统一的编码规范,以保持代码的可读性。
Hook 的最大意义,在于它标志着从被动 AI 辅助到主动 AI 集成的根本转变,关键它还是由自然语言驱动的。
Hook 主要由两个部分组成:
- 触发器:激活钩子的事件,例如保存、编辑、创建或删除文件。
- 动作:自动执行的 AI 响应,例如生成代码、更新文件或撰写文档。
与传统的开发自动化工具相比,Kiro 的 Hook 具有诸多优势:
- 自然语言配置:你不再需要编写复杂的脚本,只需使用简单的自然语言来定义钩子。
- 上下文感知:Kiro 的钩子能够理解你代码库的结构,并能更快地做出智能决策。
- 实时执行:操作在你工作时立即发生,帮助你维持流畅的开发心流。
- 协作共享:Kiro 的 Hook 可以通过版本控制系统(如 Git)与你的团队共享。
- 高度定制:你可以根据自己团队特定的工作流程和编码模式,来定制专属的自动化规则。
创建钩子的过程非常简单。只需在 "AGENT HOOKS" 菜单中点击"+"号,然后用自然语言描述当钩子被触发时,你希望 Kiro 采取什么行动即可。

比如这里我们让它监听文件变动并更新 README 文档。设置完成后,在相应的事件被触发时,Kiro 就会自动开启一个新会话,在后台为你完成工作。

Kiro 预览版的问题
尽管 Kiro 的设计非常贴合现实的工作流程,但目前的预览版在实际使用中,暴露出了相当多的问题,体验亟待提升,比如:
- 高失败率:任务执行的失败率非常高,经常需要手动点击重试。

- 不稳定性:Kiro 会频繁提示由于太多人使用导致系统稳定性不足。

- 状态更新不准确:任务状态的反馈不一定准确。我甚至遇到过在反复报错、什么都没有执行的情况下,Kiro 却提示任务已经完成的情况。

- 智能程度堪忧:面对一个简单的问题,它可能会陷入死循环,反复用同一种错误的方式进行尝试,最终也无法解决。

- 缺乏超时机制:Kiro 似乎没有做好超时处理,有时会长时间卡在某一个命令行上。

- 缺乏反馈机制:每次当 Kiro 处于"Editing"状态时,我完全不知道它在编辑什么,缺乏直观的反馈。

- 任务拆分过细,上下文丢失:Spec 模式会将一个简单的任务拆分得过于零碎,导致整体工作时长可能是普通 Agent 模式的好几倍甚至十几倍。更糟糕的是,任务与任务之间的上下文似乎不会传递,下一个任务需要重新检查文件、查看上一个任务的已有实现,导致整体的效率低下。

- 潜在的成本问题:这种高度自动化的模式,如果未来采用按对话次数或 Token 总量计费,对于用户来说可能会非常不划算。

- 模式冲突:Spec 模式与 Hook 功能如果同时使用,可能会产生逻辑上的冲突,特别是在 Spec 模式的状态处理错误时。

结语
总而言之,Kiro 既是对传统编程模式的一次复刻,也是对当前 AI 编程模式的一次革新。
它试图将专业软件工程中严谨的"规范驱动开发"思想,与 AI 的强大生产力相结合,解决当前 Vibe Coding 带来的混乱和低效问题。
不过目前的 Kiro 预览版在稳定性、智能程度和用户体验上还有巨大的提升空间,亚马逊能否沉下心来,将这套"绝世心法"的"招式"打磨好,将决定 Kiro 最终是成为昙花一现的"概念产品",还是成为一个透明、可控、遵循规范的编码助手,我们拭目以待。