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：把"先想清楚"变成可执行约束 Kiro 的核心机制是 Specs。 它的工作流是三段式的： 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 正式可用时，新增了几项能力： 基于属性的测试（Property-based Testing, PBT） 进度检查点（Checkpointing） Kiro CLI 团队版订阅 其中 PBT 是技术含量最高的一项，也是 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，把