探索处理大型代码库的有效模式、技术原理和设计思想，提升开发效率与代码质量
处理大型代码库引入了一系列与小项目不同的挑战。根据我们扩展Cursor自身代码库的经验以及管理大型代码库客户的见解，我们发现了一些处理增加复杂性的有用模式。
Cursor通过提供智能工具和工作流程，帮助开发团队有效应对这些挑战，提高大型代码库的开发效率和可维护性。
导航大型代码库，尤其是对您来说不熟悉的代码库，可能具有挑战性。您通常需要通过grep、搜索和点击来查找代码库中您要寻找的特定部分。使用Chat，您可以开始提问来找到您要寻找的内容，并获得其工作原理的详细解释。
Chat功能通过理解代码的语义和结构，而不仅仅是文本匹配，能够提供更精准的搜索结果和解释，大大降低了理解大型代码库的门槛。
如果您要向代码库中引入新的协作者，您会给他们什么上下文信息，以确保他们能够开始做出有意义的贡献？您对这个问题的答案很可能对Cursor理解也是有价值的信息。
对于每个组织或项目，都存在一些潜在知识，这些知识可能没有完全记录在您的文档中。有效使用规则是确保Cursor获得全貌的最佳方式。
createDecorator定义新的服务接口，并确保包含_serviceBrand以避免错误。Disposable，并使用registerSingleton将其注册为单例。
// 创建服务接口
export const IMyService = createDecorator<IMyService>('myService');
export interface IMyService {
_serviceBrand: undefined;
doSomething(): Promise<void>;
}
// 服务实现
export class MyService extends Disposable implements IMyService {
_serviceBrand: undefined;
constructor() {
super();
}
async doSomething(): Promise<void> {
// 实现细节
}
}
// 注册单例
registerSingleton(IMyService, MyService);
如果您有希望确保Cursor遵循的通用格式模式，可以考虑基于全局模式自动附加规则。
- 使用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。
使用Ask模式增强计划创建过程的一种方法。要创建计划，请在Cursor中打开Ask模式，并转储您从项目管理系统、内部文档或零散想法中获得的任何上下文。考虑您在代码库中已经知道要包含的文件和依赖项。这可以是一个包含您想要集成的代码片段的文件，或者可能是一个整个文件夹。
- 创建一个关于我们应该如何创建新功能的计划（就像@existingfeature.ts一样）
- 如果有任何不清楚的地方，问我问题（最多3个）
- 确保搜索代码库
@Past Chats（我之前的探索提示）
这里是来自[项目管理工具]的更多上下文：
[粘贴的工单描述]
我们要求模型创建计划并通过向人类提问来收集上下文，引用任何早期的探索提示以及工单描述。推荐使用像claude-3.7-sonnet、gemini-2.5-pro或o3这样的思考模型，因为它们可以理解更改的意图并更好地综合计划。
由此，您可以在Cursor的帮助下迭代制定计划，然后再开始实施。
有效使用Cursor的最重要的技能之一就是为工作选择合适的工具。思考您要完成的任务，并选择能保持您流畅工作的方法。
| 工具 | 使用场景 | 优势 | 局限性 |
|---|---|---|---|
| Tab | 快速、手动更改 | 完全控制，快速 | 单文件 |
| Inline Edit | 单个文件中的范围更改 | 专注的编辑 | 单文件 |
| Chat | 较大的多文件更改 | 自动收集上下文，深度编辑 | 较慢，上下文密集 |
每个工具都有其最佳应用场景：
当您使用Chat模式（可能感觉有点慢但非常强大）时，通过提供良好的上下文来帮助它帮助您。使用@files指向您想要模拟的类似代码，或@folder给它更好的项目结构理解。不要害怕将更大的更改分解成更小的块 - 开始新的聊天有助于保持专注和高效。
通过合理选择和使用这些工具，您可以显著提高在大型代码库中的工作效率，减少上下文切换，并保持开发流程的连贯性。
还没有人回复，快来发表你的看法吧！