カーソル・メモリー・システムの徹底分析：「保守的」な設計思想

AIコード・エディタの最新レビュー Cursor ニモニック・システムのキュー・ワードのリバース・エンジニアリング分析が開発者コミュニティに出回っており、その詳細が明らかになっている。 Cursor どのようにユーザーの好みを学習し、記憶するのか。その内部動作メカニズムを分解することで、トップAIツールの設計上の工夫を垣間見ることができるだけでなく、効率的で信頼性の高いAIインタラクション・システムを構築するための核となる原則を抽出することができる。

メモリーシステムの構成

Cursor メモリシステムは、アーキテクチャ上、2つのコアモジュールに分かれている：メモリ抽出とともに記憶力評価.この分離は、最終的に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之间的整数。

2段階のプロセスを支える設計ロジック

抽出タスクと評価タスクを組み合わせることは、より簡単なオプションのように思えるが Cursor の分離設計には、より深い配慮が必要だ。

まず第一に。分離することで、1つのタスクの複雑さが軽減される大規模な言語モデルは、細部の正確な区別を必要とする複合的なタスクを扱うとき、「的外れ」になりやすい。大規模な言語モデルは、細部の正確な区別を必要とする複合タスクを扱うとき、「全体像を見失う」傾向がある。モデルが「潜在的な記憶のふるい分け」と「その価値の判断」を同時に行う必要がある場合、気が散って重要な情報を見逃したり、評価時の基準が緩んだりする可能性がある。分割することで、各モジュールは単一の目標に集中し、システム全体としての精度が高まる。

第二に。一貫性を高めるために「ダブルチェック」機構を導入している。モデルは、抽出した情報を評価する際に主観的な「自己認識」バイアスを持つ可能性がある。モデルは、自身が抽出した情報を評価する際に、主観的な「自己認識」バイアスを持つ可能性がある。評価を別のステップにすることで、候補となる記憶をより客観的に調べることができ、内部バイアスを減らし、最終的に保持される記憶がより質の高い、あらかじめ定義された基準に沿ったものになるようにすることができる。

最後に、技術的なアーキテクチャの観点からは、モジュラー設計は、チームがタスクの異なるフェーズで独立して最適化し、反復し、リソースを割り当てることを可能にし、より大きな柔軟性を提供する。

Cursor 抽出＋評価」という慎重なプロセスを経て、AIシステムの記憶システムは高品質の情報ファイアウォールを構築し、価値の低い記憶がAIの性能に干渉するのを効果的に回避する。豊富さよりも希少さを好むこの非常に保守的な設計思想は、システムによって能動的に記憶される情報が少なくなる可能性があるが、現状ではAIの能力と信頼性を両立させる費用対効果の高い解決策である。将来のAIツールの競争は、その能力の上限だけでなく、出力の安定性と信頼性にも及ぶということだ。