Continue.dev：有时会失灵的瑞士军刀

第一印象

2024 年 5 月，我第一次安装Continue.dev时，并没有抱太大的期望。当时 VSCode 扩展市场充斥着许多质量低劣的代码助手；我尝试过的大多数都是一些开发者的个人项目，漏洞百出，毫无吸引力。

这个看起来很有希望！上手很简单，有很多模型和供应商可以选择，虽然在添加 Azure OpenAI 模型时需要修改 JSON 文件，这让我一开始就觉得它可能并不完美。但 Continue 提供了我期望从 AI 编码助手获得的所有主要功能，例如 GitHub Copilot：

• 编辑器中的 Tab 键自动补全功能
• 内联指令
• 聊天

我立刻把聊天区域移到了屏幕右侧，它真的相当不错！让我惊喜的是，它不仅支持代码库上下文，还提供了一些其他增强聊天功能的选项（例如网页爬取 URL、特定文件等），而且这些功能真的有效！

而且所有这些都是完全免费且开源的！

故事展开

然而，随着时间的推移，尖锐的方面开始显现出来，而且有很多。稍后会详细说明。

在使用并观察 Continue 的发展之后，我认为它就像一个充满对比和矛盾的混合体：

• 有些功能很棒，有些则差强人意——质量上的不一致性让我感到困惑。整体外观精美流畅；但“继续”功能却显得不够完善。
• 问题既出在稳定性方面（时不时会出现一些bug），也出在用户体验方面（例如，内联聊天很不方便）。
• 核心功能——编码——表现平平。即使使用最先进的模型，你也不会对建议的修改感到满意。

遗憾的是，自五月以来并没有取得重大进展。

精髓

虽然稳定性和用户界面/用户体验方面的问题用户或许可以适应（而且 Continue.dev 背后的小团队最终也能解决这些问题）……

编码部分并不简单。Continue 的构建方式既是它的优势，也是它的劣势。

下方是 VSCode 的屏幕截图，您可以看到我是如何请求内联更改的。底部是“输出”窗格，日志源已选择为“继续”。您可以在这里看到发送到 LLM 的确切提示。尝试在 GitHub Copilot 或 Cursor 中检查提示和 LLM 输出！

然而，你可以看出这种方法多么直接和“粗糙”。Continue 函数只是把符合上下文的那段代码扔给 LLM，然后礼貌地要求它根据用户的指示插入一段代码。结果可想而知，它并不奏效。

正如Aider的博客文章（例如这篇）所示，编写有效的LLM更新代码是一项具有挑战性的任务。LLM经常会出错，修改错误的部分，如果输入过多的文本，还会偏离正轨等等。

我曾多次请求进行内联编辑，但收到的代码却是不可插拔的——这在 Cursor 中我从未见过！

不仅如此，如今我们看到人工智能编码助手取得了进展，它们提供了巧妙利用语言学习模型的方法。

Aider引入了一系列技巧，使其成为比许多其他程序员更优秀的程序员：

• Tree-sitter 集成和 LLM 友好型源地图作为每个 LLM 调用的全局上下文。
• 我们对LLM的“通信协议”进行了大量实验——对如何正确地请求LLM进行代码修补进行了广泛的测试。最终，我们开发了搜索/替换协议，这是一种高亮显示代码并提供编辑选项的方法。
• 多文件编辑。
• 运行代码检查、单元测试，并将结果导入 Aider 进行自动纠错等等……

Cursor在人体工程学和概念方面都非常出色：

• 他们在后端进行了一些神奇的操作，以确保生成的代码具有最佳的可插拔性。
• 他们对自动补全和多行编辑进行了概念性的思考，不断完善自己的模型，并推出了像 Copilot++ 这样的功能。我很欣赏他们在博客中将自动补全的本质概括为“节省低熵击键的时间”。
• 他们正在尝试使用影子工作区，试图创建一个具有短反馈循环的 AI 编码代理，并赋予 LLM 真实开发者的视角，向 LLM 展示开发者所看到的内容，让 LLM 构建和运行，并获得开发者所看到的警告和错误！
• 最终推出了名为“Composer”的测试版功能，旨在实现多文件编辑。

Cursor 和 Aider 虽然外形像手术器械，但它们在精密度和效能方面都取得了长足的进步。相比之下，Continue 看起来就像一把不错的锤子。

排行

以下是我基于人体工程学和性能（编码能力）对各种编码助手进行的主观评价，忽略了开源/闭源方面：

• 继续 3/5
• Sourcegraph Cody 3.5/5*
• GitHub Copilot 3.5/5*
• 继续 + 助手 4/5
• 光标 4.5/5

*注：由于我一直在探索市场上其他的新工具和选项，所以已经有一段时间没有使用 Cody 和 GitHub Copilot 了。此排名基于我过去的经验以及我所了解到的信息。

我的方式继续

VSCode + Continue + Aider 是一套不错的工具；以下是我的使用方法：

• 在终端中使用 Aider 进行复杂编辑
• 使用 Continue 进行非常简单的行内编辑——例如，你写了一些语法错误的代码，然后让 Continue 来修复它，这种方法效果很好。
  • 然而，这并不复杂；Cursor 的内联聊天功能更强大，可以处理更复杂的任务。
• 使用“继续聊天”功能可以讨论编辑器中选定的代码片段，有时还可以通过显式添加完整文件来扩展讨论范围。例如，提出问题、请求代码审查等等。

总的来说，Continue 非常适合在 IDE 内执行一些较小的上下文任务，而 Aider 更适合处理更复杂、更详细的编码需求。

继续前进的优势所在 / 支持它的最有力理由

• 100% 本地化——Cody 免费，支持自定义模型，但需要注册。Cursor 也免费，支持自定义模型，无需注册。但即使您选择自定义模型，Cursor 仍然会从其后端发起 LLM 调用。而 Continue 则无需第三方，可以将 LLM 调用限制在 IDE 和 LLM API 端点之间。这意味着使用 Continue，您可以：使用本地部署的模型（例如，通过 LM Studio），或者使用托管在安全环境中的模型，确保数据不会超出预定义的边界。
  • Continue + Aider 仍然是 100% 本地化的，并且它们都采用 Apache 2.0 许可，因此可以免费用于商业用途。
• 探索代码助手——如果您想创建自己的代码助手，运用一些复杂的提示技巧，添加上下文提供程序，或尝试其他功能——Continue 可能是最佳的起点，它已经完成了 99% 的工作，只剩下您感兴趣的 1%。克隆他们的代码库并运行它只需要 10-20 分钟。

更多的

支持上述结论的截图、笔记和观察结果……

我喜欢的地方

出乎意料的是，这款助手的功能非常齐全。我原本以为这款完全开源的产品会像许多 VSCode 助手一样，更像是一个概念验证/业余爱好产品，但它却具备了 GitHub Copilot 一个合格替代方案所需的大部分重要功能：聊天窗口、编辑集成、代码库上下文（通过嵌入进行索引）等等。

• 服务提供商很多……但其中一半现在都停用了，因为它们根本不起作用 :)

• 模型种类繁多：本地模型、远程模型、开源模型、商业模型、OpenAI 模型和非 OpenAI 模型；聊天时模型体积大、速度慢；编辑器内自动补全（按 TAB 键）时模型体积小、速度快。

• 不仅是 VSCode，JetBrains IDE 也受支持（虽然我没有测试过）——看来市面上可选择的 IDE 非常少。

我不喜欢的地方

某些问题可能在您阅读时已得到修复！

• 该应用有时不稳定，而且会出现一些奇怪的问题……

  • 我的macOS系统索引功能出了问题，
  • 如果隐藏了“继续”侧边栏，则 CMD+I 不会显示内联提示符。
  • 点击弹出窗口中的“+ 添加更多上下文提供程序”没有任何反应。

• 内联编辑器（CMD+I/Ctrl+I）非常糟糕：

  • 首次使用时可能需要 5-10 秒才能显示 -> 调用内联编辑器却没有任何反应，这令人沮丧。看来 Continue 的延迟初始化存在一些 bug。如果直接打开 Continue 编辑器，它就会很快显示出来。
  • 用户界面/用户体验糟糕透顶，VSCode 的提示符竟然显示在窗口顶部：

• 将其与光标进行比较：

• 内联编辑器有时（大约 1/20 的概率）无法提供可插拔代码——例如，如果模型返回多个带有文本的代码块——但 Cursor 不存在这种情况，我从未见过内联编辑出现这种故障。

• 编辑器界面也有点丑，小小的“接受”/“拒绝”按钮很难看清 -> 光标在这里明显更胜一筹。

• 生成的差异通常显示所选代码 100% 的更改，但实际的更改却无法被分离出来。

• 聊天窗口中没有文件快捷方式，如果输出中提到了某个文件，你无法点击它并在IDE中打开该文件。

• 网络检索服务已损坏。也就是说，您无法让助手读取给定的 URL 并将其中的信息用于任务（例如，读取 HuggingFace 数据集描述页面并筛选出特定字段）——文档中提到了该服务，但它却无法正常工作。

• 我不明白，为什么每次打开聊天窗口时，我都必须手动将当前打开的文件添加到上下文中。我选择一段代码，按下 CMD+L 快捷键将其导入聊天窗口，但整个文件并没有自动添加到上下文中。为什么不能像其他助手那样自动添加呢？这样可以节省时间……

• 虽然只是个小问题，但 Azure OpenAI 的配置并非通过用户界面完成（与其他选项不同），我必须查阅文档才能发现它是在 JSON 配置文件中配置的 -> 问题已解决。

• 模型和提供者（用户界面中的两个独立选项卡）的整体概念有点令人困惑，添加模型时，我不确定这两个选项卡之间的区别——这更加令人困惑。

代码库理解力快速测试

• 列出所有文件 - 大部分失败，尚未列出最重要的文件

• 总结要点，阐明解决方案的目的——基本成功：

虽然列出的文件并非最具描述性，也并非至关重要（代码库索引器遗漏了核心的 .py 文件），但已识别出的文件足以得出正确的解决方案。在本练习中，我认为它的水平与 Sourcegraph 的 Cody AI 相当，但低于 Curor.sh。

需要明确的是，Continue 使用了局部嵌入模型，该模型：

• 被认为不如闭源人工智能助手使用的最终托管解决方案。
• 可以进行配置，也可以替换成效力更强的产品，但我还没试过。