Cursor怎么配置项目规则？从代码上下文到补全与调试的实用指南

先分清：项目规则不是一次性任务描述

普通提示词回答“这次要做什么”，项目规则则提供可重复使用的约定，例如技术栈、文件放置位置、命名方式和测试要求。它适合记录团队长期遵循的做法，不适合堆放完整业务文档或临时错误日志。规则能引导生成结果，但不能保证模型始终遵守，最终仍需检查代码。

Cursor支持在项目中通过.cursor/rules目录组织项目规则。具体规则格式和应用方式应以当前安装版本的说明为准，创建时可使用编辑器提供的规则功能。不要把一份网上复制的配置直接当作所有版本通用的模板。

按现有代码写规则，而不是让AI猜规范

开始配置前，先检查依赖清单、入口文件、目录结构和已有测试。以下以一个实际采用React与TypeScript、并已有相关目录的前端项目为例；如果项目结构不同，应替换为真实路径。

一份规则应写清哪些内容

• 技术栈：使用React与TypeScript，沿用项目现有路由和请求封装，不自行引入新的状态管理库。
• 目录：页面放在src/pages，共用组件放在src/components，接口请求放在src/api；先查找已有实现，再决定是否新增文件。
• 命名：组件采用PascalCase，普通变量和函数采用camelCase；文件命名与同目录现有代码一致。
• 类型与交互：复用已有接口类型，不猜测字段；异步页面应处理加载、失败和空数据状态。
• 改动边界：只修改任务涉及的文件；新增依赖、调整公共接口或改动全局配置前，先说明原因。

这些内容可以作为规则正文的起点。若项目包含前端、后端等多个区域，应按适用范围拆分规则，并使用当前版本支持的范围设置，避免前端约定影响后端代码。规则文件可纳入版本管理，让团队共同维护。

控制上下文：给足依据，但不塞入整个仓库

上下文应围绕当前任务选择。开发页面时，通常先提供目标页面、相关接口封装、响应类型及一个相似页面；排查故障时，再补充错误日志和调用链上的文件。构建产物、第三方依赖、大型历史日志通常不需要加入。

可以通过文件引用等方式指定相关材料，具体入口以当前界面为准。提交任务前，检查附带文件是否正确。材料不足时，要求AI先列出需要查看的文件，不要允许它用臆测补全接口或业务规则。

示例：根据现有接口补充页面

假设src/api/users.ts已包含列表查询，src/pages/Users.tsx是待完善页面。可以这样描述任务：“阅读这两个文件和已有列表页，按项目规则增加分页与加载状态。复用已有响应类型，不修改接口封装；如果分页参数不明确，先指出缺失信息。修改前列出计划涉及的文件。”

这样的请求同时交代了目标、依据和边界，比“帮我完成用户页面”更容易得到可核查的改动。

把补全、解释和重构分开使用

• 代码补全：在目标文件中编辑，让邻近代码提供局部线索。逐段接受建议，检查变量来源、类型和返回值，不连续接受未经阅读的大段代码。
• 代码解释：选定函数并提供必要的调用方，要求说明输入、输出、副作用和异常路径；对无法从代码确认的结论标注不确定性。
• 代码重构：明确需要保持的外部行为，例如“不改变导出接口，只提取重复校验逻辑”。先查看修改计划，再检查差异和测试结果。

定向调试：错误日志必须连接到相关代码

调试时提供复现步骤、预期结果、实际结果、脱敏后的错误日志，以及相关组件和请求函数。例如页面出现读取undefined属性的异常，应先定位堆栈对应行，再检查响应结构、初始状态和渲染条件，而不是直接要求重写页面。

可要求AI“先区分已确认事实与待验证假设，再提出最小修复方案”。修复后用相同操作复现验证，并补测正常响应、空数据和请求失败场景；异常消失不等于业务结果正确。

提交前检查代码与敏感信息

审查差异时，重点检查是否增加了无关文件、依赖或接口变更，再运行项目已有的类型检查、静态检查和测试，并手动验证关键交互。不要将生成代码未经测试直接上线。

不要把密钥、生产连接串或个人数据放进规则和提示词。可用.cursorignore限制相关文件被索引或纳入AI上下文，但它不是完整的安全隔离：终端命令及其他工具仍可能访问文件。敏感操作应结合访问权限、工具授权和独立工作环境控制，日志分享前也要脱敏。