最近看到魚皮的Cursor提示詞分享（微信公眾平臺)，剛好之前也在做Agent開發，跟提示詞打交道的多，也經常發現 ai 蠢蠢的，一點不會根據提示詞設計的來，按魚皮的分享研究了一下，寫了這篇博客。

Cursor 的提示詞不僅邏輯嚴謹、場景覆蓋全面，更把「如何讓 AI 精準理解編程需求」這件事做到了極致。今天就帶大家拆解 Cursor 提示詞的精髓，這些技巧對我們自己開發 AI 應用也會有巨大幫助。

一、Cursor 提示詞：場景化設計是核心

Cursor 并非只有一套提示詞，而是針對不同使用場景設計了多套方案，每一套都對應特定的功能目標。比如：

• Agent 模式提示詞：讓 AI 具備「自主分析-規劃-執行」的能力，能從頭到尾解決復雜編碼任務，直到問題徹底解決；
• CLI 命令行提示詞：適配命令行交互場景，支持通過指令快速調用工具；
• Chat 對話提示詞：聚焦問答場景，能快速響應用戶的代碼咨詢、語法解釋等簡單需求；
• Memory 對話記憶提示詞：負責管理 AI 的長期記憶，評估哪些信息值得沉淀（比如用戶的編碼偏好），哪些需要舍棄，避免無效信息干擾。

從開源倉庫的文件列表中，我們能清晰看到這些提示詞的迭代痕跡：

提示詞文件	說明
Agent CLI Prompt 2025-08-07.txt	2025年8月更新的 Agent 命令行場景提示詞
Agent Prompt v1.0.txt	Cursor 1.0 版本的基礎 Agent 提示詞
Agent Prompt v1.2.txt	迭代更新的 Agent 提示詞（優化邏輯）
Chat Prompt.txt	對話場景核心提示詞（已重命名優化）
Memory Prompt.txt	對話記憶管理基礎提示詞
Memory Rating Prompt.txt	記憶質量評估提示詞（篩選有效記憶）

在這些提示詞中，Agent 模式提示詞最值得深入學習——足足 500 多行的內容。

二、Agent ：三大模塊構建 AI 編程能力

Cursor 的 Agent 提示詞本質分為三大模塊：角色定義（讓 AI 知道“我是誰、要做什么”）、操作約束（教 AI“該怎么做、不能怎么做”）、支持的工具（給 AI“裝備”，讓它有能力執行任務）。

1. 角色定義：給 AI 清晰的“身份認知”

提示詞的開篇就直接明確了 AI 的定位，沒有任何模糊空間，原文（中英文對照）核心內容如下：

你是一個由 GPT-4.1 驅動的 AI 編程助手，在 Cursor 中運行。（You are an AI coding assistant, powered by GPT-4.1. You operate in Cursor.）
你正在與用戶進行結對編程，以解決他們的編碼任務。每當用戶發送消息時，系統會自動附上用戶的當前狀態（比如打開的文件、光標位置、最近查看的文件、Linter 錯誤等），這些信息是否相關由你判斷。（You are pair programming with a USER to solve their coding task. Each time the USER sends a message, we may automatically attach some information about their current state...）
在用戶的查詢完全解決之前，請繼續工作；只有確定問題已解決，才結束你的回合。返回用戶之前，需自主盡最大能力解決問題。（You are an agent-please keep going until the user's query is completely resolved... Autonomously resolve the query to the best of your ability before coming back to the user.）

這段提示詞看似簡單，卻暗藏三個關鍵技巧：

• 明確三要素：直接告訴 AI“身份（編程助手）、場景（結對編程）、目標（解決編碼任務）”，避免 AI 輸出偏離場景（比如不會突然講編程理論，而是聚焦解決當前問題）；
• 強化 Agent 屬性：強調“持續工作到問題解決”，賦予 AI 處理多步驟任務的能力（比如用戶讓“開發一個登錄頁面”，AI 會自動拆解“寫 HTML 結構→加 CSS 樣式→寫 JS 交互→處理接口請求”，而不是只做一步就停）；
• 重復強調核心目標：多次提到“解決問題”“完成查詢”，這是因為 AI 可能會忽略零散指令，通過多角度重復，能強化 AI 對核心目標的記憶（就像我們提醒別人“記得點贊三連”，會換幾種說法反復提，避免對方忘記）。

還有一個隱藏技巧叫「Re-Reading（重讀）」，本質是讓 AI 反復確認需求——有文獻證明，讓模型“再讀一遍問題”能提升推理準確性，這一點在 Cursor 的提示詞中也有體現。

2. 操作約束：教 AI“規范做事”，避免犯錯

如果說“角色定義”是給 AI 定方向，那“操作約束”就是給 AI 定規則——告訴它“該怎么說話、怎么用工具、怎么改代碼”，甚至“不能做什么”。這部分用對稱的 HTML 標簽（比如 <communication> <tool_calling>）劃分模塊，結構非常清晰，我們逐個拆解：

（1）規范 AI 的“表達方式”

核心作用是統一 AI 的輸出格式，告訴 AI 怎么說話，方便用戶閱讀和后續程序處理：

在助手消息中使用 Markdown 時，用反引號格式化文件、目錄、函數和類名（比如 src/utils.js）；用 ( 和 ) 表示行內數學公式（比如 (a2 + b2 = c^2)），用 [ 和 ] 表示塊級數學公式。

（2）AI 使用工具的“紅線規則”

這是整個提示詞中最關鍵的部分，直接決定 AI 能否正確調用工具解決問題，核心規則有 9 條，其中 5 條必須重點關注：

1. 嚴格遵循工具格式：必須按指定 schema 調用工具，不能漏填參數；
2. 禁止調用未授權工具：即使對話中提到其他工具，只要沒明確提供，就不能用；
3. 不向用戶提“工具名”：比如調用“讀取文件工具”時，不能說“我要用 read_file 工具”，而是說“我會幫你讀取這個文件的內容”；
4. 優先工具獲取信息：如果能通過工具查到答案（比如讀文件看代碼結構），就不要問用戶（避免“你這個文件路徑是什么？”這種無意義提問）；
5. 制定計劃后立即執行：不用等用戶確認（比如 AI 計劃“先讀登錄接口代碼，再寫前端調用邏輯”，直接做就行，不用問“我可以先讀接口代碼嗎？”）。

💡 這一段提示詞中，我們能學到幾個技巧：

• 通過設定負面指令（大寫的 NEVER）和正面指令（大寫的 ALWAYS），強化了對 AI 的行為約束。
• 通過 “切勿調用未明確提供的工具”、“僅使用標準的工具調用格式和可用的工具”、“讀取文件而不是猜測或編造答案” 盡可能地消除 AI 的幻覺。
• 在合適的場景給 AI 放權，不用讓它頻繁找用戶確認。

（3）讓 AI“想透徹”再動手

核心原則是“全面、深入”，確保 AI 理解所有上下文后再輸出，避免“想當然”：

收集信息時要徹底，回復前必須掌握完整場景；追溯每個符號的定義和用法（比如某個函數的參數含義），不要只看第一個相關結果；用“語義搜索”作為主要工具，先從寬泛的高層查詢（比如“用戶認證流程”）入手，再拆成子問題（比如“登錄態怎么存儲？”）；必須用不同措辭多搜幾次，第一遍結果往往漏關鍵信息。

這其實是「思維鏈（CoT）」和「推理執行（ReAct）」的結合——先讓 AI 想清楚“要查什么、怎么查”，再動手執行，而不是上來就寫代碼。比如用戶問“為什么登錄接口報 500 錯”，AI 會先搜“登錄接口的代碼位置”→“看報錯日志”→“查數據庫連接是否正常”，而不是直接猜測“可能是參數錯了”。

（4）規范 AI 的“改代碼行為”

針對“代碼修改”的專屬約束，重點解決“輸出冗余”和“代碼不可運行”的問題：

除非用戶要求，否則不要直接輸出代碼，必須用代碼編輯工具修改（比如只替換某幾行代碼，而不是重新輸出整個文件）；生成的代碼必須能立即運行，要自動加全導入語句、依賴配置（比如創建 requirements.txt）；如果引入 Linter 錯誤，最多嘗試修復 3 次，第 3 次沒解決就問用戶；構建 Web 應用時，要保證 UI 美觀且符合 UX 最佳實踐。

這個約束非常實用：比如用戶要修改一個 5000 行的配置文件，AI 不用輸出完整文件，只需用“字符串替換工具”改關鍵行——既高效，又方便用戶對比修改前后的差異。

（5） 處理“優先級”和“記憶”

• <summarization>：如果有 <most_important_user_query> 標簽，就優先處理這個核心查詢，忽略之前的需求（比如用戶先問“改按鈕樣式”，后說“先解決登錄報錯”，AI 就聚焦登錄問題）；
• <memories>：管理對話記憶，比如用戶糾正過的錯誤記憶（比如“之前說的接口地址錯了，應該是 xxx”），必須立即用 update_memory 工具刪除或更新；用記憶時必須標注來源（比如“我會用 -la 命令查看文件 [[memory:123]]”），如果因記憶拒絕用戶請求，要告訴用戶“可以糾正記憶”。

3. 支持的工具：給 AI 趁手的“裝備”

工具模塊占了整個提示詞的 80%，核心是“給 AI 清晰的工具使用指南”——通過「命名空間（namespace）」分類，讓 AI 快速找到對應工具，主要分為兩類：

• functions：基礎工具集合，比如 codebase_search（語義搜索代碼）、read_file（讀取文件）、grep_search（精確文本搜索）、file_search（按名稱找文件）；
• multi_tool_use：多工具組合包裝，支持同時調用多個 functions 下的工具，比如“先搜代碼位置，再讀文件內容”。

每個工具的定義都有嚴格的結構，以 codebase_search（語義搜索）為例：

// ### 何時使用：探索不熟悉的代碼庫、問“如何/在哪里/什么”類問題（比如“前端登錄組件在哪里”）、按含義找代碼；
// ### 何時不使用：精確文本匹配（用 grep_search）、讀已知文件（用 read_file）、簡單符號查找（用 grep_search）、按名稱找文件（用 file_search）；
// ### 示例：
// // 查詢：“前端中在哪里實現了接口 MyInterface？” // 好：問題完整，帶“前端”上下文，明確要找“實現位置”； // //
// // 查詢：“MyInterface frontend” // 不好：太模糊，應改成“ MyInterface 在前端中在哪里使用？”； // //

這里用到了提示詞的經典技巧「Few-shot（少樣本示例）」——通過“好例子+壞例子+推理”，讓 AI 快速理解工具的正確用法，比單純說“要明確查詢”效果好得多。

三、提示詞編寫原則：從 Cursor 中提煉的實戰經驗

拆解完 Cursor 的 Agent 提示詞，我們可以總結出 5 條通用的提示詞編寫原則，無論是開發 AI 編程工具，還是做其他 AI 應用，都能用到：

1. 明確場景、角色和目標：不要只說“你是一個助手”，要具體到“你是 XXX 場景下的 XXX 助手，目標是解決 XXX 問題”（比如 Cursor 中“GPT-4.1 驅動的編程助手，目標是結對解決編碼任務”）；
2. 提供詳細的執行流程：不僅要告訴 AI“做什么”，還要說“怎么做”——比如“用語義搜索時，先高層查詢再拆子問題，多換措辭搜幾次”；
3. 模塊化+格式化+強強調：用標簽（如 <tool_calling>）劃分模塊，用大寫關鍵詞（NEVER/ALWAYS）強調重點，避免零散指令被忽略；
4. 工具說明要“手把手”：如果 AI 需要用工具，必須講清“適用場景、不適用場景、示例”，最好加“好/壞例子對比”；
5. 嚴格定義輸出格式：如果 AI 輸出需要被程序處理（比如工具調用參數、代碼片段），一定要約定格式（如反引號包裹、JSON 結構），避免解析錯誤。

最后

Cursor 的提示詞之所以“驚艷”，不在于復雜的語法，而在于“以用戶需求為核心”的設計思路——每一條約束、每一個工具定義，都是為了讓 AI 更精準、更高效地解決編程問題。

參考

扒了下 Cursor 的提示詞，被狠狠驚艷到了！