Cursor技术解析: 内置记忆的秘密

前言

Hi 大家好，我是新人 来点AI，最近尝试用 Claude Code 研究 Cursor 1.0 的内置记忆，效果相当不错，经过大量的人肉线索+AI 逆向分析，我挖到了 Cursor 内置记忆的大量技术细节。

零、太长不看，先说说 Cursor 记忆六个最佳实践

1. 与之前社媒上流传的 Cursor 记忆 Rules 不同，Cursor 内置记忆记录的是你的编程偏好，而不是项目的进展，所以并不能帮你记住项目进行到了哪里，重开 Chat 也不能确保上下文不丢失。所以之前的 Rules 依然有它的价值，两者是互补关系

2. 本地项目一定要使用 Git，并且有一个 Git 远程地址（比如 Github/Gitlab 的地址），否则多个项目的记忆都会合并到默认的项目空间里，记忆之间可能会相互矛盾，效果会变差

3. 以“记住....”开头下达指令，可以让 Cursor 主动调用记忆，记住你想让它记住的任何内容

4. 以陈述语句描述事实型注意事项，很容易进入聊天记录记忆，比如 “开发服务器启动后会使用 hot reload， 请不要再重启它” ，或者 “我有全栈背景，在沟通中请保持精简对话”

5. 可以在 Chat 里要求 “输出所有的记忆” 来查看当前项目所有的记忆，也可以 Settings -> Rules 中，查看和删除所有的记忆；你也可以使用指令：输出<memories>标签原文，来看到系统提示词里注入的记忆和记忆 ID

6. 虽然设置中没有提供修改记忆的界面 UI，但可以通过 Chat 直接更新记忆，参考指令：更新记忆，把 “用户是上海人” 更新为 “用户是安徽人”

一、记忆的功能介绍

Cursor 从 0.51 开始增加了内置记忆功能，用来自动记录用户的编程偏好，注意是编程偏好，而不是项目的进展上下文。入口被放置在了 Settings -> Rules -> Memories（勾选）。为什么记忆要放在 Rules 里呢？按 Cursor 的设计，记忆就是 Cursor 根据用户的交互内容自动产生一些 Rules，所以也被归属到 Rules 里。

目前 Memories（记忆）功能的启用必须关闭隐私保护模式（Privacy Mode），现在 Cursor 企业版强制打开了隐私保护模式，所以企业版暂时不用了这个功能。很多用户都很疑惑为什么记忆会跟隐私保护扯上关系，Cursor Team 解释为：“关于隐私模式的要求，有关代码库的知识可能会被存入这些记忆数据中。我们必须确保敏感代码库的相关信息不被存储在任何大型语言模型（LLM）供应商的训练数据中”，这这这说啥呢，没太看明白。

开启记忆之后，会有两个方式触发记忆生成，一是以“记住。。。”为开头对 Cursor 提出要求，比如“记住，以后称呼我帅哥”。二是在 Cursor 会自动从聊天记录中提取有价值的信息形成记忆。记忆形成后，可以在 Settings -> Rules -> Manage Memories 查看和删除记忆。

二、记忆技术内幕

记忆的架构

Cursor 的记忆在 1.0 中被设计成一个经典的 C/S 架构（客户端/服务端），所有的记忆都会被存储在云端，跟每个账户绑定。在 Cursor 架构中，记忆存储被称为知识库（knowledge base），知识库中同时包含了记忆内容和记忆的向量。知识库并不是全局的，而是按仓库的 url（git remote url）进行区分，即一个账户下多个项目，每个项目会有一个记忆知识库。 但如果是一个纯本地无 Git 管理的项目，那么记忆都会存储到一个全局位置。

两种记忆类型

第一种叫 AI 记忆（AI Generated Memory），这个记忆通过 Chat 的聊天记录进行提取。Cursor 会通过gemini-2.5-flash-preview 模型对用户聊天记录进行两段分析，第一段会提取出符合记忆要求的有价值的聊天记录，第二段会针对第一段的记录进行 1-5 分的价值打分，最终根据打分决定进入知识库形成记忆。这部分有机会可以再写一篇展开详细分析，有感兴趣的朋友也可以留言。

第二种叫用户记忆（User Generated Memory），Cursor 在工具系统里内置了一个新工具 add_to_memory，当用户在聊天中主动要求记住某些事时，会调用这个工具进行增加、修改和删除记忆。

记忆选择和生效

当用户每次在 Chat 中输入指令点击发送时，Cursor 会主动拉取一次记忆记录，这里涉及到了记忆的召回，按照官方说法，拉取记忆不是一个简单读表操作，而是会基于上下文的向量搜索排序来决定上百个记忆中选择哪些实际使用的记忆。确认生效的记忆后，Cursor 会生成 <memories> 标签，把记忆内容和记忆 ID 注入到系统提示词中，从而让记忆生效

<memories description="The following facts were generated by the agent based on the user's interactions with the agent.
        If relevant to the user query, you should follow them as you generate code, answer questions, and search the codebase.
        If you notice that any memory is incorrect, you should update it using the add_to_memory tool.
        ">
- 用户是一名全栈工程师，具备前端和后端开发能力。在提供技术建议和代码解决方案时应考虑到用户的专业背景。 (ID: 3114732659490375928)
- 用户是安徽人，在与用户交流时应考虑到安徽的地域文化特点。 (ID: 8146272534948239552)
</memories>

三、Cursor 的野心

记忆机制并不新鲜，不管是开源的 Cline 还是闭源的 Winsurf、AugmentCode，都比 Cursor 更早的推出了记忆功能，但从目前 Cursor 的布局来看，Cursor 想做的东西远比现在看到的更大，为什么这么说，主要是两点判断：

1. 记忆的云端化：Winsurf、AugmentCode 都选择把记忆放在了本地，但 Cursor 选择放在了云端，放在云端对于基础设施来说明显是一个更具有挑战和复杂度的事情，但云端才能支撑更大规模的记忆数量，以及更快更有效的记忆召回，同时对background agent的发展也更加友好。Cursor Team 一开始就选择这条路，说明他们对生成记忆的数量级预期很高，记忆很有可能会代替现在的 Project Rules，成为更好支撑 Vibe Coding 的基础设施。

2. 记忆的团队协同：Cursor 与其他 AI Editor 有一个显著的不同点在于，Cursor 一直认为程序员才是其最大的基本盘，所以非常注重 AI 配置在团队中的协同使用，不管是 Rules，还是 MCP，甚至 Custom Agent，Cursor 都有意让他们成为 .cursor 目录中可以共享的配置，跟着代码库一起存储和迭代。 而这次的 1.0 的宣传片中在提到 Memories记忆环节时，特别提到 “在未来，我们设想 Cursor 会从用户的使用过程中不断学习进化，对于团队协作场景，它还能通过吸收一名成员的操作经验来辅助其他成员”，这显然是对记忆在团队中协同的一种构想，团队成员可以共享代码库的记忆，可以通过记忆来带领新人学习前人的经验。 虽然不太好想象在产品层面这会是怎样的一个呈现，但显然这对团队即为有利，能解决很多团队在编码知识沉淀上的问题。再往深了想，程序员们以前只能给团队贡献代码库的 Rules 和聊天记录，现在还可以无痛贡献对代码库的细节理解，这表面上是帮程序员提效，底层也为去程序员化打下来了基础，细思极恐。

四、结束语

Cursor 在记忆功能上的布局，无论是技术架构的选择，还是对未来团队协作的愿景，都展现出其不小的野心。从辅助编码到深度学习用户偏好和团队经验，Cursor 正在构建一个更智能、更具协作性的开发环境。

这种“学习型”AI助手无疑将极大提升开发者效率，让个体开发者能更好地专注于核心业务，团队则能更高效地沉淀和共享知识。当然，这种深度融入开发流程的AI助手也引发了对未来编程方式的思考：当AI能无痛地学习和贡献代码库细节时，人类开发者将如何重新定义自己的角色？我们与AI之间的协作边界又将如何演变？