AI 生成的代码，怎么才能进得了工程体系？

2025 年上半年，话题还集中在"能不能生成"——模型能不能写出可编译的代码，能不能一次跑通一个完整功能。到 2025 年下半年，Cursor、GitHub Copilot、Codex CLI、Gemini CLI 以及 Kiro CLI 先后把 Agent 推进终端之后，生成能力本身已经很难再构成差异点。

亚马逊云科技在 2025 年 7 月 16 日第一次推出 Kiro 预览版时，给出的答案是 spec-driven development（规范驱动开发）。一年多过去，这套方法论经历了正式可用、工作流修正、以及向多 Agent 工作区的延伸。它解决的到底是什么，边界又在哪里，我们一篇文章讲清楚。

Kiro 官网 FAQ 里有一句相当直白的表述：用氛围编码实现功能时，很难一路追踪所有决策，也无法为团队留下清晰文档。这不是修辞。在实际开发中，vibe coding 的痛点已经非常具体：

长会话下的上下文衰减。开发者提出目标，模型拆解并生成多步代码，但交互轮次一长，它就傻了，模型会遗忘前面约定好的接口定义、数据结构或约束条件，开发者需要回溯好几轮重新引导，而这一点这在涉及到跨模块改造时几乎是必然发生的。

决策不可追溯。为什么这一行要这么改？当时的需求前提是什么？事后无从查证，这造成的结果并不好，可能对单人项目是效率问题，对团队协作则是治理问题。

从 Demo 到生产的鸿沟。生成出来的原型能跑，但缺少需求文档、设计说明和测试覆盖，要进生产，这些还得回头用人力补——本质上等于把工程化的活重做一遍。

换句话说，vibe coding 并没有消灭工程成本，只是把成本以技术债的形式推迟了。

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

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 是技术含量最高的一项，也是 Kiro 身上最"工程"的部分。它的思路是：从需求中提取"属性"——一个普适性声明，例如"对任何已验证用户和任何活跃列表，该用户可以查看该列表"。Kiro 判断哪些属性可以做逻辑测试，然后生成成百上千个随机测试用例去执行验证。

发现违规时用一种叫 shrinking 的技术寻找最小反例——这个过程更像一支专门来破坏代码的红队，而不是传统的样例测试。发现反例后，Kiro 可以自动更新实现，或让开发者选择调整规范、修改实现，或修正 PBT 测试本身。

这跟"AI 帮你写单测"是两件事。单测验证的是具体输入输出，PBT 度量的是实现与规范之间的偏离度。它把"正确性"从一个主观判断变成了可以被测试量化的对象。这个概念在主流 AI 编码工具中并不常见。

Checkpointing 解决的是另一个问题：Agent 的变更可回溯。在 Autopilot 模式下 Agent 会自主执行多个步骤，一旦方向跑偏，能回退到某个检查点比重新引导要高效得多。

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

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 编程工具当下最核心的工程命题可能是：自主性必须配套可观测性和可干预性。

2026 年 2 月，Kiro 新增了两条工作流：design-first 和 bug-fix。

这条更新比任何一次功能发布都值得琢磨，因为它等于公开承认了规范驱动开发的一个前提缺陷——大多数开发者并不是从零开始的。真实的开发任务往往起始于一个已有代码库、一个复杂 bug，或者一份已经评审通过的架构方案。design-first 允许开发者从已有的技术方案出发——架构决策、实现草图——由 Kiro 从这个起点倒推出需求、设计规范和任务计划。

bug-fix 则面向存量代码：它不让你直接跳到代码修改，而是先记录当前行为、期望行为，以及哪些部分必须保持不变，把调试变成一次轻量的规范练习。一个工具开始适配开发者的习惯，而不是要求开发者适配它，通常是它从方法论走向工程现实的分水岭。

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

真正有区分度的是那些没有先验分布的开放需求——它们无法靠模式匹配完成，必须真的执行需求拆解、技术选型和任务规划。这类场景才是对 Agent 规划能力与泛化能力的有效压力测试。

本次 Kiro「鬼点子拍卖会」现场实操名额还在开放中，欢迎参与 QCon 上海站的 10 月 23 日专场计划中的「鬼点子计划」路演 + 拍卖会，欢迎大家来围观并创造“世界上最伟大的发明”，我们希望你能带着电脑加入其中。