先建立反馈回路，再提出假设

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

验证器偶尔接受空白邮箱，但尚无可重复检查。教学输入是空字符串、三个空格和正常地址 a@example.test；前两者应拒绝，后者应接受。你需要观察实际错误路径，再花时间解释原因。

具体做法

先建立一个能调用实际验证器并断言上述症状的检查命令，读取建立它所需的最小上下文。运行并保存实际失败；偶发问题记录输入、版本与复现条件，有 seed 才固定 seed。随后提出能被此信号证伪的假设，每次相关改动复用信号并检查正常输入。不能复现则保留缺口，不假称已诊断。

反例

先读大量无关文件，根据直觉猜是 trim 问题并修补，不运行报告的空白输入；只因命令不报错就认为通过。

改进写法

在教学项目建立并运行 node --test tests/email-validation.test.mjs，使它调用真实验证器，断言空字符串和三个空格被拒绝、a@example.test 被接受。保存当前版本的输出。先确认能捕获原症状，再提出假设和对应预测；偶发时记录复现条件，不编造固定率。改动后重跑同一信号，无法复现或执行时说明证据缺口。

为什么这样改

没有反馈信号时，多个看似合理的解释无法区分。具体症状断言让假设产生可观察预测，红绿变化也说明是否触及报告问题，而不是只让程序不崩溃。

如何验证

教学测试设计应在错误接受空格时失败，在满足三个输入契约后通过。报告只有真实执行才填写失败/通过输出与版本。

检查覆盖的是原症状、正常地址没有被误拒绝；一次偶发未出现不能直接声称永久修复。

适用边界

有时需要用户、设备或服务环境提供复现，明确缺失条件即可。读取最小材料来建立反馈是必要准备，不应把方法解释为完全禁止先看代码；来源的专用循环模板不是每个宿主的能力。