Kiro 的巧思：让 AI 先写规范，再动代码

多数 AI 编程工具把「写出第一版代码」当作主流程，Kiro 选择把注意力放到更麻烦的后一段：需求是否清楚，设计是否能被复查，代码改完后谁来发现遗漏。Kiro 的核心做法，是让 AI 先生成一组留在项目里的规格文件，再按规格执行任务；文件事件发生时，Agent Hooks 还可以在后台触发检查或补全。1

这个方向最近仍在快速迭代。7 月 17 日的 Kiro CLI 3.0 早期体验版加入了 Global Hooks：放在 ~/.kiro/hooks/ 的钩子可以在所有工作区生效，项目级钩子仍然可以同时存在。2 这不是又一个「让模型多写一点代码」的更新，而是在重新定义 AI 参与开发时应该留下什么中间物、在哪个时刻自动行动。

Kiro 不直接把「给商品加评论系统」翻译成一串代码。官方演示里，这个单句请求先被拆成查看、创建、筛选和评分等用户故事，每个故事再配上用 EARS 语法写的验收条件，把边界情况也写进需求文件。接着，Kiro 根据代码库和已批准的需求生成设计文档，里面可以有数据流图、TypeScript 接口、数据库结构和 API 端点；最后才生成按依赖关系排序的任务与子任务，并把任务连回原始需求。1

这里的设计选择很具体：AI 不再只交付一个结果，而是交付三种不同阅读尺度的对象。产品经理看需求和验收条件，工程师看设计与任务，执行过程中再看代码差异和 Agent 历史。任务可以逐个触发，完成状态会留在任务界面里，规格也能随代码变化而更新。1

这解决的是「模型到底替我补了哪些假设」的问题。聊天里的解释会随着上下文下沉，项目里的 Markdown 文件却能被提交、评论和重新打开。Kiro 官方仓库也把 Specs、Steering 和 Hooks 列为核心能力，说明这些文件不是一次性向导，而是产品的长期工作面。3

代价也很清楚：一次小改动可能先得到需求、设计和任务，初始速度比直接让 Agent 开始写代码慢；团队还要承担维护规格文件的成本。Kiro 试图用同步机制缓解这个问题，允许开发者让 AI 更新规格，或者手动修改规格来刷新任务。1 这意味着它把「快」从首轮生成速度，换成了后续返工少、责任边界更清楚的可能性，是否划算取决于项目有没有足够长的生命周期。

第二个选择更容易被低估。Kiro 的 Hooks 不是聊天里的一句「顺便帮我检查一下」，而是绑定在保存、创建、删除文件或手动触发等事件上的自动化。官方给出的例子包括：保存 React 组件时更新测试文件，修改 API 端点时刷新 README，提交代码前扫描泄露的凭据。钩子还可以提交到 Git，让同一套规则随项目进入团队工作流。1

事件触发改变了用户和 AI 的分工。聊天适合处理一次性的、不确定的问题；保存文件和提交代码则是稳定、可预测的时刻，适合交给自动化。产品没有要求用户每次都记得召唤 AI，而是把「何时值得让 AI 出手」固化成团队可讨论的规则。

7 月 17 日的 Global Hooks 又把这个对象从项目范围扩到工作区范围：全局钩子可以统一处理跨项目的 lint、提交前安全检查或审批门槛，不必在每个仓库重复配置。Kiro 同时保留项目级钩子，两个层级可以并存。2 这是一种很像操作系统的设计：局部规则服务当前项目，全局规则服务个人或团队的长期习惯。

它的风险也因此更具体。规则从「我现在要不要问 AI」变成「某个事件发生时，AI 是否会自动运行」，误触发、重复修改和权限边界都会变成真实的维护问题。尤其当钩子能写文件、调用工具或执行检查时，用户需要能看懂触发范围、执行结果和撤回路径，否则自动化只是把聊天里的不确定性藏到了后台。Kiro 的设计价值不在于消灭这些成本，而在于把成本暴露成可配置的项目对象。

Kiro 的独特之处，不是把 Agent 做得更像一个会聊天的同事，而是给 Agent 安排了三种可持续的落点：Steering 保存项目语境，Specs 保存需求到任务的链路，Hooks 保存何时自动行动的规则。它把 AI 的记忆、计划和动作都放进开发者能提交、审查和修改的文件与事件里。3

对其他 AI 产品来说，这里有一个可迁移的判断标准：如果 AI 要长期参与工作，产品应该先回答「它留下什么对象」和「它在什么事件上行动」，再回答「模型能不能多做一点」。Kiro 选择的答案更慢、更重，却让 AI 的假设和自动化边界有了可以被团队共同修改的地方。