Cursor Agent Prompt 拆解：一套能直接抄的「编程搭档」提示词模板
最近公开流传的一份 Cursor Agent 系统提示词（Agent Prompt v1.0，基于 Claude Sonnet 4）很有意思。它不教你怎么写 prompt，它自己就是一份写得很硬的 prompt。读完会发现：好的系统提示词本质是行为约束，而不是能力描述。
一、这份文件真正值得学的东西
很多人看这类泄露的系统提示词，重点是扒「它用了什么模型」「开了什么工具」。但那份文件里真正有复用价值的，是它对 AI 行为的硬约束写法：
- 有一条规则被标成
CRITICAL INSTRUCTION：能并行调用工具就并行，串行只允许在「后一步依赖前一步输出」时发生； - 明确禁止把代码贴回对话框让用户复制------必须直接用
edit_file/search_replace改文件； - linter 报错自动修，最多 3 轮，修不好就停下来问人；
- 创建临时文件必须在任务结束时清理；
- 禁止生成超长哈希、非文本二进制内容；
- 编辑器状态（打开的文件、光标位置、linter 报错、编辑历史）每次请求自动附带，要求模型优先用这些信息，而不是开口问。
这几条的共同点在于：全是否定式、可验证、带上限。 没有一句「请写出高质量代码」这种空话。
下面我把这些设计模式抽出来，写成可以直接用的模板。
二、七条可复用的设计模式
模式 1：用 CRITICAL 标记最高优先级规则
长提示词最大的风险是核心指令被淹没。解决办法很简单：给关键规则一个显眼的标记，并且全文只用一两次。
markdown
【CRITICAL】以下规则优先级高于其他所有指令，冲突时以本条为准：
1. {{最关键的一条行为约束}}
2. {{第二条}}注意两点：一是必须写明「冲突时以本条为准」，给模型一个明确的优先级裁决规则；二是真的只能有一两条。标得多了等于没标。
模式 2：否定约束要具体到可验证
对比一下：
| ❌ 无效 | ✅ 有效 |
|---|---|
| 写干净的代码 | 每个函数不超过 30 行；单文件不超过 300 行 |
| 不要乱改文件 | 优先修改已有文件，禁止新建文件，除非我明确要求 |
| 处理好错误 | linter 报错自动修复，最多 3 轮；第 3 轮仍未解决则停止并向我说明卡在哪 |
| 别生成垃圾内容 | 禁止输出超过 64 位的哈希片段、禁止输出二进制或非文本内容 |
判断标准很朴素：这条约束能不能被一个脚本检查出来？ 能，就是好约束；不能，就是客套话。
模式 3：设定「自动重试上限」，防止死循环
这是那份 Cursor prompt 里最实用的一条。AI 修 bug 有个典型死法：改错 → 报新错 → 再改 → 再报新错，循环十轮后项目比原来更烂。
diff
【自动修复策略】
- 遇到 lint/编译/类型错误，先分析根因再动手，不要逐条症状式修补；
- 同一问题最多自动重试 {{3}} 次；
- 超过上限必须停止，并给我一份「我尝试了什么 / 还剩什么假设 / 需要你提供什么信息」的简报。关键在于超限后要交出一份结构化的失败报告，而不是简单地说「我修不好」。
模式 4：交付物必须是可运行的，不是片段
diff
【交付标准】
- 输出的代码必须包含完整的 import / 依赖声明 / 入口点，我能直接运行；
- 新增依赖时，同步更新 {{package.json / requirements.txt / Cargo.toml}}；
- 新建项目时，必须同时给出依赖安装命令和 README（含启动步骤）；
- 如果某处需要我无法提供的密钥或凭证，用占位符 + 注释说明，不要编造值。最后一条尤其重要：缺信息时用占位符标出来，不要静默假设。 这跟上一篇文章里「信息不足就停下来问」是同一个原则的两种落地方式。
模式 5：中间产物要清理
【临时文件】为调试或分析创建的临时文件、日志、快照，
任务完成后必须删除，并在结尾给我一份「改动清单」（新增/修改/删除的文件各一份）。这个习惯的价值在于：三次迭代之后，你还记得项目目录里那些 _temp.py 到底是干什么的。
模式 6：主动利用已有上下文，减少无效提问
Cursor 的做法是把编辑器状态自动塞进每次请求。你没有这个环境，但可以手动模拟：
【上下文】
当前文件：{{路径}}
光标位置：{{第 N 行，函数 foo 内}}
相关报错：{{粘贴完整报错，含堆栈}}
已尝试：{{列出你做过的操作和结果}}
相关代码：{{贴关键片段，不要贴整个仓库}}然后加一条纪律：
在我提供了上述信息的前提下，不要重复询问文件路径、报错内容或语言版本。
如果信息不足，明确指出缺哪一项。模式 7：并行思维------把「能同时做的」一次性说清
Cursor 那条 CRITICAL 指令的本质是任务编排优化，而不是模型特性。迁移到普通对话里，写法是这样的：
css
以下三件事互不依赖，请在一次回复中并行完成，不要分轮进行：
1. {{任务A}}
2. {{任务B}}
3. {{任务C}}
只有当 B 需要 A 的输出时，才分成两轮。反过来说也要显式声明：
这三步有依赖关系，请按顺序执行，每步结束后等我确认再继续。显式说明依赖关系，比默认让它猜快得多。
三、整合版：编程搭档通用模板
把上面七条合起来，是一份可以直接存进本地模型系统提示或 snippet 的完整模板：
markdown
【角色】你是我的编程搭档，目标是交付可运行、可维护的代码，而不是给出建议让我自己实现。
【CRITICAL】以下三条优先级最高：
1. 直接给出可运行的完整代码，不要只给片段或伪代码；
2. 不确定时明确标注 TODO 并说明缺什么，不要静默假设；
3. 同一问题自动修复不超过 3 次，超限则提交失败简报。
【上下文】
文件：{{}} 语言/版本：{{}} 目标：{{}}
现有报错：{{}} 已尝试：{{}}
【工作纪律】
1. 先读后改：动手前先确认你理解的文件结构和调用关系，理解有误立刻指出；
2. 最小变更：优先修改已有文件，不新建；不重构与我无关的部分；
3. 完整性：包含 import、依赖、入口；新增依赖同步更新 {{配置文件}}；
4. 清洁：不留临时文件、调试日志、注释掉的旧代码；结束时给改动清单；
5. 可读性：公共函数一行用途说明；复杂逻辑用注释解释「为什么」而非「做什么」。
【输出格式】
- 第一步：用 3 句话复述你的理解和打算怎么改（不超过 3 句）；
- 第二步：给出完整代码或 diff，文件之间用文件名分隔；
- 第三步：列出「需要我确认的风险点」和「你可以直接运行的验证命令」。
【禁止】
- 不要输出二进制内容、超长哈希、占位填充文本；
- 不要用「作为AI」「我建议」「总的来说」等填充句；
- 不要一次给三个方案；给最优解 + 一个备选，并说明取舍。这份模板的前三步结构（复述 → 交付 → 风险清单）是我从那份文件里学到的最通用的骨架：对齐、执行、交接，三轮闭环。
四、非编程场景怎么套用
这套思路并不局限于写代码。任何「AI 替我产出可交付物」的场景都能照搬：
| Cursor 的原规则 | 迁移到写作/分析 |
|---|---|
| 代码必须可直接运行 | 文章必须包含标题、小标题、结语，我能直接发布 |
| 新增依赖同步更新配置文件 | 引用数据必须附来源链接，缺失则标注「未核实」 |
| linter 报错最多修 3 轮 | 改写最多 3 轮，超限则列出分歧点让我拍板 |
| 临时文件必须清理 | 草稿版本不保留，只留最终稿 + 改动说明 |
| 禁止输出超长哈希 | 禁止编造人名、机构、法条、数字 |
| 并行调用工具 | 多个独立子任务一次回复完成，不分轮 |
核心逻辑始终如一：把验收标准提前写进提示词，让交付物符合开箱即用的要求。
五、一份常驻的负面清单
无论什么场景，这几条挂上去都有收益：
diff
- 不知道就说不知道，标注「需自行核实」，不要编造。
- 不复述我的问题，不做冗长开场。
- 不给三个以上方案；最优 + 备选，说明取舍理由。
- 涉及数字、价格、版本号、法规条文、API 参数时，标注需自行核实。
- 不做与我无关的重构、优化、风格统一。
- 不用「作为AI」「建议您」「希望这对您有帮助」。第五条是从 Cursor prompt 的「不重构无关部分」化用来的，它在非编程场景同样管用------AI 最喜欢顺手把你没让它动的地方也改了，然后你还得花时间去比对差异。
六、普通写法 vs 工程化写法
| ❌ | ✅ |
|---|---|
| 帮我看看这段代码有什么问题 | 文件{{}}，现象{{}}，预期{{}}。请先复述你理解的调用链，再按「最可能→最不可能」排序给出假设，每个假设附一个验证方法，一次只让我做一个验证 |
| 把这个功能加上 | 目标{{}}，约束{{不改接口签名 / 不新增依赖}}。完成后给：改动清单 + 验证命令 + 可能破坏的边界情况 |
| 为什么报错 | 贴完整堆栈 + 环境 + 已尝试。要求：先区分「确定原因」和「推测」，推测必须标注置信度 |
| 重写一遍 | 保留结构和结论，只做三件事：缩短30%、去套话、抽象表述换具体例子 |
规律还是那条：差的提示词只给了动词，好的提示词补上了约束、验收标准和停止条件。
读完那份 Cursor 的系统提示词，我最深的感受是：它几乎没有在夸自己有多强，全篇都在划边界。
角色、能力、擅长领域这些内容，写在最前面，占了不到十分之一。剩下九成全是「不要做什么」「最多试几次」「什么时候必须停下来问人」。
这大概是个反直觉但很实用的启示------控制幻觉和失控，比激发能力更重要。 因为能力是模型自带的，而边界只有你能给它。
如果你愿意，我可以把上面的整合版模板做成一份 Markdown 文件，或者按你的技术栈（比如 Python/Web/前端/数据分析）定制一版，连占位符都帮你填好示例值，直接存进本地模型就能用。