按检查成本安排验证时机

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

使用场景

一项界面改动有类型检查、交互/可访问性测试和较慢的突变检查。它们覆盖不同主张，成本也不同。你要安排快速反馈和最终质量门，而不是每敲一个字跑全库，最后又因太慢把检查关掉。

具体做法

为每项检查写覆盖目标、实际成本与执行节点。编辑时做受影响的快速检查，任务末做相关行为测试，预览或 CI 做约定的较慢检查。复用仍匹配版本和范围的结果；发生相关改动或新失败时复验。后移必须保留明确节点和结果，不能等同于删除。

反例

每次文字编辑都跑全库所有检查，太慢就关闭浏览器与突变检查，但最终仍说完整质量门通过。

改进写法

对教学界面修改先测检查耗时并列覆盖目标。编辑后做相关类型/静态检查，任务完成运行受影响交互测试；浏览器可访问性与较慢突变检查放在明确预览/CI 节点，报告结果。仍有效的同版本证据可复用，相关代码变化或失败才重跑对应项。未到后续节点明确写待验证，不把后移写为通过。

为什么这样改

反馈越靠近修改越容易定位问题，但高成本检查频繁阻塞会被绕过。按成本安排时机并保留最后验收，使速度改进不会悄悄削弱质量要求。

如何验证

示意检查表有名称、覆盖、节点、耗时来源与状态。编辑阶段通过只支持快速项；最终完成仍需约定慢项结果。

检查慢项没有消失、成本是实际测量或明确估计，复用证据版本/范围相符。一个类型通过不能代表浏览器行为通过。

适用边界

来源的 5 秒、90 秒和命令属于其工作流，不是本项目或所有工具的保证。成本会随环境与范围变化；关键检查可以早于默认节点执行，不能仅因慢就省掉。