拆解 Cursor：一个 Android 工程师眼中的 AI 编程产品

📰 科技要闻

• OpenAI 发布 GPT-5.4 mini 与 nano 小型模型，同期 OPPO Find N6 正式发布，折叠屏竞争持续升温。

• 阿里钉钉宣布企业 Agent 规模突破 2000 万，钉钉创始人无招称 AI 时代最大变革是「使用主体变了」，B 端 AI 产品进入爆发期。

• 苏州博思得完成超亿元 C 轮融资，高能粒子核心部件国产替代提速，半导体上游硬件成新风口。

AI 编程工具里，Cursor 是个异类。不是因为它的补全有多准，而是它对"工程师到底在干什么"这件事，理解得比大多数同类产品深得多。

大部分 AI 编程工具走的是插件路线：嵌进编辑器，劫持补全接口，塞几行提示词。Cursor 不一样——它直接 fork 了 VSCode 源码，从编辑器底层开始重建。这个选择背后有很清晰的工程逻辑，也决定了它能做到哪些插件根本做不到的事。

这篇从工程视角拆一遍 Cursor——技术实现路子、context 机制、Tab 补全的延迟工程、Agent 模式的边界、交互设计逻辑，以及它的商业模式为什么能跑起来。

从 VSCode 分叉说起

Cursor 是从 VSCode 直接 fork 出来的，这一点官方没有刻意隐瞒，但很多人其实不知道背后意味着什么。

不是做了个 VSCode 插件，也不是套了个皮。是把整个 VSCode 的源码（约 300 万行 TypeScript）fork 下来，在此基础上改造。这个选择本身就很有意思——

• 插件方案（比如 GitHub Copilot）：受限于插件 API，无法深度介入编辑器行为

• 自研编辑器：成本极高，生态从零开始，工程师接受度低

• Fork VSCode：获得完整控制权，同时继承了 VSCode 庞大的扩展生态

这个决策让 Cursor 能做很多插件做不了的事。比如它的多行幽灵文字（ghost text）补全——不是简单的行尾提示，可以在光标前后同时插入内容，可以跨越多个函数体，可以在你还没打完一个变量名的时候就把接下来三个函数全帮你写好。

这些在插件层是根本做不到的，因为 VSCode 的扩展 API 根本没暴露这些能力。

Context 窗口管理：最核心的工程问题

一个绕不开的问题是：Cursor 怎么知道该把哪些代码塞给模型？

一个稍微正经点的 Android 项目，代码量轻轻松松二三十万行。就算是 Claude 3.5 的 200k token 上下文，也塞不进去一个完整工程。更何况你每次补全都实时请求，延迟是个硬指标。

Cursor 的做法，根据我的观察和一些公开的技术分享，大概是这么几层：

第一层：本地代码索引（Embeddings）

Cursor 在你打开项目时会在本地做一次代码嵌入（embedding）索引。它把代码切成语义块（chunk），向量化后存在本地，查询时用相似度检索。

注意这里有一个关键点：索引是在本地算的，不会把你的全量代码上传服务器。这对很多公司项目有代码安全合规要求的团队来说是个加分项（当然隐私模式下连请求都走 zero-data-retention，另说）。

第二层：多信号上下文组装

每次你触发 AI 操作时，Cursor 会把以下信号混合起来组装成 prompt：

• 当前文件的全文（或截断版）

• 光标位置前后的代码片段

• 最近打开/编辑过的文件（recent files）

• 通过 embedding 检索出的语义相关代码片段

• @file、@symbol、@web 等用户显式指定的上下文

• 项目根目录的 .cursorrules 配置文件

这里有个工程上的取舍：相关性和延迟之间的博弈。检索越精准，召回的代码越有用，但检索本身也要时间。Cursor 的补全（Tab 功能）走的是轻量快速路径，Chat 和 Composer 则可以走更重的召回。

第三层：.cursorrules——项目级系统提示

这个东西我用得比较多，值得单独说。在项目根目录放一个 .cursorrules 文件，每次对话都会被自动带入 system prompt。

比如我的 Android 项目里是这么写的：

// .cursorrules
// Android 项目规范- 使用 Kotlin，禁止写 Java
- 架构：MVI + Clean Architecture
- UI 层用 Jetpack Compose，
禁止 XML layout
- 状态管理：
StateFlow + sealed class
- 依赖注入：Hilt，
禁用 Koin
- 网络层：Retrofit + OkHttp，
协程，禁止 RxJava
- 命名规范：
ViewModel 后缀 VM 而非 ViewModel
- 所有 IO 操作必须在
Dispatchers.IO 上运行
- 单元测试：JUnit5 + MockK

有了这个，Cursor 生成的代码就会自动遵循项目规范，不会冒出一段 Java 代码或者突然用 LiveData。这个功能看起来简单，但对团队协作来说价值很大——不同人的 AI 辅助都走同一套规范。

实际踩坑：.cursorrules 内容太长会被截断，建议控制在 500 字以内，专注最重要的约束。有些工程师把整个技术文档塞进去，结果 token 消耗翻倍但效果没提升。

Tab 补全的延迟工程

GitHub Copilot 刚出来的时候，我用过一段时间，最大的痛点不是质量，是延迟——那种等了两秒然后出现一段不知所云的建议的感觉，真的会打断 flow。

Cursor 的 Tab 补全在延迟上明显好一截，背后是几个工程手段叠加：

预测性预填充（Speculative Prefill）

Cursor 不是等你停下来再发请求，而是在你打字过程中就悄悄开始预测你接下来可能会问什么、光标会移到哪里，提前发起请求。当你真的停下来时，结果可能已经在路上了，甚至已经回来了。

这个思路和 Android 里的预加载逻辑很像——你在 RecyclerView 滑动，在当前 item 还没到边界时就提前加载下一批数据，用户感知不到延迟。

轻量级本地模型 + 云端大模型协同

对于简单的行内补全（变量名、方法调用），Cursor 会走轻量路径甚至本地模型；对于复杂的多文件修改（Composer），则走更强的云端模型。这种分级策略在延迟和质量之间找到了平衡点。

有点像 ArXiv 上最近的一篇研究《Efficient Reasoning on the Edge》的思路——大模型的推理链（chain-of-thought）虽然准确但代价高，在边端场景下要考虑动态截断推理步骤、用小模型替代中间步骤。核心矛盾是一样的：越强的模型越慢，越快的路径越笨，关键是怎么在合适的地方做切换。

Composer/Agent 模式：从补全到执行

如果说 Tab 补全是 Cursor 的"入门产品"，那 Composer 才是它真正让我觉得"这玩意儿有点东西"的地方。

Composer 允许你用自然语言描述一个任务，然后 Cursor 会：

• 理解你的意图

• 决定需要修改哪些文件

• 生成多文件的差量修改（diff）

• 让你 review 后一键应用

更新的 Agent 模式甚至可以自动执行终端命令、运行测试、根据报错自动修复，形成一个循环。

我实际用下来，这个模式对"新增一个功能模块"类型的任务效果不错，比如我说"帮我加一个用户资料页面，包含头像、昵称、手机号展示，用 Compose 实现，遵循项目现有 MVI 架构"，它能生成完整的 ViewModel + UiState + Screen 文件，结构基本是对的。

但有一件事它经常搞错：它对"现有代码是怎么工作的"理解不够深。特别是一些隐式约定——比如我们项目里 ViewModel 的 event 处理有个特殊的 channel 机制，文档里没写，全靠代码里传承下来——Cursor 会按"它认为合理"的方式处理，导致生成的代码逻辑上看起来对，但不符合项目实际。

这就是为什么 .cursorrules 和 @file 显式指定上下文很重要：你需要主动管理它的知识边界。

长记忆问题还没解决

Cursor 当前最明显的短板之一是跨会话的记忆能力。每次开一个新的 Chat 窗口，它对你上次的对话一无所知。

这个问题其实学术界也在研究。最近 ArXiv 有篇论文《Chronos: Temporal-Aware Conversational Agents with Structured Event Retrieval for Long-Term Memory》，讨论如何让对话 AI 在跨越数周数月的交互中保持时序感知的记忆——把事件结构化存储，按时间和语义双重索引，检索时能理解"上周讨论的那个问题"和"三个月前遇到的 bug"的区别。

Cursor 目前的 Memory（记忆功能）处于早期阶段，基本上就是把对话摘要存下来，远没到 Chronos 这种精细程度。这块如果做好了，对工程师日常使用的价值会很大——想象一下它能记住"你三个月前在这个项目里解决过一个 OOM 问题，当时的方案是……"

交互设计：工程师心理模型的映射

我觉得 Cursor 在交互设计上最聪明的一个判断是：工程师不信任黑盒。

所以它的交互设计处处在给你"控制感"：

Diff 而非直接修改

Composer 生成的修改不会直接覆盖你的文件，而是以 diff 的形式展示，每个 hunk 都可以单独 accept 或 reject。这个设计简直太对了——我没有任何工程师朋友会愿意 AI 直接改掉他的代码，但 diff 就完全不同，我们每天 review PR，看 diff 是肌肉记忆。

@符号引用：显式比隐式好

在对话里可以用 @file、@symbol、@folder、@web、@docs 显式引入上下文。这个设计逻辑很工程：你知道你给了模型什么，它就知道该怎么回答。与其让 AI 猜该看哪里，不如你告诉它。

这一点和"隐式推断上下文"的产品设计有明显区别。对工程师来说，显式更好——就像函数参数宁可多写几个也不要靠隐式全局状态。

可切换的底层模型

Claude 3.5 Sonnet、GPT-4o、Cursor 自研模型……用户可以选。这也是一种控制感——工程师喜欢调参，喜欢知道"我用的是哪个模型"，喜欢自己做对比测试。

我测下来，Claude 3.5 Sonnet 在理解复杂架构、生成长代码方面更稳，GPT-4o 在快速小改、解释错误方面更灵。Cursor 自研的 Tab 补全模型则是延迟最低的。组合用比单押一个强。

商业逻辑：为什么这个生意能跑

说实话，我最开始也不信 Cursor 能做成一个大生意。IDE 市场有微软压着，GitHub Copilot 有巨大的分发优势，JetBrains 的插件生态也很强。一个小团队 fork VSCode 能做出什么？

但现在 Cursor 的 ARR 据说已经超过 1 亿美金，估值 25 亿。这个数字让我认真想了一下它的商业逻辑。

定价：对工程师不贵，对公司更不贵

个人版 20/月，商业版 40/月。对于日均使用超过 4 小时的工程师，这个价格几乎是"不用想的"。比一顿外卖贵不了多少，但节省的时间价值完全不在一个量级。

这和 JetBrains 的定价逻辑很不同。JetBrains 的工具是"行业标配，公司买单"，Cursor 瞄准的是"工程师自己掏腰包，然后带进公司"——先占领个人，再通过团队/企业版转化。

护城河：数据飞轮

这才是关键。Cursor 有大量工程师的真实编码行为数据——你接受了什么建议、拒绝了什么建议、在什么上下文里做了什么选择。这些数据可以持续训练更好的模型，形成飞轮。

GitHub Copilot 也有这个优势，但 Copilot 是插件，获取的行为信号有限；Cursor 作为完整 IDE，能观测到更细粒度的行为。

风险：模型商品化

最大的风险是 AI 模型本身正在快速商品化。如果 GPT-5 或者 Claude 4 直接把"写代码"的能力拉到天花板，Cursor 的差异化就纯粹集中在 IDE 集成体验上了。到时候微软完全有能力在 VSCode + Copilot 上发力，用分发优势正面碾压。

Cursor 能不能在那之前把数据飞轮转起来、建立足够深的工程师使用习惯，这个赌注还没到结果的时候。

作为 Android 工程师，我怎么用它

最后说点实际的。我日常怎么把 Cursor 嵌进工作流的：

高频场景：写样板代码

MVI 架构里每新增一个功能，就要写一套 State + Intent + ViewModel + Screen，结构高度相似。这种事让 Cursor 做，我写需求注释，它生成骨架，我再修细节。

// Cursor Composer 指令示例
// 参考 @UserProfileScreen.kt 的结构
// 创建订单详情页：
// - OrderDetailUiState（包含订单号、商品列表、
//   总价、状态）
// - OrderDetailIntent（刷新、取消订单）
// - OrderDetailVM（注入 OrderRepo）
// - OrderDetailScreen（Compose UI）
// 遵循 .cursorrules 规范

高频场景：写单测

这玩意儿坑了我整整半天——刚开始我让它"帮我写这个 ViewModel 的单测"，结果它生成的 MockK 用法全是旧 API，跑起来报错。后来我改成 @file 显式带入一个已有的测试文件作为 example，问题解决了。

// 有效的 Cursor 提问方式
// 参考 @UserProfileVMTest.kt 的写法，
// 为 @OrderDetailVM.kt 写单测，
// 覆盖：
// 1. 加载成功时 uiState 变化
// 2. 加载失败时错误状态
// 3. 取消订单的乐观更新逻辑

不适合的场景

复杂的性能优化、跨层级的架构重构、有隐式业务约束的逻辑——这些我不太依赖 Cursor。它对"结构已知"的代码生成很强，对"需要深度理解业务上下文"的决策就力不从心了。

换句话说，它是很好的"执行加速器"，但还不是"架构决策助手"。

---

我最好奇的是接下来 Cursor 怎么处理"团队协作"这个维度。现在它基本是个人工具，但代码从来不是一个人的事。如果能做到"感知整个团队的代码风格、历史决策、未解决的 issue"，那才算真的进化成了"团队 AI 成员"。

这个方向值得盯着。