用途：Focused TDD 用于测试优先开发、TDD 或修复前先写回归测试的场景，也适用于实现确定性业务规则、状态转换等可观察行为契约。它把测试优先视为降低风险的技术，而非普遍适用的仪式。
主要能力：先检查变更行为、邻近代码、现有测试和仓库说明，再简要声明所选方法。严格 RED-GREEN-REFACTOR 仅在同时满足以下条件时使用：变更具有可观察的行为契约；确定性自动化测试能覆盖所属层；聚焦测试足够快以支持反复反馈；观察测试失败能实质提升对实现的信心。已确认缺陷若一个聚焦测试能复现失败机制，则用回归优先。探索性、保持行为、生成、仅文档、配置密集、以视觉为主或依赖外部的工作，采用按比例验证，仅在测试能保护有意义行为时于实现后补测。
使用方式：RED 阶段为单个可独立观察的行为写一个最小测试，优先使用真实领域或应用代码，仅对缓慢、不确定或外部边界打桩；运行最窄命令，确认断言因行为缺失而失败，修正 setup 或 fixture 失败直到信号有意义；若测试通过，判断行为是否已存在，调整场景或停止，不要强行制造失败。GREEN 阶段实现满足契约的最小连贯改动，运行同一聚焦测试；契约正确时修生产代码，仅当断言契约有误时才改测试。REFACTOR 仅在改进足够值得再走一轮时进行，保持聚焦测试通过且不借清理之名扩大范围。每个可观察行为重复一次，而非每个方法或文件一次。
适用场景与限制：聚焦测试在循环中运行，行为稳定后再跑更广检查。测试应放在所属层：边界做传输映射，领域/应用代码放业务规则，必要时对真实适配器或数据库验证持久化契约，前端测试覆盖用户交互。仅当变更风险需要时，才补充负向授权、租户、幂等、并发或状态转换用例。遵循仓库特定命令与验证指引，不要另造并行测试流程。不要为每个函数、分支或实现细节建测试；不要构建成本超过变更风险的新测试框架；不要仅因代码早于测试就重写用户代码；行为已存在时不要伪造 RED；新测试从未因预期原因失败时不要声称用了 TDD。若出现两次与行为无关的环境或测试框架失败，停止严格循环，改用最佳按比例验证并报告阻塞。报告需包含：方法（严格 TDD、回归优先或按比例验证）、RED（测试与预期失败，或说明 RED 为何无价值）、GREEN（聚焦通过的命令）、更广验证（命令与结果）、剩余缺口（仅列实质性未验证风险）。