从MDD到SDD！20年开发范式轮回，AI让规范驱动开发翻红？

十大品牌 2025年11月03日 20:52 0 aa

前阵子想搞明白AI编程里的规范驱动开发，也就是SDD，特意找了Kiro、Spec-kit、Tessl三款工具试了试，结果发现这里面门道真不少。

不光工具之间差异大，连“SDD到底是什么”都还没个统一说法，今天就跟大家聊聊这段实测经历，还有我对SDD的一些看法。

先说说SDD的核心定义。

现在这领域发展太快，新术语的定义总在变。

我查了GitHub和Tessl的官方说法，前者认为在AI编程的新世界里，维护软件重点是迭代规范，开发语言得往更高层次走，代码只是最后一步的解决方案；后者更直接，说SDD是“规范优先”的开发方法，规范才是核心产物，AI负责生成匹配规范的代码。

我梳理下来，SDD其实能分成三个实现层次。

最基础的是“规范优先”，就像Kiro那样，先写好深思熟虑的规范，再用它驱动AI辅助开发；再进一步是“规范锚定”，比如Spec-kit想做的，任务完成后规范不删，留着支撑功能后续的迭代和维护；最激进的是“规范作为源”，Tessl正在试的路子，人类只改规范，代码全由AI生成，人连碰都不用碰。

不过目前大部分工具只做到了“规范优先”，后两个层次要么做得模糊，要么还在摸索。

聊完层次，就得说“规范”本身了。

很多人容易把它和产品需求文档（PRD）弄混，其实两者不一样。

本来想以为规范就是简单写个需求，后来发现不是，规范得是结构化、面向行为的，还得用自然语言把软件功能说清楚，关键是要能指导AI编程。

而且规范和项目里的上下文文档也不同，那些上下文文档更像“记忆库”，全项目的AI编程会话都能用，而规范只针对具体功能的创建或修改，这点必须拎清。

三款SDD工具实测，Kiro轻量、Spec-kit复杂、Tessl激进

试的第一款工具是Kiro，它算三款里最轻量化的。

用起来很简单，就三个步骤：需求、设计、任务，每一步都用Markdown文档记录，还能集成到VSCode里，上手没什么门槛。

我当时用它处理一个小bug，本来以为很快能搞定，结果它把这个小问题拆成了4个“用户故事”，每个故事还配了验收标准，加起来有16条，其中一条写“作为开发者，希望转换函数处理边缘情况，保证系统健壮”。

这就像用大锤砸坚果，完全没必要，小问题真犯不着这么复杂的流程。

接着试的是GitHub的Spec-kit，风格跟Kiro完全相反，复杂度一下子上去了。

它得用命令行操作，先得建一个“宪法文件”，里面全是项目的高层原则，比如API设计规范、代码风格要求，而且规定这些原则不能改，是所有开发的前提。

工作流也分四步：宪法、指定、计划、任务，每一步都会生成一堆文件和清单，用来跟踪用户澄清、宪法违规这些内容。

但问题也在这，生成的Markdown文件又多又冗长，内容还互相交叉，有的甚至包含代码片段，审查起来比直接看代码还累。

更麻烦的是，它给每个规范建一个分支，本来想实现“规范锚定”，结果变成了“规范跟着变更请求走”，功能后续维护时根本找不到旧规范，社区里也有人吐槽这个设计逻辑混乱。

最后试的是还在非公开测试的Tessl框架，它的理念最特别，明确要做“规范锚定”，甚至在探索“规范作为源”。

它也是用命令行分发，还能当MCP服务器用。

我试着让它从一个现有JavaScript文件反推规范，生成的规范里有@generate、@test这种标签，能明确告诉AI要生成什么、要测试什么，而且规范和代码文件是1:1对应。

最有意思的是，它生成的代码顶部会标一句“//从规范生成-请勿编辑”，直接把规范当源码用。

不过实测中发现，同一个规范多次生成代码，结果会有差异，得反复优化规范才能让代码稳定。

这种迭代过程挺费劲儿，但也让我觉得，这种低抽象层次的规范，或许能减少AI的解释步骤，降低出错概率。

试完这三款工具，我发现SDD要落地，还有不少绕不开的坎。

首先是工作流灵活性的问题，Kiro和Spec-kit都有自己固定的流程，面对不同大小、不同类型的项目时，适配性很差。

比如用Spec-kit做一个3-5点的功能需求，它生成的文档和步骤太多，花在审查上的时间，足够我用普通AI辅助编程把功能实现了，还不如直接写代码来得可控。

SDD落地难在哪？灵活度、审查效率都是坎儿

然后是审查效率的问题。

Spec-kit生成的大量Markdown文档，不光冗长，还和现有代码重复，审查时很容易疲劳。

我宁愿直接审查AI生成的代码，至少能直观看到功能实现，也不想对着一堆文档猜代码会是什么样。

SDD工具要是解决不了审查体验的问题，很难让开发者接受。

还有“控制幻觉”的问题，这点特别明显。

就算写了详细规范、定了流程和清单，AI还是经常不按指令来。

比如用Spec-kit时，它明明研究过现有代码，知道有哪些类，结果生成代码时还是把这些类重新写了一遍，造成重复。

有时候又会过度执行指令，比如严格遵守“宪法”里的某条原则，结果把功能搞得复杂了。

这就让人怀疑，前期花那么多时间写规范，到底能不能真正控制AI的输出？

另外，功能规范和技术规范的区分也是个难题。

很多SDD工具鼓励把两者分开，愿景是让AI填充技术细节，甚至能切换技术栈。

但实际用的时候，我总搞不清什么时候该停在功能层面，什么时候该加技术细节。

教程和文档在这方面也说得模糊，再想想以前见过的很多用户故事，也没把需求和实现分清楚，看来整个行业在这方面都还没找到成熟的方法。

说到这里，我总想起以前的模型驱动开发（MDD）。

当年MDD没火起来，就是因为抽象层次尴尬，还得建复杂的代码生成器，开销大又不灵活。

本来想SDD会不会重蹈覆辙，后来发现LLM（大语言模型）帮了大忙，不用再搞复杂的代码生成器，自然语言就能写规范，门槛低了很多。

但新问题也来了，MDD的确定性没了，LLM生成代码会有非确定性，有时候同一个规范出不同结果。

这就像捡了芝麻丢了西瓜，不知道未来能不能找到平衡。

SDD的“规范优先”原则是有价值的，我自己用AI编程时，也会先写个简单规范再给AI指令，能少走不少弯路。

现在很多开发者也在问“怎么建记忆库”“怎么写好规范”，说明大家确实有这方面的需求。

但目前“规范驱动开发”的定义太乱，有人甚至把“规范”当成“详细提示”的同义词，语义都扩散了。

试的这三款工具里，Kiro适合小项目快速试错，简单功能用着挺顺手；Spec-kit适合大团队，但得改改流程，减少冗余文档；Tessl的方向挺有前景，但还在测试阶段，很多问题没解决。

要是这些工具解决不了工作流不灵活、审查麻烦、AI不听话这些问题，SDD怕是很难大规模推广。

毕竟没人想在“改进开发流程”的过程中，反而把事情搞得更复杂，你说对吧？

双11AI导购越用越急？喊它买单卡壳的真相，藏着未来购物的暗战

全彩 AR + 全场景！这家智能眼镜发布会如何贯穿全产业与消费端场景

发表评论

从MDD到SDD！20年开发范式轮回，AI让规范驱动开发翻红？

三款SDD工具实测，Kiro轻量、Spec-kit复杂、Tessl激进

SDD落地难在哪？灵活度、审查效率都是坎儿

双11AI导购越用越急？喊它买单卡壳的真相，藏着未来购物的暗战

全彩 AR + 全场景！这家智能眼镜发布会如何贯穿全产业与消费端场景

热门文章

最新文章