看完 Cursor 记忆系统提示词，我收获满满！

前不久看了 https://github.com/x1xhlol/system-prompts-and-models-of-ai-tools 这个项目里逆向解析的 Cursor 记忆系统提示词。从中既能学习到提示词的搭建技巧，又能一窥记忆系统的运作原理，读下来收获满满，值得好好琢磨借鉴。

使用体验

首先我们先直观的体验一下Cursor记忆系统的效果。

可以看到 Cursor 会自动存储记忆点，并支持人工管理。

记忆系统的组成

Cursor 的记忆系统由 记忆提取 和 记忆评估 模块组成。接下来我会描述其中的核心要点，并提供翻译后的完整内容。

记忆提取

核心目的是从用户与助手的对话中主动识别值得记住的信息，生成符合标准的记忆条目。

其中的核心是告诉大模型哪些记忆应该提取，防止错误、模糊的记忆影响对话效果，比如：只提取明确的用户偏好信息（比如：优先用xx框架），避免提取模糊或显而易见且不可操作的偏好（比如： 一次性任务细节、临时上下文、模糊表述、基础软件工程原则（如 DRY、KISS）。

记忆提取 Prompt 由 目标（task｜target）、内容要求&限制(requirements)、少样本案例(example)、输出格式要求(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 分），模糊 / 特定内容评 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之间的整数。 

Q&A

大部分刚接触这一块的小伙伴可能会疑惑为什么不把 提取 + 评估 合并到一起执行呢，效果会有什么区别吗？

拆分步骤的主要的原因如下：

降低任务复杂度，避免 “顾此失彼”

大模型处理任务的能力有限，尤其是在需要精准区分细节的场景中。如果让模型同时完成 “从对话中筛选潜在记忆点” 和 “判断这些记忆点是否符合标准”，可能会导致两种结果：要么提取时遗漏关键信息（因为注意力被评估规则分散），要么评估时标准松动（因为需要先 “凑够” 提取内容）。拆分后，每一步可以专注单一目标，提取阶段只聚焦 “哪些信息可能有价值”，评估阶段只严格对照规则判断 “是否该保留”，精度更高。

减少 “自我干扰”，提升一致性

大模型在复杂任务中容易出现 “自我说服” 偏差：如果自己提取的信息需要自己评估，可能会潜意识里放宽标准（比如对自己提取的内容更宽容），导致评估结果偏向主观。拆分后，相当于引入 “二次校验” 机制，评估阶段可以更客观地用规则审视提取结果，减少这种内生偏差，让最终保留的记忆更符合预设标准，一致性更强。

技术架构更加灵活

可以分别控制两个阶段的资源、模型...，从技术角度来说更加合理。

总结

Cursor 通过 提取 + 评估 的流程搭建记忆系统，有效保障了记忆的高价值。通过严格 筛选规则 排除特殊化、模糊化的低质记忆，避免其干扰大模型的回复质量。

从提示词设计我们可以看出，它的其整体思路 偏保守 ，评分逻辑中低分概率远高于高分，实际使用时被保留的记忆数量较少（当然这是一个高性价比的做法）。若能在现有严格标准基础上，进一步精准捕捉不同场景的非通用偏好或规则，那对用户将会更有价值。