你准备开发一个新功能。测试驱动开发（TDD）的教条告诉你：先写测试。但问题是——写什么测试？你连 API 长什么样都不知道，也不确定这个方案能不能跑通。结果你花了两小时给一套接口写测试，30分钟后发现理解错了问题，全部重写。

这不是学习，是盲从。

打开网易新闻 查看精彩图片

过去一年，我构建了多个生产级工具：一个代码库智能分析 CLI、一套工作流自动化脚本、几个企业级智能体系统。没有一个是从测试开始的，全部成功交付。最近，我所在的团队从行为驱动开发（BDD）转向规范驱动开发（SDD），终于想通了关键：先搭原型，再定规范，最后用规范驱动测试。这不是乱来，是尊重软件实际演化规律的务实工程。

TDD 已经变成宗教仪式：写失败测试（红）、写最少代码通过（绿）、重构、循环往复。好处听起来很诱人——可测试的代码、深思熟虑的接口、回归安全、避免过度设计。它被奉为"行业最佳实践"太久，质疑它几乎成了异端。

但这里有个隐藏的致命假设：TDD 预设你已经知道要做什么。实现已知算法（排序、搜索、标准数据结构）时，TDD 确实好用——接口 predetermined，行为 well-defined，你只是把脑子里的规范翻译成代码。但当你探索全新问题空间、连方案是否可行都不确定时，TDD 就会崩掉。

证据随处可见：调查显示坚持严格 TDD 的开发者不到 30%；成功的开源项目很少从完整测试套件起步；早期创业公司先交付可用原型、测试后置；就连 TDD 拥护者也承认它"困难"且需要"纪律"——这通常是"违背直觉"的委婉说法。

以我最近发布的 RepoG 为例——这是一个提供语义搜索和 AI 分析功能的代码库智能 CLI，已上架 Homebrew 并有真实用户。探索阶段我一个测试都没写。第一周，我反复尝试不同的代码分块策略，试了三种才找到真正可行的方案；第二周评估向量数据库，在 Pinecone、Chroma 和本地选项之间切换，测试覆盖率只会拖慢这种快速迭代。

关键洞察：探索阶段的核心产出不是代码，是认知。你需要回答的是"这能行吗"，而不是"这符合规范吗"。测试在这个阶段是负债，不是资产。

那什么时候该引入测试？当原型验证可行、方案确定之后。规范驱动开发（SDD）的完整流程是：先构建探索性原型，验证核心假设；然后将稳定行为形式化为规范文档；最后让规范驱动测试编写。这样测试保护的是已知的正确行为，而不是猜测的接口。

这不是反对测试，是反对测试的时机错位。TDD 的问题不在于测试本身，而在于它强迫你在最不该承诺的时候做出承诺。