作者 | Bö

译者 | 王强

策划 | Tina

我始终都在尽力去尝试理解那最新的AI编程流行语，规范驱动开发，也就是SDD，我查看了三个宣称自己是SDD的工具，并且特意去试着弄明白它们所代表的含义 。

定 义

如同诸多于这个节奏快速的领域里冒出来的新兴术语那般，“规范驱动开发”（SDD）的定义依旧处于变动之中，以下是我依据截至目前的运用情形所能搜集到的信息，规范驱动开发指的是，在借助AI编写代码以前，要先撰写一个“规范”（“文档优先”），规范变成人类与AI的真相源头。

于这个全新问世的世界当中，对软件予以维护所代表的意义便是促使规范得以发展，开发所使用的通用具备广泛适用性的语言迈向了更高的层级，代码属于达成最终阶段目标的解决办法。

Tessl指出，存在这样一种开发方法，在此方法里，规范成了主要产物，而非代码，规范运用结构化、可测试的语言来描述意图，并且有Agent负责生成代码去匹配这些规范 。

在查看了该术语的使用情形以及一些宣称正在达成 SDD 的工具之后，于我看来，事实上，SDD 存在多个实现层面，。

首先，去编写一个经过了那般深度周全仔细且反复考量思索琢磨的规范，而后呢，把这个规范运用到当下这个任务的人工智能辅助开发工作流动过程序之中 。

规范进行锚定，即便处在任务完成之后的情况，规范依然会被留存下来，目的是能够持续用于对应功能的演变以及维护。

演变成源的规范，历经时间的推进，规范摇身变为主要的源文件，人类单单对规范予以编辑，始终不去触碰代码 。

我所寻觅而得的全部SDD方法、定义，皆是规范占先的，然而并非尽数都着力达成规范锚定、规范致源，还有随着时间有所变动，规范维护策略经常是含混模糊的，又或是全完全然开放的。

规范是什么？

当然，关键问题存在于定义方面，那就是：规范究竟是什么？似乎并不存在普遍通用的定义，我所见到的最为一致的定义，是对规范和“产品需求文档”做出对比 。

目前这个术语包含的东西太多了，以下是我尝试定义规范的尝试：

规范呢，它是一种结构化的、面向行为的产物，或者说是一组相互关联的产物，它是用自然语言编写而成的，其作用在于表达软件功能，同时还作为AI编程Agent的指导依据。而每种规范驱动开发的定义，都对规范的结构作出了定义，对细节水平给出了界定，并且还明确了这些产物在项目里的组织方式的方法。

我觉得规范跟代码库的一般性上下文文档之间存在着显著差异，那些一般性上下文属于规则文件，或者是产品以及代码库的高级阐述，某些工具把这个上下文称作记忆库，所以我在这儿会采用这个称谓，这些文件跟代码库中的所有AI编程会话有联系，而规范仅仅跟实际去创建或者变更特定功能的任务有关联。

评估 SDD 工具的挑战

有事实表明，对SSDD工具以及方法通过接近实际运用的形式去进行评估，这是极为耗费时间的。要为其试用不同大小的问题、绿地、棕地，并且要真正切实投入时间去审查以及修订处于中间阶段的产物，并非仅仅是粗略地看上一眼就行。这是因为，就像关于spec-kit的博客文章所讲的那样：“重点在于，你的角色并非单纯是引导，而是验证。在每一个阶段，你都得去反思以及提炼。”。

我尝试了三个工具，其中两个的情形是，看上去要把它们引入现有的代码库，所需的工作量更大，所以更不方便评估它们对于棕地代码库有无用处。在我听闻人们在“真实”代码库上使用它们一阵子的使用报告之前，我依旧存在许多关于这在实际生活里如何运作的尚未解决的问题。

尽管话是这么讲，不过呢，我们还是着手去深入探究这三个工具吧。我会先去分享关于它们工作方式的描述，确切来讲呢，是我所认为的它们的工作方式，然后把我的观察以及问题留到最后。需要注意的是，这些工具处于快速发展的状态，故而自从九月份我使用它们以来，它们有可能已经出现了变化。

Kiro

尝试过去的三个工具里，Kiro是其中最为简单的那个，或者说，是最轻量级那种。看似它主要将规范当作首要考量，我寻找到的全部示例，都是借助它去达成一项任务，或完成用户故事，却丝毫没有提及，在多个任务进程里，随时间慢慢推进时，该如何运用规范锚定的需求文档 。

工作流：需求 → 设计 → 任务

每一个工作流步骤，均是由一个文档予以表示的，在其基于VS Code的分发里头，Kiro会指导着你去完成这3个工作流步骤。

作为一个需求被整理，它要以需求列表的形式进行结构化，每个需求都得代表一个“用户故事”，并且每个“用户故事”都要有验收标准，验收标准要以“给定… 当… 那么…”的格式呈现 。

进行设计时，于我的那次尝试里面，设计文档是由像下图所表现的那些部分構成的。在此处仅仅存在我那次尝试期间的一个结果，因而我无法确定这究竟是一种始终保持一致的结构呢，还是会依据任务存在不同而发生变动的 。

任务，是一个任务列表，它要追溯到需求编号，还要得到一些额外的UI元素，以便逐个运行任务，并且要按任务审查更改。

Kiro 存在一个被他们称作“指导”的记忆库概念，其内容具备灵活性，他们运用的工作流好像并不依存于任何特定文件的存有情况（在我发觉指导部分之前就试着进行了一番运用），当你向 Kiro 提出生成指导文件的请求时，默认拓扑结构是 .md、.md、tech.md 。

Spec-kit

Spec-kit 是那个SDD版本 ，它作为一种CLI进行分发 ，能够为众多常见编程助手创建工作区设置 。一旦将这个结构设置妥当 ，你能够借助编程助手中的斜杠命令与 spec-kit 展开交互 。由于所有工件都直接放置到你的工作区 ，所以它是这里所讨论的三个工具里最具可定制性的 。

工作流：宪法 → 指定 → 计划 → 任务

Spec-kit的记忆库概念，是规范驱动方法的先决条件，他们把这个先决条件称作宪法，宪法应涵盖“不可变”的高层原则，且该原则要始终应用于每次更改，它本质上是一个极为强大的规则文件，被工作流大量运用。

在每个工作流步骤里，这步骤包括指定、计划、任务，spec-kit借助bash脚本以及一些模板来实例化一组文件和提示。而后，工作流在文件中大量运用清单，以此跟踪必要的用户澄清、宪法违规、研究任务等。它们如同每一个工作流步骤的“完成定义”，尽管由AI进行解释，因而没有100%的保证它们可被尊重。

从下面给出的是一个概述来看，它说明了我于 spec - kit 里头所看到的文件拓扑结构，要注意的是，此处存在一个情况，那就是一个规范是会由许多文件组合而成的句号！

初看之下，好像期望去做一种有着规范锚着的办法，（“之所以我们正在重新思索规范，并非当作静态的文档，而是作为伴随项目进展而演化的鲜活且可实施的工件。规范变成共享的真相源头。当某件事没道理时，你返回规范；当项目变得繁杂时，你使它完备；当任务感觉规模极庞大时，你把它们拆分。”）。然而，spec-kit为每个新建的规范打造一个分支，这般看来，似乎表明他们把规范视作一个变更请求的生命周期里活生生的工件，并非一个功能的生命周期。社区当中有一个讨论帖正在探讨这种混淆。这致使我联想到spec-kit依旧是我所讲的规范优先，而非随时间规范锚定的举措。

Tessl 框架

（仍在非公开测试阶段）

Tessl框架，如同spec-kit那般，是以命令行界面也就是CLI的形式来进行分发的，它能够针对各种编程助手去创建所有的工作区以及配置结构，CLI命令同时还充当着MCP服务器。

Tessl于这三个工具里，是唯一明确追寻以规范当作锚的方法的那个，其还探索了规范就是源的系统设计文档，俗称SDD的那个级别哦。Tessl规范可行使其作为被维护以及编辑的主要工件的职责，代码方面呢，甚至在顶部利用注释标记成了 // 从规范生成 - 请勿编辑这样子。目前的状况是，规范跟代码文件两者之间呈现的是1:1的映射关系，也就是说，一个规范会被转换成为代码库里面的一个文件呢 。然而，Tessl所处的状态是仍处于测试阶段，他们当下对多不同版本进行着尝试，所以呢，我能够想象得出这样一种方法也是能够在将规范映射到拥有多个文件的代码组件的那个级别上予以采用的。至于alpha产品会支持哪些能力，这还有待于进一步观察。（Tessl团队自身是把他们的框架视作比他们当前的那个公共产品，也就是Tessl注册表，更具未来特性的事物的。）。

我让 Tessl CLI 进行逆向工程了，这是从一个现有代码库中的代码文件里呈现规则的例子参照，关于这点，tessl 文档中是通过具体参数形式（tessl 文档 --code ...js）指示的。

这样的标签，诸如 @ 或者 @test 之类，好像是在告知 Tessl 究竟要生成些什么。API 那一部分，展现出了在规范里定义至少要暴露给代码库其他部分的接口的这种想法，大概而言，是为了保证这些更为关键的部分所生成的组件全然处于维护者的掌控范围之内。运行 tessl build，会为这个规范生成与之相应的代码文件。

把规范当作源代码置于相当低的抽象层次，这一层次即在每个代码文件里，如此或许减少了大型语言模型也就是LLM必须去执行的步骤以及解释，所以降低了出错的机会，纵然处在这个低抽象层次，我也察觉到了非确定性的影响，当我多次从同一个规范来生成代码时便能够看出来，迭代规范并让其愈发具体以便增加代码生成的可重复性是一项有意思的练习，这个过程使我回想起撰写一个明确且完整的规范时的一些陷阱与挑战 。

观察和问题

说这三个工具竞相宣称自身为规范驱动开发也就是（SDD）的达成体现，然而它们相互间极为不同，因此这是谈及 SDD 之际首先得记住的，它并非单单只是一件事情 。

一个适用于所有规模的工作流？

Kiro给出了一个有偏见的工作流，spec - kit也给出了一个有偏见的工作流，然而我相当确定，它们都不适用于多数现实编程问题，特别是，我不太清楚，它们要怎样满足足够多的不同问题规模的需求，进而才能够具备普遍适用性。

当我向 Kiro 询问修复一个小错误的时候，这个小错误是我过去用来尝试 Codex 的相同错误，很快就明晰了，这个工作流宛如用大锤去砸坚果。需求文档把这个小错误转变为了 4 个“用户故事”，总共存在 16 个验收标准，包含这样的“用户故事：身为一个开发者，我期望转换函数能够优雅地应对边缘情况，从而在引入新的类别格式之际系统维持健壮。”。

当我运用 spec-kit 的时候，我同样碰见了相近的难题，我不太明确拿它去处理多大的问题才合适。可获取的教程一般讲的是从起始点着手创建应用程序的部分，因为这对教程而言是最为简便容易的。我最终尝试的一个用例是我以往团队中曾用过的 3 至 5 点的故事。该功能依赖于已然存在的数量众多的代码，它应当构建一个概述模态，这个模态总结了来源于现有的仪表板的数量众多的数据。鉴于 spec - kit 所施行的步骤数目，以及它为我缔造的文件数量（目的是供我予以审查），就问题的规模而论，这依旧给人一种大题小做的感觉。这是一个超出 Kiro 问题规模的问题，不过同时也是一项更为繁杂的工作流程。我甚至都未曾达成全面的实现，然而我觉得在与运行和审查 spec - kit 结果相同的时长内，我能够借助“纯粹”的 AI 辅助编程达成此项功能，届时我会更具掌控感。

一个具备有效性的SDD工具，起码得为不同尺寸以及类别各异的变更，供给几种有着不同核心工作流程的灵活性 。

审查 而不是代码？

就像你于上述工具描述里头所瞧见的那般， spec - kit给我构建出好些文件以供我去审查。这些文件相互其间内容交织缠绕，并且跟已然存在的代码存在重复情况。其中有些甚至是含有代码的。总而言之，它们仅是极为冗长又枯燥乏味，极难进行审查。在Kiro里头，这略微要轻松一点，究其原因乃你仅获取到3个文件，并且更易于领会“需求>设计>任务”这样的心智模型。然而，正如前面所提及的那样，Kiro对于我要求它修正的那些小错误而言同样是太过冗长了。

老实说说，我宁可审查代码，而非所有这些文件。一个具备有效性的SDD工具得提供相当不错的规范审查体验。

控制的错觉？

就即便具备了所有这些文件，所有这些模板，所有这些提示，所有这些工作流，所有这些清单而言，我每每都会看到 Agent 最终未将所有指令一一遵循。没错，上下文窗口如今是更大了codejock 16，它常被当作规范驱动开发的一处推动因素而被提及。然而仅仅鉴于窗口更大，这并不意味着 AI 能够正确无误地把其中的所有内容都捕捉到。

在规划进程里的某一研究环节中，Spec-kit针对现存代码以及既有内容开展了大量研究，这挺不错的，毕竟是我要求它基于现有代码增添一项功能的。然而，最终Agent忽视了这些现有类的描述，仅仅把它们当作全新的规范，还再次生成它们，进而产生了重复项。我不但目睹了忽略指令的实例，还瞧见Agent因过度积极地遵循指令而做得过火了（比如宪法条款中的某一条款）。

经验表明，保持对构建内容的控制，最佳方法是一系列小的迭代步骤，故而我极为怀疑大量前期规范设计是否为好主意，尤其冗长之时。有效的 SDD 工具须迎合迭代方法，然而小的工作包似与 SDD 理念相悖。

如何有效地将功能规范与技术规范分开？

在SDD当中，存在着一种较为常见的想法，其为有意识地去区分功能规范以及技术实现。我进行猜测，在其背后怀揣着这样的愿景，就是终究有一天，我们能够让AI去填充所有的解答方案还有细节，并且在相同的规范的情形之下，切换至不一样的技术栈 。

事实上，在我试着使用 specｰkit 的时候，我常常会为究竟是该停留在功能层面，还是该增添技术细节而感到迷茫。教程以及文档在这一方面也并非完全一致，好像对于“纯粹功能”的真实意义有着不一样的解读。当我回想起在我的职业历程中所读过的诸多用户故事，它们并未准确地区分开需求与实现，我觉得我们作为一个行业在这方面并没有良好的记录。

目标用户是谁？

许多规范驱动开发工具的演示，诸多规范驱动开发工具的教程，包括定义产品，包含功能目标，它们甚至含有“用户故事”这样的术语。这里的想法，可能是运用AI作为那种并非普通技能，而算得上具备跨越多种技能特性的推动者，使得开发人员能够更多地投身于需求分析当中？或者可以让开发人员在这样一种工作流里，与产品人员以配对的方式来进行工作合作？这些内容均未极其明确地予以说明，而是处于一种默认开发人员会去开展所有这些分析的状况之中。

处于这种情形下，我会再度问自己，SDD适用于哪类问题大小与类型呢？或许并非是那些依旧较为模糊的大型功能？因为那必定需要更多的专业产品以及需求技能，还有研究以及相关利益者的参与等诸多其他步骤。

规范锚定和规范作为源：我们是从过去学习吗？

许多人会把 SDD 跟 TDD 或者 BDD 作类比，然而我觉得对于规范作为源而言，另一个关键的类比是 MDD（模型驱动开发）。职业生涯早期，我参与过一些大量运用 MDD 的项目，在尝试 Tessl 框架时，我老是回想起这事儿。MDD 里的模型本质上是规范，虽说不是自然语言，而是用像是自定义 UML 或者文本 DSL 去表达。我们搭建了自定义代码生成器，把这些规范转化成代码。

一个在我过往经验里的，属于结构化、可解析规范 DSL 的示例，主要是凭借记忆予以重建的。屏幕“写消息”的实例化 { … } 展现出了诸如针对领域模型字段的引用，通过从其他屏幕继承来实现模式的重复利用，以及导航逻辑之类的情况。

最终，模型驱动开发，也就是 MDD，在商业应用里从未成功兴起，它处在一种尴尬的抽象层面，仅仅是造就了过多的开销与限制。然而，大型语言模型，即 LLMs，消除了 MDD 的部分开销和限制，所以带来了新的希望，此刻我们能够最终专心去编写规范，并且从规范里生成代码。因为有了 LLMs，我们不再受限于预定义且能够解析的规范语言，我们也无需构建复杂的代码生成器。当然，为此所付出的代价是 LLMs 的非确定性。且，可解析结构存有我们当下正日趋丧失的特质：能够为规范撰写者供给诸多工具支撑，用以编写出具备收效、完备以及连贯特性的规范文档。我心生疑问，规范如经认定等同于源代码，甚或规范锚定codejock 16，最终是否会一并兼具 MDD 与 LLMs 的劣势之处：欠缺灵活性以及存在非确定性。

应当明确的是，我并非是在怀念往昔的MDD经历，进而说出“我们不妨将其带回来”这样的话。然而，我们理应去回顾过去那从规范迈向代码的尝试，进而能够在如今探索规范驱动之际从中获取经验。

结 论

就我的个人经历而言，我在运用AI进行辅助编程时，会匀出时间用心去打造某种特定形式的规范，并且预先将其交给编程Agent。所以，在许多状况下，规范优先这种大体的原则绝对有着价值，构建规范的多样方式备受青睐。它们是我当前从实践者当中听闻的最为常被问到的某些问题：“我要怎样去构建我的记忆库？”，“我该以何种方式为AI编写一份优质的规范以及设计文档？” 。

但“规范驱动开发”这一术语，尚未被很好地定义，其在语义方面已然扩散，甚至，就在最近，我听闻人们基本上把“规范”当作“详细提示”的同义词来使用 。

就我曾尝试过的工具而言，我于此处罗列了诸多有关其在现实世界里实用性方面的问题。我想要弄清楚，当中某些工具是不是曾试图特别执着地以我们现有的工作流程去投喂AI Agent，最终将现有的挑战予以扩大，类似审核过载以及幻觉这样的情况。尤其是那些构建大量文件的更为繁杂的方式，我不由自主地联想到德国复合词，我们是不是在致力于改进的进程中反而把事情弄得更糟糕了呢？

原文链接：

这看起来不像是一个规范的表述啊，其似乎存在多余的斜杠、点等不当字符，不过按照要求改写的话可以是：https://这个网址，其中。

声明：本文由 InfoQ 翻译，未经许可禁止转载。

今日好文推荐

如有侵权请联系删除！