Uma análise recente dos editores de código de IA Cursor
Uma análise de engenharia reversa das palavras-chave do sistema mnemônico está circulando na comunidade de desenvolvedores, revelando em detalhes o Cursor
Como ele aprende e lembra as preferências do usuário. Ao desconstruir seu mecanismo interno de funcionamento, podemos não apenas vislumbrar a engenhosidade do design das principais ferramentas de IA, mas também extrair os princípios fundamentais da criação de um sistema de interação de IA eficiente e confiável.
Composição do sistema de memória
Cursor
do sistema de memória é arquitetonicamente dividido em dois módulos principais:extração de memóriajunto comAvaliação da memória. Essa separação foi projetada para garantir que as informações que são adotadas pela IA sejam realmente valiosas.
extração de memória
O objetivo dessa fase é identificar e filtrar proativamente as principais informações do diálogo do usuário com a IA que serão úteis em interações futuras.
Em sua essência, há um conjunto claro de critérios de filtragem para modelos de linguagem em larga escala que especificam quais tipos de memórias devem ser extraídos, evitando informações ambíguas ou errôneas que possam interferir na eficácia do diálogo. Por exemplo, o sistema é explicitamente solicitado aSomente as preferências específicas do usuário são extraídas(por exemplo, priorizar o uso de estruturas específicas) e ignorar detalhes de tarefas pontuais, contextos ad hoc, representações difusas e princípios abrangentes de engenharia de software (por exemplo, DRY, KISS).
Essa ideia de design incorpora a estrutura clássica da engenharia de palavras-chave, ou seja, por meio da 目标 (Target)
e要求与限制 (Requirements)
e少量样本示例 (Examples)
responder cantando 输出格式 (Output)
para orientar com precisão o comportamento do modelo.
Abaixo estão as palavras do prompt traduzidas e organizadas para o módulo de extração:
<目标>
给定一段用户与助手的对话,你需要确定哪些信息可能对未来的对话有帮助,值得记住。
</目标>
<正面标准>
值得记住的信息应包括:
- 用户工作方式的高层级偏好(必须具体且可操作)
- 用户偏爱的通用模式或方法(必须包含明确指导)
- 具体的技术偏好(例如,确切的编码风格规则、框架选择)
- 需要避免的常见痛点或用户不满点(必须足够具体以便采取行动)
- 工作流程偏好或要求(必须包含具体步骤或规则)
- 用户请求中的任何重复主题(必须足够具体以指导未来回应)
- 用户明确要求记住的任何内容
- 用户表达的任何强烈观点(必须足够具体以便采取行动)
</正面标准>
<负面标准>
不应包含以下内容:
- 无法通用化的一次性任务细节
- 不会重复使用的实现细节
- 未来不再相关的临时上下文
- 纯粹来自助手对话而非用户对话的信息
- 仅适用于当前对话中讨论的特定文件、函数或代码片段且不具有广泛适用性的信息
- 模糊或显而易见且不可操作的偏好
- 任何用户都会期望的关于良好编程实践的一般性陈述
- 基本的软件工程原则,如关注点分离、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"
</格式说明>
Avaliação da memória
As "memórias candidatas" selecionadas na primeira etapa não serão adotadas imediatamente, mas entrarão no módulo de avaliação. A principal tarefa dessa fase é classificar essas memórias para determinar se vale a pena que a IA as lembre permanentemente.
Os critérios de avaliação seguem a mesma linha da fase de extração, mas são mais quantitativos. Ele enfatiza que a memória deve seruniversalmente reutilizáveleespecificamente acionáveisdo usuário e representa oPreferências ou regras comuns.
- Pontuação máxima (4-5 pontos): Regras gerais específicas e acionáveis (por exemplo, "não mais do que 50 linhas para funções"), solicitações explícitas dos usuários para serem lembradas e expressões de insatisfação ou correções pelos usuários.
- Itens de baixa pontuação (1-3 pontos): Declarações vagas ou óbvias (por exemplo, "os usuários gostam de código bom"), detalhes específicos da tarefa ou do código e conhecimento geral básico de engenharia de software.
Vale a pena observar que toda a lógica de pontuaçãoTendência a dar notas baixasEssa é uma filosofia de design prudente. Somente informações claras, específicas e de alto valor para interações futuras passam por esse filtro rigoroso.
Abaixo estão as palavras completas do prompt para o módulo de avaliação:
你是一名知识极其渊博的软件工程师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之间的整数。
A lógica de design por trás do processo de duas etapas
A combinação das tarefas de extração e avaliação parece ser uma opção mais direta, mas o Cursor
Há considerações mais profundas no design separado do
Em primeiro lugar.A separação reduz a complexidade de uma única tarefaModelos de linguagem grandes são propensos a "perder o foco" ao lidar com tarefas compostas que exigem distinção precisa de detalhes. Modelos de linguagem grandes são propensos a "perder de vista o panorama geral" ao lidar com tarefas compostas que exigem diferenciação precisa de detalhes. Se o modelo precisar "examinar as possíveis memórias" e "julgar seu valor" ao mesmo tempo, ele poderá perder informações importantes devido à distração ou relaxar seus critérios de avaliação. Ao dividir o sistema de modo que cada módulo se concentre em um único objetivo, o sistema como um todo é mais preciso.
Em segundo lugar.O projeto introduz um mecanismo de "dupla verificação" para melhorar a consistênciaO modelo pode ter um viés subjetivo de "autorreconhecimento" ao avaliar as informações que extrai. Os modelos podem ter uma tendência subjetiva de "autorreconhecimento" ao avaliar suas próprias informações extraídas. Ao tornar a avaliação uma etapa separada, as memórias candidatas podem ser examinadas de forma mais objetiva, reduzindo a tendência interna e garantindo que as memórias finais retidas sejam de maior qualidade e mais alinhadas com os critérios predefinidos.
Por fim, do ponto de vista da arquitetura técnica, o design modular oferece maior flexibilidade, permitindo que as equipes otimizem, iterem e aloquem recursos de forma independente para diferentes fases da tarefa.
Cursor
Por meio do processo prudente de "extração + avaliação", o sistema de memória constrói um firewall de informações de alta qualidade, evitando efetivamente a interferência de memórias de baixo valor no desempenho da IA. Essa filosofia de design altamente conservadora, que prefere a escassez à abundância, pode resultar em menos informações sendo ativamente lembradas pelo sistema, mas é uma solução econômica que equilibra a capacidade e a confiabilidade da IA no estado atual da arte. Isso revela uma tendência central: a concorrência das futuras ferramentas de IA não estará apenas no limite superior de seus recursos, mas também na estabilidade e na confiabilidade de seus resultados.