在日常开发中，有这么一个场景，再常见不过了，你安排一个任务下去，对方花了一个月甚至更久的时间，给你提交一个非常大的 Pr 变更。你一看，看都看不懂。和对方在 code review 的过程中，一点点梳理逻辑后。发现对方根本没有理解对业务，也没有明白当前项目的架构究竟是怎样的。
现在你不仅丢一个任务，还给他丢了个 kiloCode 和一堆规范文件。形式上，看上去他在编辑器中，不断地进行问答与纠正。但是在 pr 提交以前，并不会有第二个人知道发生了什么。对于业务和架构的错误理解，反而会被 ai 无限的放大，而且是越好的 ai 带来的问题越严重。
规范驱动开发带来了这么一个错觉——似乎只要规范文档够长够完善，那么不管是多少人，只要遵循规范下 ai 的产出，按照甘特图上的任务时间节点把代码拼起来，就能得到一个“测试覆盖率极高，功能非常完备”的产品。
这怎么可能呢？
我们写的那么多的规范，是希望团队中的其他人，在正确理解业务的情况下，依照现有的架构规范，进行合理的任务分解。真实目的就八个字：理解业务，明白架构。这个问题并不是 ai 带来的，也不是 ai 能解决的，唯一能解决的方式，就流程上入手，比如在具体的实现代码前，对任务清单进行 “task review”。
这就带来了一个新的问题，如何快速且高效的，向别人展示，“我真的理解了需求，我真的懂了架构”
我们看看规范驱动开发中，是怎么做的，ai 会在用户多轮会话后，给出一长串的 plan.md 或者是 task.md，流程上来说，似乎只要拿着这些，让 review 负责人看即可。
这个模式在非常多的公司，都已经实践过了，只是可能写在如“语雀”一类的在线协同工具中而非本地文件中，可能叫做《xxx 功能拆解文档》，但是效果却不尽如人意。这种形式，最多只能体现理解业务，体现不了明白架构。最常见的问题，便是“通用函数的重复实现”、“代码分层的循环依赖”、“基础设施的改动引起的破坏性变更”等。
那让 ai 在 md 文件里，把要改动与调用的文件，以精确到函数方法的程度，一一列出来呢？可以做，但没必要。因为测试代码已经承担了这个职能。当然，我们更熟悉的说法，是 TDD。
TDD 让我们以一种能被消费、能看得见摸得着的方式向别人展示我真的懂了需求。而我真的懂了需求，是因为我可以把需求分解成功能点。我真的懂了架构，是因为我可以在功能点内对架构进行上下文的切分。
如果做到了这些，那么在后续的软件开发中，可能 70% 的问题就都不存在了。TDD 仅仅提供了一种形式而已。
这就解决规范驱动开发中的体验非常不好的问题：ai 产出的文档太多怎么读。那就不读文档，读测试代码。
对测试代码形式的任务清单，进行第一轮 review，指正开发者对业务和架构的理解不完善的地方。然后再进行实现代码的开发。如果有资源更进一步，其实就是“结对编程”。
测试代码本身，承担了“做什么”和“怎么做”的问题。它是一杆秤，衡量的是我们对 ai 产出的预期。没有预期，就会陷入“我感觉任务划分合理，可以继续往下执行”。形式上是 spec coding，实际上，只是在 vibe coding 前，多了一步 vibe talking。