Cursor 破局的关键：两个 PMF | Cursor 底层模型 / 使用教程

注：本文为 “Cursor ” 相关文章合辑。

---

Cursor 成功的背后：两个 PMF

作者 | Hailong Zhang 责编 | 王启隆 出品丨AI 科技大本营 2024 年 09 月 09 日 16:18 北京

  ~  

  ~  

Cursor 最近在社交媒体上大红大紫，产品体验确实做的好，我也从 VSCode 切换到了 Cursor。Cursor 刚成立的时候非常难用，但两年之后终于跑出来了。在我印象中，Cursor 是少有的不信邪，硬刚大厂成功的案例。
  ~  

Cursor 在 23 年 9 月获得了来自 OpenAI 的天使投资，又在 24 年 8 月宣布了 6000 万美金的 A 轮融资

01 正面硬刚 GitHub

Cursor 背后的公司叫做 Anysphere，成立于 2022 年，Cursor 是他们的第一款产品，2023 年发布。在 Cursor 发布的时候，Coding Copilot 领域实际上已经发展了相当一段时间，并且有好几个大玩家在做。

1. GitHub Copilot

GitHub Copilot 于 2022 年 3 月底在 VSCode 上正式推出，在 24 年 1 月份已达一百三十万付费用户，是目前 用户规模最大的 Coding Copilot 产品，并且仍然保持高速增长。

2. Codeium

Codeium 在 2022 年转型做 Coding Coilot 产品。今年八月底披露了 一亿五千万美金的 C 轮融资，目前有 70 万免费用户，并在企业级市场达成八位数的 ARR 。

3. Cody

主营代码搜索的 Sourcegraph 在 2023 年底推出的新产品线，目前没有披露用户数据，Sourcegraph 曾在 21 年披露一亿两千五百万美金的 D 轮融资

4. Tabnine

2019 年上线的 Tabnine 目前已经获得 2500 万美元的 B 轮融资，根据披露的数据，2022 年其用户量达到 100 万，并获得 580 万美元的收入。

这个赛道除了 GitHub Copilot 商业化的特别成功，其他虽然融了很多钱，但都发展的比较缓慢。这个时候，有几个年轻人跳出来说要做一个 AI Native IDE，基于 VSCode 魔改，用 OpenAI 的模型，挑战微软（GitHub）。初生牛犊不怕虎，基于大厂的技术，挑战大厂已经大规模商业化的产品。 这个故事要是发生在中国，投资人第一个问的问题就是“你这事儿要是能成，为啥 GitHub/微软自己不做呢？”，“GitHub Copilot 已经那么多用户，并且商业化的很成功，你有什么优势呢？”。但，即使是这种听起来非常不靠谱的故事，依然筹集到了 800 万美元。

02 破局的关键(Product Market Fit + Product Model Fit)

从技术的角度讲 Cursor 的成功就是一句话：在几乎一样的技术基础上，找到了更好的产品化的方式。 这是一个非常典型的 Product Market Fit + Product Model Fit 的案例。这个更好的产品化体现在哪里呢？最核心的只有一条：AI 对于单一文件的多处修改/多个文件的同时修改。这里的详情可以参见 Cursor 官方博客 https://www.cursor.com/blog/instant-apply

1. AI 底层技术的快速发展解锁了更多场景

在 GPT-4 甚至 GPT-4-Turbo 时代，Cursor 想要的产品体验是做不出来的，因为底层模型太慢了。但是 2024 年上半年出现了 Sonnet 3.5 以及 Llama 3。虽然这两个模型在智力上并没有超越 GPT-4，但是性能更好了，并且 Llama 3 的出现第一次让应用侧有了一个智力正常的可以微调的模型。这两个点放在整个行业可能没啥，但是恰恰是解锁 Cursor 设想的产品体验的核心要素。这是 Product-Model-Fit。

OpenAI HumanEval 测评集得分随时间变化

2. 能形成商业闭环

Cursor 的产品体验脱胎于 GitHub Copilot，可以说 Product-Market-Fit 是 GitHub 帮 Cursor 做的，就是这个产品形态，以月费的形式向个人开发者收费能行得通。所以 Cursor 其实从 Day 1 就形成了商业闭环，这一点在国内也是不成立的。硅谷的开发者非常愿意为了效率自掏腰包，哪怕只有少量改进。

3. 大厂反应很慢很慢

你难以想象 Cursor 是在 GitHub 的眼皮子底下抢用户，然后 GitHub 似乎没有任何反应，到目前为止。Cursor 现在的产品体验并不是只有 Sonnet 3.5 能做到，GPT-4o 也是可以的，但是为啥 GitHub 没做呢？有人说是因为 VSCode 和 GitHub 是两个部门，有部门墙？但凡 GitHub 内部稍微有点话语权的人想干 Cursor 的事，都可能把 Cursor 扼杀在摇篮里。但，这种事情在硅谷往往不会发生。某种意义上，这也是 Product-Market-Fit。

以上三点，我认为是 Cursor 成功的必要条件，但这些条件对于很多创业公司都是一样的，为啥其他人没成呢？最关键的还是 Cursor 做了一个正确的产品假设，然后一直在打磨以及等待技术的成熟使得这个假设成立。正确的问题往往比解法更重要。 不知道这里远见占了几分，运气占了几分？

03 爆火下的隐忧

既然用户因为一定程度的产品体验改进，很容易从 GitHub Copilot 迁移到 Cursor，那是不是意味着也很容易迁移走？这就涉及到 Copilot 这类产品的模式问题。实际上真正的护城河是 VSCode，不是 GitHub Copilot 也不是现在的 Cursor。VSCode 已经从一个简单的编辑器变成了一个平台。用户之所以能从 GitHub Copilot 很容易的迁移到 Cursor，是因为他们都寄生于 VSCode，用户的使用习惯，体验，功能/插件都完全一样。如果 Cursor 不能迁移 VSCode 现有的体验，那它一定不能以现有的这些改进来让用户放弃 VSCode。要复制 VSCode 生态带来的各种插件和可扩展的能力非常非常困难。如果你关注这个领域，你大概知道最近还有另外一个 IDE 开始被人关注到 Zed（zed.dev）。从工程角度来讲 Zed 的工程复杂度至少是 Cursor 的 10 倍，因为 Zed 从零开始自己写了这个 IDE，完全不依赖 VSCode，并且也集成了 AI Copilot 能力。但是从目前用户的使用来看，Cursor 至少是 Zed 的 10 倍。确实，选择比努力重要。

所以无论是 GitHub Copilot 还是 Cursor 都是 VSCode 生态里的工具，对于开发者来说就是一把更好的锤子，本身不具备网络效应等护城河。另外 Cursor 这事儿也证明了 Copilot 产品所谓的数据飞轮是不存在的，GitHub 先发这么多也没有在产品体验上拉开差距。你能拿到的数据，大模型都能拿到，已经是模型的一部分了。

04 What Next

今年六月份的时候我在硅谷听过一次 Cursor 创始人的演讲，他们的核心思路就是造牛逼的工具让 Human Developer 变成 Human Super Developer。 这个理念实际上是比较另类的，我记得当时那个分论坛叫做 Developer Agent，只有他们一家在讲 Copilot，其他人全部在讲 Agent。

Copilot 是不是 Agent 的路径？目前并没有共识，我认为不是。虽然 Cursor 目前没有做 Agent，但是我觉得他们会改变这个想法。

前一阵子 OpenAI 发布了 SWE-bench_Verified https://openai.com/index/introducing-swe-bench-verified 测试集，是目前这个领域最权威的 benchmark。赛道刚刚开始，但已经竞争激烈，你会看到很多跟 Copilot 领域完全不一样的玩家：

SWE-bench_Verified 是用于测试 AI 解决真实世界中软件问题的测评集

目前 Agent 产品形态的技术基础是不成熟的，即使我们（gru.ai）已经是目前的最高分，但也只有 45 分左右，远远达不到实际商用的标准。

根据之前 OpenAI HumanEval benchmark https://paperswithcode.com/sota/code-generation-on-humaneval 的经验，我们估计等这个榜的分数普遍在 70 分以上的时候，这个领域才具有商业化的技术基础。可以说目前 Agent 领域两个 PMF 一个都没达成，没有被验证过的产品形态，没有成熟的技术。

但这个领域依然吸引了非常多的注意，我们看到有越来越多的创业公司在加入这个领域的竞争，光 YC 就毕业了至少 3 个相关团队。一方面大家在努力竞争技术储备，另外一方面在努力寻找商业化的落脚点，从解决软件工程中的小问题开始，例如写文档，写测试等等。当然，这个领域也被很多人质疑，这是普遍存在的非共识。

---

打造一个 Cursor 只需要三步

OpenSumi InfoQ 2024年09月24日 13:23 辽宁

作者 | 王兴龙

Cursor（https://www.cursor.com）是近期爆火的 AI IDE，在社交媒体上大红大紫，取代了之前 Github Copilot 的位置。Cursor 背后的公司 Anysphere 近期也宣布获得由 OpenAI 领投的 6000 万美元的 A 轮融资，更是坚定了众多做 AI 创业公司的信心：只需要在用户价值的深处持续前进，就能有机会找到 PMF（Product Market Fit，产品市场契合度）。

Cursor 成功的两个关键因素

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 默认可供选择的模型

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 和插件的对比

由上述对比或许可以得到两个结论：

1. 随着大模型上限逐渐突破，插件只能实现其中 50%，而 AI IDE 能实现 100%。
2. 未来智能研发一定是 AI + IDE 而非 AI + 插件

魔改 VS Code 带来的问题

由于 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：AI 原生 IDE 框架

OpenSumi 是一个开源的、高性能和高度可定制的 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 模块的集成

正文开始：三步构建出自己的 Cursor

📦前期准备

• 环境：Node.js 版本 >= 20
• 依赖管理：yarn
• 模型接口及 ApiKey（任意兼容 OpenAI 规范的模型）

第一步：fork&clone codefuse-ide 并安装依赖

fork&clone CodeFuse IDE https://github.com/codefuse-ai/codefuse-ide，并参照 README.md 文件安装依赖

git clone git@github.com:codefuse-ai/codefuse-ide.git && cd codefuse-ide
# 国内用户考虑使用 npmmirror 加速安装依赖
yarn config set -H npmRegistryServer "https://registry.npmmirror.com" 
export ELECTRON_MIRROR=https://npmmirror.com/mirrors/electron/
# 安装依赖
yarn
# rebuild electron native 依赖
yarn run electron-rebuild

⚙️第二步：修改配置

CodeFuse IDE 支持集成任意的模型服务，默认与本地模型对接（可使用 ollama https://ollama.com 下载和运行本地模型 ），可在 src/ai/browser/ai-model.contribution.ts 路径里修改模型请求接口，支持任意兼容 OpenAI 规范的模型服务，以 deepseek api （https://www.deepseek.com）为例，填入模型配置、apiKey 及模型名称即可

对 IDE 模型请求及 apiKey 进行默认设置

CodeFuse IDE 支持对模型进行以下配置：

配置项	说明	默认值
ai.model.baseUrl	API URL 前缀，默认与 ChatGPT 格式兼容，自动拼接 chat/completions的路由	http://127.0.0.1:1143/v1
ai.model.apiKey	API Key	-
ai.model.chatModelName	对话模型名称	-
ai.model.chatSystemPrompt	对话系统提示词	-
ai.model.chatMaxTokens	对话模型最大生成 token 数量	1024
ai.model.chatTemperature	对话模型采样温度	0.2
ai.model.chatPresencePenalty	对话模型 presence_penalty 参数	1.0
ai.model.chatFrequencyPenalty	对话模型 frequency_penalty 参数	1.0
ai.model.chatTopP	调节采样温度的替代方案	-
ai.model.codeModelName	补全模型名称，若不填则和对话模型名称一致	-
ai.model.codeSystemPrompt	补全系统提示词	-
ai.model.codeMaxTokens	补全模型最大生成 token 数量	64
ai.model.codeTemperature	补全模型采样温度	0.2
ai.model.codePresencePenalty	补全模型 presence_penalty 参数	1.0
ai.model.codeFrequencyPenalty	对话模型 frequency_penalty 参数	1.0
ai.model.codeTopP	调节采样温度的替代方案	-
ai.model.codeFillTemplate	FIM(Fill in the Middle)模版，如果未提供模版，则将光标前后代码直接发送到接口，如果提供了模版，配置如下格式：“<fim_prefix> {prefix}<fim_suffix>{suffix}<fim_middle>”,{prefix} 会替换为光标前代码，{suffix}会替 换为光标后代码 -

除了上述 IDE 配置来自定义模型请求地址以外，也完全可以通过 OpenSumi 模块开发的方式通过 OAuth 完成用户登录鉴权等功能，会更加符合商业 IDE 的形态。

另外，如果模型接口没有遵循 OpenAI 规范，也可以自己实现模型请求接口，具体实现见 src/ai/node/ai-back.service.ts

实现自定义的模型请求接口

目前 CodeFuse IDE 集成了部分 OpenSumi AI 能力，更多的 AI 能力集成可扩展 src/ai/browser/ai-native.contribution.ts，具体可以参照 OpenSumi AI 模块集成文档 https://opensumi.com/zh/docs/integrate/module-usage/ai-native-module

通过模块自定义 AI 特性

除了上述模型请求地址以外，当然还可以自定义 App 的名称（product.json）、图标（assets/icon）等。

🚀第三步&#