GitHub Copilot新增多模型选择,迎战Cursor?

GitHub Copilot迎来新挑战!此次更新引入多款新模型,与Cursor争夺用户。Claude、Gemini和o1加入,提供更全面的编码支持。

原文标题:o1之后,GitHub又接入Claude、Gemini,网友:也杀不死Cursor

原文作者:机器之心

冷月清谈:

* GitHub Copilot 引入 Anthropic Claude、Google Gemini 和 OpenAI o1 等新模型供用户选择。
* Claude 擅长处理整个软件开发生命周期的编码任务,Gemini 具备原生多模态支持,o1 拥有更先进的推理能力。
* Perplexity 集成到 GitHub Copilot,提供可验证的编程问题解答和参考来源。
* GitHub Spark 工具推出,实现以自然语言构建应用程序。
* GitHub Copilot 此次更新被认为是对 Cursor 竞争的回应,有望吸引回部分转投 Cursor 的用户。

怜星夜思:

1、本次 GitHub Copilot 更新中最吸引你的是什么功能?
2、你认为 GitHub Copilot 的更新能否让它重新夺回市场份额?
3、你更愿意选择 GitHub Copilot 还是 Cursor?为什么?

原文内容

机器之心报道

编辑:陈陈

那些转到 Cursor 的用户,会不会又被吸引过来呢?


从今天起,GitHub Copilot 用户可以有更多模型选择了。

包括 Anthropic 的 Claude 3.5 Sonnet、Google 的 Gemini 1.5 Pro 以及 OpenAI 的 o1-preview 和 o1-mini,这些模型首先在 Copilot Chat 中推出。

此前,OpenAI o1-preview 和 o1-mini 已经推出,Claude 3.5 Sonnet 将在下周逐步推出,Google 的 Gemini 1.5 Pro 将在未来几周内推出。

图片

Claude 3.5 Sonnet

Anthropic 发布的 Claude 3.5 Sonnet 模型擅长处理整个软件开发生命周期的编码任务 —— 从初始设计到错误修复、从维护到优化。在这些任务中,Claude 3.5 Sonnet 都表现的非常出色。


Gemini 1.5 Pro

Google 最新 Gemini 模型在各种编码场景中表现出极高的能力。Gemini 1.5 Pro 上下文窗口达 200 万个 token,并且原生支持多模态,能够同时处理代码、图像、音频、视频和文本。


o1-preview 以及 o1-mini

OpenAI o1-preview 和 o1-mini 模型配备了比 GPT 4o 更先进的推理能力。这些模型的推理能力可以更深入地理解代码约束和边缘情况,从而产生高效、高质量的结果。


Perplexity + GitHub Copilot

除了对模型更新外,现在 Perplexity 也已经集成到 GitHub Copilot 中,可以帮助用户回答编程中遇到的问题,这项新功能还能提供实时可验证的参考来源,增加答案的可靠性。


GitHub Spark

为了实现 GitHub 覆盖 10 亿开发者的愿景,研究团队还推出了 GitHub Spark。这是一款完全以自然语言构建应用程序的 AI 原生工具。

Spark 集成了 AI 功能和外部数据源,用户无需管理任何云资源。利用创意反馈循环,用户从初始提示开始,并可以在构建应用程序时查看实时预览,轻松查看每个请求的选项,并自动保存每次迭代的版本,以便他们可以随时比较不同版本的效果。


看到这,GitHub Copilot 这次更新诚意还是很大的。

在此之前,Copilot 首个公开版本使用的是 Codex,也就是 OpenAI GPT-3 的早期版本,之后 2023 年推出 Copilot Chat,搭载的也是 OpenAI 的模型 GPT-3.5 和后来的 GPT-4。

现在 Copilot 接入了更多模型供大家选择,大家纷纷猜测可能是受到 Cursor 的影响,毕竟 Cursor 把默认模型切到了 Claude,虽然 OpenAI 重金进行了投资。

GitHub Copilot CEO Thomas Dohmke 也进行了一波宣传,Claude 3.5 Sonnet 上线 Copilot。


有网友认为,这是 GitHub Copilot 追赶 Cursor 的一种表现,随着新模型的加入,GitHub Copilot 会赢回一批用户。毕竟很多程序员都转到 Cursor 了,因为那里可以使用 Claude-3.5-Sonnet。


还有网友表示,「可能要切换回 VS Code 了。」


「太好了!也许我可以重新激活我的 GitHub Copilot 订阅。」


还有网友表示:「老实说,我不认为 Cursor 是一个可靠的解决方案。它只是在使用 4o 和 Claude 方面比 Copilot 更胜一筹。如果 Copilot 也这么做,这很容易被取代,而微软确实这么做了。」


不过有人并不同意,表示「GitHub 花了两年时间才承诺类似的功能,在速度方面,Cursor 赢麻了,再次超越微软。」


「Cursor 并没有被杀死。」


GitHub Copilot 和 Cursor 你选哪个?欢迎评论区留言。

参考链接:
https://github.blog/news-insights/product-news/bringing-developer-choice-to-copilot/

© THE END 
转载请联系本公众号获得授权
投稿或寻求报道:[email protected]

我认为有可能,新模型的加入会提升 Copilot 的编码能力,吸引一些用户。

很难说,这取决于用户对新功能的实际体验和反馈。

新模型的加入,特别是 Claude,它的编码能力受到广泛认可。

我更喜欢 GitHub Copilot,因为它与 GitHub 生态系统紧密集成,方便使用。

我更喜欢 Cursor,因为它提供了更广泛的模型选择,而且它的 Claude 模型非常强大。

不一定,Cursor 目前在模型选择方面仍占优势,而且它的发展也很迅速。

我还在犹豫,需要亲身体验一下新版本的 GitHub Copilot,再做决定。

Perplexity 的集成,它可以提供可信赖的编程问题解答和引用。

GitHub Spark 的推出,它可以让我用自然语言轻松构建应用程序。