多年以后，面对 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 的赋能使得其自动化过程变得更加快速和高效。而其中最为关键的要素正是测试用例。正是测试用例描绘了你的产品功能提升了它的健壮性构建了它的护城河。是它让你的产品不再是海市蜃楼般的蜃景之城你能看到马路、高楼、下水道以及坚固的城墙。在一次又一次的飓风中存活和成长成为一段可以重演的历史。