最近，随着一纸收购协议的尘埃落定，曾经备受瞩目 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 最终是成为昙花一现的“概念产品”，还是成为一个透明、可控、遵循规范的编码助手，我们拭目以待。
