CodeRush 接入 GitHub Copilot：Visual Studio 开发流的 AI 增强实践

CodeRush v26.1.5 更新发布后，最大的卖点不是又多了一批代码模板，而是正式把 GitHub Copilot 拉进了 Visual Studio 的日常开发流。我用了一个多星期，最直观的感受是：以前 Copilot 是“隔壁工位的 AI 同事”，你得复制代码、切窗口、粘过去问；现在它更像是 CodeRush 这个老管家亲自带着的实习生，你在编辑器里右键、在诊断窗口里点一下，它就能接话。这篇文章想聊聊这次接入到底能给 Visual Studio 开发者带来哪些实际变化，适合正在写 C#/.NET 的朋友参考，也适合还在观望、纠结要不要同时装两个工具的人。

1. 工具角色分工：先弄清楚 Copilot 和 CodeRush 各自在干嘛

很多人一听到“CodeRush 接入 GitHub Copilot”，第一反应是“是不是用 CodeRush 替代 Copilot？”或者“是不是 Copilot 把 CodeRush 的功能都覆盖了？”实际用下来完全不是这么回事。这两个工具解决的问题层面根本不一样，搞明白各自定位，才看得懂这次接入的价值。

1.1 GitHub Copilot 的强项与明显边界

GitHub Copilot 不是一个 IDE 插件，它是一个 AI 编程助手。它擅长的东西有三类：第一类是补全，你写一个方法签名，它帮你填方法体，写一行 SQL，它帮你补后面的 join 和 where；第二类是对话，尤其是在 Copilot Chat 里，你可以把一段代码选中，直接问它“这段逻辑有什么问题”“帮我改成异步”；第三类是生成，比如根据一个接口定义生成实现类，或者根据现有代码生成单元测试。

但 Copilot 有一个不可忽略的边界：它对你当前解决方案的“理解”是浅层的。它知道你打开的这份文件里有什么，但不一定知道你整个解决方案的分层结构、团队命名规范、项目里已经存在的基类和约定。我见过不少同事让 Copilot 生成仓储层代码，结果它把数据库上下文直接塞进了控制器，代码能跑，但架构是乱的。这不是 Copilot 笨，而是它天然缺少对项目全貌的感知能力。

1.2 CodeRush 的拿手好戏

CodeRush 是 DevExpress 出品的 Visual Studio 增强工具，资历比很多 AI 工具老得多。它在解决方案层面的能力非常强，具体来说有四块：一是导航，Ctrl+Shift+Q 可以跳转到任意类型和文件，Ctrl+Alt+Down 可以快速查看一个方法的实现，这些操作在大型项目里比 Ctrl+F 好用十倍；二是模板，输入ctor生成构造函数，输入prop生成属性，输入test生成测试方法骨架，这些模板生成出来的代码风格完全受项目模板控制，非常稳定；三是重构，提取方法、提取接口、封装字段、清理 using，操作简单而且可以跨文件处理；四是分析，Code Issues 窗口会实时列出代码诊断项，包括未使用的变量、可空引用警告、潜在的异常分支等。

CodeRush 的弱项也很明显：它不具备“创造性”。模板生成出来的东西都是它预设的，你没法让它理解自然语言然后生成一段有业务含义的逻辑。以前遇到这种情况只能自己敲，或者切到 Copilot Chat 手动复制粘贴。

1.3 二者结合的真实价值

所以这次 CodeRush v26.1.5 接入 GitHub Copilot，本质上不是谁替代谁，而是把 Copilot 的“生成能力”嵌入到了 CodeRush 已有的“结构能力”里。CodeRush 负责导航、重构、诊断、整理结构，Copilot 负责生成代码、解释逻辑、提供修复方案。开发者不用再在两套工作流之间来回切换，右键菜单里就能完成从“发现问题”到“让 AI 给出方案”再到“人工确认修改”的完整闭环。

换句话说，Copilot 给了 CodeRush 一颗会思考的“大脑”，而 CodeRush 给了 Copilot 一套能落地的“手脚”。这对 Visual Studio 开发者来说，才是实际能提升生产力的关键。

2. 升级接入：安装、配置与第一个 AI 入口

写这篇博文之前，我特地在两台机器上完整过了一遍接入流程，一台是 Visual Studio 2022，一台是 Visual Studio 2026 预览版，过程中踩了一些版本相关的坑，这里把可复现的步骤整理出来。

2.1 版本要求与环境检查

接入 GitHub Copilot 不是装一个 CodeRush 就完事，有三个前置条件必须满足。第一，Visual Studio 版本不能太老，我实测 VS 2022 的 17.6 以上版本和 VS 2026 都正常，官方支持说明里也明确写了最低版本要求；第二，必须安装官方 GitHub Copilot 扩展，并且已在 IDE 内完成账号登录，这个登录状态是后续所有 AI 入口的授权基础；第三，CodeRush 本身必须是 v26.1.5 或更高版本，如果你电脑上装的是旧版，需要先升级。

升级 CodeRush 的路径很简单：菜单栏选“扩展” -> “管理扩展”，在已安装列表里检查 CodeRush 的版本号，如果有更新，会看到更新按钮。我遇到过一种情况——企业环境通过离线安装包部署的 CodeRush，更新按钮是灰的，这种需要从 DevExpress 官网下载对应版本的离线包手动覆盖安装。升级完之后务必重启 Visual Studio，不然新版本的分析引擎不会生效，右键菜单里也看不到 AI 相关入口。

2.2 在 CodeRush 选项中开启 AI 集成

装好之后，默认情况下 AI 入口可能没有完全打开。打开“工具” -> “选项”，在左侧找到“CodeRush”节点，里面有一个“AI”或者“Integration”子项，不同小版本叫法会有差异，v26.1.5 里叫“AI Services”。在这里可以看到提供方列表，选中“GitHub Copilot”，确认启用状态。

这里有个细节：如果你在 Visual Studio 的扩展管理器里能看到 Copilot 扩展已经被加载，但在 CodeRush 的 AI 选项里依然显示未连接，多半是账号授权没有同步。解决办法是打开一次 Copilot Chat 窗口，随便问一个问题，让 Copilot 扩展完成一次完整的身份校验，再回到 CodeRush 选项里刷新状态，一般就能识别到了。这个坑我一开始没注意到，一度以为是版本不兼容。

另外，CodeRush 的 AI 选项里通常有几个开关：是否在右键菜单显示 AI 操作、是否允许 Code Issues 面板调用 Copilot 修复、是否在模板生成后自动触发 Copilot 补全。我的建议是刚上手的时候先全部开启，用几天再按需关闭。关闭后只是入口不显示，不影响已经生成的代码，不用担心。

2.3 接入后第一眼看到的变化

配置完成并重启 Visual Studio 后，你会立刻发现几个明显的入口变化。第一，在代码编辑器里选中一段代码并右键，菜单中出现了“Ask Copilot”“Explain with Copilot”“Fix with Copilot”之类的选项，这和以前只能去 Copilot Chat 里粘贴代码完全不同；第二，CodeRush 的 Code Issues 窗口里，每一条诊断项的右键菜单也增加了 AI 操作，可以直接把问题描述和上下文发送给 Copilot；第三，部分版本里还会在编辑器的选中文本附近出现一个小的 AI 悬浮按钮，点开就是相关的 Copilot 命令。

这几个入口看起来只是 UI 变化，实际上改变的是工作习惯。以前你遇到一个错误，先在 Code Issues 里看描述，然后手动切到浏览器或 Copilot Chat，把错误信息和代码片段粘贴过去，再等回复，整个过程至少打断两三次。现在右键点一下，Copilot 就能拿着当前文件的上下文直接给建议，省掉的不是几十秒，而是思维连贯性。这对沉浸式编码体验的提升，比省时间本身更重要。

3. 实操链路：代码生成后如何用导航和补全快速落地

说清楚了配置，接下来直接用真实场景演示。我给自己定的任务是：在一个模拟电商项目的解决方案里，新建一个订单查询服务。这个服务要接入已有的仓储接口，返回订单数据，并且做空值保护。整个过程中我尽量只依赖 CodeRush 和 Copilot，模拟一个“尽量少手动敲键盘”的开发流程。

3.1 场景设定与项目结构

解决方案里已有这些内容：一个IOrderRepository接口，里面定义了GetByIdAsync(Guid id, CancellationToken ct)方法；一个IDateTimeProvider接口，用于获取当前时间；以及一个Order实体类，包含Id、TotalAmount、Status、CreatedAt等属性。我的任务是新建OrderQueryService，并在其中实现一个GetOrderAsync方法，返回订单，如果订单不存在则抛出异常。

这个场景很典型。难点不在代码本身，而在于要和现有的接口、实体、异常类型对齐。如果让 Copilot 完全自由发挥，它可能会自己创建一个OrderNotFoundException，但项目里已经有一个放在Exceptions命名空间下的同名异常了，这时候就需要 CodeRush 的导航能力来“纠偏”。

3.2 用模板起手，让 Copilot 补方法体

我先新建一个类文件OrderQueryService.cs，在类体里输入ctor，CodeRush 立即弹出构造函数模板，按 Tab 接受后会生成一个构造函数。然后在构造函数参数列表里我先手动输入IOrderRepository repository，再输入IDateTimeProvider clock，CodeRush 会自动把这两个参数赋值给对应的私有只读字段并生成字段声明。这一串操作下来的体感是：CodeRush 把类骨架和构造函数这种固定结构快速搭好，完全不需要手动写字段赋值。

接下来是关键一步。我在类里输入一个空方法public async Task<Order> GetOrderAsync(Guid orderId, CancellationToken ct)，然后光标停到方法体，等一两秒，GitHub Copilot 的灰色建议就出现了。它给出的实现大概是这样：

public async Task<Order> GetOrderAsync(Guid orderId, CancellationToken ct) { var order = await _repository.GetByIdAsync(orderId, ct); if (order is null) throw new OrderNotFoundException(orderId); return order; }

这个建议和项目现有的结构完全吻合，_repository字段名正确，异常类型也对，没有多搞出多余的 using。我分析了一下为什么 Copilot 这次表现得这么准：因为它看到了构造函数里 CodeRush 刚生成的字段，看到了项目文件里已有的异常类型，上下文足够完整，它就不需要“猜”了。这就是 CodeRush 负责把结构搭好、让 Copilot 在稳定上下文里生成代码的真实案例。

3.3 用导航在解决方案里跳转，确认上下文

等一下，有人可能会问：如果 Copilot 建议里的类型没有引入对应的命名空间怎么办？这正是 CodeRush 导航发挥作用的地方。按 Ctrl+Shift+Q 打开搜索框，输入OrderNotFoundException，可以直接从这个类文件跳到异常类的定义处，确认它的命名空间和构造函数签名。确认后回到服务类，如果using缺失，代码下方会出现智能标记，按 Alt+Enter 或者 Ctrl+. 就能快速添加 using，根本不需要手动去文件顶部敲。

还有一种更省事的方式：选中OrderNotFoundException这个类型名，按 Ctrl+Alt+Down，CodeRush 会显示这个类型的所有实现和引用，你可以快速确认它有没有其他构造函数重载。我在这个场景里确认了异常类只有一个接受Guid参数的构造函数，和 Copilot 的建议匹配，于是放心接受。整个过程不超过二十秒。

这个细节很值得展开说。很多开发者觉得 Copilot 生成代码之后，“能用”就算完成，但实际上“能用”和“和项目风格一致”是两回事。CodeRush 的导航和引用查找，恰恰能让你在 AI 生成内容后快速验证它是否符合项目真实结构，而不必靠肉眼去翻文件。

3.4 用 Code Cleanup 收尾

代码写完、可以编译通过之后，还有一步不能省，就是 Code Cleanup。在 CodeRush 菜单里选择“Code Cleanup”，或者用快捷键 Ctrl+K、Ctrl+E，它会按照你在选项中预设的规则清理代码，包括排序 using、删除未使用的引用、统一花括号风格、调整空行位置等。Copilot 生成的代码有时候会在代码风格上比较随意，比如空行多了少了、就近 using 的排序不对，Code Cleanup 正好把这些不统一的地方一次性修掉。

我实测在刚才那个场景里，Copilot 生成的代码有一个未使用的 using（可能是它从别的上下文推断带来的），Code Cleanup 执行后自动被移除了，同时异常抛出语句之后多出来的一个空行也被规范化了。这样提交到代码评审里的时候，diff 会很干净，不会因为 AI 生成的风格问题让同事产生额外阅读负担。这个小步骤看似简单，但对实际项目协作很有意义。

4. 修复闭环：Code Issues 发现问题，Copilot 提供方案

接下来说一个更有意思的场景，也是我最推荐的 CodeRush 和 Copilot 协作方式：让 Code Issues 负责找出问题，再让 Copilot 负责给出修复方案。这个流程以前不可能实现，因为静态分析和 AI 之间的数据没有打通，CodeRush v26.1.5 算是把这条路修通了。

4.1 复现一个典型的代码问题

我在解决方案里留了一个有问题的文件，故意写了一个旧代码风格的方法：

public async Task<decimal> CalculateTotalAsync(List<Order> orders) { decimal total = 0; foreach (var order in orders) { total += order.TotalAmount; } return total; }

这段代码能编译，但存在几个问题：方法名带Async但内部没有任何异步操作，IDE 会给出警告；List<Order>作为参数类型偏具体，不够抽象；total用foreach累加，可以改成 LINQ 的Sum。在 CodeRush 的 Code Issues 窗口里，这些诊断会依次列出来，其中至少有一条标记为“Async method lacks await”的警告，严重程度是建议。

以前处理这种问题时，要么手动改，要么打开 Copilot Chat 把代码粘进去问“帮我优化”。这次我在 Code Issues 窗口里右键这条诊断，菜单中直接出现了“Fix with Copilot”选项。点击之后，CodeRush 会把当前方法的上下文、诊断信息和相关代码一起发送给 Copilot，然后在编辑器里弹出一个内联的差异视图，显示 Copilot 推荐的修改：

public decimal CalculateTotal(IReadOnlyCollection<Order> orders) { return orders.Sum(o => o.TotalAmount); }

这相当于把诊断问题、AI 方案、人工确认三个步骤压缩到了一个右键菜单里。省事是真的省事，但这里我要提个醒：不要无脑接受。

4.2 人工确认与 CodeRush 重构兜底

我遇到过不少情况，Copilot 给出的修复方案方向对，但细节有问题。比如上面这个例子，Copilot 直接建议把List<Order>改成IReadOnlyCollection<Order>，这在当前文件内没问题，但如果你在接口里定义了相同签名的方法，改动一个调用点，可能整个调用链都要跟着变。这时候就需要 CodeRush 的“查找所有引用”功能，列出所有调用CalculateTotal或CalculateTotalAsync的位置，逐个确认影响面，再决定是否接受 AI 的建议。

所以我的习惯是：Copilot 给方案，CodeRush 给影响面。先看诊断、再让 AI 生成方案、然后用 CodeRush 查引用、最后手工接受或微调。这套流程下来，既用了 AI 的效率，又保留了人类对代码变更影响范围的判断。实际上这是一种“AI 提议、人类决策”的比较理想的落地形态，而不是把修改权完全交给模型。

这里还涉及一个常见情况：Copilot 的修复方案可能引入了新的诊断。例如它把foreach改成了 LINQ，但如果某个比Sum更适合的项目自定义扩展方法存在，CodeRush 的 Code Issues 又会出现新的建议。这时候再次右键新诊断并让 Copilot 解释，就能形成一个持续的反馈循环。说实话，这个循环刚开始用的时候会有点上瘾，因为每点一下都能看到代码在变好，但注意控制节奏，别把 AI 的建议全部照单全收，关键逻辑还是得自己把关。

5. 测试与重构联动：从生成到跑通

代码写完了也修复完了，下一步自然是测试和重构。这一节我用两个小场景展开，讲讲 Copilot 和 CodeRush 在测试、重构联动上的真实表现。

5.1 一键生成单元测试并运行

单元测试这个场景，两个工具各有各的玩法。CodeRush 本身自带测试生成模板，可以快速生成一个测试方法的骨架，比如选一个方法右键，选择“Create Unit Tests”，它会生成一个基本的[Fact]或者[TestMethod]方法，里面有一个Assert占位。GitHub Copilot 则更擅长生成测试逻辑本身，比如根据方法的行为构造测试数据、设置 mock 的返回结果、断言具体的返回值。

在接入之后，我可以在同一个右键菜单里完成这两件事：先用 CodeRush 模板生成测试方法，再在空的方法体里通过 Copilot 补全测试逻辑。举个例子，我给订单查询服务写测试：

[Fact] public async Task GetOrderAsync_WhenOrderNotFound_Throws() { var fixture = new Fixture(); var repository = Substitute.For<IOrderRepository>(); var clock = Substitute.For<IDateTimeProvider>(); var service = new OrderQueryService(repository, clock); repository.GetByIdAsync(Arg.Any<Guid>(), Arg.Any<CancellationToken>()) .Returns(Task.FromResult<Order>(null)); await Assert.ThrowsAsync<OrderNotFoundException>( () => service.GetOrderAsync(Guid.NewGuid(), CancellationToken.None)); }

这里 Copilot 生成了整个测试逻辑，包括 mock 和断言，CodeRush 则负责让这个测试方法能在 Test Runner 里被识别并运行。CodeRush 自带的 Test Runner 窗口可以直接列出当前测试类中的所有测试，点击运行，结果会在一个独立的工具窗口里展示，不用等 Visual Studio 自带的测试资源管理器慢慢刷新。实测下来，这个组合比单独用任何一方都顺滑。

5.2 重构时 Copilot 和 CodeRush 的配合

再来看一个更典型的重构场景：把一个同步方法改成异步方法。假设我有一个老的同步方法public Order GetOrder(Guid id)，希望改成public async Task<Order> GetOrderAsync(Guid id, CancellationToken ct)并更新所有调用方。如果只靠 Copilot，它可能只会帮你改当前文件，其他调用方还是报错。如果只靠 CodeRush，它能快速改名和改引用，但方法体内的异步逻辑还是要自己写。

接入后的体验是：先让 CodeRush 执行改名操作，比如把方法名改成GetOrderAsync，它会自动更新所有引用位置；再让 Copilot 基于新的签名修改方法体，补充await和CancellationToken参数传递；最后让 CodeRush 的 Code Issues 扫描整个解决方案，确认没有遗漏的调用方。三个动作串起来，一个原本需要手动改五六个文件的重构，变成几分钟内完成的操作。这个过程中最核心的体验是：AI 负责“写”，结构工具负责“改全”，二者缺一不可。

5.3 大文件下的实际体感

最后说一个我自己特别在意的问题：大文件下两个工具的表现。我在一个老项目里试过一个四千行的控制器文件，里面全是历史遗留代码。这种文件里 Copilot 经常出现两种情况：一是建议内容因为上下文太长而变慢，二是建议的代码参考了文件很靠前的内容，但屏幕上看不到，容易出错。这时候 CodeRush 的局部结构能力就特别有用。我可以用 CodeRush 的“块选择”和“折叠”功能，把大文件拆成小块，选中其中一个方法，再在选中区域里调用 Copilot 让它解释或重写。这种“先缩小上下文，再让 AI 介入”的用法，在大文件里几乎是必备技巧。

另外我还发现一个有意思的细节：CodeRush 的代码导航在 Copilot 多行建议的接受过程中非常顺手。Copilot 有时候建议的是一个完整的属性块，接收之后如果发现这个属性名重名了，CodeRush 的 Code Issues 会立刻报错。如果是以前，我可能要编译一次才能发现，现在几乎是实时反馈。这种“AI 生成、结构工具即时校验”的组合，体验上的提升是实打实的。

6. 常见问题与避坑指南

无论配置多顺利，实际用起来总会遇到各种问题。我把自己在这段时间里遇到的、以及同事反馈过的典型问题整理出来，方便大家排查。

6.1 Copilot 入口不显示或者无响应

这是接入后最常遇到的问题。右键菜单里没有“Ask Copilot”“Fix with Copilot”，一般有三个原因。第一，CodeRush 的 AI 集成选项没有打开，或者是旧版本没有这个功能入口，检查工具 -> 选项 -> CodeRush -> AI Services，确认启用。第二，GitHub Copilot 扩展没有登录，打开扩展管理看状态，如果显示需要登录，先完成登录再重启 VS。第三，用户界面语言或者版本差异导致菜单名称不同，v26.1.5 里是“Ask Copilot”，较早版本可能是“Ask AI”，按功能描述找就行。

还有一种比较隐蔽的情况：如果电脑上同时装了其他 AI 助手扩展，比如某些代码补全类的插件，可能会抢占 Copilot 的补全触发接口，导致 CodeRush 里的入口虽然存在但点击后无响应。排查方法是禁用其他 AI 相关扩展，单独启用 Copilot 和 CodeRush，重启 VS 再试。

6.2 快捷键冲突怎么办

CodeRush 和 Visual Studio 默认快捷键本来就多，接入了 Copilot 之后，AI 操作也要占用快捷键，冲突的概率直线上升。最常冲突的是 Ctrl+. 和 Alt+Enter，Visual Studio 自己的快速操作和 CodeRush 的智能标记都会用这两个键。我的处理方式是：在“工具” -> “选项” -> “CodeRush” -> “Keyboard Mapping”里，找到和 AI 操作相关的绑定，改成我自己习惯的组合，比如 Ctrl+Alt+A。另外，Copilot Chat 自己的快捷键 Ctrl+Alt+I 也可能和某些 CodeRush 命令冲突，这个在 Visual Studio 的键盘映射设置里能统一修改。

修改快捷键的思路有个原则：把频繁使用的操作绑定到最顺手的键位，不常用的别占好位置。我自己的习惯是：跳转用 Ctrl+Shift+Q，这个保持默认；AI 对话用 Ctrl+Alt+A，这个是我自定义的；快速操作保持 Alt+Enter。调整完之后，日常操作里几乎没有撞车的情况。

6.3 性能下降与上下文踩坑

接入 AI 之后，性能问题是绕不开的话题。CodeRush 本身有一个持续运行的分析引擎，Copilot 又会在后台保持一个上下文窗口，两者叠加之后，如果项目特别大，内存占用和 CPU 占用可能有明显上升。我在一个大型解决方案里实测过，同时打开 Code Issues 和 Copilot 自动补全，内存占用比只开 CodeRush 时高出大约 300 到 500 兆。对 16G 内存的开发机来说还能接受，但如果你用的是 8G 内存的老机器，建议在有明确需求时再打开 AI 集成，平时可以在 CodeRush 选项里暂时禁用。

上下文踩坑则更隐蔽。Copilot 生成建议的质量高度依赖它看到的上下文长度。在超大文件里，自动补全的准确率会下降，我自己的经验是超过一千行的方法体，Copilot 的建议质量明显变差。解决办法之一是借助 CodeRush 的“临时停用代码分析”或块选择功能，先把要处理的代码段隔离出来，再让 Copilot 在这个局部上下文里工作。这比在完整文件里让 AI 自由发挥要靠谱得多。

6.4 常见问题速查表

还有一个很实际的问题要提醒一下：代码合规和隐私。如果公司有严格的数据外发管控，使用任何 AI 编程助手前都应该和团队确认策略。CodeRush 接入 Copilot 后，右键操作会发送当前文件的相关上下文到 Copilot 服务端。虽然 Copilot 对发送内容的范围和用途有官方说明，但企业场景下，敏感代码还是建议手动脱敏后再交给 AI 分析，或者直接关闭代码相关的 AI 入口，只用本地诊断。

用到现在，我个人最深的体会是：CodeRush v26.1.5 接入 GitHub Copilot，不是把两个工具的按钮拼在一起，而是把 AI 的灵活性和结构化工具的严谨性凑到了一起。CodeRush 帮 AI 补上了对项目结构理解不足的短板，AI 则帮 CodeRush 突破了模板化生成的局限。最后给一个实用的建议：刚上手时别贪多，先把右键菜单和 Code Issues 里的两个 AI 入口用起来，等习惯了这种“AI 提议、结构工具兜底”的节奏，再慢慢打开其他入口。你会发现真正的提效不是来自某一个 AI 功能，而是来自整套开发流被重新理顺。