从“会用”到“可控”：进阶用户真正卡住的点
你已经会用 Cursor 了，但可能还会遇到这些“熟练工的烦恼”：
- Composer 改动范围越来越大：本来只想加一个参数，结果改了一片文件
- @codebase/索引用起来不稳定：有时能找到关键实现，有时像没看见一样
- 输出风格不一致：命名/目录/注释/测试策略，跟团队不统一
- Agent 想用又不敢用：担心它跑危险命令、改错文件
这篇文章不讲概念，重点讲一件事：如何把 Cursor 变成一个可预测、可审查、可回滚的生产力工具。
一套控制模型：任务控制 × 上下文控制 × 变更控制
高质量产出靠的不是“更花哨提示词”，而是三层控制：
- 任务控制：先把目标拆成可验证的小回合
- 上下文控制：只给必要上下文，不让噪声喂进去
- 变更控制：先计划后补丁，文件范围可审查可回滚
只要三层里有一层失控，就会出现“看起来很努力，结果不可用”。
三种入口的正确分工：Tab / Cmd+K / Cmd+I
| 入口 | 适合做什么 | 你应该怎么提问 |
|---|---|---|
| Tab（补全） | 你已经知道写什么，只是想省打字 | 让上下文更清晰：写好函数名、参数名、注释 |
Cmd+K（内联编辑） | 改一小段、重构、补类型、加边界 | 强约束：行为不变 / 不改 API / 只改选中范围 |
Cmd+I（Composer） | 多文件改动、功能落地、跨模块重构 | 先要改动计划（文件清单 + 修改点），确认后再生成 |
经验法则：改动文件 ≤ 2 时优先 Cmd+K，≥ 3 时再考虑 Cmd+I。
Composer（Cmd+I）实战：四阶段流程
阶段 A：定义边界（不写代码）
你要先给出：
- 目标
- 允许改动的文件范围
- 禁止触碰的目录/配置
- 验收标准
可复制开场：
目标：实现 X。
范围：只允许修改 A、B、C 文件。
禁止：不要改构建配置、依赖与目录结构。
请先输出改动计划，不要直接给代码。
阶段 B：先出计划（可审查）
计划至少包含：
- 文件清单
- 每个文件改动点
- 风险点（可能影响的调用方）
- 验证步骤
阶段 C：小批次执行（可中断）
不要一次把 8 个文件全改完。建议 2～3 文件/轮，轮次之间做快速验证。
阶段 D：收尾固化（可复用）
把本轮“有效提示词 + 验证清单 + 易错点”沉淀进规则文件，避免下次重复踩坑。
5 个高频实战脚本（可直接复制）
场景 1：跨文件加功能（最常见）
实现功能：X。
先输出改动计划：文件清单 + 修改点 + 验证步骤。
约束：不新增依赖，不改目录结构，不破坏现有 API。
确认后再生成补丁。
场景 2：线上 bug 热修
目标：修复 [错误现象]。
请先给 5 个可能原因（按概率排序）+ 最短排查路径。
范围：仅允许改动与该调用链直接相关文件。
输出：最小修复补丁 + 回归验证清单。
场景 3：重构但行为不变
对选中代码做可读性重构。
约束：行为不变、输入输出不变、对外 API 不变。
请同时列出“重构前后风险点”。
场景 4：补类型与错误处理
仅在当前文件补齐 TypeScript 类型与错误处理。
不要改业务分支，不要新增依赖。
输出：改动说明 + 为什么不会影响现有调用。
场景 5：代码评审预检
请按“正确性/可维护性/边界条件/回归风险”4 个维度 review 当前改动，
每个维度给出：问题 -> 影响 -> 建议。
索引与 @codebase：上下文越准，答案越稳
Cursor 在大项目里好不好用，很大程度取决于索引是否干净。
1）索引范围：少就是多
原则很简单：只索引你会问的那部分。
你可以用 .cursorignore 排除依赖、构建产物、缓存、数据大文件。模板与踩坑见：
2）@codebase 的问法：别让问题太“宽”
更有效的问法通常长这样：
- “@codebase 项目里哪里做了登录态持久化？请列出文件与入口函数。”
- “@codebase 找出所有把 token 写入 localStorage 的位置，并说明调用链。”
无效问法通常是：
- “@codebase 这个项目是干什么的？”（太宽）
- “@codebase 所有相关代码”（没有可执行的目标）
建议把查询写成：对象 + 位置 + 输出格式。
例如：
- 对象：
token 持久化 - 位置：
前端登录流程 - 输出格式：
列文件 + 入口函数 + 调用链
Rules：把“口头要求”升级为“项目约束”
Cursor 用久了会发现：你不是缺“提示词”，你缺的是一份团队化的“固定要求”。
这类要求最适合写进 .cursorrules：
- 技术栈与目录结构（让它别乱引框架）
- 禁止改动范围（例如不要动配置、不要跨包重构）
- 输出格式（先计划再补丁、必须附验证步骤）
推荐直接参考模板：
在团队协作里，Rules 最有价值的不是“写得多”，而是这三条：
- 先计划后补丁
- 禁止跨目录重构
- 不新增依赖（或必须先解释）
Agent：什么时候值得用（以及怎么用得更安心）
如果你的任务需要“串联多步动作”（创建文件、修改配置、运行命令、修复报错），Agent 才值得上场。
给 Agent 增加“风险闸门”会更稳：
- 先列命令，不直接执行
- 危险命令必须二次确认（删除、覆盖、批量替换）
- 每轮执行后都要给“已改文件清单 + 下一步建议”
- 保持可回滚（分支/提交/暂存）
当任务满足以下任意一条，再用 Agent：
- 需要串联“改代码 + 跑命令 + 修报错”
- 涉及重复性操作（批量改名、批量替换、脚手架初始化）
- 需要在多轮反馈后持续推进
进阶排查：响应慢、跑偏、补全不准
1）AI 响应慢
优先检查三件事：
- 索引是不是把不该索引的东西也算进去了
- 你是不是同时打开了太多无关文件
- 网络/代理是否稳定
2）回答跑偏
典型原因是“范围没钉死”。你可以把问题改写成：
仅基于当前仓库回答。先列出你准备参考的文件/模块，再给出最短可行的修改方案。
再加一条会更稳：
如果信息不足，请先提问，不要猜。
3）补全不准
Tab 补全靠的是“局部上下文”。当补全不准时，优先切换到 Cmd+K，给一个明确目标与约束，成功率会高很多。
质量评估：怎么判断你真的“进阶”了
可以用这 4 个指标观察一周：
- 单次任务平均改动文件数是否下降
- 因 AI 改动导致的回滚次数是否下降
- 从需求到可验收的平均耗时是否下降
- Code Review 一次通过率是否提升
如果只有“生成速度”变快，但回滚和返工没下降，说明流程还没进入可控状态。
延伸阅读
- 新手入门与快捷键： Cursor 使用教程（2026）
- 另一篇深度玩法： Cursor 编辑器深度玩法：AI 原生 IDE 的正确打开方式
- Copilot 相关： GitHub Copilot 高效使用技巧
