Cursor Rules 入门指南：如何高效编写提示词
深入了解 Cursor 中的 Rules 分类与提示词结构，让 AI 成为你的顶级开发助手
前言
AI 发展到今天，提示词工程仍然是很重要的一个命题。特别是在代码开发这种场景下，我们对错误几乎是 0 容忍，而 Cursor 就是一个很好的被压榨对象。
Cursor 里的提示词体现为 Rules，也就是规则，可以分为两种：
- 全局规则 - 用户设置后，Cursor 在所有项目里的表现都会默认遵循这个顶层规则
- 项目规则 - 放在项目根目录下，针对特定场景和文件类型定制的规则
全局规则
全局规则其实就是我们已经习以为常的系统提示词。
例如我们想让它始终用中文输出，那么就在 Cursor Rule 里给它下达这个指令。我们还可以让它 cosplay 成大厂顶级工程师进行工作，或者 PUA 它，给它画大饼。
# 示例：全局规则
你是一位精通 Next.js、React、TypeScript 的顶级工程师，
追求优雅的代码风格，始终用中文回复。项目规则
项目规则更像我们在使用 Few Shot 或者思维链提示词时包含的回答示例。在编程场景，对应的就是各种代码示例、API 文档或者开发工作流。
触发方式
由于一个项目中场景繁多，我们需要让 Cursor 有针对性地使用项目规则，而不是一顿乱用。可以自定义使用时机：
| 触发方式 | 使用场景 | 示例 |
|---|---|---|
| 始终执行 | 开发工作流的铁律 | 代码规范、Git 提交规范 |
| 文件匹配 | 基于框架开发 | 识别 .tsx 文件时使用 React 规则 |
| 按需调用 | 特定任务 | 开发进入测试阶段时，手动调用单元测试规则 |
工作原理
项目规则放在项目根目录下，意味着它会随着整个代码仓库被同步。Cursor 在调用时会使用内置工具读取其内容，以判断是否使用。
所以不必担心它是否过长——它不会一下子把上下文撑爆，而是会被 Cursor 阅读后，提取关键部分后使用。
提示词结构：STAR 法
写提示词其实很简单，先把骨架搭好，再慢慢优化。STAR 结构是个不错的选择：
- S - Situation（背景）
- T - Target（目标）
- A - Action（动作）
- R - Result（预期结果）
背景（Situation）
对于全局规则，我们就像写系统提示词一样，给它一个人设定位和风格。例如我的开发场景基本上围绕着 Next.js、React 展开，那么我就可以将人设定义为精通 Next.js 框架的工程师，风格则是对优雅代码的极致追求。
对于项目规则，我们的核心目的是要让 Cursor 精准判断何时调用，我们可以给这个规则一个简单明了的定义，帮助 Cursor 索引。
目标（Target）
全局规则更偏向于给 AI 一个大致的方向让它遵守，就像我们做项目，领导最关心的往往是方向对不对、有没有潜在风险，而不是事无巨细地教你怎么做。
而项目规则就不能那么粗了，我们需要给出具体的步骤，就好比做项目的 SOP 一样，照着做就行。
动作（Action）
这是占据提示词最多篇幅的部分。不论是全局还是项目规则，我们都需要具体问题具体分析。
例如我们希望 AI 在写代码时尽可能别写什么、和尽可能写什么，这个最好明确定义。在项目规则中，直接给出一个代码示例是最好的。
回看实际的产品开发流程：产品有 PRD 规范，开发有代码规范，UI 有设计规范。跟 AI 的交互无非是人换成了 AI，规范换成了提示词。
预期结果（Result）
这很像每个项目中的风控环节。有了它，项目就可以提前规划，避免不必要的麻烦。
例如在全局规则内，我们可以告诉 AI 我们不希望看到在一个代码文件中无脑堆代码。而在项目规则中，直接给 AI 一个让人小脑萎缩的代码示例就行。
总结
经过这么一折腾，一份提示词的结构就搭建好了。如果遇到新的场景，需要 AI 注意的，按这个结构做更新就非常简单了。
各位千万不要一上来就追求写出完美的提示词，你现在可以看到的成熟提示词，都是分享者在背后精心雕琢过的。建议：先模仿、再优化、最后创新。
下次我们来聊聊高质量提示词的来源。
