YX Nexus Logo
YXNexus

解密Cursor：System Prompt 深度解析 | 最佳实践

2025年4月19日
AI
分享
prompt
解密Cursor：System Prompt 深度解析 | 最佳实践

01 前言

本文会将深入分析顶级AI应用—Cursor（Agent模式）下的系统提示词（System prompt）。通过拆解其结构与规则，我们可以学习到构建高效、可控的AI Agent Prompt的最佳实践。

关于更详细的版本及其他AI应用的Prompt（如Replit、Devin、v0、Lovable等）可以在此开源仓库找到：

https://github.com/x1xhlol/system-prompts-and-models-of-ai-tools

（强烈推荐关注此仓库以获取更多AI应用 System Prompt的实例。）

接下来，02部分是关于Cursor Agent prompt的拆解，03部分则是一些prompt构建的启示。

02 拆解

有趣的是，Prompt中声明Cursor是世界上最好的IDE。而且，默认模型是Claude-3.7-Sonnet。这份Prompt设定了模型在Cursor IDE中的行为准则和能力范围。

1. 核心角色与目标：

  • 作为AI编程助手仅在Cursor中工作，与用户结对编程。
  • 任务：创建、修改、调试代码或回答问题。
  • 上下文：会接收用户消息，并可能附带IDE状态信息（打开文件、光标位置、历史、错误等），AI需自行判断信息相关性。
  • 首要目标是遵循用户的明确指令。

2. 工具调用规则 (<tool_calling>)：

  • 关键规则：与用户交流时，绝不能提及工具的内部名称。用自然语言描述操作（“我会编辑文件”而非“我会用edit_file工具”）。（比较有趣，之前我还无意中问出来了。我认为这个规则与要和用户结对编程的优先级存在逻辑冲突，即我明确指出告诉我工具更有利于我们的合作，它就告诉我了。）
  • 精确性（严格按照工具定义提供必须参数）、有效性（绝不调用列表中为明确提供的工具）、必要性（仅在任务确实需要时才调用工具）。
  • 在调用每个工具前，必须先向用户解释为什么需要执行该操作。

3. 代码修改规则 (<making_code_changes>)：

实际上，在我实际使用中，模型对于以下规则的遵循不是很准确。

  • 禁止直接输出：除非被要求，否则绝不直接在聊天中输出代码块。必须使用代码编辑工具来实施变更。

  • 频率限制：每轮对话最多使用一次代码编辑工具。

  • 可运行性保证（核心要求）：

    1. 包括合并编辑：对同一文件的修改应聚合到单词编辑工具调用：；

2. 项目初始化：从零创建项目时，需包含依赖管理文件（如requirements.txt含版本）和有用的README。；

3. Web UI/UX：创建Web应用时，应注重美观、现代的UI和良好的UX；

4. 上下文获取：编辑前必须先读取相关代码区域（除非是简单追加或新建文件），确保理解上下文；

5. 错误处理：主动修复因修改引入的Linter错误（如果明确如何修复），但同一文件错误修复尝试不超过3次，之后需询问用户；

6. 编辑重试：若合理的编辑建议未被正确应用（可能由较简单的模型执行失败），应使用reapply工具尝试再次应用。

4. 搜索与阅读规则 (<searching_and_reading>)：

  • 工具优先级：优先使用语义搜索（codebase_search）。
  • 阅读效率：读取文件时，倾向于一次性读取较大范围，而非多次小范围读取。
  • 目标导向：一旦找到足够信息进行编辑或回答，就停止搜索/阅读。

5. 函数/工具列表 ():

这个是我感觉最有趣的。

codebase_search：
语义搜索代码，应复用用户查询措辞。

read_file：
读取文件指定行范围（最多250行）或整个文件（受限情况），需确保获取完整上下文，注意未显示行。

run_terminal_cmd： 
提议在用户终端运行命令，需用户批准，注意shell状态（新/旧）、对交互式命令加管道 (| cat)、后台运行长命令。

list_dir：
列出目录内容，用于探索文件结构。

grep_search：
精确文本/正则搜索（基于ripgrep），可指定包含排除模式、大小写。

edit_file：
提议文件修改，使用特定格式（// ... existing code ...代表未变动代码），需附带单句指令说明意图，target_file参数优先。

file_search：
模糊匹配文件名进行快速查找。

delete_file：
删除指定文件。

reapply：
当edit_file应用效果不佳时，要求更智能的模型重新应用上一次的编辑提议。

web_search：
进行网络搜索以获取最新信息。

diff_history：
查看工作区内文件的近期修改历史。

6. 代码引用格式：

  • 强制规定了引用代码块的唯一格式:起始行:结束行:文件路径换行后跟// ... existing code ...。

7. 用户信息 (<user_info>)：

  • 提供用户的环境信息（操作系统、工作区路径、Shell类型）供AI参考。

8. 最终指令：

  • 强调必须使用可用工具、检查必需参数、必要时询问用户、精确使用用户提供的值、不臆测可选参数、分析用户描述性词语中的潜在参数。

03 Prompt构建启示

Cursor Agent的System Prompt设计已经很简洁了，我看到其他的一些都非常长。

一些我个人对于这份Prompt构建的看法：

  • 指定角色。这对于大模型能力发挥可能一直都会起到很重要的作用，这本身就源于其基于概率输出的原理。Cursor中的模型被指定为“结对程序员”，统一了行为与沟通风格，强化人机协作范式（很看好）。
  • 明确行为。Prompt包含大量具体、可操作的行为规则。例如，Cursor Prompt中关于“Linter错误最多重试3次”、“编辑前必须读取上下文”、“禁止提及工具名”、“Web应用需包含良好UI/UX”等，都是精细化行为控制的体现。
  • 严格限制。这包括对于AI的输出进行格式限制（如代码引用格式），还有内容限制，确保一致性、可解析性（对于工具调用很重要）。
  • 设计体验。很厉害的是，我认为开发者要求Cursor不提及工具，一方面考虑是保密，还有一方面是对于用户体验的影响。我不知道这些工具时，Cursor总给我一种直接在操作代码的感觉，而不是调用那些繁杂的工具。这使得交互自然流畅，隐藏实现细节、优化体验。
  • 容错迭代。Prompt需要预见错误并提前注明错误的处理方式。例如，reapply工具用于处理编辑应用失败，Linter错误处理规则包含了重试与向用户求助。

很有意思的优秀范例，推荐关注开源仓库。

总结：详细的角色定义、精细的行为准则、严格的输出限制、用户体验的考量。

来自AI总结：

本文深入拆解了顶级AI应用Cursor Agent的System Prompt。

该Prompt将AI定位为Cursor IDE中的“结对程序员”，强调通过特定工具（如代码编辑、语义搜索、终端命令）执行任务，而非直接输出代码。

Prompt包含精细规则：如对用户隐藏工具名以优化体验、调用工具前解释原因、保证代码可运行性、系统化处理Linter错误（含重试限制）、优先使用语义搜索等。

关键启示包括：明确角色、制定细致行为规则、严格限制输出格式与内容、精心设计用户体验和内置容错机制。

这为构建高效、可控的AI Agent提供了宝贵范例，推荐关注文中提及的开源仓库获取更多实例。

浏览更多文章