Phase 3 / Ep 12: TDD——拴住巨兽的钢铁锁链

⏱ 预计阅读 3 分钟 更新于 2026/4/13

很多开发者讨厌写单元测试，因为觉得它慢、反人性。 在手工写代码的时代，如果你不写测试，你也许可以通过自己人脑的记忆力勉强维护一个几万行的项目。

但是在 Agent 驱动开发时代，不写测试，整个 codebase 会在三分钟内崩溃！

1. 速度背后的代价

大语言模型（如 Gemini、Claude、GPT）写业务代码的速度是一秒百行。 但由于 Token 遗忘和注意力漂移的本质缺陷，一旦到了重构阶段，AI 修改了一处，极有可能在别的地方产生引发雪崩的蝴蝶效应。它不会因为疲惫而停手，它会一遍一遍地自圆其说，直到把你的老代码结构彻底揉碎。

这时候，最能拉住 AI 悬崖勒马的东西，就是冷酷无情的断言语句（Assertions）。

2. 什么是针对大模型的 TDD？

传统的 TDD (Test-Driven Development) 是: 红灯 (写测试报错) -> 绿灯 (写代码通过) -> 重构代码。 给 Agent 使用的 TDD，是在 task_plan.md 里的每一项任务开始时，都先用测试划定出一个牢笼。

Agent-TDD 的黄金准则：

“只要一段逻辑还没在 Vitest/Jest 里跑出红色报错，你就绝对不准碰它的 src/ 业务代码。”

3. 把“感性对话”降级为“机器判决”

如果你不写单元测试，你是怎么测代码的？ 你会在浏览器里点一下你的页面，然后报错了。你需要告诉 AI：“点击那个新增按钮时，并没有弹出时间块”。这是极其感性且低效的传话。

有了 TDD 的测试环境，一旦业务逻辑写错。Agent 可以自己通过终端运行 npx vitest run block_allocator.spec.ts。 它会自己阅读抛出来的控制台堆栈错误：“Expected [2 hours] but received [undefined]”。

一旦进入这种状态，人类就完全退出了 Debug 的苦海。Agent 会进入一种极度兴奋且高效的**“与终端做交互的自愈循环（Self-healing loop）”**中，直到终端给出了绿色的 Pass，它才会停手把执行权交还给你。

下一期，我们要把这份锁链实体化，编写我们系统的 test-driven-development 专项技能（Skill）。