Cursor（https://www.cursor.com）是近期爆火的 AI IDE，在社交媒体上大红大紫，取代了之前 Github Copilot 的位置。
Cursor 背后的公司 Anysphere 近期也宣布获得由 OpenAI 领投的 6000 万美元的 A 轮融资，更是坚定了众多做 AI 创业公司的信心：
只需要在用户价值的深处持续前进，就能有机会找到 PMF
（Product Market Fit，产品市场契合度）。
Cursor 能取得如此成功，很大程度上归功于其采用了最先进的 AI 模型。
据 Cursor 创始人透露，早在 2022 年 12月，在大部分人还在体验 ChatGPT 3.5 时 Cursor 就拿到了 GPT 4 的体验权限，并开始基于 gpt-4 构建 AI Native IDE，最近更是因为接入 claude sonnet 3.5 后，生成的代码质量和成功率大大提高了。如果基于 ChatGPT3.5 或者更差的模型，是无法达到 Cursor 想表达的 AI 功能。
Cursor 本身对模型也进行了非常多的优化，例如让模型对当前仓库代码生成更准确（将本地代码分割上传至服务端做 embedding）、更快速（使用推测解码 Speculative Decoding 技术将输出速度达到对1000 个 token/秒），
这些是 Cursor 最重要的核心技术
。
另外，Cursor 也找到了更好的 AI 编程交互方式
，例如在智能编辑器方便，Cursor 做了多行补全、智能改写、下一次补全的预测等称之为“Cursor Tab”功能，可以一路进行 tab 完成编程工作；再比如 Cursor 做的 Inline Chat 的功能，可以在编辑器快速唤起输入框，通过自然语言完成业务需求的代码生成，并且可以在过程中观察到代码逐行生成的过程。
cursor 的 inline chat 功能
除了优秀的代码生成场景以外，Cursor 的聊天面板功能也非常强大，例如可对整个仓库进行问答的 Codebase Agent、可请求互联网的 Web Agent、可快速对在线文档进行索引的 Doc Agent。除了以上核心功能以外，能称之为 AI Native IDE，还有对于众多 IDE 本身功能进行了升级，例如可自然语言设置终端命令、对于终端输出进行拦截并非常方便的给出解释和修复建议。
Cursor 通过自然语言完成终端命令
那么问题来了，为什么这么多家做智能研发助手的公司，没有能做出类似于 Cursor 一样的 AI 原生交互？
自从 2022 年 12 月 ChatGPT 发布开始，大语言模型取得了前所未有的突破，催生了无数 AI 驱动的应用程序，尤其在研发领域，各大公司都相继推出响应的智能研发助手插件，例如 Microsoft 的 GitHub Copilot、Amazon 的 CodeWhisperer、Sourcegraph 的 Cody、智谱的 CodeGeeX、百度的 Comate、阿里云的通义灵码、蚂蚁集团的 CodeFuse，
可以说 AI 辅助编码是大模型最早落地的应用之一，也是最具有实用性和商业价值的场景之一。
这些插件基于 VS Code、Jetbrains 系 IDE 的插件体系，做出了代码补全的功能；通过菜单、命令面板或者 CodeLens、Decoration 做出在编辑器里触发解释代码、添加注释、添加单测，并在 Chat 面板中插入对应代码的功能。但由于插件 API 限制，智能研发助手无法做出像 Cursor 一样的多行补全功能，也无法做出 Cursor 一样 Inline Chat 功能。
以代码优化、生成单测功能为例，智能研发助手通常使用右键菜单或者 CodeLens 将要优化的代码丢给聊天面板，聊天面板回答后通过代码块插入功能或者手动复制功能，将代码替换，替换后想查看 Diff 需要通过 SCM 面板进行 Diff 查看，修改完成后再返回到之前编辑器。反观 Cursor，可以非常自如的在编辑器内部弹出输入框，输入代码优化或者其他任意任务，之后在编辑器内部直接生成的代码，并以 Diff 的方式展示，开发者只需选择接受或者放弃即可，整体体验一气呵成，
让用户的注意力只专注在编辑器的范围，更容易达到“心流”状态。
智能研发助手代码优化交互与 Cursor Inline Chat 对比
VS Code 也在做相关 UI 升级的尝试，这些尝试通常只会出现在一方的 Github Copilot 上，作为“实验性”的插件 API，其余插件并不能直接使用，而且后续插件 API 会频繁改动，也无法预测会在什么时候变为“稳定” API 供三方插件使用，以至于一些智能研发助手只能选择利用解决冲突 Diff 的交互 + 评论组件完成 Inline Chat 的交互。
Github Copilot Inline Chat 功能
对比一些常见的 AI 功能，Cursor 为代表的 AI 原生 IDE 与智能研发助手功能对比如下图：
|
功能项
|
AI IDE 可以做
|
插件可以做
|
|
仓库级补全
|
✅
|
✅
|
|
多行补全
|
✅
|
❌
|
|
智能改写
|
✅
|
⚠️可以通过编辑器 Decoration 完成功能，但会出现代码过多导致溢出看不见的问题
|
|
下一次补全预测
|
✅
|
✅
|
|
编辑器内通过自然语言生成代码
|
✅
|
❌
|
|
编辑器内快速问答
|
✅
|
❌
|
|
智能终端
|
✅
|
❌
|
|
AI Lint
|
✅
|
❌
|
|
聊天面板
|
✅
|
✅
|
AI IDE 和插件的对比
由上述对比或许可以得到两个结论：
1、随着大模型上限逐渐突破，插件只能实现其中 50%，而 AI IDE 能实现 100%
2、未来智能研发一定是 AI + IDE 而非 AI + 插件
由于 VS Code 在 AI 时代过于慢的反应，Cursor 选择直接 fork VS Code 进行魔改，以满足上述对于 IDE 定制化的需求。有此类想法公司并不少见，例如 Google Project IDX、字节跳动 MarsCode IDE、华为 CodeArts IDE，都是此类方式魔改 VS Code 打造定制化的 IDE，但 VS Code 在诞生之时就不是为了让其他业务场景定制化来设计的（VS Code 对外扩展的唯一方式就是插件），所以在魔改 VS Code 时无法避免三个问题：
1、升级困难：对 VS Code 改的越深入，会导致分叉越大，这样的分叉不可避免地增加了后续对 VS Code 升级和解决冲突的成本，这个问题会随时间推移越来越严重
2、维护成本高：VS Code 本身不是为了业务定制而设计，而且基于 VS Code 进行深度定制本来就是一项复杂的工作，需要投入大量的时间和资源来维护和更新
3、潜在的缺陷：一些在 VS Code 中不存在的问题可能会在 Cursor 中出现，这可能是由于定制过程中引入的新代码或修改导致的，例如 Cursor 论坛的讨论帖，与 VS Code 的分叉已经带来了不可预料的问题
https://forum.cursor.com/t/vs-fork-question
OpenSumi
（https://github.com/opensumi/core）
是一个开源的、高性能和高度可定制的 IDE 研发框架，它为开发者提供了模块化开发的方式，并提供一套工具和组件，用以构建双端（Web 和 Electron）的集成开发环境。与 VS Code 和 IntelliJ IDEA 等 IDE 产品不同的是，OpenSumi 定位是可扩展的 IDE 框架，着重于降低定制难度，使开发者能够轻松组合功能模块，以满足特定的业务需求。OpenSumi 的主要特点如下
1、
模块化开发：
提供 50+ IDE 的原子模块，集成方可以根据需求自由排列组合
2、
扩展性高：
提供依赖注入（Dependency Injection）方式开发，集成方可方便替换 OpenSumi 底层实现
3、
多端支持：
支持构建桌面端、Cloud IDE、Remote 模式、无容器 IDE 等多种形态的 IDE 模式
4、
兼容 VS Code 插件生态：
兼容 VS Code 三方插件，无缝迁移用户使用习惯
2024年5月，OpenSumi 发布 OpenSumi 3.0，对编辑器、终端面板、SCM 面板、设置面板等核心面板进行了 AI 增强或重构，详情可阅读
我们用大模型给 IDE 升了个级，这是我们总结的万字心得
。OpenSumi 一直在积极探索 AI 能力，除了文章里介绍的 AI 特性以外，OpenSumi 近期更新的功能有：
1、
开放 Inline Chat 对话：
开放了 Inline Chat 里的对话模式，让开发者可以通过自然语言和编辑器进行交互，并支持流式输出与 Diff 级采纳能力
使用英文添加注释
2、
支持多行补全及智能改写：
多行补全是在原来代码补全基础之上的增强能力，可以在当前光标范围内对原代码进行多个补全，采纳后即可全部应用；智能重写其实是多行补全的一种 UI 展现形式，当要补全的新代码内容与原代码有较大出入时就会展示
多行补全能力
智能改写能力
3、
编辑器错误修复：
在开发过程中经常会遇到编辑器 Lint 报错问题，通常语言服务插件可提供部分错误的快捷修复方案，对于其他处理不了的问题可通过大模型修复
编辑器错误修复能力
CodeFuse IDE：开源驱动的桌面AI IDE
近期在外滩大会上，
蚂蚁集团 CodeFuse（https://codefuse.ai）针对桌面端 IDE + AI 服务场景，开源了基于 OpenSumi 构建的 CodeFuse IDE
https://github.com/codefuse-ai/codefuse-ide，并在外滩大会现场演示了在联想 AIPC 上与 CodeFuse 本地模型交互的场景。
codefuse ide 介绍
对于 OpenSumi 的集成方来说，CodeFuse IDE 有以下特点：
1、生产可用：
CodeFuse IDE 代码组织符合生产可用的 OpenSumi 模块组织规范，不同功能划分到不同的 package 中，每个 package 都有 browser（前端）、node（后端）、common（前后端通用）的目录来划分，
CodeFuse IDE 就是 OpenSumi 构建桌面端 IDE 的标准模板
2、研发链路完整
：CodeFuse IDE 使用 electron-forge 来打包桌面端应用，并支持开发、构建、打包、自动更新等客户端研发链路
3、AI First：
CodeFuse IDE 也更加专注于 OpenSumi AI 模块的集成
📦
前期准备
1、环境：Node.js版本 >= 20
2、依赖管理：yarn
3、模型接口及 ApiKey（任意兼容 ChatGPT 规范的模型）
⬇️ 第一步：fork&clone codefuse-ide 并安装依赖
fork&clone CodeFuse IDE
(https://github.com/codefuse-ai/codefuse-ide)
，并参照 README.md 文件安装依赖。
git clone [email protected]:codefuse-ai/codefuse-ide.git && cd codefuse-ideyarn config set -H npmRegistryServer "https://registry.npmmirror.com" export ELECTRON_MIRROR=https://npmmirror.com/mirrors/electron/yarnyarn run electron-rebuild
⚙️ 第二步：修改配置
CodeFuse IDE 支持集成任意的模型服务，默认与本地模型对接（可使用 ollama https://ollama.com 下载和运行本地模型 ），可在 src/ai/browser/ai-model.contribution.ts 路径里修改模型请求接口，支持任意兼容 ChatGPT 规范的模型服务，以 deepseek api （https://www.deepseek.com）为例，填入模型配置、apiKey及模型名称即可。
对 IDE 模型请求及 apiKey 进行默认设置
CodeFuse IDE 支持对模型进行以下配置：
|
配置项
|
说明
|
默认值
|
|
ai.model.baseUrl
|
API URL 前缀，默认与 ChatGPT 格式兼容，自动拼接 chat/completions 的路由
|
http://127.0.0.1:11434/v1
|
|
ai.model.apiKey
|
