test-first：轻量测试驱动纪律

红绿重构的循环你已内化，本技能不复述教程。它只守住赶进度时最容易丢的两个门槛，并把测试用例的来源接到失败清单上。基线事实：没有纪律约束时，agent 在时间压力下会实现完冒烟一遍即宣布完成，零自动化测试。

两个门槛

1. 实现代码之前，先有一个会失败的测试。
2. 亲眼看它红过，并把红输出贴出来，再让它变绿。 没红过的测试证明不了任何事——它可能恒真、可能测错对象、可能根本没被跑到。红，是对测试自身的测试。贴出失败输出是测试先行的可审计证据：无红输出记录＝未走 TDD，事后任何人（包括你自己）都能核查。

测试用例从失败清单来

测试先行的哲学内核是逆向思维——不问「它该怎么工作」，先问「它怎样算坏了」。

• 有 spec（如 clarify 的产出）时：验收标准逐条翻译成测试，一条标准至少一个测试。
• 没有 spec 时：动手前先自问「什么情况下这个改动算失败」，列 3–5 条失败场景——必须覆盖新行为正确与旧行为不回归两维，再逐条翻译。
• 节奏小步：一个失败场景 → 一个红测试 → 最小实现变绿 → 下一条。不攒一大批测试一次性写完。
• 后写的测试一次就绿时（实现已顺带覆盖了该场景）：不能就此认账——临时破坏对应实现路径重跑，亲眼看它能红，再恢复。怎么破坏都红不了的测试是坏测试，删掉重写。

有 spec 时的推荐模式：出题者与实现者分离