深度解析 Cursor 记忆系统：一种“保守”的设计哲学

最近，一份对 AI 代码编辑器 Cursor 记忆系统提示词的逆向工程分析在开发者社区流传，它详细揭示了 Cursor 是如何学习并记住用户偏好的。通过解构其内部工作机制，我们不仅能窥见顶尖 AI 工具在设计上的巧思，还能从中提炼出搭建高效、可靠AI交互系统的核心原则。

记忆系统的构成

Cursor 的记忆系统在架构上分为两个核心模块：记忆提取与记忆评估。这种分离式设计旨在确保最终被AI采纳的信息是真正有价值的。

记忆提取

此阶段的目标是从用户与AI的对话中，主动识别并筛选出那些对未来交互有帮助的关键信息。

其核心在于为大型语言模型设定一套清晰的筛选标准，明确指出应提取哪些类型的记忆，同时规避那些可能干扰对话效果的模糊或错误信息。例如，系统被明确要求只提取具体的用户偏好（如：优先使用特定框架），并忽略一次性任务细节、临时上下文、模糊表述以及普适性的软件工程原则（如DRY、KISS）。

这种设计思路体现了经典的提示词工程结构，即通过 目标 (Target)、要求与限制 (Requirements)、少量样本示例 (Examples) 和 输出格式 (Output) 来精确引导模型的行为。

以下是经过翻译和整理的提取模块提示词：

<目标>
给定一段用户与助手的对话，你需要确定哪些信息可能对未来的对话有帮助，值得记住。
</目标>
<正面标准>
值得记住的信息应包括：
- 用户工作方式的高层级偏好（必须具体且可操作）
- 用户偏爱的通用模式或方法（必须包含明确指导）
- 具体的技术偏好（例如，确切的编码风格规则、框架选择）
- 需要避免的常见痛点或用户不满点（必须足够具体以便采取行动）
- 工作流程偏好或要求（必须包含具体步骤或规则）
- 用户请求中的任何重复主题（必须足够具体以指导未来回应）
- 用户明确要求记住的任何内容
- 用户表达的任何强烈观点（必须足够具体以便采取行动）
</正面标准>
<负面标准>
不应包含以下内容：
- 无法通用化的一次性任务细节
- 不会重复使用的实现细节
- 未来不再相关的临时上下文
- 纯粹来自助手对话而非用户对话的信息
- 仅适用于当前对话中讨论的特定文件、函数或代码片段且不具有广泛适用性的信息
- 模糊或显而易见且不可操作的偏好
- 任何用户都会期望的关于良好编程实践的一般性陈述
- 基本的软件工程原则，如关注点分离、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"
</格式说明>

记忆评估

通过第一步筛选出的“候选记忆”并不会被立即采纳，而是会进入评估模块。此阶段的核心任务是对这些记忆点进行打分，以最终判断其是否值得被AI永久记住。

评估标准与提取阶段一脉相承，但更加量化。它强调记忆必须是通用可复用、具体可操作的，并代表用户的通用偏好或规则。

• 高分项（4-5分）： 具体且可操作的通用规则（如“函数不超过50行”）、用户明确要求记住的内容、用户表达的不满或纠正。
• 低分项（1-3分）： 模糊或显而易见的表述（如“用户喜欢好代码”）、特定于任务或代码的细节、基础软件工程常识。

值得注意的是，整个评分逻辑倾向于给予低分，这是一种审慎的设计哲学。只有那些明确、具体且对未来交互有高价值的信息才能通过这层严格的过滤。

以下是评估模块的完整提示词：

你是一名知识极其渊博的软件工程师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之间的整数。

两步式流程背后的设计逻辑

将提取与评估任务合并处理，似乎是更直接的选择，但 Cursor 的分离式设计有其深层考量。

首先，分离可以降低单一任务的复杂度。大型语言模型在处理需要精准区分细节的复合任务时，容易出现“顾此失彼”的现象。如果模型需要同时“筛选潜在记忆”并“判断其价值”，可能会因注意力分散而遗漏关键信息，或在评估时放宽标准。拆分后，每个模块专注于单一目标，系统整体的精确度更高。

其次，该设计引入了“二次校验”机制，以提升一致性。模型在评估自己提取的信息时，可能存在主观上的“自我认可”偏差。而将评估作为独立步骤，能够更客观地审视候选记忆，减少内部偏差，确保最终保留的记忆质量更高、更符合预设标准。

最后，从技术架构角度看，模块化设计提供了更高的灵活性，允许团队针对不同阶段的任务进行独立的优化、迭代和资源分配。

Cursor 的记忆系统通过“提取+评估”的审慎流程，构建了一道高质量的信息防火墙，有效避免了低价值记忆对AI性能的干扰。这种高度保守、宁缺毋滥的设计哲学，虽然可能导致被系统主动记住的信息偏少，但却是在当前技术水平下，平衡AI能力与可靠性的高性价比方案。它揭示了一个核心趋势：未来AI工具的竞争，将不仅在于其能力的上限，更在于其输出的稳定性和可信赖度。