Eingehende Analyse des Cursor-Speicher-Systems: eine "konservative" Entwurfsphilosophie

Ein aktueller Überblick über KI-Code-Editoren Cursor In der Entwickler-Community kursiert eine Reverse-Engineering-Analyse der Stichwörter des mnemonischen Systems, die im Detail die Cursor Wie es lernt und sich Benutzerpräferenzen merkt. Indem wir seinen internen Arbeitsmechanismus dekonstruieren, können wir nicht nur einen Einblick in den Design-Einfallsreichtum der besten KI-Tools gewinnen, sondern auch die Kernprinzipien für den Aufbau eines effizienten und zuverlässigen KI-Interaktionssystems herausfinden.

Zusammensetzung des Speichersystems

Cursor des Speichersystems ist architektonisch in zwei Kernmodule unterteilt:Speicherauszugzusammen mitBewertung des Gedächtnisses. Diese Trennung soll sicherstellen, dass die Informationen, die letztlich von der KI übernommen werden, wirklich wertvoll sind.

Speicherauszug

Ziel dieser Phase ist es, aus dem Dialog des Nutzers mit der KI proaktiv die Schlüsselinformationen zu identifizieren und herauszufiltern, die für zukünftige Interaktionen hilfreich sind.

Das Herzstück ist ein klarer Satz von Filterkriterien für groß angelegte Sprachmodelle, die angeben, welche Arten von Erinnerungen extrahiert werden sollen, während mehrdeutige oder fehlerhafte Informationen, die die Effektivität des Dialogs beeinträchtigen könnten, vermieden werden. Zum Beispiel wird das System ausdrücklich aufgefordertNur bestimmte Benutzerpräferenzen werden extrahiert(z. B. Priorisierung des Einsatzes bestimmter Frameworks) und ignorieren einmalige Aufgabendetails, Ad-hoc-Zusammenhänge, unscharfe Darstellungen und allgegenwärtige Software-Engineering-Prinzipien (z. B. DRY, KISS).

Diese Design-Idee verkörpert die klassische Struktur des Stichwort-Engineerings, d.h. durch die 目标 (Target)und要求与限制 (Requirements)und少量样本示例 (Examples) im Gesang antworten 输出格式 (Output) um das Verhalten des Modells genau zu steuern.

Nachstehend finden Sie die übersetzten und geordneten Aufforderungswörter für das Extraktionsmodul:

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

Bewertung des Gedächtnisses

Die im ersten Schritt ausgewählten "Erinnerungskandidaten" werden nicht sofort übernommen, sondern gelangen in das Bewertungsmodul. Die Hauptaufgabe in dieser Phase besteht darin, diese Erinnerungen zu bewerten, um festzustellen, ob sie es wert sind, von der KI dauerhaft gespeichert zu werden.

Die Bewertungskriterien entsprechen denen der Extraktionsphase, sind aber quantitativer. Es wird betont, dass das Gedächtnis sein mussuniversell wiederverwendbarundkonkret einklagbardes Nutzers und repräsentiert dessenGemeinsame Präferenzen oder Regeln.

• Hohe Punktzahl (4-5 Punkte): Spezifische und umsetzbare allgemeine Regeln (z. B. "nicht mehr als 50 Zeilen für Funktionen"), ausdrückliche Wünsche der Benutzer, dass sie nicht vergessen werden, und Äußerungen von Unzufriedenheit oder Korrekturen seitens der Benutzer.
• Niedrig bewertete Punkte (1-3 Punkte): Vage oder offensichtliche Aussagen (z. B. "Benutzer mögen guten Code"), aufgaben- oder codespezifische Details und allgemeines Software-Engineering-Grundwissen.

Es ist erwähnenswert, dass die gesamte BewertungslogikTendenz zur Vergabe niedriger PunktzahlenDies ist eine umsichtige Designphilosophie. Nur Informationen, die klar, spezifisch und von hohem Wert für zukünftige Interaktionen sind, durchlaufen diesen strengen Filter.

Im Folgenden finden Sie die vollständigen Aufforderungen für das Bewertungsmodul:

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

Die Logik hinter dem zweistufigen Prozess

Die Kombination der Extraktions- und Bewertungsaufgaben scheint eine einfachere Option zu sein, aber die Cursor Es gibt tiefergehende Überlegungen bei der getrennten Gestaltung der

Erstens.Die Trennung reduziert die Komplexität einer einzelnen AufgabeGroße Sprachmodelle neigen dazu, bei zusammengesetzten Aufgaben, die eine genaue Unterscheidung von Details erfordern, "den Überblick zu verlieren". Große Sprachmodelle neigen dazu, bei komplexen Aufgaben, die eine genaue Unterscheidung von Details erfordern, "das große Ganze aus den Augen zu verlieren". Wenn das Modell gleichzeitig potenzielle Erinnerungen "durchforsten" und "ihren Wert beurteilen" muss, kann es aufgrund von Ablenkung wichtige Informationen übersehen oder seine Bewertungskriterien lockern. Durch die Aufteilung konzentriert sich jedes Modul auf ein einziges Ziel, und das System als Ganzes ist genauer.

Zweitens.Der Entwurf sieht einen Mechanismus der "doppelten Kontrolle" vor, um die Konsistenz zu verbessern.Das Modell kann eine subjektive "Selbsterkennungs"-Voreingenommenheit haben, wenn es die Informationen bewertet, die es extrahiert. Modelle können eine subjektive "Selbsterkennungs"-Voreingenommenheit haben, wenn sie ihre eigenen extrahierten Informationen bewerten. Indem die Bewertung zu einem separaten Schritt gemacht wird, können die in Frage kommenden Erinnerungen objektiver geprüft werden, wodurch die interne Verzerrung verringert und sichergestellt wird, dass die schließlich beibehaltenen Erinnerungen von höherer Qualität sind und besser mit den vordefinierten Kriterien übereinstimmen.

Aus Sicht der technischen Architektur schließlich bietet der modulare Aufbau mehr Flexibilität, da die Teams die Möglichkeit haben, die verschiedenen Phasen der Aufgabe unabhängig voneinander zu optimieren, zu iterieren und Ressourcen zuzuweisen.

Cursor Durch den umsichtigen Prozess der "Extraktion + Bewertung" baut das Speichersystem eine Firewall aus qualitativ hochwertigen Informationen auf und vermeidet so effektiv die Beeinträchtigung der KI-Leistung durch minderwertige Speicher. Diese äußerst konservative Designphilosophie, die Knappheit dem Überfluss vorzieht, kann dazu führen, dass weniger Informationen aktiv vom System gespeichert werden, aber es ist eine kosteneffiziente Lösung, die KI-Fähigkeit und Zuverlässigkeit unter dem aktuellen Stand der Technik ausbalanciert. Darin zeigt sich ein zentraler Trend: Der Wettbewerb künftiger KI-Tools wird nicht nur in der Obergrenze ihrer Fähigkeiten liegen, sondern auch in der Stabilität und Vertrauenswürdigkeit ihrer Ergebnisse.