Cursor AI 编程助手使用心得：规则配置与高效协作

📌 前言

Cursor 是一款基于 VS Code 的 AI 原生代码编辑器，内置了强大的 AI 编程助手。经过一段时间的使用，我总结了一套通过自定义规则来规范和提升 AI 协作效率的方法。本文将分享这些经验。

🎯 为什么需要配置规则

AI 编程助手虽然强大，但如果没有明确的约束和指引，生成的代码可能会出现以下问题：

• 代码风格不一致：不同次对话生成的代码风格差异大
• 缺乏架构意识：AI 倾向于写大函数、大文件，容易导致高耦合
• 文档与代码脱节：改代码不更新注释，文档逐渐失效
• 提交信息随意：Git 提交信息质量参差不齐

通过在项目中配置 .cursor/rules/ 目录下的规则文件，可以让 AI 始终遵循你设定的最佳实践。

📂 规则文件结构

在项目根目录创建 .cursor/rules/ 文件夹，每个规则使用 .mdc（Markdown Cursor）格式编写。我配置了以下 5 个核心规则：

1
2
3
4
5
6

.cursor/rules/
├── add-new-feature.mdc        # 先规划后编码
├── code-length-limit.mdc      # 代码长度与低耦合准则
├── low-coupling-architecture.mdc  # 低耦合架构原则
├── flasgger-route-docstring.mdc   # API 文档规范
└── git-commit.mdc             # Git 提交规范

📋 核心规则详解

规则一：先规划，后编码

文件：add-new-feature.mdc

这条规则是 AI 协作工作流的基石。当提出新功能或重大变更时，AI 必须先创建实施计划文档，等待我批准后才能开始编码。

运作流程：

1. 分析需求：先通读相关代码，理解现有实现
2. 创建计划：在 docs/plan/ 下生成 implementation_plan_*.md，内容包括：
   • 需求概述
   • 文件结构变更
   • 核心组件/函数设计
   • 数据流与逻辑
   • 问题与澄清
3. 等待批准：提交后必须等明确批准指令
4. 执行编码：严格按照计划实现

💡 心得：这个流程看起来增加了步骤，但实际上大大减少了返工。AI 在写计划时就能发现潜在的矛盾和遗漏，而不是写到一半才发现方向不对。

规则二：代码长度限制

文件：code-length-limit.mdc

防止 AI 生成过于臃肿的文件和函数：

执行方式：

• 新建或修改代码前，先检查文件行数
• 接近限制时主动提出拆分方案
• 按职责拆分，而不是机械切割

💡 心得：这条规则尤其重要。AI 天然倾向于把所有逻辑写在一个文件、一个函数里。有了这个限制，AI 会主动思考如何拆分为多个模块，代码可读性显著提升。

规则三：低耦合架构原则

文件：low-coupling-architecture.mdc

从架构层面补充代码长度限制的不足，核心原则包括：

1. 单一职责：每个模块只做一件事
2. 依赖方向清晰：避免循环依赖，保持单向调用链
3. 依赖注入：通过参数传递依赖，而非硬编码全局状态
4. 接口稳定：对外暴露稳定的接口，隐藏内部实现
5. 避免上帝模块：不要把所有逻辑塞进一个类或文件
6. 共享逻辑下沉：提取公共函数，而不是复制粘贴

💡 心得：文件长度限制解决的是”症状”，低耦合原则解决的是”病因”。两者配合使用效果最好——AI 会先按原则设计模块结构，再确保每个模块不超限。

规则四：API 文档规范

文件：flasgger-route-docstring.mdc

适用于 Flask 项目的路由文档规范，要求每个路由函数必须有完整的 flasgger 风格 docstring：

必须包含的内容：

• 中文功能说明（含关键业务规则）
• tags：所属模块
• parameters：所有入参的 name/type/required/description
• responses：成功和错误响应的完整 schema

核心要求：

• 改代码必须同步改 docstring
• 参数和响应结构发生变化时，文档必须跟着变
• 不允许”代码改了、注释还是旧的”

💡 心得：这条规则在使用 Cursor 开发 Flask API 时特别有用。AI 不仅帮你写路由代码，还会自动生成符合规范的 docstring，省去了手动写 API 文档的大量时间。

规则五：Git 提交规范

文件：git-commit.mdc

要求 AI 在提交代码时：

• 查看暂存区的变更内容
• 写出简洁的 commit message（不超过 200 字）
• 自动执行 git commit

💡 心得：相比 GitHub Copilot 等工具，Cursor 的规则系统可以直接控制 AI 的 Git 行为。提交时 AI 会理解变更的上下文，生成的 commit message 比手动写的更准确。

🔧 规则文件格式说明

.mdc 文件采用的是 Markdown + YAML front-matter 格式：

1
2
3
4
5
6
7
8

---
description: 简短的规则说明
globs: **/*.py        # 限定文件类型（可选）
alwaysApply: true      # 是否始终应用
---
# 规则标题

规则正文...

关键字段：

• description：规则描述，AI 会读取它来判断何时应用
• globs：文件匹配模式，例如 **/*.py 只在 Python 文件中生效
• alwaysApply: true：设置为始终应用，不限制文件类型

🚀 使用技巧总结

1. 规则要具体、可执行

❌ 不好的规则：

1

代码质量要好。

✅ 好的规则：

1

单个函数不超过 200 行。超过时应拆分为多个子函数，每个函数只负责单一职责。

2. 规则之间要互补

• code-length-limit.mdc 和 low-coupling-architecture.mdc 配合：一个管文件级别，一个管架构级别
• add-new-feature.mdc 管工作流流程，其他规则管代码质量

3. 不同项目配置不同规则

• Python/Flask 项目：加上 flasgger-route-docstring.mdc
• 前端项目：可以配置 CSS/Tailwind 相关规范
• 纯文档项目：只保留 git-commit.mdc 即可

4. 规则优先级

Cursor 的规则读取顺序是：用户规则 > 项目规则。最近的 AGENTS.md 会覆盖上级目录的规则。利用这个特性，可以为不同子项目配置不同规则。

📝 总结

通过合理配置 .cursor/rules/，可以让 Cursor AI 编程助手：

配置这些规则后，AI 从”一个能写代码的工具”变成了”一个遵循你团队规范的程序员伙伴”。

🔗 相关链接

• Cursor 官方文档
• Cursor Rules 配置指南

📢 如果本文对你有帮助，欢迎点赞收藏！如有问题欢迎在评论区留言讨论。