网上的 Cursor Rules 教程动不动几百行，全堆上去 AI 反而选择性遵守。这篇只保留每个场景真正管用的规则，拿去就能用。

---

为什么需要分场景？

一个常见的误区：把所有规则一股脑塞进 .cursorrules 文件。

问题是——

• 规则越多，AI 越容易"漏掉"关键的那条
• 写代码和 Review 代码需要的规则完全不同
• 方案讨论阶段你根本不需要代码风格规则

正确做法：当前做什么，就只挂那一套规则。

下面是我实际使用中沉淀的 7 个场景规则，每个都砍到了最精简。

---

一、方案设计

适用时机：你说"分析一下"、“怎么做”、“给个方案”

# 方案设计
- 先说你对需求的理解，我确认后再往下走
- 给 2-3 个方案，优先推荐最简单的
- 列出要改的文件清单和影响范围
- 我选定前不要写代码
- 不要用"未来可能需要"当理由搞复杂

为什么有效： Cursor 默认行为是"你一问它就开始写代码"。加上这条规则后，它会老老实实先做分析，等你拍板再动手。"优先推荐最简单的"这句尤其关键——AI 天然喜欢炫技，不压着它就会给你搞出过度设计。

使用示例：

@lib/actions/order.ts @prisma/schema.prisma
订单模块要加"批量退款"，支持部分退款。给方案，不要写代码。

---

二、代码编写

适用时机：日常写代码，建议常驻

# 代码编写
- 给完整可运行代码，不要 TODO / 省略 / "implement here"
- 文件太长就分部分给，但每部分能拼成完整文件
- 该删的代码直接删，不要注释保留
- 不确定的 API 直接说，不要编造
- 参考 @ 提供的范例文件风格，不要自由发挥
- 不要擅自格式化无关代码

为什么有效： 这 6 条解决的是 Cursor 最高频的 6 个毛病：

毛病	对应规则
给半截代码让你自己补	给完整可运行代码
用 // ... rest 偷懒	分部分给但能拼成完整文件
旧代码注释一堆不敢删	该删直接删
瞎编不存在的 API	不确定就说
风格跟项目不一致	参考范例文件
动你没让它动的代码	不擅自格式化

这套建议放在 L1（全局规则）里，每次对话都生效。

---

三、Code Review

适用时机：让 AI 帮你审代码

# Code Review
按优先级检查：
- P0：安全漏洞、数据丢失风险、N+1 查询、未处理异常
- P1：函数过长、重复代码、命名不清、错误被吞
- P2：可简化的写法、魔法数字、多余注释

每个问题：指出位置 → 说明问题 → 给修复代码
最后总结：几个 P0/P1/P2，能否合并

为什么有效： 不给分级标准，AI 会把"变量名可以更好"和"SQL 注入"放同一个优先级说。加了 P0/P1/P2 之后，你能一眼看出哪些必须改、哪些可以下次再说。

使用示例：

@lib/actions/order.ts @lib/services/orderService.ts
Review 这两个文件，按 P0/P1/P2 分级给意见。

---

四、Bug 修复

适用时机：修 Bug 的时候

# Bug 修复
- 先定位根因，不要只修表面症状
- 最小改动，不要顺手重构
- 说明为什么出 bug、为什么这样改
- 不要用 try-catch 包住问题假装修好
- 告诉我应该补什么测试防回归

为什么有效： Cursor 修 Bug 的默认行为是"大力出奇迹"——动不动重写一整个函数。"最小改动"和"不要顺手重构"这两句能把它按住。最后一条"补什么测试"也很实用，修完 Bug 顺手把测试用例也拿到了。

使用示例：

@app/dashboard/orders/page.tsx
Bug：筛选条件为空时白屏，控制台报 Cannot read property 'map' of undefined。
定位原因，最小改动修复。

---

五、重构

适用时机：代码太乱需要整理

# 重构
- 先输出方案：当前问题 → 目标结构 → 文件清单 → 分几步
- 一步一验证，每步编译通过
- 只改结构不改行为，不要同时加功能
- 不要顺手改不相关的代码

为什么有效： 重构最怕的是"改着改着就变成重写了"。4 条规则做一件事：控制范围。先出方案让你确认，分步走每步可验证，不夹带私货。

使用示例：

@lib/utils.ts
这个文件 800 行了，帮我分析怎么拆。只出方案，不要改代码。

---

六、写测试

适用时机：补测试的时候

# 测试
- 每个函数覆盖：正常路径 + 异常输入 + 边界条件
- 一个 test case 只测一个行为
- mock 数据贴近真实结构，不要 { a: 1, b: 2 }
- 不写 test.skip / test.todo，给完整实现

为什么有效： 不加"正常 + 异常 + 边界"这条，AI 只会给你写 happy path。不加"不写 test.skip"，它会用 TODO 糊弄你。4 条刚好覆盖测试质量的核心要求。

---

七、Git Commit

适用时机：让 AI 帮你写 commit message

# Commit
格式：type(scope): 中文描述（50 字内）
type: feat / fix / refactor / docs / test / chore
一个 commit 一件事，不要写"更新代码"这种废话

使用示例：

看一下这次 diff，帮我写 commit message。

会得到类似 fix(order): 修复筛选条件为空时列表白屏的问题 而不是 fix bug。

---

怎么组合使用？

核心原则：不要全堆上去，当前做什么挂那一套。

你在做什么	全局常驻	按需加载
日常写代码	代码编写	—
讨论方案	代码编写	方案设计
审代码	代码编写	Code Review
修 Bug	代码编写	Bug 修复
重构	代码编写	重构
补测试	代码编写	写测试

"代码编写"那套永远在，其他的谁上场谁挂。

具体放哪里：

• 全局常驻 → Cursor Settings > Rules（对所有项目生效）
• 按需加载 → 对话开头粘贴，或者放 Notepad 里随时 @ 引用

---

最后

规则不在多，在准。上面每一条都是从"AI 犯了这个错 → 加一条规则治它"这个循环里筛出来的。

建议你也这样：先不加规则裸跑，遇到什么毛病加什么规则，慢慢就有了自己的最佳实践。

别人的规则是起点，你踩坑后的规则才是终点。