你有没有过这样的时刻？打开AI编程助手，对着聊天框噼里啪啦敲了一大段需求，模型倒是秒回了——洋洋洒洒几百行代码，但你一跑就发现逻辑跑偏了。删掉、重写、再调试，几轮下来，半小时过去了，代码还没成型。这就是过去两年我用GitHub Copilot的典型循环：先写代码，然后重构。直到几周前，我在同事的强力安利下，尝试了AWS推出的Kiro IDE，才猛然意识到，原来生成式AI辅助开发可以完全是另一套打法。
Kiro这款工具，我是从一次实际任务中开始上手的。那时我们要给一个内部后台新增权限管理模块，按照以往的习惯，我下意识就打开了Copilot Chat，想先描述需求让它出个初版。但Kiro的思路完全不同：它上来不让我写半行代码，而是先拉着我定义“规格”。它问我：这个功能对外暴露什么接口？校验逻辑有哪些？跟现有哪些模块交互？我说得越清楚，它越不急——它把这些问题整理成一份需求文档，再拆成一张可执行的任务清单，最后才切换到代码实现。整件事下来，我感觉自己终于不是在“驯服”AI，而是在“协作”。
这种工作方式刚好击中了一个我一直想把Copilot用得更顺手的痛点。我以前想在Copilot里实现的是：先给我一个结构化的指令，然后让模型照着生成代码。但真操作起来，往往变成在Chat里反复澄清需求、不断修改提示词，来回倒腾。Kiro干脆把这个前置规划阶段自动化了。它所谓的“spec-driven”方法论，就是从需求到技术设计再到任务分解，一条线贯穿下来，代码只是最后一步的输出。这和我之前“先写出代码看看样子再改”的路径恰好相反，但效率却高得多。
从产品形态上看，Kiro的本质是一个基于VS Code开源版（Code OSS）构建的集成开发环境，本身就天然兼容VS Code的插件生态和编辑体验。不过，它的灵魂在于内嵌的那套AI工具——不是简单地接一个聊天面板，而是围绕规格驱动重新设计了人机协作流程。你定义蓝图，它帮你自动整理成清晰的任务列表；然后你可以选择逐条执行，也可以一次性跑完所有相关任务。这种“蓝图先行”的思路，让每一次代码生成都有了明确的基准，而不是漫无目的地猜测。
要让这种工作流发挥最大效力，项目根目录下一个叫AGENTS.md的文件至关重要。我第一次用时没太在意这个东西，直到后来在Kiro文档里看到，它其实会作用于每一次聊天交互。文件里应该简明扼要地说明项目的核心系统要求（比如架构团队定下的约束）、技术栈限制，还有常用的关键命令。不需要长篇大论，但要足够精准，让AI在每一次生成时都能遵循统一的项目规则。设定妥当之后，Kiro代理在执行任务时表现出的理解力明显上了一个台阶。
说到代理，Kiro的代理体系与Copilot的代理理念一脉相承：它们是自主、专精的AI助手，你可以根据具体任务类型选中不同的代理来帮忙。Kiro自带了一组内置代理，每次新建聊天会话时可以选择，同时也允许你创建自己的代理。不同版本的Kiro可能展示的代理略有差异，但其中“Spec代理”是这次着重体验的核心，它专门负责把模糊的功能想法落地成规格文件。当代理开始自动生成需求、设计规划、
热门跟贴