Cursor 装好之后，多数人的使用停留在"Tab 补全真香"阶段，然后遇到复杂任务就退回网页版聊天。其实 Cursor 的四套交互各有明确的适用场景，用对了效率能再翻一倍。
一、四种交互方式的分工
| 交互 | 快捷键 | 适合场景 |
|---|---|---|
| Tab 补全 | Tab | 写重复性代码、顺着思路续写 |
| Inline Edit | Cmd+K | 选中一小段代码局部修改 |
| Chat | Cmd+L | 提问、解释代码、方案讨论 |
| Composer/Agent | Cmd+I | 跨多文件的功能开发 |
新手最大的误区是用 Chat 干 Composer 的活：在聊天框里让它"重构整个模块"，然后手动把代码一段段贴回文件。跨文件改动请直接用 Composer，它会自己读相关文件、生成 diff，你逐个确认即可。
二、Inline Edit 的高效姿势
选中代码后 Cmd+K，指令要具体：
> 把这个函数改成异步的，调用处用 await，错误用 try/catch 包裹
Inline Edit 的上下文只有你选中的代码和附近内容，所以指令里要把意图说全。改完后 diff 视图里逐行确认，别闭眼全收。
三、用 .cursor/rules 固定项目约定
在项目根目录建 .cursor/rules 目录，放 Markdown 规则文件，比如 style.mdc：
---
description: 项目代码约定
alwaysApply: true
---
- 所有金额以"分"为单位存储，变量名以 _cents 结尾
- API 路由必须做参数校验，统一返回 { code, message, data }
- 组件使用函数式写法，禁用类组件
alwaysApply: true 的规则每次会话都会注入，相当于给 AI 的入职文档。团队约定写进去之后，AI 生成代码的"风格漂移"会明显减少。
四、让上下文可控：@ 引用
Chat 和 Composer 里用 @ 精确引用上下文：
@文件：引用具体文件，比让它自己全盘搜索更准@文件夹：给一个模块的完整上下文@Docs：引用官方文档（可添加项目用到的框架文档）@Web：让它联网查最新资料
上下文给得越准，废话越少。一个经验：宁可多 @ 两个文件，也不要让它自己猜。
五、大任务的正确节奏
- 先在 Chat 里讨论方案，确定改哪几个文件
- 切到 Composer，把方案贴进去作为任务描述，附上讨论中确定的文件
- 生成后逐个 diff 确认，跑测试
- 测试不过就把报错原样贴回 Composer 让它修
六、实战：用 Cursor 修一个真实 Bug
走一遍完整流程。现象：订单列表页偶发白屏，控制台报 Cannot read properties of undefined (reading 'map')。
- Chat 里贴上报错和组件文件，问："哪些数据路径可能导致 list 为 undefined？"它列出三处：接口返回空、分页参数越界、加载竞态。
- 让它"先别改代码，给每个可能原因写一个验证方法"。按它给的思路加日志，确认是加载竞态——切换筛选时旧请求后返回覆盖了新数据。
- Cmd+K 选中数据请求段，指令："用请求序号或 AbortController 丢弃过期响应"。生成 diff，确认逻辑无误。
- 跑测试，再手动复现原操作路径验证。
全程 15 分钟。注意第 2 步：先定位再动手，是人和 AI 协作都适用的纪律。
注意事项
- AI 重构后一定跑测试，没有测试的模块先补关键路径测试
- 长会话上下文会稀释，任务完成后开新会话比一直续聊效果好
- 敏感信息（密钥、客户数据）不要贴进对话，注意遥测与隐私设置
小结
Cursor 的核心不是"哪个按钮"，而是把任务拆到合适的交互层级：补全交给 Tab，局部改交给 Cmd+K，讨论交给 Chat，跨文件交给 Composer，长期约定交给 rules。分好层，它就是真正的结对搭档。