Cursor使用

我最开始使用Cursor的时候，Cursor还不火，还能换邮箱薅羊毛，后来出了Composer，Agent，然后越来越火，后来代码补全已经几乎没人用了，很多之前的策略已经逐渐淘汰。下面的内容是我之前总结的，已经更新到了最新版本。这篇文章是我写的，最早发布在Medium，翻译为中文后在知乎回答竟然被标记为了AI创作内容 -_-。

2026.1.27 Update: 建议更新到最新版本，新版本中内置支持 Bash； Browser；Code Explore 这几个subagent，可以有效控制上下文，提升token使用效率。另外支持了Skills，这让Cursor有了实现AIDLC的技术支撑，后续我会写一篇文章专门讲。

本文概述了在 2026 年高效使用 Cursor 的推荐工作流、优化策略及最佳实践。遵循这些准则将有助于减少 Token 用量，提高代码生成准确性，并简化开发流程。

Ⅰ. 核心原则

开发者是代码的终极责任人

AI 只是一个辅助工具。开发者最终需要对代码的正确性、安全性和可维护性负责。永远不要盲目信任 AI 的输出，保持代码审查的习惯。

Ⅱ. 规划与执行策略

规划先行

准则：在让 Agent 编写生产代码之前，先使用 Cursor 原生的 Plan Mode（规划模式） 来明确需求。这对复杂需求尤为重要。

为什么？ 直接开始写代码可能会导致“管窥效应”（Tunnel Vision）， 可能一击命中，也可能走上弯路浪费时间。一个专门的规划阶段会强制 AI 先研究代码库、检查依赖关系并勾勒出架构。

实操：

  • 阶段 1：规划模式 (Plan Mode)
  1. 在 Composer/Agent 中，切换到 Plan Mode。
  2. 描述你的目标。Agent 会扫描相关文件并生成分步计划。
  3. 审查与完善：如果逻辑有缺陷，反馈给 Agent 让其修改计划。
  • 阶段 2：执行 (Agent)

注：核心原则是“规划先行”。你也可以使用像 OpenSpec 或 SpecKit 这样的外部规范框架来生成正式的 Spec。Cursor 的 Plan Mode 本质上是这一理念的轻量级集成实现。当然，这些都是Prompt Engineering，你也可以自己在提示词中控制Agent，让他先做规划，并且和你确认它不确定的问题。

Ⅲ. 上下文与规则配置

使用上下文感知的项目规则

准则：使用 .cursor/rules/ 目录配合 .mdc 文件来提供细粒度的上下文。

为什么？ 规则应当被精准加载。globs 确保当你编辑特定文件时规则自动加载，而 description 允许 Agent 在需要时智能地拉取规则。

实操： 在 .cursor/rules/ 中创建mdc文件。可以直接让 Cursor 帮你创建。如果文件较长可以让Cursor根据功能分为多个文件。 [2026.1.26 更新] 新版本已经支持Skills，更好用，Cursor官方提供了 migrate-to-skills 方法支持将 rule和command迁移为Skills。

拆分大文件

准则：立即重构大文件；以此为目标进行模块化。

为什么？ 大文件会产生巨大的上下文开销。AI 必须读取整个文件才能理解一个小小的更改。

实操：如果文件过大，要求 AI 帮助重构并将其拆分为单一职责的模块。（随着技术进步，如LSP等的实现，这一点之后可能不再需要）

忽略无关文件

准则：使用 [.cursorignore](https://zhida.zhihu.com/search?content_id=269335812&content_type=Article&match_order=1&q=.cursorignore&zhida_source=entity) 排除那些 git 没有忽略但在 AI 上下文中不需要的文件。

为什么？ Cursor 默认遵循 .gitignore。使用 .cursorignore 来处理那些你需要提交（git 跟踪）但想对 AI 隐藏的文件（例如大型测试数据文件或特定的配置模板）。

实操：在 .cursorignore 中添加严格的排除项以防止 Token 浪费。

禁用闲置的并且不支持延迟加载的 MCP

准则：在不主动使用时关闭不支持延迟加载的 MCP。

为什么？：不支持延迟加载的闲置MCP 配置会消耗 Token 并分散模型的注意力。

实操：仅在专门与外部工具交互时（例如 JIRA MCP）启用 MCP 工具。对于支持延迟加载MCP可以保留，只在命中meta信息时加载必要上下文。

控制输出冗余

准则：明确限制 AI 生成不必要的总结、解释或文档，除非你主动要求。

为什么？：LLM 往往很啰嗦。由于输出 Token 通常比输入 Token 更贵且更慢，冗长的回复会浪费资源并弄乱聊天记录。

实操：在用户规则（User Rules）中添加一条来限制文档输出。例如：“仅在明确要求时才创建新文档。”

Ⅳ. 工作流与交互

拆分任务与管理会话

准则：将复杂功能分解为原子子任务，并频繁开启新对话（New Chat）。

为什么？：随着聊天记录的增长，LLM 的表现会下降。一个新的对话意味着清除了噪点。

实操：不要在一个长对话中完成整个功能，而是为“API 实现”、“前端逻辑”和“UI 样式”创建单独的对话。

使用 @

准则：使用 @ 符号手动缩小上下文范围。

为什么？：防止 AI 猜测（并产生幻觉）它需要读取哪些文件。

实操：显式标记文件：“更新 @AuthService.ts 以包含新的登录逻辑。”

控制终端噪音

准则：保持日志清洁，并使用高性价比的模型来处理执行任务。

为什么？：Agent 会读取终端输出来进行调试。冗长的日志会燃烧 Token。仅为了读取一个编译错误而使用高端模型是浪费。

实操：[2026.1.26更新] 下载最新版本Cursor，其已经内置Bash subagent，可以很好的解决这个问题。

Ⅴ. 故障排除与优化

陷入僵局时的使用重置策略

准则：如果一个 Bug 在多次尝试后仍未修复，停止并重置。

为什么？：上下文窗口已经被失败的尝试污染了。继续下去只会导致死循环和糟糕的代码。

实操：删除最近的消息或开始一个新的对话。使用更具体的约束条件编辑你的 Prompt。选择 Continue 前先 revert 代码。

拒绝并让AI自己改正

准则：使用“Reject（拒绝）”按钮或明确说不正确。

为什么？：你自己默默修复 AI 的糟糕代码并不能教会模型任何东西。

实操：如果输出是错误的，拒绝更改并解释原因，强制其自我修正。这同样适用于你想修改现有代码时。

Ⅵ. 处理大型遗留项目

通过日志增强理解

准则：利用 AI 在遗留代码中植入日志以追踪执行流。

为什么？：遗留系统通常包含“僵尸逻辑”（已废弃/死亡但仍存在的代码）和误导性的描述或者注释。日志提供了实际运行情况的“真实数据（Ground Truth）”，而不是凭空猜测。

实操：

  1. 指示 AI 增强核心逻辑的日志记录。
  2. 运行应用程序并分析日志，验证哪些代码块实际上被命中了。
  3. 要求 AI 根据这些发现生成报告。

Ⅶ. 模型选择策略

准则：根据任务难度匹配模型，以优化成本和速度。

复杂逻辑 / 规划 / 深度调试

  • 推荐模型：[Claude 4.5 Sonnet](https://zhida.zhihu.com/search?content_id=269335812&content_type=Article&match_order=1&q=Claude+4.5+Sonnet&zhida_source=entity), [GPT-5.2](https://zhida.zhihu.com/search?content_id=269335812&content_type=Article&match_order=1&q=GPT-5.2&zhida_source=entity), Gemini 3 Pro
  • 使用场景：制定计划、重构、架构决策。

简单编辑 / 样板代码 / 测试执行

  • 推荐模型：grok-code, Gemini 3 Flash
  • 使用场景：快速修复、编写简单的单元测试、解释终端错误。

如果你不确定复杂度

  • 使用 Auto 模式。