Cursor 进阶：Notepads、BugBot 与后台 Agent 高阶功能

最后更新 2026-06-25

你将学到

会用 Notepads 把项目规范和常用上下文存成可复用便签，不再每次对话重复喂背景
理解 BugBot 的工作原理，知道在 PR 流程里哪个环节接入它最合适
掌握后台 Agent 的启动和管理方式，让多个任务并行跑而不互相阻塞
会用 @Rules 进阶写法把团队规范固化进 Cursor，减少 AI 输出的"不合规"返工

你把 Cursor 装好、跑通了 Tab 补全和 Composer，感觉还不错——但如果每次打开新对话，都要重新解释"我们项目用 TypeScript、接口要写注释、异步统一用 async/await、禁止 any"，那你只是在用一个更贵的文本编辑器。

进阶功能才是 Cursor 真正拉开差距的地方。这篇把五个最值得投入的高阶功能讲透：Notepads、BugBot、后台 Agent、@符号高阶引用、Rules 规范管理。每个都告诉你干啥、怎么用、什么场景值、常见坑在哪。

进入进阶之前，先确认基础

这篇内容承接 Cursor 上手：Tab 补全、Composer 多文件编辑与 Agent 自主跑任务（2.4）。如果你还没跑通三大核心能力，先去那篇把基础建立起来——进阶功能建在基础上，没有基础直接上进阶，容易搞不清楚到底是基础没用对还是进阶功能有问题。

本篇讲的内容都和上下文管理强相关。如果你还不太理解为什么上下文质量决定 AI 输出质量，可以配合上下文是一切：引用规则与 Token 管理（3.1）一起看。

Notepads：把常用背景存成可复用便签

干啥

你有没有这种经历：每次开新对话，都要打一段"我们的项目是 xxx，技术栈 xxx，代码规范 xxx"——半分钟的废话，打了几十遍。Notepads 解决的就是这个问题。

Notepads 是 Cursor 里的一个持久化便签系统。你把项目背景、编码规范、常用 prompt 模板写进去，之后在任何对话里用 @Notepads 引用，Cursor 就能直接读取这段背景，不用重复解释。

怎么用

创建 Notepad：

在 Cursor 侧边栏找到 Notepads 面板（通常在左侧图标栏，或者通过命令面板 Cmd/Ctrl + Shift + P 搜"Notepads"打开）。点击"+"新建一个。

给它起个有意义的名字，比如 项目规范、后端接口约定、测试写法模板。内容就是你想让 Cursor 记住的东西，比如：

项目：用户管理后台
技术栈：Node.js + TypeScript + Express + PostgreSQL
编码规范：
- 所有接口返回格式 { code, data, message }
- 异步函数统一 async/await，禁止回调
- 类型定义放 src/types/ 目录，禁止 any
- 每个接口写 JSDoc 注释，说明参数和返回
测试：Jest，覆盖率目标 80%，用 describe/it 结构

使用 Notepad：

在 Composer 或 Chat 输入框里，输入 @ 弹出菜单，找到 Notepads，选你要引用的那个。这段背景就会附加到这次对话的上下文里。

@项目规范
帮我给用户模块加一个"批量停用账号"的接口，
包含参数校验和事务处理

什么场景值得用

团队项目：把团队的代码规范存成 Notepad，所有人都能引用，输出结果风格一致。
多模块项目：不同模块有不同规范的，分别建 Notepad，用时按需引用，不互相干扰。
重复性任务模板：比如"写单元测试"的 prompt 模板你已经打磨好了，存成 Notepad，以后直接 @ 进来。

常见坑

Notepad 内容太长会占用大量 Token 窗口，挤压给 Cursor 实际工作的空间。原则是精炼，不是全面——跟这次任务无关的背景不要塞进去，不然质量反而下降。

BugBot：让 PR 自动过一遍

干啥

BugBot 是 Cursor 提供的一个 PR 代码审查机器人。你把它接入 GitHub 仓库后，每次有新 PR 创建，它会自动分析这次改动，主动在 PR 里评论它发现的潜在 bug 或问题。

注意它的定位：它是帮你做第一道粗筛的，不是替代人工 review。比如一个明显的空指针风险、未处理的 Promise rejection、漏掉的边界条件——这类它抓得到；架构决策合不合理、业务逻辑对不对，它做不到。

怎么用

接入步骤（细节以官方文档为准，截稿 2026-06）：

在 Cursor 设置里找到 BugBot 配置入口。
授权 Cursor 访问你的 GitHub 账户。
选择要启用 BugBot 的仓库。
配置触发条件（比如所有 PR，还是只有特定分支的 PR）。

接入后，下次提 PR，BugBot 会在 PR 评论区自动发出分析结果，格式类似：

🤖 BugBot 分析结果
在 src/api/user.ts 第 42 行发现潜在问题：
userId 未做 null 检查，如果上游传入 null 会导致数据库查询报错
建议加: if (!userId) throw new BadRequestError('userId 不能为空');

你可以在评论里回复 BugBot，让它进一步解释，或者标记"已知晓、不修改"。

什么场景值得用

小团队缺乏专职 reviewer：BugBot 帮你补第一道筛选，让真正的 review 聚焦在高价值问题上。
新人入手的代码库：新人写的代码容易有一些低级错误，BugBot 能早期拦截，减少 review 来回。
高频迭代项目：PR 数量多、reviewer 精力有限，BugBot 做粗筛能减轻 reviewer 负担。

哪类问题它识别得好，哪类识别不好

识别质量	例子
好	空指针风险、未处理的异常、明显的 off-by-one 错误
一般	性能问题（取决于代码规模和可见性）
差	业务逻辑正确性、架构合理性

不要把 BugBot 的"没问题"当成"可以上线"的背书，它的扫描覆盖面是有限的。

后台 Agent：让任务在后台并行跑

干啥

Cursor 上手篇提过 Agent 模式，这里讲的是它的后台并行用法——更高级的使用方式。

普通 Agent 模式是你在前台等它跑完再干下一件事。后台 Agent 是你启动任务之后，切回去继续写代码，Agent 在后台独立执行，完成后通知你。你可以同时开多个后台 Agent 任务，互不干扰。

实际场景：你有一个功能在 Agent 跑测试、自动修复；同时你在 Composer 里处理另一个模块的改动；另一个 Agent 在后台帮你跑 lint 修复。三件事并行，不互相等待。

怎么用

启动后台 Agent：

在 Agent 面板里，启动任务时找"后台运行"或"Background"选项（具体入口位置以官方文档为准，截稿 2026-06）。启动后，任务会在独立的 Agent 会话里跑，你可以切走。

管理后台任务：

Cursor 的 Agent 管理面板（通常在侧边栏）会列出所有正在运行的任务。你可以：

点进去查看某个任务的执行进度和输出日志
随时点 Stop 终止某个任务
任务完成后会有通知（取决于你的通知设置）

给后台 Agent 的任务要写清楚：

后台跑的任务你不会实时盯着，所以任务描述要比前台更精确。模糊的指令在前台你能随时纠偏，后台你发现偏了的时候它可能已经改了一堆文件。

比较好的写法：

把 src/utils/ 目录下所有函数的 JSDoc 注释补全，
按照 @项目规范 里的格式，只补注释、不改逻辑，
完成后告诉我改了哪些文件

比较危险的写法：

帮我把代码整理一下

什么场景真提效

跑测试并修复：让所有单元测试通过——测试数量多、修复时间长，扔后台最合适。
批量格式整理：按 eslint 规则修复 src/ 下所有警告——不涉及逻辑改动，安全后台跑。
补注释/文档：给所有公开函数补 JSDoc——纯增量工作，不怕出错。

什么场景要谨慎

核心逻辑改动：后台跑完你可能没有及时 review，建议这类任务还是前台盯着。
涉及文件删除或重命名：后台 Agent 也能执行这类操作，没盯着风险更高。
依赖外部确认的任务：比如 npm install 如果遇到冲突需要手动选择，后台会卡住等你。

常见坑

任务卡死不动：通常是 Agent 在等一个需要你确认的输入，比如命令行提示符。去任务面板看一下输出日志，往往一眼就能发现。

多个后台 Agent 同时改同一文件：会有冲突风险。建议不同 Agent 任务负责不同的目录或模块，不要让它们在同一时间碰同一个文件。

@符号高阶引用：不只是引文件

上手篇介绍了基础 @ 用法。进阶用法是把 @ 组合起来，精准控制 Cursor 看到的信息范围。

几个进阶场景

@Docs——引用外部文档

Cursor 支持把外部文档索引进来。比如你在用某个框架，可以把官方文档地址添加进 Cursor（Settings → Features → Docs），之后用 @Docs 引用，Cursor 就能基于这份文档来回答和生成代码，而不是靠训练数据的过时记忆。

对引入了较新版本的库特别有用——AI 的训练数据有截止日期，新 API 它未必知道，@Docs 能解决这个问题。

@Git——引用 git 历史

@Git 可以引用某次 commit 或 diff，让 Cursor 基于这次变更来分析。比如：

@Git last commit
这次改动引入了什么 bug 风险？

或者帮你写 commit message：

@Git staged changes
帮我写一个准确的 commit message

@Web——搜索网络

让 Cursor 实时搜索，补充它不知道的最新信息。比如某个报错信息你不确定是什么原因，可以：

@Web "TypeError: Cannot read property 'map' of undefined" React 18
这个报错在我这个场景里可能是什么原因

组合引用

多个 @ 可以放在同一条消息里：

@项目规范 @src/api/payment.ts @Web Stripe webhooks 最佳实践 2024
帮我审查这个支付接口的 webhook 处理，有没有安全问题

Cursor 会把这几个上下文来源合并一起分析。但注意 Token 是有限的，不要无节制地叠加 @——见上下文是一切：引用规则与 Token 管理。

Rules 进阶：把团队规范固化进去

干啥

Rules 是 Cursor 的另一个规范管理机制，功能和 Notepads 有交叉，但定位不同：

Notepads：你手动在对话里 @ 进来，灵活按需引用。
Rules：配置一次，自动生效——每次触发 AI 的时候都会带上这些规则，不需要手动引用。

Rules 适合放那些所有 AI 交互都应该遵守的规范，比如"代码里不要用 any"、"函数命名用驼峰"、"提交代码前先检查有没有硬编码的 key"。

怎么用

Rules 可以放在两个地方：

全局 Rules（Settings → Rules for AI）：对你所有项目都生效，适合放个人习惯，比如"回答时用中文"、"代码示例用 TypeScript 而不是 JavaScript"。

项目级 Rules（项目根目录的 .cursor/rules 文件，或 .cursorrules 文件）：只对当前项目生效，适合放项目规范。推荐把这个文件 commit 进仓库，这样团队成员都能共享同一套 Cursor 规范。

项目级 Rules 示例：

# 代码规范
- 使用 TypeScript，禁止 any，必须显式声明类型
- 异步操作统一用 async/await，禁止 .then().catch() 链式调用
- 每个函数必须有 JSDoc 注释，包含 @param 和 @returns

# 结构规范
- 新接口放在 src/api/ 目录，文件名用 kebab-case
- 类型定义放在 src/types/，不要在业务文件里定义类型
- 工具函数放在 src/utils/，每个函数配对应的单元测试

# 安全
- 绝对不要在代码里硬编码 API key 或密码
- 所有用户输入必须经过校验，不要直接拼 SQL

什么场景真提效

Rules 写得好，能把大量的"AI 输出不符合规范→你手动纠正→AI 重新生成"的来回变成"第一次就对"。这对团队项目尤其有价值：不同人对 AI 说话方式不同，但 Rules 是统一的，输出结果的一致性会高很多。

常见坑

Rules 太长了会有两个问题：一是占用 Token，二是 AI 会选择性忽略优先级低的规则。建议每条 Rule 写一句，简洁直接，20 条以内效果最好。

哪些进阶功能真提效，哪些是锦上添花

实话实说，这几个功能的实际价值差异很大：

功能	真提效程度	说明
Rules 项目级规范	★★★★★	一次配置长期受益，降低大量返工，强烈推荐
Notepads 上下文复用	★★★★☆	重复性任务特别有用，偶发任务收益一般
后台 Agent 并行	★★★★☆	跑测试/lint 等机械任务效果好，逻辑任务谨慎
@Docs 文档引用	★★★☆☆	用新版本库时很有用，用熟悉库时意义不大
BugBot	★★★☆☆	小团队缺 reviewer 时有帮助，大团队本来就有 review 流程则意义有限
@Git 引用历史	★★☆☆☆	偶尔有用，不是高频需求

如果你只想优先落地一个，先把 Rules 项目级规范配置好。其他功能根据你的实际痛点再按需投入。

故障排查表

症状	可能原因	解法
Notepads 内容引用了但 Cursor 没有按规范来	Notepad 内容太长，Token 窗口溢出，规范被截断	精简 Notepad，删掉不相关内容，只保留这次任务必要的部分
Rules 写了但 AI 没有遵守	Rules 条目太多，或单条写得太长，AI 优先级降低	减少条目数，每条精炼成一句话，优先级最高的放最前面
后台 Agent 启动后一直显示等待	任务中有需要手动确认的命令交互	打开任务日志，看卡在哪一步，去终端手动处理那步
后台 Agent 改动范围超出预期	任务描述不够明确，Agent 自行发挥	重新描述任务，加上"只处理 xxx 目录"、"不修改逻辑"等约束
BugBot 接入后不触发	仓库权限未正确授权，或 webhook 未配置	去 Cursor 设置里重新检查 GitHub 授权状态，以官方文档步骤为准
@Docs 引用后 Cursor 还是用旧 API	文档索引未更新，或引用的文档版本有误	在 Cursor 设置的 Docs 管理里手动触发重新索引

常见问题

Q：Notepads 和 Rules 都能放规范，用哪个？

用途不同，不互斥。Rules 放所有任务都必须遵守的硬规范（命名、禁止 any、安全要求），自动生效不用手动引用。Notepads 放特定场景的上下文背景（某个模块的架构说明、某类任务的 prompt 模板），需要的时候手动 @ 进来。两个配合用效果最好。

Q：后台 Agent 会不会乱改我的代码？

它和前台 Agent 一样，做的修改都会记录在 Agent 面板的执行日志里，你可以随时查看和回滚。关键是：一，任务描述要明确范围；二，最好在 git 干净的状态下启动（这样万一出问题，git diff 或 git checkout 可以快速恢复）。

Q：BugBot 找到的问题一定要修吗？

不一定。BugBot 是静态分析，有时候会有误报——它指出的"问题"你根据业务上下文判断不是问题，完全可以在 PR 评论里标注"wontfix"然后忽略。把它当参考，不要当命令。

Q：Rules 文件需要 commit 到 git 仓库吗？

如果是个人习惯，可以不 commit（或者加进 .gitignore）。如果是团队共享的项目规范，强烈建议 commit——这样所有成员 clone 仓库就自动获得同一套 Cursor 规范，新人上手也不会"不知道 AI 为什么输出和别人不一样"。

Q：这些进阶功能会消耗更多额度吗？

Notepads 和 Rules 引入的内容会占用 Token，间接增加额度消耗。BugBot 和后台 Agent 也会消耗额度（因为都在调用模型）。具体额度计算以 Cursor 官方定价为准（截稿 2026-06）。

下一步去哪

进阶功能用熟之后，下一个提升点是把 Cursor 放进多工具组合工作流——它不需要单打独斗，和 Claude Code、GitHub Actions 结合起来能做更多事。