上一篇把 Claude Code 在终端里跑第一个任务的全过程拆完，评论和私信里立刻冒出另一批问题：Cursor 我也装了，可除了看着它灰扑扑地补全几行、我机械地按 Tab，好像就不会别的了，这钱花得值不值全靠运气。
这篇专门讲 Cursor。不聊选型（三个工具怎么分工前面那篇写过了），只讲一件事：真正天天用的人，手在键盘上反复做的到底是哪几个动作。我把自己用得最熟、也确实最省时间的几招摊开，配上什么时候用、最容易在哪翻车。快捷键以 mac 为主，Windows 和 Linux 一般把 Cmd 换成 Ctrl；Cursor 菜单和键位改得挺勤，具体以它官方当期的快捷键表为准，别照着几个月前的旧教程死记。
一、先把观念拧过来：它不是"自动写代码机"
很多人用 Cursor 的方式是：丢一句话，等它吐一大段，闭眼全部接受，跑挂了再骂它不靠谱。这是最亏的用法，也最容易埋 bug、烧额度。
Cursor 的定位从一开始就是坐你旁边的副驾，不是替你开车的自动驾驶。它最值钱的地方不是"能写多少"，而是每一个改动都以 diff 的形式摊在你面前，收不收、留哪几行，全由你拍板。你始终握着方向盘，它负责把草稿递过来。
把这个观念立住，后面所有功能你才会用对：你不是在等它交作业，而是在不断地"提要求、看改动、做取舍"。Tab 补全只是门槛，远不是全部。
二、Tab 补全：九成的人停在这一步，而且用得很糙
灰字预判（Ghost Text）大家都见过，光标一停，它在后面用浅色字猜你接下来要写什么，Tab 收下、Esc 放弃。机制简单，但补得准不准，差别全在你给的上下文：
- 相关的文件在编辑器里打开着、你当前的命名和项目已有风格一致、光标停在合理的位置，它顺着套路往下补，往往一补一个准；
- 项目本身陌生、上下文是乱的、你连自己要写啥都没想清楚，它补出来的东西就似是而非，看着像那么回事，细究全是坑。
写重复性高的结构------参数校验、一堆 CRUD、相似的分支处理------时，可以让它补整块而不只是一行，效率很高，但接受前一定通读一遍。
最该养成的肌肉记忆是"扫一眼再 Tab"。补全是建议，不是答案，尤其碰到涉及边界条件、权限判断、删除操作的行，多看那两秒能省掉后面半小时的排查。想只接受它补的前半句、不想连带收下后面猜错的部分，就用方向键控制接受范围（不同版本操作略有差异），别为了一句对的话，顺手收下一句错的。
三、内联改写：我每天用得最多的"轻指令"
如果说 Tab 是被动等它猜，内联改写就是你主动点着某段代码让它改，这是我日常用得最频繁的功能。
用法很简单：选中一段代码，mac 上按 Cmd+K（Windows 是 Ctrl+K），然后直接用大白话说要怎么改------给这个函数的入参加非空校验、把这堆回调改成 async/await、补几个边界情况、把变量名起得更清楚、给这段加上注释。它只动你选中的范围，改完照样把 diff 摊给你，收不收你定。
为什么我偏爱它而不是动不动开对话？因为上下文就是你选中的这段加上当前文件，不用重新交代一遍项目背景，搬运量小，额度实打实花在这处改动上。这点在前面"额度审计"那篇里算过账：最贵的从来不是改代码本身，而是反复搬运上下文。
指令还是那句老话，越具体越好。"给入参加非空校验，校验失败时抛出带字段名的错误，其他逻辑别动"，效果远胜于一句"优化一下"。它适合小到中等、范围明确的改动；真要跨十几个文件的大重构，别用它，那是多文件面板和终端原生 Agent 的活。
四、对话和 @ 引用：上下文要"喂"得准
mac 上按 Cmd+L 打开对话面板。新手最大的一笔浪费，就是开个空对话来一句"帮我看看这个项目"，于是它呼啦啦读进来一堆文件，额度掉得飞快，而你其实只想改一个函数。
正确做法是用 @ 精准喂上下文：@ 某个文件、@ 某份文档、@ 某段代码，只把真正相关的东西塞给它。要改哪几个文件就 @ 哪几个，能直接贴代码片段就别让它自己满仓库翻。
遇到跨多个文件联动的改动，用多文件编辑那个面板（不同版本里叫 Composer 或 Agent，入口名字略有差异，以你当期界面为准）：它能同时改好几个文件，还能自己跑命令、看报错、再修。能力强，但更要把缰绳攥紧------指令里务必写清四件事：做什么、能碰哪些文件、哪些绝对不许动、做完的验收标准是什么，生成之后逐文件看 diff，别一键全收。
一条能让它少返工的指令，基本都长这样："给 utils 里的日期函数补 5 个边界测试并修掉跨年算错的 bug，只许动这个函数和它的测试文件，其余别碰，跑通全部测试算完。"
五、项目规则：把约定写一次，别让它每次重新猜
这是很多人忽略、但回报极高的一步。Cursor 支持给项目配规则------早期版本通常是项目根目录里的 .cursorrules 文件，新版本把它收进了 Rules（项目规则）设置里统一管理，具体放哪、怎么写，以官方当期文档为准。
规则里写什么？写那些你不想每次都重复一遍的约定：代码风格、统一用哪个库、目录怎么组织、接口返回长什么样、哪些文件（配置、密钥、自动生成的代码）绝对不许碰、提交信息用什么格式。
配好之后，它生成的东西默认就贴着你的项目走，你不用每开一个对话都重申"我们不用那个库""别改这个目录"。省下来的是一轮轮纠正的返工，也是额度。
写规则有个忌讳：别写空话。"写出高质量代码""注意性能"这种它没法执行，等于没写。要写成能落地的具体约束，比如"时间处理统一用 dayjs""接口返回结构固定是 code、data、msg 三段""不要引入新的网络请求库"。通用的个人偏好（注释习惯、语言）放全局规则，这个项目特有的规矩放项目规则，两者别混在一起。
六、diff 把关和几个救命习惯
功能就那些，真正拉开差距的是下面这些习惯：
- 每处改动都走 diff，逐条看、逐条收，"拒绝"和"接受"一样常用。看不懂的改动别猜，直接在对话里问它"这处为什么这么改"。
- 改乱了立刻撤销或用版本控制恢复，所以开工前确认自己在独立分支上、能一键回滚------这和用 Claude Code 那篇讲的是同一条底线。
- 别在你最重要的项目里第一次试大改动，先拿个能随便删的练手项目，把面板和快捷键摸熟。
- 模型档位按活切：改名、补注释、写样板代码用快档就够；难啃的 bug、跨文件重构再切强档，别什么活都挂最贵的那档。
- 一个话题聊完就开新对话，别在聊了一两天的长会话里无限追加，必要的结论用一两句话带进新会话，比让它重发几十轮历史便宜得多。
为了方便对号入座，把高频动作整理成一张速查表：
| 动作 | 入口（mac，Win 多换 Ctrl） | 主要用来干什么 | 关键提醒 |
|---|---|---|---|
| 接受 / 拒绝补全 | Tab / Esc | 收下或放弃灰字预判 | 先扫一眼再 Tab |
| 内联改写 | Cmd+K | 选中一段就地改 | 只改选中范围，指令要具体 |
| 打开对话 | Cmd+L | 提问、解释、生成代码 | 配合 @ 精准喂上下文 |
| 引用上下文 | @ | 指定文件 / 文档 / 代码 | 只 @ 相关文件，别让它全仓库翻 |
| 多文件改动 | Composer / Agent 面板 | 跨文件改、跑命令自修 | 写死可碰与禁碰，逐文件看 diff |
| 项目约定 | 项目规则 Rules | 让生成默认贴合你的项目 | 写可执行的具体约束，别写空话 |
再附一张新手高频踩坑对照表：
| 你遇到的情况 | 多半是怎么回事 | 怎么办 |
|---|---|---|
| 补全总是不对味 | 上下文没给够、风格不统一 | 打开相关文件，先手动定好命名和骨架，再让它顺着补 |
| 一改就动一大片、收不住 | 用了多文件模式却没圈范围 | 指令写死可碰 / 禁碰文件，小步生成、逐文件 review |
| 额度掉得飞快 | 空对话让它"看整个项目"、全程挂强档 | @ 精准引用、优先内联改写、按活切档、聊完开新会话 |
| 接受后才发现它改了没让动的地方 | 闭眼全收 diff | 逐条收，删除和配置类改动人工盯，独立分支兜底 |
| 规则写了却不生效 | 规则太泛，或放错了入口 | 写成可执行的具体约束，按当期文档放到正确的规则位置 |
| 快捷键按了没反应、菜单对不上 | 版本更新、键位被占用或系统差异 | 以官方当期快捷键表为准，别死磕旧教程 |
写在最后
Cursor 的定位一直没变：坐你旁边、和你一起写的副驾。它带来的效率，不来自"替你把代码写完"，而来自你能熟练地在 Tab 补全、内联改写、@ 引用、项目规则这几个动作之间切换，让它每一下都改在你划定的范围里，再由你用 diff 把关。
手熟之后你会发现，真正省下来的不是敲键盘那点时间，而是来回切换窗口、反复返工、以及跟它"鸡同鸭讲"消耗掉的那部分精力。工具还是那个工具，差别全在你会不会"派活"。
评论区留个数字，看看你现在用到第几层：1、基本只用 Tab 补全；2、开始常用内联改写（Cmd+K）；3、经常 @ 引用、用多文件面板；4、已经配好项目规则在跑。 票数最高的那档，我下一篇把对应功能再往深里拆。另外，"怎么判断一个接入渠道靠不靠谱"的避坑清单也在排期里，那篇只讲怎么分辨、不推任何东西。
觉得有用，点个赞、收藏起来对着练；顺手关注一下，这个系列我一篇篇往下更。