关于 antithesis-review-inputs
用于只读审查 Antithesis 测试负载输入生成方式的技能，面向希望了解随机输入是否限制探索范围的开发者。它按结构性反模式分级报告未覆盖的状态空间，不修改负载或提交代码更改。
主要功能
- 01检查操作选择与数据生成
- 02审查并发、节奏和初始状态
- 03按严重程度整理发现
- 04指出代码位置及未探索空间
- 05只读生成审查报告
适用场景
- 01排查测试负载长期未发现问题的原因
- 02定期检查人工编写或生成的负载
- 03评估随机策略是否限制状态探索
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/antithesis-review-inputs确认已加载。
附带文件references/anti-patterns.md
详细介绍
Antithesis 输入审查
技能版本： 2026-10-21 4f8d80b
目的和目标
检查工作负载，并报告其输入生成对状态空间的探索程度。被测系统是一个黑盒——审查完全依据工作负载代码以及用户提供的任何文档进行。
此技能为只读。它会生成一份调查结果报告，不会修改工作负载、创建 PR，也不会建议具体代码更改。
这里采用“尚未探索的空间”这一视角——调查结果反映的是工作负载尚未触及的空间，而非缺陷。即使工作负载存在任何反模式，仍可能很有成效。关键问题在于：如果从结构上改变其使用随机性的方式，是否能够触及更有意思的行为。
适用场景
当用户没有发现漏洞，并想了解工作负载的输入生成是否限制了 Antithesis 的探索范围时使用。也可用于定期检查工作负载的健康状况，适用于人工编写和 Agent 生成的工作负载。
核心原则
每次运行都要随机化策略，而不仅仅是在固定策略下随机选择。每次运行都应通过采用不同的配置偏向来探索不同的行为区域。此技能会审查工作负载在这方面的表现。
工作流
1. 定位工作负载
找到测试命令和工作负载代码。常见位置包括：
antithesis/test/— 测试命令脚本- 测试命令引用的工作负载源文件
- 工作负载使用的客户端库或辅助工具
如果工作负载的位置不明确，请询问用户。
2. 阅读反模式参考
在检查工作负载之前，先阅读 references/anti-patterns.md。该文件按类别整理了完整的输入生成反模式目录，并解释了每种模式为何会限制探索，以及更好的做法是什么。
3. 检查工作负载
阅读工作负载代码，寻找与反模式相符的结构模式。重点关注代码中可见的内容：
操作选择 — 如何选择操作？
- 是否始终启用固定的完整操作集合，还是会针对每次运行进行子集选择？
- 操作权重是固定的、均匀的，还是会随每次运行变化？
- 顺序是由测试框架设定的，还是由随机性自然形成的？
- 是否总是同时启用对称操作对？
数据生成 — 如何生成输入？
- 值是硬编码的、从固定池中抽取的，还是动态生成的？
- 范围是否会随每次运行变化，还是边界值被硬编码？
- 输入质量是否会变化（有效、无效、混合），还是始终有效？
- 载荷大小是否跨越多个数量级，还是始终处于较窄范围内？
结构 — 工作负载如何组织？
- 并发级别是固定的，还是会随每次运行变化？
- 操作节奏是否会变化，还是始终保持稳定／快速？
- 工作负载是否总是从空状态开始？
4. 整理调查结果
针对你在工作负载中识别出的每种反模式：
- 写出模式名称
- 指出你在代码中的发现位置（文件和行号）
- 说明它让哪些状态空间未得到探索
- 描述如果改变这一点，工作负载可能触及哪些行为
说明应具体针对该工作负载，而不是泛泛地复述反模式。“你的三个操作（put、get、delete）始终全部启用且权重相同——只触发 delete 的运行可以测试没有任何键时的行为”比“所有操作始终启用”更好。
5. 对发现进行分级
并非所有发现都同等重要。请按以下级别划分：
- 高信号 — 工作负载存在明显的结构性限制，导致它无法触及整个状态空间区域。例如：所有操作始终处于启用状态，且无法进行子集选择；所有值都是硬编码的。
- 值得考虑 — 通过修改，工作负载可以探索更多状态空间，但该限制更依赖具体情境或影响较轻。例如：没有对空值／缺失值进行变化、并发级别固定。
- 观察 — 审查者注意到的、可能因系统而异的重要事项。例如：编码方式变化、每次运行使用相同的种子数据。
如果缺乏领域知识就无法评估某项发现的严重程度（例如，“这个范围是硬编码的，但我不知道系统接受哪些值”），请如实说明。指出结构事实，并让用户自行判断其领域影响。
6. 提交报告
报告结构如下：
-
工作负载的行为 — 简要概述审查者观察到的内容：工作负载执行了哪些操作、如何生成数据，以及它的结构。这是审查者对工作负载的理解，应先呈现给用户，以便用户在阅读发现之前纠正误解。
-
发现 — 按级别组织（高信号优先）；如果多项发现集中在同一类别，则按类别分组。每项发现都应指出相应模式、标明代码位置，并结合该工作负载具体说明未探索到的状态空间。
-
做得好的方面 — 指出工作负载已采用的良好模式。如果工作负载会为每次运行选择操作子集，或改变负载大小，请明确说明。只列出发现的报告读起来像是在批评；认可做得好的方面，能让报告更像一份评估。
语气
报告应传达“这里有一些你尚未触及、但可以探索的状态空间”，而不是“你的工作负载很糟糕”。即使工作负载存在多种反模式，它仍可能发现 bug；目标是帮助它发现更多 bug。
不要把发现表述成“你需要这么做”。应表述为“这是你尚未触及的状态空间，以及触及它会是什么样子”。由用户决定哪些修改值得进行。
范围边界
本技能审查的是输入生成——工作负载如何驱动系统进入多样化状态。它不审查：
- 断言质量 — 工作负载触及 bug 时是否能够发现它。这属于另一个问题。
- 系统正确性 — 被测系统的行为是否正确。SUT 是黑盒。
- 工作负载正确性 — 工作负载代码本身是否有 bug。审查者关注的是工作负载的结构，而非其正确性。
- 基础设施 — Antithesis 设置、Docker 配置或测试模板是否正确。
如果审查者注意到范围之外但似乎很重要的事项（例如，工作负载完全没有断言），可以简要提及并将其作为观察，但不应深入审查。
参考文件
| 参考资料 | 阅读时机 |
|---|---|
references/anti-patterns.md | 检查任何工作负载之前——完整目录 |