先寫測試再開發？這個流程可能搞反了

你準備開發一個新功能。測試驅動開發（TDD）的教條告訴你：先寫測試。但問題是——寫什么測試？你連 API 長什么樣都不知道，也不確定這個方案能不能跑通。結果你花了兩小時給一套接口寫測試，30分鐘后發現理解錯了問題，全部重寫。

這不是學習，是盲從。

過去一年，我構建了多個生產級工具：一個代碼庫智能分析 CLI、一套工作流自動化腳本、幾個企業級智能體系統。沒有一個是從測試開始的，全部成功交付。最近，我所在的團隊從行為驅動開發（BDD）轉向規范驅動開發（SDD），終于想通了關鍵：先搭原型，再定規范，最后用規范驅動測試。這不是亂來，是尊重軟件實際演化規律的務實工程。

TDD 已經變成宗教儀式：寫失敗測試（紅）、寫最少代碼通過（綠）、重構、循環往復。好處聽起來很誘人——可測試的代碼、深思熟慮的接口、回歸安全、避免過度設計。它被奉為"行業最佳實踐"太久，質疑它幾乎成了異端。

但這里有個隱藏的致命假設：TDD 預設你已經知道要做什么。實現已知算法（排序、搜索、標準數據結構）時，TDD 確實好用——接口 predetermined，行為 well-defined，你只是把腦子里的規范翻譯成代碼。但當你探索全新問題空間、連方案是否可行都不確定時，TDD 就會崩掉。

證據隨處可見：調查顯示堅持嚴格 TDD 的開發者不到 30%；成功的開源項目很少從完整測試套件起步；早期創業公司先交付可用原型、測試后置；就連 TDD 擁護者也承認它"困難"且需要"紀律"——這通常是"違背直覺"的委婉說法。

以我最近發布的 RepoG 為例——這是一個提供語義搜索和 AI 分析功能的代碼庫智能 CLI，已上架 Homebrew 并有真實用戶。探索階段我一個測試都沒寫。第一周，我反復嘗試不同的代碼分塊策略，試了三種才找到真正可行的方案；第二周評估向量數據庫，在 Pinecone、Chroma 和本地選項之間切換，測試覆蓋率只會拖慢這種快速迭代。

關鍵洞察：探索階段的核心產出不是代碼，是認知。你需要回答的是"這能行嗎"，而不是"這符合規范嗎"。測試在這個階段是負債，不是資產。

那什么時候該引入測試？當原型驗證可行、方案確定之后。規范驅動開發（SDD）的完整流程是：先構建探索性原型，驗證核心假設；然后將穩定行為形式化為規范文檔；最后讓規范驅動測試編寫。這樣測試保護的是已知的正確行為，而不是猜測的接口。

這不是反對測試，是反對測試的時機錯位。TDD 的問題不在于測試本身，而在于它強迫你在最不該承諾的時候做出承諾。