三款代码助手对比：谁真能帮开发者成长？

在过去的一年里，我们在 Virtual Coffee 社区进行了大量关于 AI 的对话。如果你刷过 X 或 LinkedIn，你可能意识到人们对 AI 有非常强烈的观点。在 Virtual Coffee，我们是一个紧密联系的社区，所以关于 AI 的影响、初级开发者在使用 AI 时如何成长（或停滞不前）、团队是否应该采用 AI，以及是否应该在不告诉老板的情况下使用 AI，有很多关注。许多这些对话的核心是一种感觉，即如果你使用 AI，你在某种程度上是在"作弊"，而且如果你在使用 AI，你就不会学习或成长。我认为这种情绪出发点是好的，是出于对人们的关心，但我认为有很多选项和方法可以防止这种情况。我相信，当我们考虑科技领域不断变化的格局时，我们也需要思考科技教育格局的变化。我们大多数人最终都会在我们的工作流中使用 AI，无论是出于必要还是因为我们的团队要求。这就是为什么我认为 AI 编程助手实际上有能力以前所未有的方式帮助每个人成长。

学习 vs 速度陷阱

你使用 AI 助手进行学习的方式确实很重要。并非所有 AI 编程助手都能帮助提高开发者的编码技能。学习你正在编写的代码、你的团队如何解决问题，以及如何将 AI 作为工作流的一部分来利用，这些对于在科技领域的成长是必要的。团队不需要能够通过 prompt 提示找到可行方案但在代码出问题时无法调试的人。大多数 AI 编程助手都是为了速度而不是学习而优化的。它们的设计目的是让你尽可能快地从问题到解决方案。如果你的目标是技能发展，你应该把 AI 采用更多地看作是引入一位导师，而不是替代你。

上下文感知指导

最有效的以学习为重点的助手应该了解你想要做什么，以及你应该从中学到什么。它们突出模式、指出潜在问题，并建议可能教给你一些新东西的替代方法。

今天，我在一个新特性上测试了几个 AI 编程助手。（我有兴趣做一个后续帖子，在现有文件上使用它。让我知道这是否是你想看的！）我在为我的写作网站添加的新特性上测试了每个编程助手，使用了这个简单的 prompt：

我想为这个网站创建一个游戏，人们（未登录）可以向故事中添加单词。一旦故事达到 300 个单词，就会锁定提交。没有人应该能连续提交超过 3 个单词。

以下是我对 Continue、GitHub Copilot 和 Cursor 的看法。我给每个工具都提供了相同的初始 prompt。

Continue 在这方面表现突出，因为他们的哲学明确解决了学习问题。他们的文档谈论"放大意图"而不是替代意图，并特别警告不要成为"人类剪贴板"。你可以在创意阶段通过"vibe coding"探索想法，但当涉及到生产工作时，他们强调开发者需要保持控制。它是开源的，模型灵活的（自带 LLM），并鼓励创建自定义助手来强化你的团队编码标准。对于专注于成长和提高开发者编码技能的团队，Continue 提供了透明度和控制。

在给我任何代码之前，它给了我一个初始规划响应，概述了对用户故事的分步方法。看到这个计划可以帮助用户与 Continue 一起完成任务。

之后，它提供了带注释的代码以及可重用的模板。内联注释分解了一些逻辑，帮助用户理解它生成代码所经历的过程。代码后面，它总结了所有所做的更改。你可能会注意到它提到了 Flask，但这实际上是一个 Astro 应用。那是我的错误。当我最初设置助手时，我用 Python 为中心的指令对其进行了配置，并将其指向 Python 文档，因为我的规则最初是为 Python 助手编写的。一旦我更新了这些设置并特别与助手共享了我的仓库，Continue 就能够适当地遵循我项目的样式约定并利用现有组件。

最后，它提供了所实现功能的概述和改进的想法。我很欣赏它提供了更多关于其方法的背景、在新文件中注释了代码，并为我的下一次迭代提供了灵感。

在不必进一步询问它所做的决定和所采取的方法的情况下，我认为它为开发者提供了良好的背景信息来理解这个过程。

GitHub Copilot 因代码补全而闻名，包括基于 agent 的功能。它可以加快重复任务的速度，但学习往往是通过耳濡目染发生的。你需要识别建议中的模式，可能会随着时间的推移而习得。你必须更主动地通过询问 Copilot 它所做决定来进行学习。

Copilot 的方法与 Continue 的方法差异很大。它直接跳到代码生成，没有上下文设置或其方法的解释。

它在代码后确实提供了"总结"，但不如我从 Continue 获得的彻底或完整。

值得一提的是，Copilot 还告诉我创建 Svelte 组件是最好的选择，然后当我质疑它时，Copilot 告诉我 Astro 实际上是最好的路径。一旦我质疑它，它在方法上是灵活的，但它肯定需要我与它深入探讨。学习对于 Copilot 来说绝对是被动的。

Cursor 提供了一个以 AI 为先的编辑器体验，具有 agent 模式，但他们对"与你一起构建的 AI"的强调引发了关于开发者在复杂任务中实际在进行多少构建的问题。虽然我只是为这篇文章对全新特性进行基础测试，但我确实通过突出它生成的一些代码并询问"这是做什么的？"来体验了一下它的交互式、AI 原生的 IDE 体验。我计划在后续文章中进行更多的测试以进行比较。

在给出与 Continue 和 Copilot 相同的 prompt 后，Cursor 让我了解了它正在采取的方法，并包括了它查看的文件以到达那里。然而，它自动创建了一个 Svelte 文件用于游戏（我确实在项目中安装了 Svelte），我必须进行大量的来回讨论来理解它所做的决定和原因。我实际上从未使用过 Svelte，所以这是我必须更深入地研究的东西。

我喜欢 Cursor 体验的一点是，它逐段解释并要求我接受更改。这迫使用户思考正在实现的内容。它还自动纠正了一些自己的错误，这是一个很好的学习机会，可以看到它如何进行调试。

我希望它能够在整个代码中自动添加代码注释，但解释是有价值的。末尾的摘要说明了用户可以做什么和功能。这比 Copilot 更彻底，但我喜欢 Continue 所提供的改进建议。

构建以学习为先的 AI 战略

我认为这种探索对于进入科技领域的新人以及认真考虑使用 AI 来帮助团队成长而不仅仅是更快交付的团队很重要。这里的路径应该：

以意图开始：在将任何 AI 工具添加到你的工作流或你的团队之前，清楚地定义你的目标。你是在尝试帮助自己或团队中的初级开发者理解架构模式吗？学习新框架？提高代码审查技能？不同的学习目标可能需要不同的 AI 方法。

选择具有教育基因的工具：寻找专为教育而不仅仅是生产力而设计的 AI 助手。Continue 强调放大开发者意图而不是替代它的想法是这种思维的一个很好的例子。

实施学习保障：无论你选择哪种工具，都要建立流程来通过要求对 AI 生成的解决方案进行解释、进行关注理解而不仅仅是正确性的定期代码审查、添加配对编程会话来鼓励学习（其中 AI 建议成为讨论要点），记录决定和权衡。

衡量学习，而不仅仅是输出：跟踪你的开发者随着时间的推移是否在提出更好的问题，而不仅仅是他们是否在更快地关闭工单。他们是否在代码审查中建议替代方案？他们能否调试 AI 生成的代码中的问题？他们是否学习可以在没有 AI 帮助下应用的模式？

我们希望使用 AI 的开发者理解问题。这是 AI 助手和 AI 导师之间的区别。

我认为最好的 AI 编程助手对于个人和团队都关注开发者技能增长。基于哲学、方法和明确的学习重点，Continue 似乎比大多数工具更好地理解这种区别。但工具只是等式的一部分。更大的部分是以学习作为主要目标而不仅仅是生产力来进行 AI 采用。最多产的团队和开发者理解他们正在构建什么，无论是否有 AI 帮助。