> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 往事回响：SDD 与已知范围的错觉
- URL: https://www.hubwiz.com/blog/a-blast-from-the-past-sdd-and-the-illusion-of-know-scope/
- Published: 2026-05-30T01:44:03.000Z
- Updated: 2026-10-13T15:48:44.000Z
- Description: 实现从来不只是打字。它是发现和学习的过程。工具变了，人类解决问题的方法没有变。
- Author: admin
- Tags: INDUSTRY, #Import 2026-10-14 14:41

超现代的智能体时代最引人注目的方面之一，是早期试图驯服软件开发的种种尝试正在回归。最新复兴的趋势被称为规范驱动开发（Spec-Driven Development，SDD）。SDD 的显著之处在于它复兴了一种信念：代码只是一种附属品。

本文通过一个经历过过去建模时代的人的视角来探讨 SDD。我承认"这次可能不同"，但我将把我的担忧集中在"实现只是已知范围的执行"这个有缺陷的观念上。实际上，实现是发现过程本身不可或缺的一部分。我们离它越远，就越困难。

## 1、快速回顾：什么是 SDD？

SDD 的核心思想是将预期行为捕捉在一个结构化的规范中。然后让编码智能体执行由此产生的任务，并在过程中生成设计文档等。

然而，[正如 Birgitta Böckeler 指出的那样](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html?ref=hubwiz.com)，SDD 似乎有多种形式。它可以是从相对轻量级地驱动智能体的方式，到规范本身就是事实真相的强形式。我关心的是后者。

风险在于 SDD 成为一种古老的经理梦想的最新迭代：让你的高级人员指定要构建什么，然后将其传递给看似简单的"实现"，同时假装这一步是可预测的且不那么重要。在 1990 年代，"实现"意味着一个被蒙在鼓里的编码团队。今天，显然是智能体。

这个过程当时运作得并不好。由于软件交付的节奏和期望现在提高了几个数量级，我对这次 SDD 能运作得有多好持怀疑态度。不是因为瀑布思维——许多 SDD 从业者迭代地演进他们的系统——而是因为问题解决的本质。

## 2、驱动力：对可预测性的需求

软件开发正处于一个十字路口。智能体革命最好的可能结果是我们提高了软件工程的门槛。我们知道什么对我们有益：强大的自动化测试套件、持续交付、小的增量、模块化架构和一流的代码质量。

我们也知道生成式 AI 是随机性的。但是一群人类协作开发软件也是如此。如果历史教会了我们什么的话，解决方案不仅仅是更好的输入，还有更快的反馈循环。让我通过回到模型大战的时代来详细说明。

## 3、皇帝的新可执行衣裳

SDD 与几十年前（幸好）已经远去的模型驱动架构（Model-Driven Architecture）、可执行 UML 和辉煌的 Rational 统一过程（RUP）有着强烈的相似之处。

在我职业生涯的早期，我在两家不同的公司使用过这些技术。在第一家，我们有一个有效的设计评审流程。作为开发者，我基本上会把软件设计勾画为 UML 类图，用一些序列图补充动态行为，然后为我的同行做一次走查。

是的，这个过程很慢。但我们设计的通常能作为实现方向的指导。真正的优势是，由此产生的 UML 图很好地服务于入职培训和扩展。很容易获得解决方案的高层视图，这在后来深入代码时很有帮助。

到目前为止还不错。然后工具供应商来了。我的意思是，如果你已经勾画出了你的设计，为什么不把它完成一个闭环，从那个草图生成所有代码呢？毕竟，代码只是一个实现细节，对吧？所需要的只是用一种"动作语言"来扩展 UML，以捕捉那些"细节"。

在实践中效果如何？哦，第一个牺牲品是被记录的设计。可执行图表变得如此臃肿和冗长，以至于完全无法理解。毕竟，新的受众是编译器，不是人类。

变更和扩展变得痛苦。你看，我们习以为常的所有那些强大工具——构建管道、命令行实用程序、IDE、代码检查器等——在供应商的设计工具中都不存在。想象在 Microsoft Word 文档中编码。那就是那种感觉。

![](https://substackcdn.com/image/fetch/$s_!BoGG!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Feb64fca0-2b17-4898-8bb4-c2c5e1499a68_1536x1024.png)

## 4、强规范的认知陷阱

工具只是模型驱动灾难的一部分。更大的问题是当时的流程思维方式。敏捷是全新的，除了狭窄的程序员圈子之外，很少有人熟悉这个运动。几乎我合作过的每家公司都在瀑布模式下运作。

然而，那时对软件交付的期望完全不同。今天，每日部署成为标准，我们承受不起在反馈上反应迟缓。

人类的问题解决本质上是迭代的，由行动中的反思驱动。我们在做中学。用代码表达一个想法，测试它，观察，学习。这个循环扩展了我们对试图解决的问题的理解。然后，这种改进的理解被转化为对程序的修改，我们反过来从中观察和学习。周而复始。我们无法绕过这个过程。

不，我不是说我们不应该在早期深思熟虑。我们应该。我们也应该把东西写下来，使之更加具体并引发对话。这也有助于思考。但我们需要把那份文档视为一个不完美的起点，而不是成品。

## 5、代码最被低估的方面：需求爆炸

如果我们基于一个规范来工作，仿佛问题已经被理解了，主要挑战就开始了。原因是*需求爆炸*的概念。这个术语由 Robert Glass 首次提出。Glass 认为"问题复杂度每增加 10%，软件解决方案的复杂度就会增加 100%。"

换句话说，规范中的每个需求将导致数十个需要解决的隐含设计需求。我们不能把那些留给智能体去猜测。

要让 SDD 发挥作用，我们必须提供指令，让智能体解决所有这些隐含需求中的很大一部分。

那么，我们不能用详细的解决方案模型来补充我们的规范吗？我们可以。但那将使我们面临三个主要障碍：

1. **自由文本缺乏精确性**。是的，我们可以在文本中解释约束等，但那会变得冗长且难以检查。即使是结构化散文和检查清单也留有歧义的空间。这就是我们有编程语言的原因。它们非常适合捕捉旨在给机器的精确规则。
2. **我们无法提前知道解决方案需求**。记住：我们在做中学。如果我们不做，而是让智能体替我们做决定，那么推导和捕捉解决方案需求就会变得困难几个数量级。想想逆向工程一个遗留代码库。那就是我们将处于的位置。不断地。
3. **用实现细节和契约扩展需求规范会使模型模糊**：这是在 MDA/UML 时代打击最大的一点：模型开始变成实现，并失去了作为概览、不同抽象层次的价值。代码需要另一个层次的精确度。

> 当模型成为实现的那一刻，它就不再是一个好模型了。

## 6、另一条前进之路

SDD 是我会继续观察但目前不会参与的东西。然而，这并不意味着我不重视结构和一定的可预测性。只是意味着我们应该在其他地方寻找这些品质。

可预测的进展建立在领域专业知识、意图揭示的软件设计、代码及其行为的自动化保障措施和快速的视觉反馈之上，所有这些都由一支高技能团队放大。这些能力比编写规范更难培养。但它们也更有价值。无论有没有 SDD。

---

原文链接: [A Blast from the Past: SDD and the Illusion of Known Scope](https://adamtornhill.substack.com/p/a-blast-from-the-past-sdd-and-the)

汇智网翻译整理，转载请标明出处

> **这是「AI 编程 / Vibe Coding」专题的一部分。**完整地图见：[AI 编程 / Vibe Coding 完全指南](https://www.hubwiz.com/blog/vibe-coding-stack/)