在 VS Code 中追求极致智能
2023 年 11 月 13 日，作者：Chris Dias, @chrisdias
如果您上周关注了 GitHub Universe，您会看到人工智能在整个开发者工作流程中取得了巨大的进步、创新和愿景。在这篇博文中，我们想重点介绍过去几个月 Visual Studio Code 在实现这一更宏伟愿景方面取得的进展。
“聪明绝顶”
在马特·达蒙和本·阿弗莱克开创性的电影《心灵捕手》中，我最喜欢的一句台词是“my boy's wicked smaaahtt”（用波士顿口音读，效果更佳）。
这句台词由 Morgan（凯西·阿弗莱克，本的兄弟）说出，当时 Will（马特·达蒙）通过逐页、逐字地回忆美国历史事实，化解了 Chuckie（本·阿弗莱克）与一位过于自信的“一年级研究生”之间的冲突。可以说，Will 是通过他读过的所有书籍训练出来的，并能根据对话内容回忆起它们。
AI 与 Will 类似——它了解大量文本。但 AI 缺少的是——人类拥有而 AI 没有的——特定交互的上下文，以便给出最佳答案。在 Will 的案例中，因为他还能“察言观色”，所以他能利用书本知识给出一个精心设计的有力回击。
大语言模型 (LLM) 是在某个时间点上使用公共代码仓库数据训练的。这意味着它们对您当前的代码一无所知。它们了解一般的代码，但没有必要的上下文来准确回答关于您代码的问题，或者建议符合您工作区形式和功能的新代码。
为了解决这个问题，GitHub Copilot Chat 会发送代码片段来帮助模型更好地回答问题（这被称为“检索增强生成”，即 "RAG"）。通过看到最相关的代码，答案会变得更好。但是，可以发送给 LLM 的代码量（以及通过提示进行的指导）是有限的。对于一个小项目来说，这通常不是问题。但考虑到任何大型源代码仓库，您会很快意识到不可能将每个文件的内容都发送给模型。获得更好答案的解决方案是在合理的时间内，使用适量的资源，发送相关的上下文。为了帮助解决这个问题并解锁许多其他场景，我们在 Copilot Chat 中加入了**参与者 (participants)** 的概念。
参与者
聊天参与者是领域专家，他们可以以任何他们想要的方式回答用户的查询——通过在查询处理中充分利用 AI，或者通过传统方式将其转发到后端服务。参与者还可以为大语言模型提供访问领域特定工具的权限。在 LLM 的帮助下，参与者可以选择一个工具并定义如何调用它。@workspace 就是这样一个聊天参与者的例子。@workspace 参与者了解您的工作区，并能回答关于它的问题。在内部，该参与者由不同的工具提供支持：GitHub 的知识图谱结合语义搜索、本地代码索引和 VS Code 的语言服务。
聊天参与者可以由客户端或服务端提供。在 GitHub Universe 上，演示了一个服务端参与者，即 github.com 聊天体验中的“文档代理 (Docs Agent)”，它知道如何搜索代码仓库中的文档（即将登陆 VS Code）。
客户端参与者可以通过传统的 VS Code 扩展来提供。关于这一点，我们将在可扩展性部分详细介绍，但让我们先看看今天在 VS Code 中可用的两个聊天参与者：@workspace 和 @vscode。
@workspace
@workspace 参与者知道如何收集关于您工作区中代码的上下文，可以帮助您导航、查找相关的类、文件等。想象一下，您在 VS Code 代码仓库中，想了解更多关于负责当前 ICodeEditor 的服务；您可以使用该参与者，像这样：
使用自然语言向 @workspace 参与者提问：“我用哪个服务类来获取当前的 ICodeEditor”。然后，参与者会执行以下操作，以获取恰到好处的上下文发送给 LLM：
-
vscode 仓库已被 GitHub Search Blackbird 服务索引。
@workspace参与者使用此索引作为工具来利用仓库的知识图谱。@workspace参与者运行语义搜索，返回相关的代码片段和元数据。GitHub 搜索服务已经索引了排名前 1 万的 GitHub 仓库，并计划增加更多。 -
@workspace参与者使用的下一个工具是在本地索引上进行词法文本搜索，以查找额外的代码，例如本地未提交的更改和 Copilot 的对话历史记录。 -
然后，
@workspace使用最后一个工具——VS Code 的语言智能，来添加关键细节，如函数签名、参数，甚至内联文档。
所有这些上下文信息都由 @workspace 参与者进行排序、切片和总结，然后发送给 LLM 来回答问题。
因为它拥有所有必要的上下文，@workspace 参与者可以回答开发者更可能提出的那种问题。例如，关于代码不同部分如何交互的问题：
- “
@workspace通知是如何调度的？”
或者需要了解相关代码、依赖项和设计模式的问题：
- “
@workspace添加表单验证，类似于时事通讯页面”
@vscode
VS Code 的定制方式多种多样，以至于即使是 VS Code 团队的成员在发现一些隐藏功能时也会感到惊喜。为了帮助我们的用户和团队成员充分发挥 VS Code 的潜力，我们创建了 @vscode 参与者。
该参与者对 VS Code 了如指掌，可以帮助您弥合自然语言与 VS Code 命令和定制之间的差距。@vscode 参与者内部使用的工具使其能够访问所有设置和命令的索引，我们正在添加一个工具，以便该参与者也可以使用 VS Code 的文档。现在您可以问一些模糊的问题，比如“@vscode vscode 假打开文件时那个东西叫什么？怎么禁用它？”。
请注意，响应中有一个**在设置编辑器中显示 (Show in Settings Editor)** 按钮。这是因为 @vscode 参与者不仅知道 VS Code 的工作原理，还有一个工具可以调用设置编辑器或命令面板。
此外，命令面板现在支持相似性搜索，所以您在搜索命令时不再需要知道确切的名称。您不再需要说 VS Code 独特的行话，就能解锁团队每个月发布的所有好功能。
这仅仅是 @vscode 参与者的开始。我们计划支持越来越多的场景，让用户更好地理解和完全控制 VS Code。
斜杠命令
聊天参与者还可以贡献我们称之为**斜杠命令**的功能，它们是参与者提供的特定功能的快捷方式。回答问题时的任务之一是确定意图，理解您想做什么。
我们可以推断出“创建一个新的 Node.js Express Pug TypeScript 工作区”意味着您想要一个新项目，但“@workspace /new Node.js Express Pug TypeScript”则明确、简洁，并节省您的打字时间。
一旦意图明确，尽管自然语言存在固有的模糊性，@workspace 参与者有更好的机会满足用户的需求。@workspace 可以提议一个目录结构，用户可以点击提议的文件进行预览。还有一个**创建工作区 (Create Workspace)** 按钮，可以在新文件夹中生成这些文件。
可扩展性
“VS Code 只是一个空壳，你需要扩展才能让它大放异彩！”——这是从事 VS Code 扩展开发的微软团队在会议上常说的一句话，自豪地炫耀他们在 VS Code 成功中的作用。我们作为 VS Code 核心团队，完全同意他们的看法——没有丰富的扩展生态系统，VS Code 不会是今天这个样子！AI 也不例外，虽然核心 AI 体验由 Copilot 点亮，但我们的愿景是，我们生态系统中的所有扩展都可以参与进来，让 LLM 模型拥有最佳的上下文和基础。今天，我们通过在提案状态下添加 聊天参与者 API，为这一愿景奠定了基础。
聊天参与者 API 允许扩展贡献可以回答用户特定问题的参与者。@workspace 和 @vscode 参与者都是使用这个 API 实现的。通过聊天参与者，用户可以在编辑器流程中将来自其内部和外部循环工具的丰富且最新的信息带入 AI 对话。参与者就像某个领域的专家，当用户在提示中明确提及一个 @participant 时，该提示会被转发给贡献该特定参与者的扩展。
参与者可以使用 Markdown 来响应简单的文本和图片，也可以用文件树或按钮来提供更具交互性的体验。例如，当参与者提议为用户创建一个新工作区时，可以使用文件树作为预览。参与者可以为每个响应提供后续操作，可以把它们想象成推动对话进一步发展的建议。为了提供流畅的用户体验，整个 API 都是基于流的。如前所述，参与者可以引入斜杠命令——特定功能的快捷方式。例如，@docker 参与者可能会贡献一个 /generate 斜杠命令，从而产生以下示例用户提示：“@docker /generate a DOCKERFILE for workspace”。当前明确而简洁的语法可以方便地节省时间。尽管如此，我们仍在研究意图检测，以允许 VS Code 核心根据用户的自然语言提示自动选择正确的参与者和斜杠命令。
想象一下，在 VS Code 中直接安装一个了解 Azure 或 Docker 的聊天参与者。或者您可能只需要一个 DALL-E 参与者，它使用图像生成作为工具，展示一个可爱的动物来肯定您做得很好。
参与者可以带来任何领域特定的内容，同时访问该领域的工具。例如，1ES 代表 One Engineering System，是微软内部的工程系统。1ES VS Code 扩展贡献了一个 @1es 参与者，可以为微软内部工程师回答特定问题。@1es 参与者会动态地规划并展示它正在做什么。它使用了一些 LLM 模型中可用的公开数据，但也识别了微软内部的特性，并将两者结合起来提供最佳答案。
因为参与者拥有当前上下文，所以它可以继续讨论。
我们还增加了一个 API，允许扩展访问 LLM，并可以选择使用 LLM 来处理和回答用户的查询。目前，这个 API 仅限于那些实现参与者的扩展。聊天参与者 API 会将确切的用户提示传递给贡献的参与者，通过 LLM 访问，参与者可以方便地将这些语言提示转换为特定的后端 API 调用。我们将谨慎且透明地处理此 API 的使用，以便用户了解参与者使用了多少请求和令牌。
聊天参与者 API 仍处于提案阶段，我们正在征求关于如何改进它的反馈，目标是在不久的将来最终确定该 API。您今天就可以尝试一些东西，最好的起点是我们的聊天参与者可扩展性示例。我们迫不及待地想看到您为开发者创造的由 AI 驱动的创新。
便利性
我们对参与者及其带来的无限可能性感到非常兴奋，但我们也想谈谈我们在 VS Code 中直接在您的常规工作流程中添加的那些由 Copilot 驱动的便利小交互。您不应该为了利用 AI 而重新学习您的编辑器。
智能操作
智能操作无缝集成在您的 VS Code 流程中（例如，在快速修复和上下文菜单中），它们完全不需要您编写任何提示。最强大的智能操作是 /fix。这里有一个相对简单的 TypeScript 快速排序算法，带有一个错误提示“类型 'number' 的参数不能赋给类型 'never' 的参数”。点击灯泡图标并选择**使用 Copilot 修复 (Fix using Copilot)**。
这个选项会打开内联聊天，并填充 /fix 和错误信息。在幕后，我们引入了额外的 VS Code 诊断上下文，然后让 Copilot 提供一个修复方案——更新 left 和 right 数组以使用正确的类型声明。
我们注意到 /fix 对于像 shell 脚本这样的语言特别有用，因为这些语言的传统工具支持有时会有所欠缺。
为了使其建议更清晰，Copilot 会尝试解释为什么它提出了特定的修复方案。我们很高兴地了解到，用户接受 Copilot 建议的修复方案的比例约为 60%。有时，修复可能与灯泡附近的源代码无关，而是需要安装一个缺失的依赖项——在这种情况下，/fix 会提议一个可以在集成终端中运行的命令。
与 /fix 类似，/doc 智能操作也很受用户欢迎。要使用 /doc，选择一段代码，右键单击，然后选择 **Copilot** > **生成文档 (Generate Docs)**。Copilot 会为您的代码生成文档注释，我们相信您会对文档质量感到惊讶。
生成提交和拉取请求消息
有时意图非常明确。当这种情况发生时，AI 的体验会感觉近乎神奇。我现在最喜欢的功能是让 Copilot 自动生成提交消息。在安装了 Copilot 的源代码管理视图中，您会在提交消息字段旁边看到一个新的闪光图标。选择这个闪光图标，Copilot 就会为您填写好消息！
我对这个体验非常兴奋，前几天在用 vscode.dev/github 编辑 Markdown 时，我甚至做了这样一个提交，因为 Copilot 扩展还没有适配 Web。
回到我们的流程，让我们继续创建一个拉取请求。我安装了 GitHub Pull Requests and Issues 扩展，它能感知到 Copilot Chat 扩展的存在。当我创建一个 PR 时，标题和描述旁边会出现另一个闪光图标。选择它，Copilot 就会自动写好一段不错的描述！
这是 AI 可以帮助您提高生产力的另一个领域，它能自动处理您每周要做几十次甚至上百次的简单而繁琐的任务。
说什么？！
最后，打造一个真正智能的 AI 意味着让交互尽可能地轻松。
在过去的几年里，我们整个行业在语音识别技术方面取得了长足的进步。我们知道很多人一直渴望将语音助手与先进的 LLM 结合起来。现在，您可以在 VS Code 中同时使用这两者了。
新的 VS Code Speech 扩展为 VS Code 带来了语音转文本的支持。安装后，您会在所有自然语言输入对话框中看到一个麦克风图标。选择它，向 Copilot 提出您的问题，然后享受魔法吧。
觉得怎么样？！我告诉过你，我的伙计聪明绝顶！
该扩展仍处于预览阶段，目前只支持英语，但我们会在未来几个月内继续更新，增加新的语言和功能。
工作更聪明，而不是更辛苦
以上所有以及更多功能今天都可以在 VS Code 中使用！您只需安装 GitHub Copilot 扩展即可。您可以在我们的文档中了解更多关于 Copilot Chat 的功能。
谢谢！
Chris 和 VS Code 团队
祝您**智能**编程愉快！