Kiro用规范驱动开发：AI生成的代码怎么进工程体系

AI 编程工具的比拼，最近一年悄悄换了方向。

2025 年上半年，大家关心的是"能不能生成"——模型写出的代码能不能编译，能不能一次性跑通一个完整功能。到了 2025 年下半年，Cursor、GitHub Copilot、Codex CLI、Gemini CLI 以及 Kiro CLI 陆续把 Agent 推进终端，这时候生成能力本身已经很难拉开差距。

问题于是往后挪了：AI 写出来的代码，到底能不能进工程体系。

2025 年 7 月 16 日，亚马逊云科技首次发布 Kiro 预览版，当时给出的答案是 spec-driven development（规范驱动开发）。一年多下来，这套方法论走过了正式可用、工作流修正，也延伸到多 Agent 工作区。它究竟解决了什么，边界又画在哪里，下面逐一说明。

一、Vibe Coding 的成本只是被推迟了

Kiro 官网 FAQ 里的说法很直接：用氛围编码实现功能，很难一路追踪所有决策，也无法给团队留下清晰文档。这话不是修辞。放到实际开发里，vibe coding 的痛点已经相当具体：

• 长会话下的上下文衰减。开发者给出目标，模型拆解并生成多步代码，可交互轮次一多，它就糊涂了，前面约定好的接口定义、数据结构或约束条件会被忘掉，开发者不得不回溯好几轮重新引导，一旦涉及跨模块改造，这几乎躲不掉。

• 决策不可追溯。这一行为什么要这么改？当时的需求前提又是什么？事后都查不到。带来的结果并不好，单人项目里是效率问题，到了团队协作就成了治理问题。

• 从 Demo 到生产的鸿沟。生成的原型能跑，但需求文档、设计说明和测试覆盖都缺，要上生产还得靠人力回头补——说白了等于把工程化的活重做一遍。

也就是说，vibe coding 并没有让工程成本消失，只是把它变成技术债往后推。

Kiro 产品负责人 Nikhil Swaminathan 与开发者体验副总裁 Deepak Singh 在发布博客里，把 Kiro 定位成"从原型到生产"（prototype to production）。这个定位划出了它和 Cursor 这类工具的分界：后者更接近项目级 AI 编程助手，前者则想介入软件开发生命周期的前端。

二、Specs：把"先想清楚"变成可执行约束

Specs 是 Kiro 的核心机制。

它的工作流分成三段：

• requirements.md——按 EARS 格式（Easy Approach to Requirements Syntax）来写用户故事和验收标准。拿"为电商应用添加评论系统"举例，会自动覆盖查看、创建、筛选、评分等操作，每一项都带着明确的验收条件。

• design.md——技术设计，涵盖架构、数据流、接口定义，Kiro 会生成数据流示意图，缺了什么团队一眼就能看出来。

• tasks.md——任务拆解，每条任务都挂靠单元测试、集成测试、加载状态、移动端适配与无障碍支持等要素，开发者能逐条触发、查看进度，并通过代码差异和日志审计执行过程。

可要是只做到"先让 AI 写一份文档"，那也没什么新意。真正该留意的是 Spec 与代码库的双向同步：写代码可以更新 Spec，改 Spec 也能刷新任务列表。正是这一点，把它和"AI 生成一次性文档"彻底分开。Spec 不是开工前交差的前置产物，而是一份跟着项目演进、持续有效的契约。

官方说法是"Kiro 的 Spec 与你不断演进的代码库保持同步"。对于要长期维护的项目，这个差别是决定性的。

此外还有两项基础能力：

Hooks 属于事件驱动的 Agent 触发器。开发者保存或创建文件时被触发，Agent 自动执行预定义动作——例如更新相关测试文件、补齐样板代码。它把团队协作里那些"改了 A 别忘了改 B"的约定，变成了可执行的自动化。

Steering 是 Agent 的行为规则文件，项目级与全局配置都支持，作用类似 Cursor 的 Rules，但在 Kiro 里属于一等公民。关键在于 IDE 与 CLI 共用同一份 steering 文件、MCP 配置和订阅额度——终端里跑出来的行为和 IDE 里一致，不会变成两套割裂的体验。

三、PBT：把"正确性"变成可度量的对象

2025 年 11 月 18 日 Kiro 正式可用时，新增了几项能力：

• 这次 Kiro 正式可用是 2025 年 11 月 18 日的事，同期新增的能力包括基于属性的测试（Property-based Testing, PBT）、进度检查点（Checkpointing），以及 Kiro CLI 团队版订阅。

三项里技术含量最高的是 PBT，也是 Kiro 身上最"工程"的那块。做法是从需求里提取"属性"——一种普适性声明，比如"对任何已验证用户和任何活跃列表，该用户可以查看该列表"。哪些属性适合做逻辑测试由 Kiro 来判断，接着它会造出成百上千个随机用例去跑。

一旦撞上违规，Kiro 会用 shrinking 技术去找最小反例。这套流程更像一支专门来拆代码的红队，而不是传统那种样例测试。找到反例之后，Kiro 能自动改实现，也可以让开发者在调整规范、修改实现、修正 PBT 测试本身之间做选择。

这跟"AI 帮你写单测"不是一回事。单测看的是具体输入输出对不对，PBT 量的是实现与规范之间偏了多远。它把"正确性"从主观判断变成了能拿测试量化的东西。主流 AI 编码工具里，这个概念并不常见。

Checkpointing 管的是另一个问题：Agent 的变更得能回溯。Autopilot 模式下 Agent 会自己连着走好几步，方向一旦跑偏，退回某个检查点比重头引导省事得多。

Kiro 还提供 Autopilot 与 Supervised 双模式，前者让 Agent 自主执行多步操作、开发者随时可中断接管，后者要求每个操作都经过确认。不同阶段对可控性的要求不一样——探索期图效率，落地期要确定性。

四、从单次会话到长期运行：Kiro CLI 与 Kiro Crew

2025 年 11 月推出的 Kiro CLI 把整套能力搬进了终端，Claude Sonnet 4.5、Haiku 4.5 和 Auto Agent 被封装进命令行，构建功能、自动化工作流、分析错误、追踪 bug 并给出修复建议都能在数秒内完成，也支持定制 Agent。但真正的进度条发生在 2026 年。开发者开始同时调度多个 Agent，把代码迁移、故障排查、依赖升级这类任务交给它们连续跑数小时甚至更久，这时候卡住的不再是模型会不会写代码，而是 Agent 能不能跨会话记住项目背景、在没人盯着的时候安全执行，并且让开发者知道它到底做了什么。

Kiro Crew 就是在这样的情况下出现的，2026 年 8 月 4 日开源。它不替代 IDE，而是搭在 Kiro CLI 之上的持续运行工作区。

具体来说：持久记忆与状态保持，跨 Session 保留上下文、记忆和任务进度，应付长任务的上下文断裂；多 Agent 协作与调度，协调多个 Agent 并行执行，支持定时任务、Webhook 和状态监测，能持续盯着代码仓库、构建流水线与部署状态；经验沉淀，把纠正、失败和项目经验存成 Lessons，把重复的工作模式变成可编辑的 Skills；多端入口，Mac、本地 Container、远程机器都支持，入口覆盖 Desktop、Web、CLI、Slack、Discord；安全控制方面，官方称提供 7 层安全防护，覆盖运行隔离、权限控制、敏感信息保护和操作审计。

眼下 Agentic 编程工具最核心的工程命题可能就是：自主性必须配套可观测性和可干预性。

五、一次诚实的修正：design-first 与 bug-fix 工作流

到了 2026 年 2 月，Kiro 把 design-first 和 bug-fix 两条工作流加了进来。这次更新的分量，比之前任何一次功能上线都更值得细看：它实际上承认了规范驱动开发有个前提站不住脚——开发者很少是白手起家。真正要干的活，多半从一个现成代码库、一个难缠的 bug，或者一份已经过评审的架构方案开始。按 design-first 的做法，开发者可以拿已有的技术方案当起点，架构决策也好、实现草图也好，Kiro 会顺着这个起点把需求、设计规范和任务计划反推出来。

bug-fix 针对的则是已经存在的代码：它不让人一上来就动手改，而是先把当前行为、期望行为，还有哪些地方必须原封不动记下来，让调试变成一次不重的规范训练。工具主动去迁就开发者的习惯，而不是让开发者去迁就工具，这往往意味着它开始从方法论落到工程现实里了。

六、「鬼点子」——观察窗口的提供

从工程角度看，评估这类工具有一个方法论难题：拿标准 CRUD 场景去测，几乎没有区分度。这类需求在训练语料里密度极高，社区方案也成熟，绝大多数工具都能跑通，可跑通了也说明不了什么。

没有先验分布的开放需求，才是拉开差距的地方。模式匹配应付不了这类任务，必须真刀真枪做需求拆解、技术选型与任务规划。想检验 Agent 的规划水平和泛化能力，这种场景才是有说服力的压力测试。

换句话讲，AI 编程工具真正值钱的区间，正从"生成"挪向"交付"。

亚马逊云科技眼下在推的 Kiro「鬼点子计划」（点击阅读原文，报名活动），就提供一个可观察的样本。Kiro 走的路子是这样：生成过程由 Spec 来约束，规范符合度用 PBT 来衡量，团队约定靠 Hooks 和 Steering 固化下来，再用 Crew 把能力铺到长期运行的无人值守场景里。不过这条路不便宜——前期成本高，灵活性也受限，还对任务粒度有要求。换来的好处，则落在长期维护、团队协作和合规审计这些常被 vibe coding 略过的环节上。它在开放、非结构化的创意场景里是不是同样管用？这个问题 Kiro 自己也没完全给出答案，也正是这次「鬼点子计划」值得去掺一脚的原因。

活动介绍：

Kiro「鬼点子拍卖会」的现场实操名额还没关，10 月 23 日 QCon 上海站专场计划里的「鬼点子计划」路演 + 拍卖会欢迎来参与、来围观，一起造"世界上最伟大的发明"——记得带上电脑。

活动划出三个赛道：无用之用，比的是对开放性意图的理解与转化，作品看似没用，却好玩、治愈或者让人上瘾；无趣之趣，比的是长链路执行的一致性，把无聊的事做到极致；无心之心，比的是真实场景下的可靠性，用技术去表达关心。

• 开发工具方面，活动限定使用 Kiro（IDE、CLI、Web、Kiro Crew）。

活动价值：

• 前三名的奖品是 Kiro 大礼包（超级大奖哦～）

• 还能把真正属于你的"伟大发明"拿走（疯狂心动吧！）

• 顺带解锁 Kiro 的最新打开方式（现场有专家指导）。

• 也能多捞些"新点子"（看看别人怎么玩～）