多年以后，面对 Vibe Code，我想起了拿起 TDD 的那个下午

多年以后，当面对 Vibe Code，我想起了拿起《测试驱动开发》那个下午。当下最受瞩目的莫过于 Vibe Code。它承诺用户只需用自然语言详细描述软件需求，AI 便能自主完成编码、测试乃至上线部署的全过程。对于软件生命周期中不可避免的变更，Open Spec 也推出了一系列标准，旨在通过自然语言记录变更需求，进而指导 AI 基于变更文档修改代码并进行测试。

这些发展首先让我联想到的是传统的软件工程范式：需求文档、设计文档、代码实现、代码测试、部署上线。如今，所有这些环节似乎都将通过 AI 实现自动化。

软件工程的固有挑战与 AI 的介入

软件的最终交付物是软件服务，即一堆运行中的代码。在代码生成之前，所有产生的文档，无论是需求规格书还是设计说明，大多是为代码服务的，是对其的抽象描述，旨在指导代码的编写。过去，这些文档用于指导人类程序员；现在，它们将用于指导 AI 程序员。随之而来的问题是，自然语言文档需要详细到何种程度才足够？从某种角度来看，代码本身也算是一种文档，只不过它更加详细、更加精确。因此，自然语言文档理应保持一定的抽象度，否则便直接等同于代码。

然而，自然语言文档与代码之间需要持续同步。无论是自然语言文档的变更影响代码，还是代码的修改反过来影响文档，这种双向同步工作在软件工程中带来了诸多困扰。甚至有人提出直接阅读代码，放弃文档维护，认为设计文档并不可靠。在某些项目中，甚至代码注释都可能变得不可靠。AI 的出现，似乎为解决这部分同步工作提供了新的解决方案，使得双向同步变得更加高效。

无论是阅读自然语言文档还是代码，其目的都是为了让人或 AI 更好地理解软件服务，从而指导修改和优化。但我们不应忘记，软件服务本质上是一堆运行中的代码。要更好地理解一个软件服务，最有效的方式是通过测试用例。

关键先生：测试用例

正因如此，人们提出了 TDD（测试驱动开发） 的理念。在 TDD 中，一切都围绕着测试用例展开。自然语言文档的编写和更新，是为了生成和维护对应的测试用例；代码的编写，则是为了让这些测试用例能够顺利运行通过。当需要了解软件的某个功能时，相关的测试用例也能提供极大的帮助。一个软件累积的测试用例越丰富，软件就越容易被理解，也越健壮。

于是有人提出，测试用例是一个软件公司的护城河。而测试工作本身蕴含着深厚的门道，其中一个关键技术便是 Mock 技术。

Mock 技术是编写单元测试时不可回避的话题。一个单元函数势必会依赖第三方函数或特定的上下文环境。我们需要通过 Mock 技术，去构造一个虚拟的上下文环境，模拟不同第三方函数的返回结果。例如，在调用第三方地图接口查询地址坐标的场景中，我们可以模拟出查询不到结果、查询报错、查询到不同地理坐标等多种输出情况，以此来测试我们函数对不同情况的处理逻辑。拥有一个与自身公司业务强相关的、完整的模拟环境，将成为一个公司最核心的护城河之一。

这正是为什么英伟达要推出 Cosmos 世界基础模型。近年来，人形机器人和自动驾驶汽车领域之所以能取得显著进展，主要也得益于它们在真实环境进行集成测试之前，可以在 Mock 环境中轻松且大规模地进行单元测试。

结语

对于身处行业内的我们而言，Vibe Code 并没有什么神奇之处。我们有我们自己的解读：它无非是过往知识与 AI 结合的产物。软件工程、测试驱动开发、DevOps，再加上 AI 的赋能，使得其自动化过程变得更加快速和高效。而其中最为关键的要素，正是测试用例。正是测试用例，描绘了你的产品功能，提升了它的健壮性，构建了它的护城河。是它让你的产品不再是海市蜃楼般的蜃景之城，你能看到马路、高楼、下水道以及坚固的城墙。在一次又一次的飓风中存活和成长，成为一段可以重演的历史。