原贴链接

大家好！在我出发去机场度假之前简单说几句🥳。简而言之，Continue.Dev从Cursor那里借鉴了不少优点，我可能会取消Cursor的订阅，因为我在M1 Max低功耗模式下使用Llama - 8b时达到了每秒45个token的速度。—过去几个月我一直在非常执着地使用Cursor；作为一个12个月前还没怎么接触过代码的人来说，它在IDE中与模型无阻碍地聊天然后点击一个按钮就能实现代码这一点对我来说是一个巨大的变革。当我刚开始使用Cursor时，我看到的普遍共识是Continue.Dev总体不错，但缺少Cursor的一些关键特性……但由于我即将乘坐飞机，我想无论如何都要试用一下Continue.Dev。我不确定是我之前理解有误，还是自那以后Continue.Dev有了重大版本更新，但老实说，它已经能满足我95%的需求了！我只是简单地在LMStudio上设置了Qwen - 14b Coder Instruct 4bit MLX，将其设置为服务器，然后在Continue.Dev中选择LMStudio，嘿，就这么简单，体验几乎和Cursor一模一样！同样的快捷键，同样在IDE中与模型聊天的功能，同样按下一个按钮就能实现编写了一半的代码……我非常高兴，老实说，根据我度假期间的情况，回来后我可能会取消Cursor的订阅👀。我一直在MLX中摆弄一些推测性解码的东西，在低功耗模式下得到了一些非常令人印象深刻的结果。我说的是Llama - 8b - 4bit在编码任务中每秒45个token的速度。而且由于是低功耗模式，我的笔记本电脑从不发热——MacTOP显示GPU的最大功耗仅为14W（！）。如果我能拼凑出一个带有推测解码和自动提示缓存处理程序的MLX服务器，那么老实说，我想从现在开始我可能会坚持使用本地模型。一切都在向好的方向发展😄。再见🫡

讨论总结

原帖作者分享在低功耗模式下使用Continue.Dev的良好体验，提到可能会取消Cursor订阅。评论者们从不同角度展开讨论，包括Continue.Dev与Cursor的功能对比，如特定功能的有无；模型在不同任务中的能力表现；还有技术提升方面，如推理速度的提升操作等，整体氛围比较积极，大家分享自己的使用经验和见解。

主要观点

  1. 👍 [Continue.Dev添加特定功能后会从Cursor切换]
    • 支持理由：[Continue.Dev在部分功能上已经和Cursor相似且体验较好]
    • 反对声音：[未提及]
  2. 🔥 [8b和14b模型不适合严肃任务]
    • 正方观点：[在严肃任务中表现不佳]
    • 反方观点：[原帖作者未提及反驳]
  3. 💡 [成功提升Qwen2.5 - coder - 32b的推理速度]
    • [分享了具体的操作过程以及一些相关的测试结果]
  4. 💡 [在处理多Python文件添加概念时，Cursor会做多余操作]
    • [结合自身使用经验，阐述Cursor会改变原有工作方式]
  5. 💡 [目前Continue.Dev缺少手动接受或拒绝单行代码功能]
    • [虽然不是决定性因素，但会影响使用体验]

金句与有趣评论

  1. “😂 Armym：Once continue.dev adds the apply feature, where you apply code from sonnet to your codebase leaving you to accept/dismiss changes. I am switching from cursor”
    • 亮点：[明确提出Continue.Dev添加特定功能就会从Cursor切换，体现了对Continue.Dev功能的期待]
  2. “🤔 Pancake502：I’m using that but it’s buggy AF, maybe because my code is on a Jupiter notebook, but still I can’t use it despite really like the idea.”
    • 亮点：[指出在Jupiter notebook上使用相关功能时Bug很多，但仍然认可这个想法]
  3. “👀 mark - lord：Related: just managed to boost Qwen2.5 - coder - 32b from 13.7 tokens / sec to 19.86 tokens / sec! In low power mode spec decoding goes from about 7.2 to 11.7!”
    • 亮点：[分享了提升Qwen2.5 - coder - 32b推理速度的数据，很有技术含量]

情感分析

[总体情感倾向为积极，主要分歧点在于对不同模型能力的看法以及Continue.Dev和Cursor功能完整性的不同观点。可能的原因是大家使用场景和需求不同，以及对软件功能的期望和要求存在差异]

趋势与预测

  • 新兴话题：[MLX在正常应用中的使用以及如何进一步提升模型在不同任务中的性能]
  • 潜在影响：[如果能解决模型能力和软件功能相关问题，可能会影响开发者对代码编写辅助工具的选择]

详细内容：

标题：《关于 Continue.Dev 的惊喜发现与热烈讨论》

在 Reddit 上，有一则题为“Pleasantly surprised by Continue.Dev!”的帖子引起了广泛关注。该帖子在发布后获得了众多点赞和大量评论。原帖作者表示，在即将去机场度假之前分享这个消息。

作者过去几个月一直依赖 Cursor 来辅助编码，因其在 IDE 中与模型交流以及一键实现代码编写的便捷性而改变了自己的编程体验。然而，在即将出行前尝试了 Continue.Dev 后，发现它满足了自己 95%的需求。作者通过在 LMStudio 上设置 Qwen-14b Coder Instruct 4bit MLX 并在 Continue.Dev 中选择，获得了与 Cursor 几乎相同的体验。同时，在低功耗模式下，作者使用 Llama-8b 处理编码任务时能达到每秒 45 个令牌，且笔记本电脑不会过热。作者甚至考虑度假回来取消 Cursor 的订阅。

帖子引发的讨论焦点主要集中在 Continue.Dev 与 Cursor 的功能对比以及模型性能等方面。有人指出，一旦 Continue.Dev 增加了像 Cursor 那样能在代码库中应用代码并可手动选择接受或拒绝更改的功能，就会从 Cursor 切换过来。也有人解释了 Cursor 中一键无缝实现代码编写的功能，而 Continue.Dev 目前缺少手动接受或拒绝单行代码的功能，这虽不是致命缺陷，但可能会造成不便。

有用户分享了自己在 Shopify 代码库中使用 Continue.Dev 的经历，也有人表示 Continue.dev 存在很多漏洞，还有人认为 8b 和 14b 模型对于严肃任务不够出色。

有人通过实验提升了 Qwen2.5-coder-32b 的推理速度，并分享了相关配置和代码，但目前还无法在普通应用中使用。

这场讨论让我们看到了用户对于编程辅助工具的不同需求和期望，也反映出技术不断发展和改进过程中的各种挑战与机遇。到底 Continue.Dev 能否在未来超越 Cursor，为用户带来更优质的服务，让我们拭目以待。