关于 absolute-deflake
用于通过统计失败率、查找根因并反复运行验证修复，定位和解决非确定性测试失败。它区分不稳定测试、确定性失败和潜在的产品代码竞态。
主要功能
- 01重复运行测试以统计失败率
- 02检查独立、随机顺序和并行运行
- 03诊断常见的非确定性来源
- 04按风险排列修复优先级
- 05通过多次运行验证修复
适用场景
- 01调查 CI 中的间歇性失败
- 02查找本地通过但 CI 失败的测试
- 03修复根因后移除重试或跳过标记
- 04检查不稳定测试是否暴露产品代码竞态
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/absolute-deflake确认已加载。
附带文件README.mdreferences/health-engine.md
详细介绍
🧪 请以 🧪 表情符号作为首次回复的开头。
Absolute Deflake
找出会时而通过、时而失败的测试，诊断每个测试的根本原因并修复——不是通过重试或跳过，而是消除不确定性的来源。 输出内容应为证据（每个测试的失败率）→ 原因 → 修复，并通过重复运行验证。
运行 references/health-engine.md 中的共享引擎——阅读该文件，了解 DETECT → SCAN → TRIAGE → FIX → VERIFY → REPORT 流程和安全约定。此文件仅涵盖与不稳定测试相关的内容。
适用场景
- “我们的 CI 不稳定”“这个测试会随机失败”“修复间歇性故障”。
- 测试在本地通过、在 CI 中失败（或反之），或者约每 N 次运行失败 1 次。
- 清理一批被
retry/skip标记掩盖真实不稳定问题的测试。
不适用于确定性失败的测试——那是真实 bug 或真实回归（使用 /absolute work 修复，或者直接修复即可）。deflake 的目标是非确定性失败。
扫描内容
通过实证确认不稳定性——不能因为有人这么说，就认定测试不稳定。使用配置中的
preferences.health.deflakeRuns 作为重复运行的默认次数 N（否则为 20）：
| 生态系统 | 重复运行 / 检测 |
|---|---|
| Jest/Vitest | 运行测试套件 N 次（--run 循环），随机调整顺序（--shuffle / testSequencer） |
| pytest | 使用 pytest-randomly + pytest --count=N（pytest-repeat）；使用 -p no:randomly 进行 A/B 测试 |
| Go | go test -count=N -shuffle=on ./...，以及 -race |
还要收集其他信号：现有的 retry/flaky/skip 注解、可获取的 CI 历史记录，并分别以单独运行和完整套件/并行运行的方式运行测试套件——依赖执行顺序和并发的问题，只有在其中一种情况下才会显现。记录每个疑似测试的失败率。
常见根本原因（诊断，不要猜测）
| 原因 | 判断依据 | 修复 |
|---|---|---|
| 测试顺序 / 共享状态 | 单独运行时通过，在套件中失败（或反之） | 隔离状态；在测试之间重置/清理 |
| 时间 / 时钟 | 接近午夜、夏令时切换或负载较高时失败 | 使用模拟计时器 / 注入时钟；不使用实际的 sleep |
| 异步竞争 / 遗漏 await | 并行运行或 CI 较慢时失败 | 等待实际条件；不使用固定超时 |
| 随机性 | 无明显规律地以约 X% 的概率失败 | 为随机数生成器设定固定种子；在测试中固定种子 |
| 网络 / 外部 I/O | 离线或网络缓慢时失败 | 对边界进行模拟/替身处理 |
| 无序集合 | 因 map/set 迭代顺序而失败 | 断言前先排序 |
| 资源泄漏 / 端口重用 | 重复运行或并行运行时失败 | 使用唯一资源；做好清理 |
风险排序（TRIAGE）
| 波次 | 类别 | 默认处理 |
|---|---|---|
| 1 | 原因明确且孤立（种子、await、模拟时钟、排序） | 立即修复 |
| 2 | 共享状态 / 执行顺序问题——需要重构 fixture | 在本轮中逐个测试修复 |
| 3 | 不稳定测试指向真实的产品竞争问题，而非单纯的测试问题 | 暂缓处理——标出；可能是需要修复的真实 bug |
不稳定测试有时意味着代码存在竞争问题，而不是测试的问题。不要为了“稳定”测试而掩盖真实的并发 bug——将第 3 波情况标出，以便进行真实修复。
修复与验证
- 修复原因。然后证明修复有效：多次重新运行测试（并随机调整顺序 / 并行运行 / 使用
-race）——只通过一次不算消除了不稳定性；在 N 次随机运行中均通过才算。 - 修复原因后，移除用于掩盖问题的
retry/skip/flaky注解。 - 绝不要通过增加重试次数、盲目延长超时、添加
sleep或跳过测试来“修复”——那只会掩盖不稳定性，无法消除它。 - 重新运行完整测试套件，确认修复没有导致相邻测试不稳定。
常见陷阱
- 通过重试／跳过来修复。 这会掩盖间歇性故障，却让不确定性随产品一起发布。在这里严禁这样做。
- 用
sleep来规避竞态。 这会拖慢测试套件，而且在负载较高时仍会出现间歇性故障。请等待条件满足。 - 一次通过就算完成。 间歇性故障具有概率性——请通过多次随机运行来验证。
- 稳定化实际的产品竞态。 如果是 代码 存在竞态，就修复代码，而不只是修改断言。
- 忽略顺序／并行维度。 在隔离环境中 和 测试套件中都运行；漏洞会藏在你跳过的任一场景中。
配套命令
/absolute upgrade—— 测试套件存在间歇性故障，会导致升级验证不可靠；请先消除间歇性故障。/absolute debt—— 间歇性测试标注属于测试债务；此命令会从根源上清除这些标注。/absolute work—— 当间歇性故障源于真正的产品代码竞态，需要进行实际的设计工作时使用。