一句话定位：编辑器不再只是「写代码的地方」，而是你和一个能读懂整个仓库的助手协作的地方。

这是「一天一款产品」系列的第一篇。今天讲 Cursor。

过去两年，几乎每个 AI 编程工具都在解决同一个问题：怎么让模型更好地写代码。Cursor 的选择不是再做一个聊天框，而是把 AI 拆进编辑器的每一个动作里——补全、选中、重构、提问、跑测试——让 AI 成为编辑过程的一部分，而不是一个需要你切换窗口的「外部工具」。

这篇能回答什么

前置知识：用过 VS Code 或其他 IDE，了解基本的「打开文件 → 编辑 → 调试」流程；知道 AI 编程工具大致分哪几类（补全插件 / 对话侧边栏 / Agent）。

它解决什么问题

在 Cursor 之前，用 AI 写代码的典型流程是这样的：

问题不在于模型不够聪明，而在于上下文搬运全靠人。你要让模型理解一个函数，得复制那个函数；要让它改一处 bug，得贴出错误上下文和调用方。粘贴过程中丢掉的往往是关键信息——这个函数被谁调用、这个配置项在哪些地方被读过。

Cursor 把这三个窗口合成一个：

它的核心赌注是最后一个。 前面三个功能，任何一个 AI 插件都能做；把「Agent 能在真实仓库里连续工作」做成日常体验，才是需要重做编辑器架构的部分。

装完之后，前十分钟建议这么用：

关键路径是：先让它读，再让它写。 跳过读这一步直接派任务，是多数「AI 改坏了代码」事故的来源——它没看到你没告诉它的约束，就自己补了一个看起来合理的。

Cursor 是 VS Code 的 fork，扩展生态、设置面板、主题、调试配置、快捷键、文件浏览全部继承。

这看起来像保守的选择，实际是产品上的关键决断：

代价是包袱：fork 意味着要跟着上游版本升级，冲突解决是持续的维护成本；VS Code 的一些设计假设（比如插件沙箱模型）对 AI 代理的权限需求也不完全契合。

大模型有上下文窗口，但窗口里放什么、放多少，是产品的核心决策。

Cursor 的做法是多层上下文：

第四层是关键。它把「这个概念在仓库里还出现在哪」变成可检索的问题。Agent 改一个配置项时，能顺着索引找到所有引用点，而不是只改你给它看的那一处。

这也解释了为什么 Cursor 的体验不依赖单一模型的补全质量——当模型能力相当时，喂给模型的上下文质量才是拉开差距的地方。

Agent 会跑命令、会改文件、会装依赖。对一个每天在生产仓库里工作的人，这部分的风险设计比模型能力更重要。

Cursor 的取向是：默认给出可见的中间状态。Agent 的每一步都留下可回滚的痕迹，改文件走 diff 接受，跑命令在终端里可见，失败时把错误塞回上下文让它自己纠偏。

这跟「一个黑盒按钮，点了等结果」的产品思路相反，但后者在真实仓库里几乎不可用。

它真正改变的不是「代码怎么写出来」，而是「你什么时候需要离开编辑器」。