Cursor Agent---如何更好地掌控AI编程助手

Cursor是一款受到开发者欢迎的AI编程助手，今天我们来分析它的系统提示词，以便更好地理解它的工作原理，提高使用效率。

古月居GYH

2427人浏览 · 2025-06-12 10:00:00

古月居GYH · 2025-06-12 10:00:00 发布

0. 简介

Cursor是一款受到开发者欢迎的AI编程助手，今天我们来分析它的系统提示词，以便更好地理解它的工作原理，提高使用效率。

1. Cursor Agent系统提示词

或询问可选参数。仔细分析请求中的描述性术语，因为它们可能表明应该包含一些必需的参数值，即使未明确说明。

你是一名功能强大的自主AI编码助手，由 Claude 3.7 Sonnet 提供支持。你只在世界上最好的 IDE——Cursor 中专门运行。

你正在与一位 USER 进行结对编程，以解决他们的编码任务。 该任务可能需要创建一个新的代码库、修改或调试现有代码库，或者只是回答一个问题。 
每次 USER 发送消息时，我们都可能自动附加一些有关他们当前状态的信息，例如他们打开了哪些文件、光标位置、最近查看的文件、到目前为止会话的编辑历史、linter 错误等更多内容。 
这些信息可能与编码任务相关，也可能无关，由你来决定。你的主要目标是在每条消息中遵循 USER 的指示。


<tool_calling> 
你有可用的工具来完成编码任务。请遵守以下关于工具调用的规则： 
始终严格按照指定的工具调用模式进行，并确保提供所有必要的参数。 
此对话可能引用一些不再可用的工具。切勿调用未明确提供的工具。
在与 USER 交谈时，绝不要提及工具名称。 例如，不要说"我需要使用 edit_file 工具来编辑你的文件"，只要说"我将编辑你的文件"即可。 
只有在必要时才调用工具。如果 USER 的任务是一般性的，或者你已经知道答案，那么无需调用工具，直接回答即可。
在调用每个工具之前，先向 USER 解释你为什么要调用它。 
</tool_calling> 

<search_and_reading> 
如果你对 USER 的请求答案不确定，或者不知道如何满足他们的请求，你应该收集更多信息。 这可以通过额外的工具调用、提出澄清性问题等方式完成…… 
例如，如果你进行了语义搜索，结果可能并不能完全回答 USER 的请求，或者需要收集更多信息，也可以随时调用更多工具。 
同样，如果你进行了某个编辑，可能只能部分满足 USER 的请求，但你不确定，可以在结束回合前收集更多信息或使用更多工具。 
倾向于不要向用户寻求帮助，如果你可以自行找到答案的话。 
</search_and_reading> 

<making_code_changes> 
当需要进行代码更改时，除非被请求，否则绝不要向 USER 输出代码。相反，应使用其中一种代码编辑工具来实现更改。 
每回合最多只能使用一次代码编辑工具。 
让你的生成代码能够被 USER 立即运行是极其重要的。为确保这一点，请仔细遵循以下说明： 添加所有必要的 import 声明、依赖和端点，以便运行代码。 
如果你是从头开始创建代码库，则需要创建一个合适的依赖管理文件（例如 requirements.txt），其中包含包的版本和有用的 README。 
如果你从头开始构建一个 web 应用程序，请为其提供美观且现代的 UI，并带有最佳用户体验实践。 
切勿生成非常长的哈希值或任何非文本代码（如二进制），因为这对 USER 没有帮助并且成本高昂。

除非你只是向一个文件追加一些很容易应用的编辑，或创建一个新文件，否则你必须先阅读你要编辑的文件的内容或你要编辑的部分，然后才能进行编辑。 
如果你引入了（linter）错误，并且你清楚如何修复（或可以很容易地找到修复方法），就进行修复，不要盲目猜测。并且不要在同一个文件上针对 linter 错误循环超过 3 次。如果在第三次仍无法修复，你应该停止并询问用户下一步该怎么做。 
如果你建议的一个合理的 code_edit 没有被应用模型跟进，你可以尝试重新应用该编辑。 
</making_code_changes> 

<calling_external_apis> 
除非 USER 明确要求，否则可以使用最合适的外部 API 和包来完成任务。无需征求 USER 的许可。 
当选择 API 或包的版本时，选择与 USER 的依赖管理文件兼容的版本。如果不存在此文件或其中没有该包，则使用你训练数据中存在的最新版本。 
如果外部 API 需要 API Key，请务必向 USER 指明。遵循最佳安全实践（例如，不要在可能暴露的位置对 API Key 进行硬编码） 
</calling_external_apis> 

<user_info> 
用户的操作系统版本是 darwin 24.3.0。用户工作区的绝对路径是 $PATH。用户的 shell 是 /bin/zsh。 
</user_info> 

回答 USER 的请求可以使用相关工具（如果可用）。请检查每个工具调用所需的所有参数是否已提供或可以从上下文中合理推断。
如果没有相关工具或缺少必要的参数，请让 USER 提供这些值；否则继续进行工具调用。
如果 USER 为某个参数提供了特定值（例如带引号），请确保精确使用该值。不要自行编造或询问可选参数。仔细分析请求中的描述性术语，因为它们可能表明应该包含一些必需的参数值，即使未明确说明。

2. 系统提示词解读

2.1 模型驱动与身份定位

系统提示词首先明确了Cursor Agent的身份是"功能强大的自主AI编码助手"，由Claude 3.7 Sonnet驱动。这不仅告诉我们Cursor使用的是哪款模型，也暗示了它的定位是专业编程助手而非通用聊天工具。
从设计上看，这部分可能是个变量，因为Cursor新版本支持自动选择模型。明确标注模型类型也是为了避免用户在计费问题上产生疑问，因为Cursor按不同级别的模型（高级模型如Claude 3.5/3.7、GPT-4o以及非高级模型如DeepSeek、GPT-4o-mini等）收取不同费用。

2.2 工具调用规范

提示词中的<tool_calling>部分详细规定了工具调用的规则，包括：

严格按照指定模式调用工具
不调用未明确提供的工具
与用户交流时不直接提及工具名称
只在必要时调用工具
调用前向用户说明原因

这些规则确保了用户体验的流畅性，避免了技术细节干扰用户的思路。例如，Cursor不会说"我将使用edit_file工具"，而是直接说"我将编辑你的文件"，这种细节处理让交互更自然。

2.3 信息收集策略

在<search_and_reading>部分，提示词指导了Cursor在不确定如何满足用户请求时的信息收集策略：

通过工具调用、提问等方式收集信息
在不完全解决问题时继续收集信息
尽量自行寻找答案，而非向用户求助

这部分体现了Cursor的自主性设计理念，使它能像真正的编程助手那样，在遇到问题时主动寻找解决方案。

2.4 代码更改原则

<making_code_changes>部分包含了代码编辑的核心原则：

使用编辑工具而非直接输出代码
每轮对话最多使用一次编辑工具
生成能立即运行的代码（包含必要的导入和依赖）
为新项目创建适当的依赖管理文件和README
提供美观现代的UI和良好用户体验
避免生成长哈希值或二进制代码
编辑前先阅读文件内容
修复linter错误但不循环超过3次

这些原则确保了Cursor生成的代码高质量、可运行，并且符合现代开发标准。特别是"能够立即运行"这一点，体现了Cursor对用户体验的重视。

2.5 外部API调用指南

<calling_external_apis>部分规定了使用外部API和包的原则：

可自主选择最合适的API和包
选择与依赖管理文件兼容的版本
对需要API Key的服务进行明确提示
遵循最佳安全实践

这一部分反映了Cursor在实际开发中对安全性和兼容性的考虑，例如避免硬编码API密钥，这些都是专业开发中的基本准则。

2.6 用户环境信息

<user_info>部分提供了用户环境的基本信息，如操作系统版本、工作路径和shell类型。这些信息帮助Cursor在生成代码时考虑用户的具体环境，避免兼容性问题。

3. 如何更好地使用Cursor

基于对系统提示词的深入理解以及实际使用经验，我们可以采取以下详细策略来更好地利用Cursor：

3.1 充分利用Summarized Composers功能

Summarized Composers是Cursor v0.45版本引入的功能，可以极大地缓解上下文限制问题：

具体使用方法：
在Composer对话框中输入"@"，选择"@Summarized Composers"
系统会显示可选的历史Composer对话摘要
可以同时引用多个Summarized Composers
每个Composer对话可以重命名，方便快速定位

使用时机：
当你发现Cursor开始"健忘"时，就是使用此功能的最佳时机。一个简单的判断方法是在.cursorrules中添加一个识别标记，例如：
xxxxx开头
当Cursor不再使用这个特定的开头语句时，就说明上下文可能已经超限，需要开启新对话并引用之前的摘要。

.cursorrules是放在项目根目录下的一个文件，你可以在里面指定ai如何生成代码。比如设置命名风格（驼峰or下划线）、缩进风格（2空格or4空格）、使用什么语言（JS or TS）等等。

一定要有Composer历史对话，才有办法引用这个新功能，否则就会出现“No available options”的提示。

3.2 合理配置Optional Long Context

Cursor v0.45版本还引入了Optional Long Context功能，允许在Composer模式下使用更长的代码上下文：

配置方法：
在【Cursor Settings-Features-Chat&Composer】中勾选开启
启用后会消耗更多的fast requests，可能略微降低响应速度
最佳使用场景：
- 处理大型代码文件（超过1000行）时
- 需要AI理解更广泛的上下文信息时
- 分析复杂的跨文件依赖关系时
- 进行大规模代码重构时
使用建议：
对于简单查询和小型文件，保持关闭状态以提高效率
在处理复杂项目时开启此功能
如果发现AI响应不够准确，可尝试启用此功能
根据实际需求灵活开启/关闭，平衡效率和资源消耗

3.3 建立有效的项目文档结构

良好的项目文档是缓解上下文限制的关键。特别是README.md文件，可以作为项目的"记忆库"：

实施方法：
在项目初始阶段，在.cursorrules中添加以下要求：

## 项目初始化
- 在项目开始时，首先仔细阅读项目目录下的 README.md文件并理解其内容，包括项目的目标、功能架构、技术栈和开发计划，确保对项目的整体架构和实现方式有清晰的认识；
- 如果还没有README.md文件，请主动创建一个，用于后续记录该应用的功能模块、页面结构、数据流、依赖库等信息。
这条要求的目的就是给项目生成README.md文档，用于记录项目的整体目标，功能模块和每个模块的用途，项目所使用的技术栈和依赖库，以及关键节点的变更和开发进度等。

 每完成一个功能模块后，让Cursor更新README.md，记录相关信息  
 在后续对话中，使用"@File"来指定README.md作为上下文参考

这种方法的优势在于，相比Summarized Composers的高度提炼，README.md能保留更丰富的项目架构信息，为Cursor提供更完整的背景。

如果需要快速生成一些标准的提示可以使用花生插件来完成。

3.4 灵活运用Notepads保存常用逻辑

Notepads是Cursor中强大的上下文共享工具，适合存储频繁使用的代码模板和逻辑：

适用场景：
- 动态模板生成（如常见组件模板）
- 架构文档（前端规范、后端设计模式等）
- 开发指南（编码规范、最佳实践等）
最佳实践：
- 使用清晰的标题和分区
- 包含相关示例
- 保持内容专注和有序
- 使用Markdown格式提高可读性
- 添加必要的相关文件附件

示例结构：

# API Development Guidelines
## Endpoint Structure
- Use RESTful conventions
- Base URL: `/api/v1`
- Resource naming in plural form
## Authentication
- JWT-based authentication
- Token format: Bearer {token}
- Refresh token mechanism required
## Response Format
{
  "status": "success|error",
  "data": {},
  "message": "Optional message"
} 
## Attached References
@api-specs.yaml
@auth-flow.md

值得注意的是，Notepads不会跨项目自动同步。因此，一个实用的替代方法是将这些规范/指南先写在本地文件中，再复制到新项目中，然后使用"@File"实现类似的上下文索引效果。