验证结果，而不是相信完成声明

“测试通过”是有价值的证据，但首先要知道测试覆盖什么。如果现有测试只检查内容日期和工具分类，就不能据此宣布页面已经对齐。

本章讨论这一次修改是否完成；比较两个模型或两版流程，要用一组任务的评估。

先把需求映射到证据

以本站的共享容器调整为例：

一条检查只证明它覆盖的要求。这里不是让你永远加更多检查，而是避免用无关证据替代关键证据。

Bug 最好有改前与改后对照

先用用户给的路径复现，再改，再走同一路径。这样可以防止修了一个看起来相似却不同的问题。

如果当前版本已经没有问题，要说“在这些条件下未复现”，并留下视口、地址和观察结果。不要人为制造一个失败来补齐故事。

已经修改后才想起记录基线，也不能伪造旧截图。可以用真实旧版本在隔离环境重现；做不到就明确缺少改前运行证据。

测试应该怎样失败

假设需求是“普通用户不能访问管理员接口”。一个有价值的测试应真的用普通用户凭据请求接口，并断言拒绝访问。

如果测试先把权限判断 Mock 为“拒绝”，再检查结果是拒绝，它并没有证明权限逻辑正确。类似地，布局测试直接读取你刚设定的常量，也证明不了元素实际坐标相同。

评审测试时问：若目标 Bug 仍存在，这个测试会失败吗？ 如果不会，测试数量再多也不能作为该问题的修复证据。

执行检查时保留失败信息

本站的统一命令是：

npm run verify

它依次执行 lint、测试、生产构建。如果前一步失败，后面的检查可能尚未执行。报告“verify 失败”还不够，要说明停在哪一步。

其他项目先读取脚本定义；不要给不存在的命令打勾。运行失败后也不要直接关闭规则、删除测试或改预期来获得绿色结果。

一个可审阅的验证记录

下面只是报告格式示例，没有声称这些检查已经运行：

需求：三个页面共享水平边界。
 
已执行：
- [填写命令、结果、对应代码版本]
- [填写视口、页面、实际观测]
 
失败或受阻：
- [填写错误、影响、下一步]
 
未执行：
- [填写必要但未完成的检查]
 
结论：
- 哪些要求已有证据；
- 哪些要求仍不能判定；
- 是否还存在阻止交付的问题。

“应该没问题”“目测大概一致”不是禁用词，但只能表达判断强度，不能代替已执行检查。

评审要找反例，不是再总结一次实现

可以让一个独立上下文只读审阅：

对照原始需求审查最终 diff。
重点找：没有覆盖的消费者、失败路径、被削弱的测试和越界改动。
每个问题给出触发条件、后果和代码依据。
不要把个人风格偏好当缺陷；没有可证实问题可以不报。
不要修改文件。

独立上下文并不意味着结论自动正确。人工仍要复核评审发现，必要时写一个能复现的测试；评审模型之间的一致意见，也不等同于运行证据。