stryker-mcp-reporter 于近日发布 v1.13.0。该版本新增一个 ESLint 钩子，并允许 AI 代理运行 Stryker 突变测试，以追逐 100% 的变异得分（Mutation Score）。不过，这个"已验证"的宣称目前缺乏可复现的实证支撑。

核心事实如下：

打开网易新闻 查看精彩图片

· v1.13.0 新增针对 McCabe 复杂度和 max-lines 的 ESLint 钩子；
· 支持 Antigravity、Cursor、Claude Desktop、Roo Code、Cline 等 AI 编程工具；
· 配置采用单个 JSON 块加 npx 命令；
· 项目在 GitHub 上以 MIT 许可证开源；
· 公告声称通过 MCP 循环实现了"已验证的 100% 变异得分"。

标准代码覆盖率衡量的只是代码执行路径，而非测试强度。AI 编程助手常常生成数百行单元测试，却陷入"快乐路径偏差"——测试能跑通的功能，而不是会被打破的边界。项目公告将 v1.13.0 定位为填补这一空白的方案。

然而，新版本本身的功能增量相当有限：提交 330a951 添加了一个强制 McCabe 复杂度和 max-lines 限制的 ESLint 钩子。其余价值几乎全部来自 MCP 集成本身——它让 AI 结对编程代理执行突变测试、通过模型上下文协议检查存活的突变体，并编写边界测试来逐步缩小缺口。

为什么变异得分比覆盖率更有意义？突变测试会修改源代码——翻转运算符、删除语句——然后检查你的测试套件能否捕获这些改动。100% 变异得分意味着每一个注入的故障都被探测到，这比行覆盖率是更强的信号：行覆盖率可能达到 100%，而测试却没有断言任何有价值的内容。代价则一直是成本：底层框架 Stryker 会生成大量突变体，每个突变体都要跑一遍完整的测试套件，慢且嘈杂。

v1.13.0 的价值在于把这一昂贵的循环交给 AI 代理来自动化。但"100% 变异得分"的宣称要想成立，需要提供可复现的步骤、CI 日志或最小化示例。公告中这些一概缺失。对于严肃的工程团队，建议在本地流水线中自行验证，而非直接采信发布公告中的数字。