先看看示例
作者提供的示例，实际效果取决于你的输入和使用工具。
输入
原逻辑：amount <= limit；变异：amount < limit；现有用例只测 5<10 与 15>10，变异存活。
输出
编辑示例 · 未运行
存活原因：现有用例没有覆盖 amount 等于 limit。
应补规则用例：amount=10、limit=10，预期允许。
对照：原代码应通过，变异代码应失败。
不能据此断言：其他金额计算都正确。
后续：在限定模块重跑该变异与相关测试，记录真实结果；本例尚未执行。
方法说明
配置 mewt 或 muton 变异测试，分析存活变异与测试缺口。 具体任务 在限定模块运行变异测试活动：选择 mewt/muton 配置、测试命令与预算，观察刻意改坏代码能否被发现。 解释存活变异对应的测试缺口：区分等价变异、未覆盖和断言不足，提出具体补测。 必需材料 目标模块与现有测试命令 可接受运行时间和外部依赖限制 可选材料 已有变异结果 覆盖率与慢测试清单 使用门槛 有可重复且隔离的项目测试环境，并能使用兼容版 mewt 或 muton。 这个 Skill 额外提供的方法 把测试质量问题定位到具体规则和断言，而不是只追覆盖率数字。 编辑示例（未运行） 发现价格上限的边界没被测试 任务：分析一条编辑构造的存活变异。 输入： 原逻辑：amount <= limit；变异：amount < limit；现有用例只测 5<10 与 15>10，变异存活。 结果片段： 存活原因：现有用例没有覆盖 amount 等于 limit。 应补规则用例：amount=10、limit=10，预期允许。 对照：原代码应通过，变异代码应失败。 不能据此断言：其他金额计算都正确。 后续：在限定模块重跑该变异与相关测试，记录真实结果；本例尚未执行。 展示精确的边界缺口和预期区别，而非只建议“增加测试”。 此为编辑示例，未安装或运行上游 Skill。 首次任务 在【模块/测试命令】范围内做变异测试，预算【时间】，限制【外部依赖】；验收：报告存活原因、等价判断与具体补测，并记录真实运行范围。 必需材料：目标模块与现有测试命令：【请填写或粘贴】；可接受运行时间和外部依赖限制：【请填写或粘贴】 验收方法 测试本身是否稳定可重复 存活项是否确实可区分而非等价变换 补测是否验证业务规则而非实现细节 依赖与准备 mewt 或 muton、项目测试环境；CLI 接口以安装版本帮助为准，执行会消耗计算资源。 使用边界 计算开销可能较高，应限定目录和时间预算。 杀死率不是业务正确性的证明，等价变异需人工判断。 排错 活动耗时超出预算：缩小模块或变异集合，先解决高价值存活项。 高覆盖率仍有大量存活变异：检查断言是否只验证不抛异常，加入结果与边界判断。 固定来源 https://github.com/trailofbits/skills/blob/0cc1c73a5e96749ab32d7ea5e14892fafa6972ae/plugins/mutation-testing/skills/mutation-testing/SKILL.md