当前位置：首页 > news >正文

告别“氛围编程”混乱！Kiro、Spec Kit等工具助力规范驱动开发

news 2026/6/2 19:24:22

Kiro、Spec Kit等工具助力规范驱动开发，告别“氛围编程”混乱！

2025年2月，AI开发者Andrej Karpathy在当时还叫Twitter的平台发推文，提到他所谓的“氛围编程”。他描述这种编程方式是完全沉浸在氛围里，追求指数级效果，甚至忘记代码存在。这可行是因为大语言模型（如集成了Sonnet的Cursor Composer）变得强大，他用SuperWhisper和Composer交流，几乎不用碰键盘，会提“愚蠢”要求，直接“全部接受”，遇到错误复制粘贴通常能解决问题。代码超出他通常理解范围，有时大语言模型无法修复bug，他就绕过或要求随机修改。不过，他只是在“周末临时项目”用“氛围编程”，非日常工作，还自嘲会提“愚蠢”要求。

虽然他说“氛围编程”可行是因大语言模型强大，且“大部分时候能正常工作”，但“大部分时候能正常工作”并非高度赞扬。将“氛围编程”用于严肃项目有严重风险，会产生隐藏bug和技术债务。即便有能力和经验的人清理重构代码，虽可能避免最坏结果、减少技术债务，但比手动设计架构和编写代码花费时间更多，还会降低程序员生产力，与使用大语言模型初衷背道而驰。

什么是规范驱动开发？

规范驱动开发（Spec - driven development，SDD）能避免“氛围编程”混乱，又无需完全回归手动编程。它比瀑布式规划和编写详尽需求文档更轻量级，设计得易于阅读和简洁。微软的Den Delimarsky介绍Spec Kit时，称规范为“思维的版本控制”，还表示这是代码行为的契约，是工具和AI代理生成、测试和验证代码的事实来源，可减少猜测和意外情况，提高代码质量。Thoughtworks的Birgitta Böckeler将其分为三个实现级别：

规范优先：先编写深思熟虑的规范，再在AI辅助开发工作流中用该规范完成任务。
规范锚定：任务完成后保留规范，用于相关功能的演进和维护。
规范即源：规范是主要源文件，随时间推移，只有规范由人工编辑，人工无需触碰代码。不过目前不确定有无工具实现，这是值得追求的目标，但尚未达到。

下面介绍目前支持规范驱动开发的四种工具和框架。

Kiro

AWS称Kiro是自主代理，能在独立完成软件开发任务时保持上下文并学习。它既可以作为IDE（基于Code OSS）使用，也有CLI工具版本，由“AWS内部一个有独特见解的小团队”开发。Kiro IDE明确支持“氛围编程”和规范驱动开发。目前Kiro CLI暂不处理规范，但有规划代理和代理引导功能。

Kiro SDD会生成三个Markdown文件构成规范：

需求（requirements.md）：用结构化的EARS符号记录用户故事和验收标准。
设计（design.md）：记录技术架构、序列图和实现考虑因素。
任务（tasks.md）：提供详细实现计划，含可离散跟踪的任务。

还能从其他系统导入规范并迭代，甚至根据“氛围编程”会话生成规范，理想情况是为每个项目功能创建一个规范。EARS符号记录用户故事遵循“WHEN [条件/事件] THE SYSTEM SHALL [预期行为]”模式，格式清晰可测试，Kiro能据此生成基于属性的测试（PBT），比通常单元测试更全面。

此外，Kiro还生成三个Markdown文件定义代理的引导信息，让Kiro了解工作空间及其约定：

产品概述（product.md）：定义产品目的、目标用户、关键功能和业务目标，助Kiro理解技术决策“原因”，提出符合产品目标的解决方案。
技术栈（tech.md）：记录所选框架、库、开发工具和技术约束，Kiro建议实现方案时优先考虑已有技术栈。
项目结构（structure.md）：概述文件组织、命名约定、导入模式和架构决策，确保生成代码融入现有代码库。

免费计划中，Kiro IDE支持三种Claude模型、Sonnet 4.5、Sonnet 4和Haiku 4.5，还可自动选模型。文档提到Opus 4.5，推测专业版（每月20美元）或更高级别计划可激活该模型。Kiro IDE支持“氛围编程”和规范驱动开发两种工作流。

Foundry Spec Kit

Spec Kit是微软推出的开源工具包，用于规范驱动开发。它提供分四个阶段的结构化流程，将规范驱动开发引入编码代理工作流，与约30种编码代理集成。

可通过安装specify CLI开始使用，建议用uv持久安装，也可用uvx运行一次。specify命令可初始化Spec Kit项目，还能选指定AI代理，检查已安装工具。项目初始化后，AI编码代理（如GitHub Copilot或Claude Code）可用几个斜杠命令进行结构化开发：

/speckit.constitution：项目管理原则
/speckit.specify：需求和用户故事
/speckit.clarify：澄清未明确区域
/speckit.plan：技术实施计划，包括技术栈
/speckit.tasks：可执行的实施任务列表
/speckit.analyze：一致性和覆盖范围分析
/speckit.implement：执行所有任务
/speckit.checklist：验证需求的检查清单

Spec Kit可从头创建项目（绿地项目）、对遗留代码现代化改造（棕地项目），并并行探索多种方案。关于如何使用及是否属“规范锚定”有讨论，但除观察到发布的Spec Kit倾向为每个功能制定小规范外，无普遍共识。

Tessl

Tessl口号是“用Tessl让你的代理按部就班”，通过框架、包注册表及评估功能，在CLI辅助下实现。Tessl CLI可扫描项目依赖项，为Claude Code、Codex和Gemini等AI编码代理配置模型上下文协议（MCP）服务器设置，还能在包注册表中按名称、PURL或HTTP URL搜索“模块”。模块含技能、文档和规则，可使用现有注册表，也可创建自己的技能和模块。

用Tessl的Tessl SDD模块可进行规范驱动开发，安装后在提示中包含“使用规范驱动开发”，代理会在编写代码前询问问题并编写规范，还可通过安装记录所用工具的模块提高效果。

Zenflow

Zenflow是免费平台，用于协调AI代理构建软件，有“规范驱动的工作流、内置验证和真正有效的多代理执行”功能，也被描述为编排层。它由Zencoder团队开发，与Zencoder插件配合使用，其部分功能已添加到Zencoder中。Zencoder的CEO Andrew Filev称，经验丰富的工程师团队已用Zenflow进行产品开发一年多。

Zencoder和Zenflow关系可概括为：Zenflow是工作流的大脑，Zencoder负责执行工作。Zencoder既是公司名称，也是IDE的AI插件名称，还是公司内部编码代理名称，是Zenflow四个代理选项之一，也是Zencoder插件至少可用的九种模型之一。

启动Zenflow项目可选择标准工作流：快速更改、修复bug、规范与构建或完整的SDD工作流，项目范围越广，工作流需更多结构确保不偏离需求，也可定义符合团队标准的自定义工作流。

Zenflow可在隔离环境中并行运行多个任务，代理在工作流中协调，不破坏代码库。它会自动验证更改，每个工作流运行自动化测试和跨代理代码审查，测试失败触发自动修复，通过所有验证关卡后代码才能发布。

Zenflow项目分解为任务，任务再分为子任务和聊天，每个任务在自己的隔离Git工作树中运行，可在看板或堆叠列表视图中查看任务状态。它支持多种工作流，也可定义自定义工作流。