What Happens When You Give AI Agents the Map of Your Code's Coverage?
TL;DR · AI 摘要
JetBrains Rider 2026.2引入AI代理技能系统，通过代码覆盖率数据帮助AI智能定位测试位置，将AI成本降低一半，解决AI代理盲目搜索项目文件的效率问题。
核心要点
- Rider 2026.2新增finding-tests技能，利用代码覆盖率数据指导AI编写测试
- AI代理技能系统可将AI token消耗减少50%，提升开发效率
- 支持IDE、全局、项目级等多种作用域配置AI技能
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- Rider AI代理技能系统
- 问题背景
- AI测试定位困难
- Token消耗过大
- 解决方案
- Agent Skills标准
- 代码覆盖率数据
- 实现细节
- finding-tests技能
- 多作用域配置
金句 / Highlights
值得收藏与分享的关键句。
在复杂的.NET解决方案中，单个生产文件可能在多个项目或测试套件中进行测试，AI代理仍可能猜错位置。
Rider 2026.2通过教授AI代理新技能，利用JetBrains .NET覆盖工具将AI费用削减一半。
AI代理技能系统基于Anthropic引入的开放标准，扩展AI代理能力并提供专门知识和工作流程。
技能可在不同作用域启用：IDE范围、全局每代理范围、每项目范围和每项目每代理范围。
.NET 和游戏开发者的必备生产力工具包
当你给 AI 代理提供代码覆盖率地图时会发生什么？
2026年5月22日
当你让 AI 代理编写新功能时，一个好的代理最终会说："我需要为此写一个测试。"
但接下来发生的事情通常很混乱。
为了确定那个新测试应该放在哪里，代理必须开始搜索你的项目。它可能会扫描文件名，检查文件夹，grep 方法名，并逐个读取文件来理解你的测试是如何组织的。这会快速消耗你的 token 限制。
更糟糕的是，在复杂的 .NET 解决方案中，单个生产文件可能在多个项目或测试套件中进行测试，代理仍然可能猜错。它可能会把测试放在错误的位置，错过相关的测试装置，或者采用与团队已使用的方法完全不同的测试风格。
在 Rider 2026.2 EAP 中，我们通过教授 AI 代理一项新技能来改进这个工作流程——这项技能利用 JetBrains 的 .NET 覆盖率数据工具，将你的 AI 开销减半。
为什么 AI 代理需要的不仅仅是代码上下文
AI 代理之所以有用，是因为它们可以处理多步骤的开发任务。它们可以检查代码、进行更改、运行测试、响应失败并迭代。
但即使是有能力的代理，其表现也仅限于它们接收到的上下文质量。
当代理需要添加测试时，问题不仅是："这个测试应该断言什么？" 它还需要知道：
- 这段代码的测试通常放在哪里？
- 哪些现有测试已经执行了附近的代码？
- 这个项目使用什么测试框架、装置结构、命名约定和断言风格？
- 是否已经有一个应该扩展而不是创建新文件的测试文件？
人类开发者通常从经验中知道这些。AI 代理通常必须以昂贵的方式发现它们：通过阅读整个项目。
这就是 AI 代理技能发挥作用的地方。
什么是代理技能？
如果你一直在关注 AI 辅助开发的发展，你可能遇到过代理技能的概念——这是由 Anthropic 引入的开放标准，用于通过专门的知识和工作流程扩展 AI 代理的功能。你可以从这篇博客文章了解更多关于 JetBrains IDE 中的代理技能。
在 Rider 中，技能使 AI 代理能够访问 IDE 原生的上下文和工作流程。技能可以帮助代理使用 Rider 已经理解的信息执行特定任务，而不是仅依赖通用文档或要求模型手动探索你的项目。
你可以在 Rider 中从 _设置/首选项 | 工具 | AI 助手 | 技能_ 管理技能。根据你想要使用技能的方式和位置，可以在不同范围内启用技能：
- IDE 范围： 在 Rider UI 内的所有项目和所有代理都可用。
- 全局每代理范围： 在所有项目中对特定代理可用，包括 IDE 外部。例如，这可以在特定代理目录中配置，如 ~/.codex。
- 每项目范围： 对使用特定项目的所有代理可用，包括 IDE 外部。例如，这可以在项目级 .agents 目录中配置。
- 每项目每代理范围： 仅对特定项目中的特定代理可用，比如项目级 .codex 目录。
一旦安装，支持的代理可以在相关任务中自动使用技能。你也可以在 AI 聊天中通过输入 _/_ 后跟技能名称手动调用技能。
介绍查找测试技能
虽然像 Microsoft 的 dotnet/skills 这样的生态系统为 AI 代理提供了关于_如何_编写 .NET 测试的通用文档，但它们仍然让 AI 猜测_在哪里_放置测试。
与其让代理在需要编写测试时盲目搜索你的代码库，我们引入了一个名为 finding-tests 的新代理技能。它以两部分形式发布：作为 Rider AI 助手的捆绑技能，以及用于 Claude Code 或 Codex 等外部代理的独立 MCP 工具（findTests）。
捆绑技能在 Rider 2026.2 EAP 的 Rider AI 助手中默认启用。要在外部代理中使用它，请在相关代理或项目范围内安装技能，然后确保外部客户端可以通过 MCP 访问 Rider。你可以从 _设置/首选项 | 工具 | MCP 服务器_ 执行此操作：启用 MCP 服务器，然后使用_自动配置_为外部客户端设置访问权限。
想法很简单：Rider 已经通过捆绑的dotCover 工具访问强大的 .NET 覆盖率分析，所以当 AI 代理需要了解一段代码在哪里被测试时，它不应该仅从文件夹名称和搜索结果推断这种关系。
它可以只询问 Rider。
Rider 随后将使用 dotCover 覆盖率数据来识别哪些测试与代理正在处理的代码相关联。这将覆盖率数据转化为 AI 生成测试的可操作上下文。
以下是工作流程的内部实现：
- 代理决定需要一个测试。当 AI 编写新代码、修改现有行为或您明确要求它添加测试覆盖率时，它可以触发
finding-tests技能。 - Rider 向 dotCover 请求覆盖上下文。dotCover 运行解决方案中包含的测试，并映射出代理正在处理的代码周围的覆盖率数据。
- 找到正确的测试位置。由于 Rider 可以理解哪些测试已经覆盖了附近的代码，它可以为代理提供相关的测试文件路径，而不是让代理手动发现。
- 代理遵循您现有的测试风格。代理直接转到正确文件，读取周围测试，遵循项目约定，并生成适合现有代码库的测试。
以下是 IDE 内部完整工作流程的样子：
结果：代币成本减半
这不仅仅是生活质量的改进。它对您的工作流程和预算都有重大影响。
✂️ 代币成本减少 50%。
通过阻止 AI 在您的项目中无谓地游荡，您可以节省大量资金。
在我们的内部基准测试中（主要使用 Claude 代理进行测试），将代理直接路由到正确文件可以将代币消耗减少多达 50%。
_在真实开源解决方案中的各种 C# 测试生成案例的成本比较显示，使用带有 Claude 的 finding-tests 代理技能可以显著降低平均 AI 代理任务成本。_
好处不仅仅是降低 AI 支出。对于使用基于配额访问或共享 AI 积分池的团队来说，这也意味着在搜索和探索上浪费的积分更少。相反，更多的 AI 配额可以用于更高价值的开发任务。
🎯 每次都是正确的文件
没有覆盖率数据，代理只能猜测。在大型代码库中，一个类可能从多个位置进行测试，这些猜测经常是错误的，导致测试被放入错误的文件、以不匹配的风格编写，或者完全针对错误的测试套件。
使用 finding-tests，代理拥有精确的地图。无需猜测。没有错误的文件。没有风格不匹配。
时间与代币
我们希望完全透明地说明这是如何工作的：这种设置用时间支出换取代币支出。
为了让 AI 获得确切的文件路径，dotCover 必须对您的解决方案运行覆盖率分析。对于小型或中型项目，这可能需要 30 秒。但如果您在大型代码库中工作，运行完整的覆盖率扫描可能需要几分钟甚至几小时。
如果明天您有发布截止日期，您最不想看到的就是您的 IDE 突然启动一个多小时的测试运行。幸运的是，解决方案相当简单。
如何关闭它
由于这种时间权衡，让您掌控控制权是我们的首要任务。finding-tests 技能在此次 EAP 中捆绑并默认启用，但您可以禁用它或将其限制在特定项目中。
要管理它，请转到 _设置 / 首选项 | 工具 | AI 助手 | 技能_。在面板上找到 finding-tests，您可以检查技能、禁用它，或使用下拉菜单为其配置特定项目。
您可以稍后轻松重新启用该技能。
已知问题
由于这是早期访问计划 (EAP)，我们仍在解决一些小问题。以下是您应该注意的问题：
- 首次运行故障：
finding-tests工具偶尔会在首次启动时出现故障或失败。第二次尝试通常可以确保其正常运行。 - IDE 中的 Codex 支持目前有限：目前，由于技能捆绑机制的已知问题，AI 助手中的 Codex 无法使用捆绑技能。AI 助手团队正在修复此问题。
_可能的解决方法_：如果您想将 finding-tests 与 Codex 一起使用，请在全局或项目范围内显式安装该技能。这使得该技能可用于外部和 IDE 内部的代理。
- 大型解决方案的超时：如果完整测试运行时间超过 120 秒，Codex 和 Copilot 代理当前会超时。我们知道实际解决方案的测试时间可能更长，我们正在优化此管道。
Codex 的解决方法：外部 Codex 可以通过在 MCP 配置中增加工具超时来缓解此问题。在全局或项目 MCP 配置中为 tool_timeout_sec 参数设置更大的值_按照 Codex 文档_。
- 外部代理需要 MCP 设置：要将
finding-tests与 Claude Code 或 Codex 等外部代理一起使用，您需要启用 Rider 的 MCP 服务器并为代理配置 MCP 访问权限。
转到 _设置 / 首选项 | 工具 | MCP 服务器_，启用 MCP 服务器，然后自动配置或手动为您代理配置 Rider 的 MCP 服务器。之后，在代理的全局或项目范围内安装该技能。
路线图上的下一步
这里是一个预览，说明这将走向何方：如果 finding-tests 技能证明有价值，我们的下一步将是引入目标覆盖率——一个 AI 代理自动生成足够单元测试以达到特定预选代码覆盖率百分比的功能。
这将让您轻松满足强制性覆盖率要求，而无需花费额外时间手动编写测试。您对此 EAP 的反馈直接影响此功能是否会构建。
告诉我们您的想法
此功能对 Rider 2026.2 EAP 中的所有用户开放，这为您提供了免费体验 dotCover 的好机会——我们的明星代码覆盖率工具通常需要 dotUltimate 许可证。
目前，我们需要了解这项技能是否有效并为您提供了足够的益处，以及是否存在我们需要考虑的边缘情况。请试用新的测试生成功能，看看它如何影响您的工作流程，并请告知我们这项技能是否应该默认捆绑或移至可选注册表！
[](https://blog.jetbrains.com/dotnet/2026/05/22/claude-codex-ai-agent-skill-for-writing-tests/#)