让必须验证的要求足够明确

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

使用场景

你已修改一个补丁，准备报告它是否通过验证。教学项目约定用 node --test tests/retry.test.mjs 检查这次重试行为，检查必须针对修改后的版本，且你能读取命令退出码和测试结果。旧版本的成功记录不能自动覆盖新补丁。

具体做法

把关键要求写成具名规则：没有对应验证证据，就不声明通过。先确定能支撑这项主张的检查，执行完整的约定命令，读取退出码、失败数和检查范围，再写结论。检查失败时报告实际失败；不能执行时报告未验证及原因。更高优先级指令限制执行时，遵守限制并调整交付状态，而不补写通过结论。

反例

完成上述补丁后，有时间就尽量运行 node --test tests/retry.test.mjs。看起来没问题的话，可以说已经通过。

改进写法

验证规则：声明上述补丁通过前，运行 node --test tests/retry.test.mjs 并读取退出码、测试数和失败输出。报告命令与对应版本。只有结果支持这项主张时才写通过；失败则写失败项；无法运行或被明确限制执行时写未验证和原因。检查后又改了相关代码，应重新验证受影响行为。

为什么这样改

“尽量”和“看起来”允许把主观信心换成完成状态。具名规则把结论绑定到具体检查与版本，读者能分辨代码已写完、检查已执行和检查通过这三个不同状态。

如何验证

给三份教学记录判断状态：退出码 0、3/3 通过 → 本项检查通过；退出码 1、2/3 通过 → 检查失败；命令不存在 → 未验证，报告缺失环境。

核对报告是否包含实际使用的命令和版本，是否没有把失败或未执行写成通过。即使本项通过，也只说明这项检查覆盖的行为，不自动代表所有平台或整个系统正确。

适用边界

规则应绑定相关且已约定的检查，不为了措辞强硬而要求无关的全套测试。用户限制、环境缺失和既有有效证据影响可执行步骤，但不使未知结果变成已知。教学记录并非本项目真实测试结果。