VS Code 这次没重做 UI：它把 Agents 窗口那套设计系统搬回了编辑器
原文：Modernizing the VS Code UI 作者：Lee Murray（VS Code 团队；具体职位未在博客中注明） 来源：Visual Studio Code Blog，发布于 2026 年 10 月 15 日
我读 Lee Murray 在 2026 年 10 月 15 日发布的《Modernizing the VS Code UI》，先找的是改版目的。官方给出的方向很明确：理清十余年累积的界面层级、减少干扰，用同一套设计基础承接手动编辑和 AI 智能体（agent）会话，同时保留信息密度、定制能力和熟悉的操作习惯。【关键词：#VSCode #现代UI #Agents】
顺着这个目的，我更关心的是：这套设计为什么先在 Agents 窗口落地，搬回编辑器后，又为老用户改了什么。下文依据博客发布时的预览状态解读，设置建议未经本地实测。
01｜我先分清：这次改的是哪一层
我先看了博客里的时间线：2015 年首发预览，2016 年加入编辑器标签页，2019 年更新树状控件，2023 年推出 Dark Modern / Light Modern 主题。今天看着理所当然的界面，其实是一块块加上来的。
原文把这种演进叫作逐个组件推进。工作台（workbench，也就是包围代码区的导航、面板、标签等界面）里的各个部分，未必遵循同一套间距、字号和控件规则。我把它理解成一间不断添家具的书房：每件家具单看都能用，放在一起，尺寸和动线却未必协调。
我理解这次改版的边界是：保留文件编辑方式，改造工作台外壳。 密集的文件导航、多编辑器分组和已有操作习惯，都要继续照顾。沿着原文，我把推进过程串成三步：
- 颜色先动：以 Dark 2026 / Light 2026 两个新主题为起点，一起考虑工作台配色和代码语法高亮。
- 共享设计系统在 Agents 窗口里跑通：这个窗口在 2026 年早些时候进入 Stable（稳定版），当时仍是 Preview（预览功能）。它围绕发起智能体会话、跟踪进度、检查结果组织界面，为统一间距、字号、界面底色和控件规则提供了落地场景。
- 把同一套规则铺到编辑器外壳：活动栏（Activity Bar）、侧边栏、编辑器组、面板、标签、状态栏，成为应用共享规则的区域。
读到这里，我才把 Agents 窗口和这次改版连起来：直接编辑文件时，重点是快速找文件、切分组；委托智能体做事时，重点是看会话状态、下一步动作和修改结果。两种工作流需要不同布局，但字体、间距、颜色和控件可以共用一套规则。Agents 窗口是实验室，编辑器外壳是推广地，并不意味着要把编辑器也摆成一个聊天窗口。
我还留意到：按博客发布时的说明，现代 UI 经历了 Insiders（预览体验版）默认启用、Stable 分组实验，随后默认开启，但仍被称为预览。旧界面（classic UI）在过渡期保留，可以取消勾选 workbench.experimental.modernUI 切回。“默认开启”，还不等于设计定稿。
02｜共享设计系统，和换个主题差在哪儿
读到“共享设计系统”，我会接着问：和换一套主题有什么区别？原文给出的关键是设计令牌（design tokens）：把间距、尺寸、颜色变成有名字的公共值，组件引用它们，不必各写一份。
比如调整紧凑程度时，有了共同的间距规则，就能协调修改多个区域。颜色仍然重要，但仅换颜色，解决不了标签太占地方、面板拖动位置不好找的问题。我把文中的具体变化放在一起看：
| 关注的地方 | 博客描述的做法 | 我理解它要解决的问题 |
|---|---|---|
| 颜色 | Dark 2026 / Light 2026 一起考虑工作台与代码配色，统一悬停、焦点、选中等状态的表达 | 让重要内容更容易辨认 |
| 间距 | 用命名令牌统一规则，支持不同密度 | 让多个区域能协调收紧或放宽 |
| 字号 | 简化字号层级，移除全大写标签，同时保留可选设置 | 减少争抢注意力的文字样式 |
| 控件 | 调整面板分隔与缩放控件 | 让边界和可拖动的位置更容易发现 |
| 标签 | Connected Tabs（连接式标签）把活动标签与编辑器表面连成一片 | 更容易对应当前文件与下方内容 |
我看这次“统一”，重点就在规则能不能复用。原文也明确保留了主题、密度和工作区安排的选择，并不要求所有人的 VS Code 长得一样。
03｜留白好看，但代码区不能跟着缩水
我读到反馈部分，最关注的是屏幕空间这笔账。原文列出的意见很具体：间距挤占代码、文件树和终端的位置；标签与编辑器割裂；状态栏装不下原有信息；面板边界、主题控制和渲染性能也需要继续调整。这些问题在官方的公开反馈汇总中也能对照到。
在 1920×1080、100% 缩放下，原文给出的空间变化是：现代 UI 横向多占约 20 px，纵向多占 12–18 px，具体取决于布局。官方增加间隔，是为了分清区域、让控件容易找；代价就是留给内容的位置变少。
我认可把区域分清楚这个目的，但会把“还能看见多少代码”一起算进去。 博客随后给出的回应，正好落在密度和标签这两处。
Layout Density（布局密度）新增的紧凑档，就是在保留现代 UI 结构和定制能力的前提下收紧间距。可以在标题栏的 Customize Layout 中选择 Layout Density → Compact，也可以把 window.density.layout 设为 compact。我会把紧凑档理解为一次密度补偿：官方明确回应了“少看见代码”的问题，但没有给出它能回收多少像素的数据。
标签的变化则更直观。早期胶囊式标签像独立按钮，浮在编辑器上方；当主题的活动状态颜色不明显时，当前标签和下面的内容不容易连起来。Connected Tabs 把两者接成连续区域。我更看重它恢复了“这个标签对应这块内容”的熟悉线索。新样式如果让当前文件更难辨认，就有理由改回来。
此外，原文还列了几个可选设置。我会按遇到的问题来找它们：
workbench.experimental.modernUIUppercaseViewHeaders：视图标题、侧边栏标题、面板标签是否用全大写（实验性，未来可能改）。workbench.activityBar.compact：让活动栏更窄（受支持的设置）。workbench.editor.tabActionReserveSpace：标签是否始终预留操作按钮的位置；关闭后，没有待保存改动的非活动标签可以多留一些空间给标签文字（受支持的设置）。
这里我会多看一眼设置名。带 experimental 的设置可能调整或移除；另外两项是受支持的自定义选项。它们都不要求用户为了迁移而逐一配置。 先找到具体不舒服的地方，再改对应设置，比整套照抄更合适。
04｜看到 8.2%，我先找它的比较对象
性能这一段，我先找测试场景和比较对象。官方把调整窗口与面板大小、切换视图、滚动、打开差异对比、运行控件动画串成可重复的基准，比较现代 UI 的一批样式选择器修复前后的变化。
问题可以先用人话讲：界面状态变化后，浏览器要重新判断哪些样式该应用到哪些元素。CSS 选择器就是描述这些匹配条件的规则；如果它需要检查很大一片页面元素，重算就可能多做工作。
原文的做法，是把部分需要检查大范围页面结构的选择器，换成组件自己维护的状态类。比如差异概览是否存在、调试操作是否出现，组件本来就知道，可以直接用类名标记，减少样式匹配时再次推断的开销。
我把结果并排放，避免只挑下降的数字看。下面沿用博客披露的口径，比较对象都是现代 UI 修复前后：
| 指标 | 修复后的相对变化 | 我怎样读 |
|---|---|---|
| 样式重算时间 | -8.2% | 样式匹配的耗时下降 |
| 整组基准的实际经过时间 | -3.3% | 这组交互整体耗时下降 |
| 布局时间 | +6.6% | 这一项反而增加，不能省略 |
这些百分比对应不同耗时项目，不能直接相加抵消。博客明确限定：修复追回了相对旧界面的部分差距，没有全部追回。我对照的性能修复记录也把旧界面、现代 UI 修复前、修复后三组结果分开列出；上表沿用博客的百分比口径。
真正让我想划线的，是后续怎么防止退回去：他们加了静态检查规则，拒绝已知开销大的选择器，还提供 npm run perf:css 重复测量。我能从这里借鉴的是：修掉一次性能问题之后，把已知坏模式交给规则拦截，把效果交给基准继续验证。 这比把 8.2% 写成“VS Code 全面提速”有用得多。
05｜读完之后，我会先改哪里
回到日常使用，我会先检查自己有没有遇到代码区变挤、标签难辨认的问题。界面如果已经顺手，就没有必要为了追上改版，把设置重新折腾一遍。
主题这件事也可以先放轻松。原文说明，现有主题兼容现代 UI 和旧界面；新增的颜色标识符（color IDs）如果没有定义，会回退使用已有工作台颜色。我据此理解：继续用原来的主题，不需要先迁移到新颜色配置。
如果要精细控制界面底色、边框、标签、活动栏和窗口状态，再考虑新颜色 ID。它们仍是实验性的；主题作者需要检查新旧两套界面，以及浅色、深色、高对比度主题。我会把这笔验证成本算进修改计划，只看一套深色界面还不够。
假设用一台 14 寸笔记本，代码区比较紧张，我会按下面的顺序尝试，具体效果要在自己的版本和屏幕上确认：
- 先把
window.density.layout设为compact，比较同一窗口大小、缩放和分组下，代码与终端的可见空间是否更合适。 - 如果活动栏仍然占地方，再尝试
workbench.activityBar.compact，避免一次改太多项，分不清是哪项起了作用。 - 标签先看默认的连接式设计能否清楚标出当前文件。只有偏好胶囊样式时，才查看
workbench.experimental.modernUIEditorTabStyle；博客没有提供具体取值，我不补写。
全大写标题和新颜色 ID，我会等有明确需求再动。至于旧界面还能保留多久，博客只确认了计划退役、尚未确定移除日期，并承诺提前通知。我不会据此猜一个截止时间。 如果紧凑档和颜色调整仍然影响工作，过渡期内切回旧界面也是官方保留的选择。
写在最后
读完这篇，我更能理解 VS Code 为什么选择从工作台外壳改起：它要让手动编辑和委托智能体工作共用一套基础，又得照顾已经形成的操作习惯。“先在新窗口跑通，再回填”的路径，给成熟产品改界面提供了一个不掀桌子的做法。但共享规则能否适合不同屏幕和布局，还得继续接受用户反馈与性能测量。
我会用一个很实际的标准看后续改进：找文件、辨认当前标签、看终端输出这些事，能不能照常顺手。遇到问题时，记录屏幕分辨率、缩放、主题和布局，比只说“新 UI 不好看”更能帮助团队定位原因。
如果你已经试过紧凑档，在相同缩放和编辑器分组下，代码区变挤的问题解决了吗？
作者：猫咪不吃愚（科技从业者 / 程序员 / 运动爱好者） 写于 2026 年 10 月
AI 协作声明：本文含 AI 辅助检索、解读与文字改写，依据 VS Code 官方博客 Modernizing the VS Code UI（2026-10-15）及文中链接的官方记录整理。文中性能数字来自官方披露，配置建议未经本地实测；以第一人称表达对原文的理解与取舍。
封面由 AI 辅助生成；按平台规则发布时保留 AI 生成内容标识。