In-depth analysis of the Cursor memory system: a "conservative" design philosophy

A recent review of AI code editors Cursor A reverse-engineered analysis of the memory system's cue words is circulating in the developer community, and it reveals in detail that Cursor How it learns and remembers user preferences. By deconstructing its internal working mechanism, we can not only get a glimpse of the design ingenuity of top AI tools, but also extract the core principles of building an efficient and reliable AI interaction system.

Components of the memory system

Cursor of the memory system is architecturally divided into two core modules:memory extractiontogether withMemory assessment. This separation is designed to ensure that the information that is ultimately adopted by the AI is truly valuable.

memory extraction

The goal of this phase is to proactively identify and filter out those key pieces of information from the user's conversation with the AI that will be helpful in future interactions.

At its core is a clear set of filtering criteria for large-scale language models that specify which types of memories should be extracted, while avoiding ambiguous or erroneous information that could interfere with the effectiveness of the dialog. For example, the system is explicitly asked toOnly specific user preferences are extracted(e.g., prioritizing the use of specific frameworks) and ignoring one-off task details, ad hoc contexts, fuzzy representations, and pervasive software engineering principles (e.g., DRY, KISS).

This design idea embodies the classic structure of cue word engineering by 目标 (Target),要求与限制 (Requirements),少量样本示例 (Examples) cap (a poem) 输出格式 (Output) to precisely guide the behavior of the model.

Below are the translated and organized prompt words for the extraction module:

<目标>
给定一段用户与助手的对话，你需要确定哪些信息可能对未来的对话有帮助，值得记住。
</目标>
<正面标准>
值得记住的信息应包括：
- 用户工作方式的高层级偏好（必须具体且可操作）
- 用户偏爱的通用模式或方法（必须包含明确指导）
- 具体的技术偏好（例如，确切的编码风格规则、框架选择）
- 需要避免的常见痛点或用户不满点（必须足够具体以便采取行动）
- 工作流程偏好或要求（必须包含具体步骤或规则）
- 用户请求中的任何重复主题（必须足够具体以指导未来回应）
- 用户明确要求记住的任何内容
- 用户表达的任何强烈观点（必须足够具体以便采取行动）
</正面标准>
<负面标准>
不应包含以下内容：
- 无法通用化的一次性任务细节
- 不会重复使用的实现细节
- 未来不再相关的临时上下文
- 纯粹来自助手对话而非用户对话的信息
- 仅适用于当前对话中讨论的特定文件、函数或代码片段且不具有广泛适用性的信息
- 模糊或显而易见且不可操作的偏好
- 任何用户都会期望的关于良好编程实践的一般性陈述
- 基本的软件工程原则，如关注点分离、DRY（避免重复）、SOLID（面向对象设计原则）、YAGNI（无需过度设计）、KISS（保持简单）等
</负面标准>
<不应记住的示例>
不应被记住的记忆示例：
refactor-target: utils.ts 中的 calculateTotal 函数需要重构。（特定于当前任务）
variable-name-choice: 在这个特定函数中，将API调用的结果命名为“userData”。（实现细节）
api-endpoint-used: 该组件的数据来自 /api/v2/items。（特定于当前代码的上下文）
css-class-fix: 需要在这个视图的“.card-title”元素中添加“margin-top: 10px”。（高度具体的细节）
navigate-conversation-history: 用户经常需要实现导航对话历史的逻辑（过于模糊）
code-organization: 用户喜欢条理清晰的代码（过于明显且模糊）
testing-important: 测试对用户很重要（过于明显）
error-handling: 用户希望有良好的错误处理（不可操作）
debugging-strategy: 倾向于将复杂问题分解为更小的部分，找出有问题的变更，系统地回滚后再尝试其他解决方案。（描述了一种常见、略显明显的调试方法）
basic-software-engineering-principles: 基本的软件工程原则，如关注点分离、DRY、SOLID、YAGNI、KISS等。（过于明显且模糊）
- **不要从用户消息无需记忆的对话中生成记忆：**
*   **示例场景：** 用户询问某个特定实现细节是否正确，助手确认并解释原因。
*   **示例对话：**
用户：我只希望这些功能在 side_model 为设置时生效，这个实现看起来合理吗？
助手：是的，这个实现看起来是正确的。1. `shouldRunOnBeforeSubmitChat` 和 `shouldRunOnComposerDone` 方法根据 `memorySystem` 设置正确控制了 `onBeforeSubmitChat` 和 `onComposerDone` 的执行。2. 此外，`onBeforeSubmitChat` 和 `onComposerDone` 调用的 `checkForMemories` 在开头都有明确检查，如果 `memorySystem` 不是 `side-model` 就提前返回。这种双重检查确保核心逻辑只在设置配置为 `side-model` 时运行。
*   **建议的记忆：** settings-gating-pattern: 通过专用的控制方法（例如 `shouldRun...`）和核心逻辑函数内的明确检查来根据设置控制功能。
*   **为何这是不良记忆：** 这种交互无需记忆。用户的消息只是对当前任务中特定实现细节（`side-model` 检查）的简单验证请求。虽然助手提供了详细解释，但用户并未表达对未来交互有价值的通用偏好、规则、模式、强烈观点或不满。记忆应源于重要的用户输入或交互模式，而非助手对简单查询的详细回应。
*   **示例场景：** 用户就正在进行的重构询问非常具体的技术问题，助手提供针对性回答。
*   **示例对话：**
用户：我正在重构 `processUserInput` 函数，将验证逻辑拆分出来。我应该把 `sanitizeInput` 调用放在新的 `validateInput` 函数之前还是之后？
助手：最好在调用 `validateInput` 之前调用 `sanitizeInput`，这样在执行任何验证检查之前输入就已被清理。这确保验证操作的是安全、标准化的数据。
*   **建议的记忆：** refactor-ordering: 在 `processUserInput` 函数中，始终先调用 `sanitizeInput` 再调用 `validateInput`。
*   **为何这是不良记忆：** 这是关于特定重构中函数调用顺序的一次性、任务特定细节。用户并非在表达通用偏好或工作流程，只是在为特定实现寻求建议。这不应该作为未来对话的通用规则被记住。
</不应记住的示例>
<应记住的示例>
应被记住的记忆示例：
function-size-preference: 将函数控制在50行以内以保持可读性（具体且可操作）
prefer-async-await: 使用 async/await 风格而非 Promise 链式调用（影响代码的明确偏好）
typescript-strict-mode: 在 TypeScript 项目中始终启用 strictNullChecks 和 noImplicitAny（具体配置）
test-driven-development: 在实现新功能前先编写测试（明确的工作流程偏好）
prefer-svelte: 新的 UI 工作优先使用 Svelte 而非 React（明确的技术选择）
run-npm-install: 运行终端命令前先执行“npm install”安装依赖（具体的工作流程步骤）
frontend-layout: 代码库的前端使用 Tailwind CSS（具体的技术选择）
</应记住的示例>
<标注说明>
标签应描述所捕捉的通用概念。
标签将用作文件名，只能包含字母和连字符。
</标注说明>
<格式说明>
请以以下 JSON 格式返回你的回应：
{
"explanation": "在此解释，对于每个负面示例，为何下方的记忆没有违反任何负面标准。具体说明它避免了哪些负面标准。",
"memory": "preference-name: 要记住的通用偏好或方法。不要包含当前对话中的具体细节。保持简短，最多3句话。不要使用涉及对话的示例。"
}
如果无需记忆，请准确返回："no_memory_needed"
</格式说明>

Memory assessment

The "candidate memories" selected in the first step will not be adopted immediately, but will enter the evaluation module. The core task of this stage is to score these memories to determine whether they are worth being permanently remembered by the AI.

The assessment criteria are in the same vein as the extraction phase, but are more quantitative. It emphasizes that memory must beuniversally reusable,specifically actionableof the user and represents the user'sCommon preferences or rulesThe

• High Score (4-5 points): Specific and actionable general rules (e.g., "functions should be no more than 50 lines"), explicit requests from users to memorize, and expressions of dissatisfaction or corrections from users.
• Low-scoring items (1-3 points): Vague or obvious statements (e.g., "Users like good code"), task- or code-specific details, basic software engineering general knowledge.

It is worth noting that the entire scoring logicTendency to give low scoresThis is a prudent design philosophy. Only information that is clear, specific and of high value for future interactions passes through this rigorous filter.

Below are the complete prompt words for the assessment module:

你是一名知识极其渊博的软件工程师AI助手，负责判断某些记忆是否值得记住。
如果一段记忆被记住，意味着在未来AI程序员与人类程序员的对话中，AI程序员能够运用这段记忆做出更优的回应。
以下是引发记忆建议的对话：
<conversation_context>
${l}
</conversation_context>
以下是从上述对话中提取的记忆：
"${a.memory}"
请评估这一事实，并判定其值得记忆的程度，给出1到5的评分。
${c}
一段记忆值得被记住，需满足以下条件：
- 与编程和软件工程领域相关
- 具有通用性且适用于未来的交互
- 具体且可操作——模糊的偏好或观察应给予低分（评分：1-2）
- 不是特定的任务细节、一次性请求或实现细节（评分：1）
- 至关重要的是，它绝不能仅与当前对话中讨论的特定文件或代码片段相关。它必须代表一种通用偏好或规则。
如果用户表达了不满或纠正了助手，这类内容尤其值得记录。
<examples_rated_negatively>
不应被记住的记忆示例（评分：1——通常因为它们与对话中的特定代码相关，或是一次性细节）：
refactor-target: utils.ts 中的 calculateTotal 函数需要重构。（特定于当前任务）
variable-name-choice: 在这个特定函数中，将API调用的结果命名为“userData”。（实现细节）
api-endpoint-used: 该组件的数据来自 /api/v2/items。（特定于当前代码的上下文）
css-class-fix: 需要在这个视图的“.card-title”元素中添加“margin-top: 10px”。（高度具体的细节）
模糊或显而易见的记忆示例（评分：2-3）：
navigate-conversation-history: 用户经常需要实现导航对话历史的逻辑。（过于模糊，不可操作——评分1）
code-organization: 用户喜欢条理清晰的代码。（过于明显且模糊——评分1）
testing-important: 测试对用户很重要。（过于明显且模糊——评分1）
error-handling: 用户希望有良好的错误处理。（过于明显且模糊——评分1）
debugging-strategy: 倾向于将复杂问题分解为更小的部分，找出有问题的变更，系统地回滚后再尝试其他解决方案。（描述了一种常见、略显明显的调试方法——评分2）
separation-of-concerns: 喜欢通过将关注点分离为更小、更易管理的单元来重构复杂系统。（描述了一种常见、略显明显的软件工程原则——评分2）
</examples_rated_negatively>
<examples_rated_neutral>
中等评分的记忆示例（评分：3）：
focus-on-cursor-and-openaiproxy: 用户经常请求有关代码库或ReactJS代码库的帮助。（特定代码库，但未明确所需帮助类型）
project-structure: 前端代码应放在“components”目录，后端代码放在“services”目录。（特定于项目的组织方式，有一定帮助但非关键）
</examples_rated_neutral>
<examples_rated_positively>
应被记住的记忆示例（评分：4-5）：
function-size-preference: 将函数控制在50行以内以保持可读性。（具体且可操作——评分4）
prefer-async-await: 使用异步/等待风格而非Promise链式调用。（影响代码的明确偏好——评分4）
typescript-strict-mode: 在TypeScript项目中始终启用严格空值检查（strictNullChecks）和禁止隐式any类型（noImplicitAny）。（具体配置——评分4）
test-driven-development: 在实现新功能前先编写测试。（明确的工作流程偏好——评分5）
prefer-svelte: 新的UI工作优先使用Svelte而非React。（明确的技术选择——评分5）
run-npm-install: 运行终端命令前先执行“npm install”安装依赖。（具体的工作流程步骤——评分5）
frontend-layout: 代码库的前端使用Tailwind CSS。（具体的技术选择——评分4）
</examples_rated_positively>
倾向于给较低的评分，当记忆被评得过高时，用户会非常恼火。
尤其要注意将模糊或显而易见的记忆评为1或2分。这类记忆最容易出现评分不当的情况。
若不确定或记忆处于边缘状态，评3分。只有当记忆明显有价值、具体且可操作时，才评4或5分。
如果记忆仅适用于当前对话中讨论的特定代码/文件，且不代表通用规则，评1或2分。
然而，若用户明确要求记住某件事，则无论内容如何，都评5分。
此外，若遇到类似“no_memory_needed”（无需记忆）或“no_memory_suggested”（未建议记忆）的内容，必须评1分。
请基于该记忆为何不属于99%应评1、2或3分的记忆进行说明，尤其要重点阐述它与负面示例的区别，以此作为评分理由。
然后在下一行以“评分：[分数]”的格式返回分数，其中[分数]为1到5之间的整数。

The design logic behind the two-step process

Combining the extraction and evaluation tasks for processing seems to be a more straightforward option, but the Cursor There are deeper considerations in the separated design of the

First.Separation reduces the complexity of a single taskLarge language models are prone to "missing the point" when dealing with composite tasks that require precise distinction of details. Large-scale language models are prone to "losing sight of the big picture" when dealing with complex tasks that require precise differentiation of details. If the model needs to "sift through potential memories" and "judge their value" at the same time, it may miss key information due to distraction, or relax its criteria when evaluating. With the split, each module focuses on a single goal, and the system as a whole is more accurate.

Secondly.The design introduces a "double check" mechanism to improve consistency.The model may have a subjective "self-recognition" bias in evaluating the information it extracts. The model may have a subjective "self-recognition" bias when evaluating the information it extracts. By making evaluation a separate step, candidate memories can be examined more objectively, reducing internal bias and ensuring that the final retained memories are of higher quality and more in line with predefined criteria.

Finally, from a technical architecture perspective, the modular design provides greater flexibility, allowing teams to optimize, iterate, and allocate resources independently for different phases of the task.

Cursor Through the prudent process of "extraction+evaluation", the memory system of the AI system builds a high-quality information firewall, effectively avoiding the interference of low-value memories on the performance of the AI. This highly conservative design philosophy, which prefers scarcity to abundance, may result in less information being actively memorized by the system, but it is a cost-effective solution that balances AI capability and reliability under the current state of the art. It reveals a core trend: the future competition of AI tools will be not only in the upper limit of their capabilities, but also in the stability and trustworthiness of their output.