用途：TDD Workflow 是一份操作流程而非知识集合，强调按顺序执行红-绿-重构循环，价值来自纪律性而非概念理解。
适用场景：用户要求 TDD、测试先行；向已有测试套件的代码添加新行为；报告缺陷且修复不应回归；需改动无测试保护的代码；用户希望确认重构未改变行为。不适合一次性探索性原型，或正确行为尚未明确的代码，应先探索再重新开始循环。
核心能力：循环分三态且顺序固定。Red——写一个失败测试表达下一个行为增量，运行并确认它因预期原因失败；Green——写最简单改动使其通过并运行整套测试；Refactor——在测试全绿下改进代码与测试，每次结构改动后运行测试。循环应短至分钟级。为何必须观察失败：从未失败的测试不能证明任何事，可能断言同义反复、目标错误或静默跳过。增量应只编码一个决策：一个分支、一个校验或一个边界。对未测试的遗留代码，反转循环，先用特征测试固定当前实际行为（含缺陷），再作修改。
使用方式：1. 建立基线，改动前先运行套件；已红的套件无信号，先修复或隔离并说明。示例：npm test 或 pytest -q、go test ./...、cargo test、mvn -q test。2. 用一句话命名增量，作为测试名。3. 写一个失败测试，安排-执行-断言，断言可观察行为而非私有内部。4. 运行并阅读失败信息，确认失败原因正确。5. 简单实现使其通过，可硬编码，运行整套测试。6. 重构代码与测试，每次结构改动后运行测试。7. 回到第2步或停止，行为完全明确时停止。
限制与反模式：勿先写代码后补测试；勿测试实现细节；勿过度 mock，只在真实边界（网络、时钟、文件系统、支付商）mock；勿跳过重构；勿追求覆盖率数字；勿写一个巨型循环。
参考资料提及 Legacy Code Strategies 和 Worked Examples，以及 Kent Beck、Michael Feathers 等著作。价格、平台支持等细节暂未提供。