用途：这是一套测试驱动开发（TDD）实践指南，适用于实现任何新功能、修复 bug、重构或改变行为时，要求在编写实现代码之前先写测试。
核心原则：先写测试，看着它失败，再写最少代码使其通过。如果你没亲眼看到测试失败，就无法确认它测的是正确的东西。铁律是：没有失败的测试，就不写生产代码。若先写了代码，应删除并从头开始。
主要流程（红-绿-重构）：
- 红：写一个最小测试，展示应该发生什么。一个行为、名称清晰、测试真实代码而非 mock（除非不可避免）。
- 验证红：必须运行测试并确认失败。可用 npm test path/to/test.test.ts。需确认失败原因正确（功能缺失，而非拼写错误）。
- 绿：写最简单代码让测试通过，不添加额外功能或重构其他代码。
- 验证绿：必须再次运行测试，确认本次测试通过、其他测试仍通过、输出无错误警告。若失败应改代码而非改测试。
- 重构：仅在绿灯后进行，消除重复、改进命名、抽取辅助函数，保持测试通过且不新增行为。
- 重复：为下一个功能写下一个失败测试。
常见反对与回应：测试后补会立刻通过，无法证明测试有效；手动测试是临时的，无记录、无法重跑；删除已有代码不浪费，保留不可信代码才是技术债；TDD 是务实做法，能更早发现 bug、防止回归、记录行为并支持重构。
危险信号：先写代码后写测试、测试立即通过、无法解释测试为何失败、以“仅此一次”为借口跳过、认为手动测过就够了、把先写的代码留作参考再改。出现这些情况应删除代码并重新按 TDD 开始。
限制与未提供信息：资料未说明具体支持的编程语言、框架、安装命令、平台、收费或价格。示例使用 TypeScript 与 npm test。特殊例外（一次性原型、生成代码、配置文件）需征求人类伙伴同意。