规范可以晚点再写：从 AI 编码会话中提取规范并重新生成代码

当我说“删掉代码，保留规格”这类话时，很多人似乎把它理解成一条规则：先写规格，然后才允许编程。

我不是这个意思。也没有人是这样真正构建软件的。我认为，这正是我听到的许多反对意见的根源——不仅针对我自己的想法，也针对过去几年里涌现的各种规格驱动开发方法。\

有经验的开发者对此深有体会。编程是我们发现自己真正想要什么的最重要方式之一。你尝试某种做法，发现不对，然后改变主意。有些需求直到某个实现打破了它们才存在。

有一条规则我知道是真的：我对一个系统的最初几次规格描述总是错的。这是我从上世纪90年代认真开始编程以来就一直当作规则的事实。我想，这也是我一看到极限编程就被它吸引的原因。“用户故事是一场对话的承诺”。有时是与业务负责人的对话。有时是与单元测试和编译器的对话。

Matteo Paltenghi 和 Satish Chandra 似乎有同样的直觉。AfterVibe：当对话结束时还剩下什么从科学角度探讨了这一点。他们从已完成的 AI 编码会话以及这些会话产生的代码变更中提取规格。然后他们把恢复出的规格交给另一个 agent，让它在一个现有仓库中重建同样的变更。

这正是我觉得令人兴奋的部分。第一次实现是你发现自己真正意图的方式。第二次则是你检验自己有没有把它写下来的方式。

于是顺序就反过来了。你从一个模糊的想法开始，一路乱搞直到某个东西能跑起来。等你走出来时，手里有了一份第一天根本写不出来的规格。然后你重新生成，看看这份规格实际保留了什么。只要有足够的时间和金钱，有史以来每一个软件项目都能从中受益。但现在，借助（再）生成式 AI，我们每天可以做很多次。

这一切都没有消除判断力。忠实地重新生成一个 bug，你得到的只是一个来源更清晰的 bug。仍然得有人来决定哪些发现应该成为需求，哪些只是意外。

你不必在开始之前就知道一切。你只需要停止丢弃你学到的东西。

感谢 Codeplain 的 CEO Dusan Omercevic 向我指出这篇论文。