详尽规格不等于代码：为什么过度设计的需求文档适得其反A sufficiently comprehensive spec is not (necessarily) code

抱歉上周没更新！我生病了，后来又忙得不可开交。

这周我想聊聊一个让我特别在意的问题，这在下面的漫画里表现得淋漓尽致：

“全面而精确的规范”并不等于代码。规范对应着一组可能的实现方式，而代码只是这组实现中的一个具体实例。只要这个集合包含不止一个元素，规范与代码之间就存在分离。

设想一位业务人员（bp）提出需求：

我想要一个工具，能把英里转换成公里。

这是否算得上全面的规范？也许吧——你可以把它交给 Claude Code，让它自行决定所有设计细节，它确实能生成一个将英里转为公里的程序。但与此同时，这个需求里遗漏了大量关键信息：用什么编程语言？用户体验如何？是命令行脚本、手机应用，还是企业级 SaaS？正因如此，如果把 Claude 生成的结果交给那位业务人员，他很可能会不满意。因为满足该规范的实现方案中，既包括他想要的程序，也包含许多他不想要的程序。

于是他们接着补充说：

应该是一个网页上的文本框。

好，这样就把很多可能性排除了，但仍有不少细节需要确定：用 React、vanillajs 还是 htmx？输出结果是另起一个文本框还是弹窗？换算系数用 1.6、1.61 还是 1.609？所以有人可能会认为，这仍然算不上“全面且精确的规范”。但如果那位业务人员对 Claude 生成的任何结果都满意呢？那说明他们的原始需求已经足够全面和精确——因为他们得到了一个真正解决其问题的程序！

现在漫画更进一步声称：“足以生成程序的全面规范就是代码”——这一点在 LLM 出现之前甚至都不成立。程序综合（program synthesis），即从规范自动生成符合要求的程序，一直是活跃的研究领域！据我所知，到 2019 年为止，这类系统还只能根据类型规范生成局部函数；至于 LLM 时代是否有突破，我不太清楚。但无论如何，这恰恰说明代码和全面规范是两种不同的东西。

规范本质上是抽象

我想强调的是，规范本质上是对代码的抽象。每个规范都对应一组能满足它的程序集合。规范越全面、越精确，这个集合中的程序就越少。如果 spec1 对应的程序集合包含 spec2 对应的集合，我们就说 spec2 是对 spec1 的细化。当一个规范不再需要进一步细化时，它就是充分的：无论提供什么合理的实现（within reason），规范制定者都会感到满意。因此，一个规范不必完全全面，只要能解决问题即可。

程序员仍需编写规范

漫画还提出一个观点：“充分详细的规范就是代码”，并据此认为即使我们能自动从规范生成代码，程序员也不会失业——这个判断依然正确。

我们通常会用形式化语言来表达这种抽象规范。我首先想到的是 TLA+、UML，甚至是 Planguage，但最常见的例子其实是测试套件。测试本身也是一种规范！而且几乎可以肯定，非技术人员很难成功地将需求编码进形式化语言中。Cucumber 试图让业务人员编写形式化规范，但最终失败了。

但这能算作一份全面的“代码”规范吗？我认为不能。虽然可以用编程语言（比如测试套件）来编码规范，但这本质上只是编码而已。规范仍然对应一组可能的实现程序，即使我们不将其编码为代码，它依然是有用的。将“代码”和“规范”视为两个不同的概念是有益的。