理念惊艳,体验拉胯:写在Kiro初体验之后

最近,随着一纸收购协议的尘埃落定,曾经备受瞩目 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 会创建以下几个详细的规范文件:

  1. 需求分析

Kiro 首先会将你的模糊提示,分解成具体的、可操作的需求点。

  1. 技术设计

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

  1. 任务分解

最后,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 最终是成为昙花一现的"概念产品",还是成为一个透明、可控、遵循规范的编码助手,我们拭目以待。

参考

kiro.dev/blog/introd...

kiro.dev/blog/from-c...

kiro.dev/blog/kiro-a...

kiro.dev/blog/automa...

相关推荐
尚学教辅学习资料1 小时前
我用Cursor,1周上线了一个虚拟资料流量主小程序技术选型
小程序·ai编程·cursor·流量主小程序·虚拟资料
AWS官方合作商2 小时前
深入解析 Amazon Q:AWS 推出的企业级生成式 AI 助手
人工智能·云计算·aws
sealaugh322 小时前
aws(学习笔记第四十九课) ECS集中练习(1)
笔记·学习·aws
Jack_num111 小时前
Claude Code 最新详细安装教程
ai·编辑器·ai编程·claude code
AWS官方合作商1 天前
从AWS MySQL数据库下载备份到S3的完整解决方案
数据库·mysql·aws
qiyue771 天前
别急还有救!Cursor国内无法使用 Claude
人工智能·ai编程·cursor
葫芦和十三1 天前
破局与重构:关于 UGC 平台多身份账号体系的架构思考
架构·ai编程·领域驱动设计
Jooolin1 天前
【C++】deque的设计思想
c++·后端·ai编程
WebCandy1 天前
Kiro AI IDE上手初体验!亚马逊出品,能否撼动Cursor的王座?
人工智能·ai·github·aigc·ai编程