Visual Studio 十月更新改善 AI 与 Git 工作流

Visual Studio 的 18.11 更新，把两件事放到了一起：减少 IDE 日常操作的摩擦，以及把 Copilot 聊天迁到统一的 SDK 上。前者改善合并、构建和会话恢复，后者试图让 IDE 跟上 Copilot 其他客户端的能力演进。

对程序员来说，最该关注的未必是 AI：三个重要功能默认关闭，更新后需要手动启用；构建提速的数据也有明确适用范围。这篇解读把可直接使用的改进、架构调整和升级代价拆开看。

先解决那些每天都在浪费时间的小事

原文列出的发布节奏是：18.11.0 在 10 月 13 日推出，18.11.1 在 10 月 20 日跟进，18.11.2 在 10 月 25 日发布。作者把这轮更新的重点归为基础体验：少丢工作现场，少做重复操作，早点结束注定失败的构建。

Git 有两项实用变化。在 Git Repository 窗口右键某次提交，选择 Compare with Working Tree，就能把该提交与当前代码比较，覆盖已提交和未提交的变化，无须切换检出。重构到一半，想确认「从那个版本开始到底改了什么」，就适合用它。

另一项是批量解决冲突。在 Git Changes 的 Unmerged Changes 下，Keep All Current 和 Take All Incoming 可以作用于文件、文件夹或仓库根目录，一次处理其下的冲突。它适合已经确定取舍策略的内容，例如统一接受传入的生成文件。按钮减少的是点击次数，取舍仍由开发者负责。这些改进接续了 18.9 的 worktree 支持和 Git submodule 集成。

Hot Exit 则负责保存工作现场：未保存的新文件、已有文件的未保存修改、包含 Ctrl+Z 在内的撤销历史，以及标签页和窗口布局，都可以在重开后恢复。它默认关闭，需要在 Tools → Options → Projects and Solutions → General 勾选 Reopen unsaved documents on solution load or empty environment。Ctrl+N 新建文件中的 Markdown 模板也能配合使用，让临时笔记跨重启保留。

更新完成，不等于这些改进已经生效。

构建快了 94%，到底快在哪里

Stop solution build after first failure 同样需要手动开启，位置是 Tools → Options → Projects and Solutions → Build and Run。首次失败后，Visual Studio 停止排队启动后续项目，并安全停止正在运行的项目；最终结果仍标记为失败，而非取消。

原文引用的 Microsoft 测试中，四次常规构建在关闭该设置时平均耗时 26 秒，开启后为 1.5 秒，失败后的耗时减少 94%。

这个数字不能理解成所有构建都能提速 94%。它描述的是特定解决方案中，已经出现失败以后还能省下多少等待。底层项目出错，后面一串依赖项目继续构建也无法产出有效结果，尽早停下才有收益。原文明确说结果会变化，长依赖链和高度并行的构建被认为更可能受益，但没有给出覆盖更多项目的对照数据。

其他调整也沿着减少打断的方向展开。Fonts and Colors 迁到 Unified Settings，增加分类导航、搜索、行内预览和网格视图，并接入 settings.json：界面修改能反映到文件，文件修改也能反映到界面，方便版本管理和共享。

键盘操作也补齐了一些细节。Ctrl+Numpad 1 到 9 跳到对应编号的文档标签；Ctrl+Shift+PgUp 和 PgDn 移动标签，固定与未固定标签保持分组。这会接管原先 Edit.ViewTopExtend、Edit.ViewBottomExtend 的绑定。Ctrl+NumPad0 将缩放恢复到 100%。

Quick Info 悬停延迟可设为 50 到 10000 ms，默认 150 ms；Open Folder 也开始遵循与解决方案相同的恢复设置。

Copilot 换底座，收益和迁移成本一起到来

新聊天体验基于 Copilot SDK，与 Copilot CLI、GitHub Copilot app 使用同一基础。迁移从 7 月的 Agent (Preview) 开始，18.11 扩展到 Ask mode、Agent mode 和底层聊天基础设施。

Microsoft 声称它能减少 agent 工作流中的来回交互，通过更好的提示缓存支持更长会话，并让不同客户端表现更一致。这里的关键是共享实现：以后 Copilot 底层改进，有机会更顺畅地进入 Visual Studio。原文没有提供响应速度、任务成功率或缓存收益的对照测试。

启用路径是 Tools → Options → GitHub → Copilot → Copilot Chat，勾选 Use new Copilot chat experience 后重启。它也是默认关闭。

此前几版已经铺好部分能力：18.9 的 Git agent 可审查未提交修改和提交，在 GitHub、Azure DevOps 仓库留下行内评论；18.10 支持在聊天里浏览 pull request，并跳转到评论和文件。IDE 内的 pull request 浏览与审查位于 Tools → Options → Preview Features。

迁移也带来兼容性变化。18.10 的 Bring Your Own Key 预览支持 Microsoft Foundry、OpenAI、Anthropic、Ollama，但仅用于新 Agent (Preview)。旧 Ask 和 Agent modes 的 BYOK 路径已不再受支持。18.8 内置的 .NET、Azure skills 则默认关闭。

费用与信任边界也需要一起看。18.9 为受支持模型提供 low、medium、high 思考强度和用量视图，原文称 Copilot 已转向按 token 消耗计量。自 18.7 起，MCP server 信任校验默认开启：配置以及 tools、prompts、resources、instructions 会与上次批准的指纹比较，变化后要求重新批准。它检查的是工具环境有没有变，并不能据此认定每次工具调用都安全。

我的判断

我认同作者对基础体验的重视。提交与工作区比较、省掉无效构建、恢复未保存现场，都对应具体操作，收益容易在自己的项目里验证。相比切换提交再比较、逐文件处理冲突，这些集成操作确实能缩短路径。

但 SDK 统一能否让 Visual Studio 更快获得新能力，目前仍是架构上的合理预期。原文没有跨客户端的交付延迟数据，也没有新旧聊天的任务对照。减少来回交互、改善长会话等说法，应当先按官方宣称理解。

月更也有代价。原文称从 5 月的 18.6 起，每月都有编号更新，期间穿插每周补丁；9 月更新包含多项 .NET、ASP.NET Core 安全修复，18.11.2 又包含三项安全公告。同时，18.11.2 已知存在按 F5 无法启动 Blazor WebAssembly 调试适配器的问题，较早补丁还修过 Copilot 聊天打不开。

作者建议把每轮前两周视作软发布，这是经验建议，没有回归率数据支撑。是否等待，应结合团队依赖的调试功能和安全补丁紧迫程度决定。

能拿来做什么

• 使用 Visual Studio 的团队可以通过 Visual Studio Installer 更新，再按需启用 Hot Exit、首次失败停止构建和新聊天。原文列出的产品为 Visual Studio 2026，所述最新构建为 18.11.2。
• 做大规模重构时，用 Compare with Working Tree 对照关键提交；只有目录内冲突取舍已经明确时，才在该目录使用批量接受操作。
• 维护大型 .NET 解决方案时，可以记录首次失败后的等待时间，再评估提前停止构建的收益。涉及 Blazor WebAssembly 的项目，还应验证 F5 调试是否受已知问题影响。
• 使用 Copilot、BYOK 或 MCP 时，升级前核对新 Agent (Preview) 的适用范围、token 用量和信任提示。Copilot 功能需要 GitHub Copilot 套餐，组织级 custom agents、custom instructions 还需要 GitHub organization。