处理大型代码库与做小型项目相比，会遇到一套全新的挑战。基于我们在扩展 Cursor 自身代码库的实践，以及来自管理超大代码库客户的经验，我们归纳出了一些应对复杂度提升的实用模式。 在本指南中，我们会带你了解这些我们在大型代码库场景下行之有效的技巧。

​
使用 Chat 快速上手不熟悉的代码

浏览大型代码库，尤其是对你来说是新的代码库时，可能会很有挑战。你经常需要用 grep、搜索、到处点来定位你要找的具体代码部分。借助 Chat，你可以直接提问来找到目标内容，并拿到其工作原理的详细解释。 这里我们在寻找 Cursor 中代码库索引的实现细节时得到了帮助，甚至还让它给出一些示例，方便理解。

​
为领域知识编写规则

如果你要让一位新伙伴上手你的代码库，你会给 TA 哪些背景信息，才能让 TA 立刻开始做出有价值的贡献？ 你对这个问题的回答，同样是 Cursor 很需要了解的内容。每个组织或项目都有一些文档里未必完整覆盖的隐性知识。善用规则，是确保 Cursor 看清全貌的最佳方式。 比如，当你在写如何实现某个新功能或服务的指引时，不妨顺手写一条简短的规则，把它记录下来以备后查。
样板
---
description: 添加一个新的 VSCode 前端服务
---

1. **接口定义：**
   - 使用 `createDecorator` 定义一个新的服务接口，并确保包含 `_serviceBrand` 以避免报错。

2. **服务实现：**
   - 在新的 TypeScript 文件中实现该服务，继承 `Disposable`，并使用 `registerSingleton` 将其注册为单例。

3. **服务接入：**
   - 创建一个 contribution 文件用于导入并加载该服务，并在主入口进行注册。

4. **上下文集成：**
   - 更新上下文以纳入该新服务，使其可在整个应用中访问。
如果你有想让 Cursor 一定遵循的常见格式约定，可以考虑基于 glob 模式自动附加规则。
格式
---
globs: *.ts
---
- 使用 bun 作为包管理器。脚本见 [package.json](mdc:backend/reddit-eval-tool/package.json)
- 文件名使用 kebab-case
- 函数和变量名使用 camelCase
- 硬编码常量使用 UPPERCASE_SNAKE_CASE
- 优先使用 `function foo()`，而非 `const foo = () =>`
- 使用 `Array<T>`，而非 `T[]`
- 使用具名导出而非默认导出，例如（`export const variable ...`、`export function`）

​
紧贴计划制定流程

对于较大的改动，在制定精确且范围清晰的计划上投入比平时更多的思考，能显著提升 Cursor 的输出质量。 如果针对同一个提示尝试了几种不同的变体后仍然得不到理想结果，可以试着拉高视角，从零开始制定一个更详细的计划，就像给同事写一份 PRD 一样。很多时候，难点在于先弄清楚应该做什么样的改动——这更适合人来把关。有了正确的指令，我们就能把部分实现工作交给 Cursor。 用 AI 强化计划制定流程的一种方式是使用 Ask 模式。要创建计划，在 Cursor 中开启 Ask 模式，把你从项目管理系统、内部文档或零散想法中掌握的任何上下文都丢进去。想一想代码库里有哪些文件和依赖是你已经确定要包含的。可能是一个包含你想集成的代码片段的文件，或甚至是整个文件夹。 下面是一个示例提示：
规划提示
- 制定一个计划，说明我们该如何开发一个新特性（参照 @existingfeature.ts）
- 如果有不清楚的地方，向我提问（最多 3 个问题）
- 记得在代码库里搜索相关内容

@Past Chats（我之前的探索性提示）

这里还有一些来自 [project management tool] 的上下文：
[工单描述（已粘贴）]
我们让模型先拟定计划，并通过向人类提问来收集上下文，同时参考之前的探索性提示和工单描述。建议使用像 claude-3.7-sonnet、gemini-2.5-pro 或 o3 这样的思维型模型，因为它们能理解此次改动的意图，并更好地综合制定计划。 基于此，你可以在开始实现之前，借助 Cursor 迭代完善这份计划。

​
为任务选择合适的工具

高效使用 Cursor 的关键之一是为任务选对工具。想清楚你要达成什么目标，然后选择能让你保持心流的方式。
ToolUse caseStrengthLimitation
Tab快速、手动修改完全掌控，速度快仅限单文件
Inline Edit在单个文件内的局部修改聚焦编辑仅限单文件
Chat更大规模的多文件修改自动汇集上下文，深度编辑更慢、上下文重
每个工具都有它的最佳适用场景：
  • 需要快速编辑并亲自把控时，用 Tab
  • 需要对特定代码片段做聚焦修改时，Inline Edit 更合适
  • 需要 Cursor 理解更广泛上下文、进行更大改动时，用 Chat
使用 Chat 模式时（可能感觉更慢，但非常强大），通过提供充分的上下文来帮它更好地帮你。使用 @files 指向你想要仿照的相似代码，或用 @folder 帮它更好地理解项目结构。也别怕把大改动拆成更小的块——开启新的对话能让事情更聚焦、更高效。

​
要点总结

  • 缩小改动范围，别一次塞太多
  • 能给上下文就尽量给
  • 让 Chat、Inline Edit 和 Tab 各做擅长的事
  • 多开新对话
  • 规划用 Ask 模式，实现用 Agent 模式