企业官网建设流程全解析

• 文档
• 教程

导读

VS Code 内置 400+ 项设置，加上扩展贡献的自定义设置后数量急剧膨胀，用户仅靠关键词匹配常常找不到想要的那一项。本文以 2018 年 VS Code 官方博客《Bing-powered settings search in VS Code》为骨架，结合当前仓库中的官方设置文档与扩展清单规范，完整剖析这套由 Bing 团队打造的智能设置搜索系统的离线索引、在线检索两大架构，以及它在 VS Code 设置编辑器中的实际落地效果。读完本文，你将理解"为什么搜update能匹配到upgrade相关设置"这类智能行为背后的完整工程链路，也能掌握设置编辑器搜索与过滤器（@modified、@tag等）的实战用法。

为什么设置搜索是一个真问题

从 GitHub Issues、StackOverflow 问题、推文和 VS Code 团队开展的用户研究中，可以看到大量用户反馈"找不到某个设置"。这并非偶然：

• VS Code 开箱即用就包含400+ 项设置；
• 安装扩展后，设置数量会显著增长——每个扩展都可以通过其package.json的contributes.configuration贡献自己的设置项；
• 用户自身的拼写错误、以及"不知道该用什么搜索词"的选词困难，进一步放大了匹配难度。

正因如此，VS Code 团队与 Bing 团队合作，在两个月内交付了一套由 Bing 驱动的智能设置搜索体验。它不再只是对设置名称做字面匹配，而是能理解用户意图、容忍拼写错误、识别同义表达。

官方文档对设置编辑器的定位也印证了这一点：在用户与工作区设置文档中，搜索框是发现设置的主要入口——打开设置编辑器（File > Preferences > Settings，或通过命令面板执行Preferences: Open Settings）后，在搜索栏输入内容即可实时过滤设置列表，并且修改即时生效，被修改的设置左侧会显示彩色标记条，与编辑器中已修改行的指示方式一致。

系统架构总览

整条链路分为离线侧（采集与索引构建）和在线侧（查询响应）两大部分：

• Bing Ingestion Service（离线）：负责把 VS Code 自身与扩展的设置数据加工成富索引，并尽量把工作前置到摄取阶段，以缩短查询响应时间；
• Gating Module（离线）：对每次索引入库做质量校验，防止索引损坏；
• Search Service + Azure Load Balancer（在线）：处理用户查询、检索索引并返回结果。

Bing Ingestion Service：离线索引构建

收集 VS Code 与扩展的设置数据

VS Code 自身的设置：每次构建时，VS Code 会以特殊模式启动，把全部配置元数据写入一个 JSON 文件。之所以"必须真正启动 VS Code"，是因为无法静态确定全部配置元数据。该文件对每个设置记录以下信息：

构建完成后，该 JSON 文件被上传到Azure Storage。文件路径中的123000832是唯一构建号（由产品版本号加上自上一发布以来的 Git 提交数计算得出），c1cd4378...则是该构建对应的 Git commit id。整个过程完全自动化：Bing 的Polling Service持续监听 Azure Storage 容器，发现新构建后通知 Ingestion Service 开始摄取。

扩展的设置：Bing 同时持续爬取 VS Code 扩展市场，一旦发现新扩展或更新，就下载其package.json文件并把其中声明的设置传给 Ingestion Service。与 VS Code 本体不同，扩展的全部配置元数据都包含在package.json中，无需启动扩展即可读取——这正是扩展清单中contributes.configuration字段的用途（详见扩展清单规范）。

由于链路全自动，稳定版发布构建和每日 Insiders 构建都会在几分钟内同步进 Bing 索引，新加入的设置几乎实时可被检索到。关于 Insiders 与 Stable 构建的关系，可参考入门文档中"Should I use Stable or Insiders?"一节：Stable 每周发布并自动更新，Insiders 则是可与之并行的每日预览构建。

1. Alternative Words Pipeline（同义词流水线）

用户常常使用与设置名/描述不同但等价的词语。该流水线借助 Bing 搜索数据（用户行为、点击、在线排序、页面相似度等信号）收集"意义相近的词对"，例如update与upgrade互为 alternative words——搜索其中一个，会返回包含另一个词的设置。

2. Stemmer and Speller Pipeline（词干提取与拼写纠正流水线）

早期实验表明：简单的模糊匹配要么漏掉人类能理解的英文词形变化，要么产生过多误报。因此系统从运行在 Bing.com 的完整服务中抽取出 Speller（拼写检查器）与 Stemmer（词干提取器），为索引补充常见拼写错误和同一词干的不同词形。例如设置中若包含formatting，则formatted、formatter、format都会被纳入索引。

3. Natural Language Processing Pipeline（自然语言处理流水线）

让用户能用自然语言描述需求。该流水线收集常见的口语与文本模式并加入索引，例如能识别出how to disable css validation中的重要词，从而定位到css.validate这一设置。

4. Feedback/Ranking Pipeline（反馈与排序流水线）

提供人工反馈机制：可手动指定新的词对，或对特定查询提升期望结果。反馈上传到服务后，几乎立即反映到搜索结果中，实现了"人机闭环"的持续改进。

Gating Module：入库质量闸门

每次索引入库都要经过 gating module，其职责是确保索引没有因编程错误而损坏。配套的测试用例验证：

• 新索引向后兼容，能服务所有 VS Code 构建版本；
• Golden query set（金标准查询集）返回预期结果。

一旦 gating 失败，将阻止该次索引入库并立即通知团队。配套的 Dashboard 服务监控整条管道各阶段的健康状态，具备告警机制，并可回滚到最后一个已知良好状态，把故障影响时间降到最低。

Search Service：在线查询服务

运行时，用户的查询先打到Azure Load Balancer，负载均衡器根据物理就近性或当前负载，从多个异地复制的服务器中选一台处理查询；该位置的Search Service在索引中完成检索，必要时应用人工排序覆盖（ranking overrides），最后把结果返回 VS Code 客户端。这套"多副本 + 负载均衡"的设计保证了查询的响应速度与可用性。

与设置编辑器的联动：搜索与过滤器实战

智能搜索上线后，设置编辑器本身的搜索体验也围绕"快速定位设置"持续演进。根据用户与工作区设置文档：

• 搜索栏实时过滤设置，输入即见结果；
• 搜索栏右侧的漏斗形按钮可快速添加过滤器，搜索框也支持撤销/重做（kb(undo)/kb(redo)），右侧的Clear Settings Search Input按钮可一键清空搜索词或过滤器。

可用的常用过滤器（输入@符号可发现全部过滤器）：

扩展安装后会把自己的设置显示在设置编辑器的Extensions区块下；按扩展名（如gitlens、python）搜索可以快速收敛到该扩展贡献的设置（见官方设置文档）。扩展设置的底层来源，即package.json中contributes.configuration声明的配置（详见扩展清单规范）。

效果验证：Putting it all together

最终这套系统能"理解"设置查询，为大量此前返回空结果的自然语言查询给出答案，例如：

• 输入类似 "format on keypress" 的表达，能匹配到对应的格式化设置；
• 输入 "open files on left" 这类描述性语句，能定位到新文件打开位置相关的设置；
• 输入 "beautify" 这类口语化/产品化名称，也能找到对应设置或扩展。

如需自己动手验证效果，直接在设置编辑器搜索栏输入上述自然语言短语即可观察结果。仓库中的视频文件FormatOnKeypress.mp4、OpenFilesOnLeft.mp4、Beautify.mp4（均位于blogs/2018/04/25/）记录了这些示例查询在设置编辑器中的实际表现。

如果你没有专门的搜索团队来定制这样的服务，也可以借助通用认知服务为自有应用添加智能能力，例如 Bing Spell Check（拼写检查）、Language Understanding (LUIS)（语言理解）、Bing Web Search 与 Bing Custom Search（Web/自定义搜索）。这些能力与本系统采用的词干/拼写/NLP 思路同源，可作为自建方案的起步点。

测试体系：基于 NDCG 的量化评估

开发过程中需要一个量化评估结果的框架，团队选择了Normalized Discounted Cumulative Gain（NDCG）——给定查询、一组结果及对应打分，衡量搜索引擎结果排序质量的标准方法。关键做法：

• 手工编写了一批测试用例；
• 由于设置会持续新增、扩展设置不断变化，又编写了自动生成测试用例的工具：取设置名称与描述中的词，通过多种变换器模拟用户"换用同义词""打字出错""用自然语言表述"等行为，并为若干热门扩展的设置也生成了用例；
• 每 6 小时运行一次完整测试套件，且测试套件可自动更新，始终针对最新构建的设置；运行期间能自行完成"测试设置来自最新构建"的自刷新。

这套机制既保证系统正常运行，也让后端改动时有信心"不会损害结果质量"。

已知边界与演进方向

系统当前仍有一些明确边界，官方博客如实列出：

• 仅索引英文：翻译后的设置描述尚未入索引，非英文搜索暂不支持；
• 部分元数据未索引：例如workbench.colorCustomizations的合法取值尚未纳入索引；
• 不返回未安装扩展：未来希望做到搜索debug python时，在本地设置匹配不足时引导用户安装相关扩展；
• 命令面板联动：考虑将同类技术推广到命令面板搜索等场景；
• 行为反馈闭环：若大量用户搜索相似查询后选择同一结果，可据此自动提升该结果排名（基于用户行为的自动反馈回路）。

用户反馈渠道

设置搜索结果的持续改进依赖真实用户反馈。官方建议：搜索设置时如果没看到预期结果，请提交 Issue；使用VS Code Insiders构建时，设置编辑器内会出现一个按钮，可一键唤起 Issue Reporter，自动附带排障所需的全部上下文细节。

参考资源

• Bing 驱动设置搜索官方博客原文
• 用户与工作区设置官方文档（设置编辑器、搜索与过滤器）
• 扩展清单规范：contributes.configuration与设置贡献
• VS Code 入门：Stable 与 Insiders 构建说明
• 组织策略与受控设置

• 文档
• 教程