正确使用Cursor

我们直奔主题：把 Ryo Lu 的 12 条 Cursor 使用建议拆成可执行步骤与示例，既有思路也有落地方法，方便你在真实项目里马上复用。

1. 设定规则

一句总结：要用规则喂 Cursor，而不是随口问它

  • 为什么重要：清晰规则为 AI 提供稳定的上下文，减少“跑偏”与重复修复成本。

  • 可执行步骤：

    1. 在项目根目录创建 .cursor/rules 或 AGENTS.md；

    2. 首次写 5–10 条关键约束（技术栈、命名规范、禁止项）；

    3. 用 /generate rules 试跑一次，查看结果并调整。

  • 小例子：把禁止使用 var、强制 ES6、数据库列用 snake_case 这些写进规则，AI 的输出会更可预测。

2. 细化提示

提示写成“Mini Spec”，避免模糊描述，如同编写一份迷你规格书般详细说明一般。

  • 核心要点：模糊提示 = 模糊代码。提示结构推荐：技术栈 + 行为要求 + 限制条件。

  • 示例对比：

    • 错：写一个登录功能。

    • 对：用 React + TypeScript 实现 OAuth2 登录组件，不依赖第三方库，按钮支持暗黑模式。

  • 实操建议：习惯把示例输入输出与边界条件写清楚。

3. 逐文件处理，分块做“生成 → 测试 → 评审”

  • 原则：每次只处理一个文件，完成“生成 → 测试 → 评审”的循环后再推进下一个文件。

  • 好处：更易定位问题、测试回归更小、代码评审更快。

4. 测试驱动

先编写测试并固定规则，再让 Cursor持续生成代码直至所有测试通过。（TDD）

  • 做法：

    1. 手动写好单元测试（Jest、Vitest 等）并确认失败；

    2. 让 Cursor 根据测试生成实现，执行测试，修复不通过项直到全部通过。

  • 优势：测试驱动能把需求从“自然语言”转换为“机器可验证”的断言。

俗话说得好：测试写得好，代码错不了！如果错了，那一定是产品经理给的需求case不完善！

5. 手动评审并把修正结果“教给” Cursor

  • 原则：修复比解释更有效。每次修改后加注释让 AI 学习，例如用 @fixed 标注正确写法。

AI干出来的代码，有些时候会自由发挥过多，跑偏了。这时最快的方式是"改"。

小建议：如果你让AI自己改问题，一旦超过两三次都没修改正确，请自己手动介入~

  • 示例：如果忘了给 API 添加 JWT，就在修正处加注释说明“所有 API 必须包含 JWT 鉴权头”。

6. 用 @ 符号精确定位上下文，减少误伤

  • 常用定位：

    • @file:src/components/Button.tsx

    • @folder:src/utils

    • @git#main（与主分支对比）

也就是常用的@文件，@文件夹，@git分支。

  • 扩展用法：@web 联网搜索、@docs 引用外部文档，让 Cursor 获取最新规范。

7. 保存文档

将设计文档和检查清单保存在目录.cursor/（.cursor/docs）下，确保 AI代理能全面掌握后续任务所需的上下文信息。

  • 内容建议：架构图、API 规范、数据模型、关键设计决策、示例文件。

  • 原因：为 Agent 提供完整背景，减少每次沟通的上下文传递成本。

8. 重写修正

如果代码有错误，那就直接改！改比长篇解释更有效

  • 事实情况是：AI 从你实际修改中学得更快。把正确版本提交，并用注释说明“为什么这样做”。

AI有时候比较固执（倔强），你得调教它~

9. 用好历史记录（/history），把常用 Prompt 做成模板

  • 做法：

    • 定期把高质量对话（解决方案、修复流程）整理为模板；

    • /history 调出旧对话复用，避免重复从头描述。

10. 按需选择模型：不同模型有不同强项

这个确实比较考验使用心得！

大部分的小伙伴都说最近出的Claude Opus 4.5很好，很强大！这不可否认，但不是每个模型都能在各个方面全面领先的！

那最新的Claude Opus 4.5和Gemini 3 Pro来说。前者在复杂业务逻辑上，严谨度更高，表现更好；后者在前端页面交互和体验度上，效果又更棒！

因此，选模型很重要！不同模型有不同优势，根据任务类型选择合适的模型。

  • Gemini：高精准度 —— 适合算法实现

  • Claude：理解更广泛 —— 适合创意型任务（严禁逻辑/文案）

  • DeepSeek：在讨论和科研场景表现优异

当然，有其他的模型供大家使用。这三个，我个人比较常用。

11. 遇到陌生栈，把官方文档贴给 Cursor 并要求逐行解释

这种情况比较麻烦！因为不熟悉，弄好了，大功一件；弄砸了，可能领导会觉得能力不行！

但我们熟悉的技术栈，不也是从0开始的吗？

  • 操作步骤：

    1. 把文档链接或片段放入对话（如 @https://xxx/docs）；

    2. 要求 Cursor 逐行解释报错并给修复建议；

    3. 把得到的解释加入项目文档或注释中。

12. 项目索引

大项目建议“非工作时间进行首次索引”，并用 scope 聚焦

  • 背景：对于代码量巨大的项目，Cursor AI 工具首次进行全量索引（理解整个项目的结构和依赖关系）可能需要较长时间，可能导致噪音和性能问题。

  • 策略：

    • 预索引：先让 Cursor 建立索引（夜间跑或空闲时跑）；

    • 运行时用 @scope:core 限定关注模块，提高响应速度。

额外实用技巧（速查）

  • 四大功能模块要熟：Tab（补全）、Inline Chat（即时修改）、Ask（项目问答）、Agent（自动化执行）。

  • 终端对话：用 Command/Ctrl + K 直接让 Cursor 生成并执行命令。

  • 一键生成提交信息：让 Cursor 自动生成规范 commit message，节省写描述时间。

  • Checkpoint：AI 修改出问题时快速回滚到稳定点，减少损失。

基础快捷键速查（提升效率必备）

新手如何把这些建议落地（15 分钟实操清单）

  1. 在项目根建 .cursor/rules 或 AGENTS.md，写 5 条核心规则（技术栈、命名、鉴权、测试规范、提交规范）。（5 分钟）

  2. 为团队约定提示模板：Mini Spec 模板存入 .cursor/docs。示例模板包含输入/输出/异常处理。（5 分钟）

  3. 设定一个小模块为试验场：写测试 → 让 Cursor 完成实现 → 人工评审并注释修正。把修正写入规则中。 （5–10 分钟）

切记：第一把，不要想着把这份实操做得十分完美，而是想着把它先做出来。

结语：我们成为战略家，让 AI 做战术

Ryo Lu 的核心观点并不复杂：你要做“规则与架构的设计师”，把繁琐的实现细节交给 AI。

在团队里推广这些做法时，记住：多写文档、少聊天。把规则写清楚，提供明确指导，Cursor 才能稳定输出可复用的代码。