creating-cursor-rules-skill

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Creating Cursor Rules

创建Cursor规则

You are an expert at creating effective

.cursor/rules

files that help AI assistants understand project conventions and produce better code.

您是创建高效

.cursor/rules

文件的专家，这类文件能帮助AI助手理解项目约定并生成更优质的代码。

When to Apply This Skill

何时应用此技能

Use when:

User is starting a new project and needs
```
.cursor/rules
```
setup
User wants to improve existing project rules
User asks to convert skills/guidelines to Cursor format
Team needs consistent coding standards documented

Don't use for:

One-time instructions (those can be asked directly)
User-specific preferences (those go in global settings)
Claude Code skills (this skill is specifically for Cursor rules)

适用场景：

用户启动新项目，需要设置
```
.cursor/rules
```
用户希望改进现有项目规则
用户请求将技能/准则转换为Cursor格式
团队需要记录统一的编码标准

不适用场景：

一次性指令（可直接询问）
用户特定偏好（应放在全局设置中）
Claude Code技能（本技能专门针对Cursor规则）

Core Principles

核心原则

1. Be Specific and Actionable

1. 具体且可执行

Rules should provide concrete guidance, not vague advice.

❌ BAD - Vague:

markdown

Write clean code with good practices.
Use proper TypeScript types.

✅ GOOD - Specific:

markdown

Use functional components with TypeScript.
Define prop types with interfaces, not inline types.
Extract custom hooks when logic exceeds 10 lines.

规则应提供具体指导，而非模糊建议。

❌ 错误示例 - 模糊：

markdown

使用良好实践编写整洁的代码。
使用正确的TypeScript类型。

✅ 正确示例 - 具体：

markdown

结合TypeScript使用函数式组件。
使用接口定义属性类型，而非内联类型。
当逻辑超过10行时提取自定义hooks。

2. Focus on Decisions, Not Basics

2. 聚焦决策，而非基础内容

Don't document what linters handle. Document architectural decisions.

❌ BAD - Linter territory:

markdown

Use semicolons in JavaScript.
Indent with 2 spaces.
Add trailing commas.

✅ GOOD - Decision guidance:

markdown

Choose Zustand for global state, React Context for component trees.
Use Zod for runtime validation at API boundaries only.
Prefer server components except for: forms, client-only APIs, animations.

不要记录linter已处理的内容，应记录架构决策。

❌ 错误示例 - Linter管辖范围：

markdown

在JavaScript中使用分号。
使用2个空格缩进。
添加 trailing commas。

✅ 正确示例 - 决策指导：

markdown

全局状态选择Zustand，组件树状态选择React Context。
仅在API边界使用Zod进行运行时验证。
默认优先使用服务端组件，除了：表单、仅客户端API、动画场景。

3. Organize by Concern

3. 按关注点组织

Group related rules into clear sections:

markdown

undefined

将相关规则分组到清晰的章节中：

markdown

undefined

Tech Stack

技术栈

Next.js 14 with App Router
TypeScript strict mode
Tailwind CSS for styling

Next.js 14 + App Router
TypeScript严格模式
Tailwind CSS用于样式

Code Style

代码风格

Functional components only
Named exports (no default exports)
Co-locate tests with source files

仅使用函数式组件
命名导出（禁止默认导出）
测试文件与源文件放在同一目录

Patterns

模式

Use React Server Components by default
Client components: mark with "use client" directive
Error handling: try/catch + toast notification

默认使用React Server Components
客户端组件：标记"use client"指令
错误处理：try/catch + 提示通知

Project Conventions

项目约定

API routes in app/api/
Components in components/ (flat structure)
Types in types/ (shared), components/*/types.ts (local)

undefined

API路由位于app/api/
组件位于components/（扁平结构）
类型定义：全局类型放在types/，组件本地类型放在components/*/types.ts

undefined

Rule Anatomy

规则结构

MDC Format and Metadata

MDC格式与元数据

Cursor rules are written in MDC (.mdc) format, which supports YAML frontmatter metadata and markdown content. The metadata controls how and when rules are applied.

Cursor规则采用**MDC（.mdc）**格式编写，支持YAML前置元数据和Markdown内容。元数据控制规则的应用方式和时机。

Required YAML Frontmatter

必填YAML前置内容

Every Cursor rule MUST start with YAML frontmatter between

---

markers:

yaml

---
description: Brief description of when and how to use this rule
globs: ["**/*.ts", "**/*.tsx"]
alwaysApply: false
---

每个Cursor规则必须以

---

包裹的YAML前置内容开头：

yaml

---
description: 简要说明此规则的使用场景和方式
globs: ["**/*.ts", "**/*.tsx"]
alwaysApply: false
---

Frontmatter Properties

前置内容属性

Property	Type	Required	Description
`description`	string	Yes	Brief description of the rule's purpose. Used by AI to decide relevance. Never use placeholders like `---` or empty strings.
`globs`	array	No	File patterns that trigger auto-attachment (e.g., `["*/.ts"]` ). Leave empty or omit if not using Auto Attached type.
`alwaysApply`	boolean	No	If `true` , rule is always included in context. If `false` or omitted, behavior depends on Rule Type.

属性	类型	必填	描述
`description`	字符串	是	规则用途的简要说明，AI会据此判断相关性。禁止使用 `---` 或空字符串作为占位符。
`globs`	数组	否	触发自动附加的文件模式（例如 `["*/.ts"]` ）。如果不使用自动附加类型，可留空或省略。
`alwaysApply`	布尔值	否	如果为 `true` ，规则会始终包含在上下文环境中；如果为 `false` 或省略，行为取决于规则类型。

Rule Types

规则类型

Control how rules are applied using the type dropdown in Cursor:

Rule Type	Description	When to Use
Always	Always included in model context	Core project conventions, tech stack, universal patterns that apply everywhere
Auto Attached	Included when files matching `globs` pattern are referenced	File-type specific rules (e.g., React components, API routes, test files)
Agent Requested	Available to AI, which decides whether to include it based on `description`	Contextual patterns, specialized workflows, optional conventions
Manual	Only included when explicitly mentioned using `@ruleName`	Rarely-used patterns, experimental conventions, legacy documentation

通过Cursor中的类型下拉菜单控制规则的应用方式：

规则类型	描述	使用场景
Always（始终应用）	始终包含在模型上下文环境中	核心项目约定、技术栈、全局通用模式
Auto Attached（自动附加）	当引用匹配 `globs` 模式的文件时自动包含	特定文件类型的规则（例如React组件、API路由、测试文件）
Agent Requested（AI主动调用）	可供AI使用，AI会根据 `description` 判断是否包含	上下文相关的模式、特定工作流、可选约定
Manual（手动应用）	仅当使用 `@ruleName` 显式提及才会包含	极少使用的模式、实验性约定、遗留文档

Examples by Rule Type

各规则类型示例

Always Rule (Core conventions):

yaml

---
description: TypeScript and code style conventions for the entire project
alwaysApply: true
---

Auto Attached Rule (File pattern-specific):

yaml

---
description: React component patterns and conventions
globs: ["**/components/**/*.tsx", "**/app/**/*.tsx"]
alwaysApply: false
---

Agent Requested Rule (Contextual):

yaml

---
description: RPC service boilerplate and patterns for creating new RPC endpoints
globs: []
alwaysApply: false
---

Manual Rule (Explicit invocation):

yaml

---
description: Legacy API migration patterns (deprecated, use for reference only)
globs: []
alwaysApply: false
---

Always规则（核心约定）：

yaml

---
description: 整个项目的TypeScript和代码风格约定
alwaysApply: true
---

Auto Attached规则（特定文件模式）：

yaml

---
description: React组件模式与约定
globs: ["**/components/**/*.tsx", "**/app/**/*.tsx"]
alwaysApply: false
---

Agent Requested规则（上下文相关）：

yaml

---
description: 创建新RPC端点的RPC服务模板与模式
globs: []
alwaysApply: false
---

Manual规则（显式调用）：

yaml

---
description: 遗留API迁移模式（已废弃，仅作参考）
globs: []
alwaysApply: false
---

Best Practices for Frontmatter

前置内容最佳实践

Description is mandatory - AI uses this to determine relevance. Be specific:
- ❌ Bad:
```
Backend code
```
- ✅ Good:
```
Fastify API route patterns, error handling, and validation using Zod
```

Use globs strategically - Auto-attach to relevant file types:

React components:
```
["**/*.tsx", "**/*.jsx"]
```
API routes:
```
["**/api/**/*.ts", "**/routes/**/*.ts"]
```
Tests:
```
["**/*.test.ts", "**/*.spec.ts"]
```

Avoid always applying everything - Use
```
alwaysApply: true
```
sparingly:
- ✅ Good for: Tech stack, core conventions, project structure
- ❌ Bad for: Framework-specific patterns, specialized workflows
Make Agent Requested rules discoverable - Write descriptions that help AI understand when to use:
- Include keywords: "boilerplate", "template", "pattern for X"
- Mention specific use cases: "when creating new API routes"

Description是必填项 - AI会据此判断相关性，请务必具体：
- ❌ 错误示例：
```
后端代码
```
- ✅ 正确示例：
```
使用Zod的Fastify API路由模式、错误处理和验证
```
策略性使用globs - 自动附加到相关文件类型：
- React组件：
```
["**/*.tsx", "**/*.jsx"]
```
- API路由：
```
["**/api/**/*.ts", "**/routes/**/*.ts"]
```
- 测试文件：
```
["**/*.test.ts", "**/*.spec.ts"]
```
避免全部规则始终应用 - 谨慎使用
```
alwaysApply: true
```
：
- ✅ 适用场景：技术栈、核心约定、项目结构
- ❌ 不适用场景：框架特定模式、特定工作流
让Agent Requested规则易于被发现 - 编写能帮助AI理解使用场景的描述：
- 包含关键词："boilerplate"、"template"、"X的模式"
- 提及具体使用场景："创建新API路由时"

Required Sections

必填章节

Every Cursor rule file should include these sections:

每个Cursor规则文件应包含以下章节：

1. Tech Stack Declaration

1. 技术栈声明

markdown

undefined

markdown

undefined

Tech Stack

技术栈

Framework: Next.js 14
Language: TypeScript 5.x (strict mode)
Styling: Tailwind CSS 3.x
State: Zustand
Database: PostgreSQL + Prisma
Testing: Vitest + Playwright


**Why:** Prevents AI from suggesting wrong tools/patterns.

框架：Next.js 14
语言：TypeScript 5.x（严格模式）
样式：Tailwind CSS 3.x
状态管理：Zustand
数据库：PostgreSQL + Prisma
测试：Vitest + Playwright


**原因：** 避免AI推荐错误的工具/模式。

2. Code Style Guidelines

2. 代码风格指南

markdown

undefined

markdown

undefined

Code Style

代码风格

Components: Functional with TypeScript
Props: Interface definitions, destructure in params
Hooks: Extract when logic > 10 lines
Exports: Named exports only (no default)
File naming: kebab-case.tsx

undefined

组件：结合TypeScript的函数式组件
属性：使用接口定义，在参数中解构
Hooks：当逻辑超过10行时提取为自定义Hooks
导出：仅使用命名导出（禁止默认导出）
文件命名：kebab-case.tsx

undefined

3. Common Patterns

3. 通用模式

Always include code examples, not just descriptions:

markdown

undefined

务必包含代码示例，而非仅文字描述：

markdown

undefined

Patterns

模式

Error Handling

错误处理

typescript

try {
  const result = await operation();
  toast.success('Operation completed');
  return result;
} catch (error) {
  const message = error instanceof Error ? error.message : 'Unknown error';
  toast.error(message);
  throw error; // Re-throw for caller to handle
}

typescript

try {
  const result = await operation();
  toast.success('操作完成');
  return result;
} catch (error) {
  const message = error instanceof Error ? error.message : '未知错误';
  toast.error(message);
  throw error; // 重新抛出供调用者处理
}

API Route Structure

API路由结构

typescript

// app/api/users/route.ts
export async function GET(request: Request) {
  try {
    // 1. Parse/validate input
    // 2. Check auth/permissions
    // 3. Perform operation
    // 4. Return Response
  } catch (error) {
    return new Response(JSON.stringify({ error: 'Message' }), {
      status: 500
    });
  }
}

undefined

typescript

// app/api/users/route.ts
export async function GET(request: Request) {
  try {
    // 1. 解析/验证输入
    // 2. 检查权限
    // 3. 执行操作
    // 4. 返回响应
  } catch (error) {
    return new Response(JSON.stringify({ error: 'Message' }), {
      status: 500
    });
  }
}

undefined

What NOT to Include

禁止包含的内容

Avoid these common mistakes:

❌ Too obvious:

markdown

- Write readable code
- Use meaningful variable names
- Add comments when necessary
- Follow best practices

❌ Too restrictive:

markdown

- Never use any third-party libraries
- Always write everything from scratch
- Every function must be under 5 lines

❌ Language-agnostic advice:

markdown

- Use design patterns
- Think before you code
- Test your code
- Keep it simple

避免以下常见错误：

❌ 过于明显的内容：

markdown

- 编写可读代码
- 使用有意义的变量名
- 必要时添加注释
- 遵循最佳实践

❌ 过于严格的内容：

markdown

- 禁止使用任何第三方库
- 所有功能必须从零开始编写
- 每个函数必须少于5行

❌ 与语言无关的建议：

markdown

- 使用设计模式
- 编码前先思考
- 测试代码
- 保持简洁

Structure Template

结构模板

Use this template for new Cursor rules:

markdown

undefined

使用以下模板创建新的Cursor规则：

markdown

undefined

Project Name - Cursor Rules

项目名称 - Cursor规则

Tech Stack

技术栈

[List all major technologies with versions]

[列出所有主要技术及版本]

Code Style

代码风格

[Specific style decisions]

[具体的风格决策]

Project Structure

项目结构

[Directory organization]

[目录组织方式]

Patterns

模式

[Common patterns with code examples]

[通用模式及代码示例]

Pattern Name

模式名称

[Description + code example]

[描述 + 代码示例]

Conventions

约定

[Project-specific conventions]

[项目特定约定]

Common Tasks

常见任务

[Frequent operations with step-by-step snippets]

[频繁操作的分步代码片段]

Task Name

任务名称

Step one
Step two [Code example]

步骤一
步骤二 [代码示例]

Anti-Patterns

反模式

[What to avoid and why]

[需要避免的内容及原因]

Testing

测试

[Testing approach and patterns with examples]

undefined

[测试方法及模式示例]

undefined

Example Sections

示例章节

Tech Stack Section

技术栈章节

markdown

undefined

markdown

undefined

Tech Stack

技术栈

Framework: Next.js 14 (App Router) Language: TypeScript 5.x (strict mode enabled) Styling: Tailwind CSS 3.x with custom design system State: Zustand for global, React Context for component trees Forms: React Hook Form + Zod validation Database: PostgreSQL with Prisma ORM Testing: Vitest (unit), Playwright (E2E) Deployment: Vercel

Key Dependencies:

```
@tanstack/react-query
```
for server state
```
date-fns
```
for date manipulation (not moment.js)
```
clsx
```
+
```
tailwind-merge
```
for conditional classes

undefined

框架： Next.js 14（App Router） 语言： TypeScript 5.x（启用严格模式） 样式： Tailwind CSS 3.x + 自定义设计系统 状态管理： 全局状态使用Zustand，组件树状态使用React Context 表单： React Hook Form + Zod验证 数据库： PostgreSQL + Prisma ORM 测试： Vitest（单元测试）、Playwright（端到端测试） 部署： Vercel

核心依赖：

```
@tanstack/react-query
```
用于服务端状态管理
```
date-fns
```
用于日期处理（禁止使用moment.js）
```
clsx
```
+
```
tailwind-merge
```
用于条件类名

undefined

Anti-Patterns Section

反模式章节

markdown

undefined

markdown

undefined

Anti-Patterns

反模式

❌ Don't: Default Exports

❌ 禁止：默认导出

typescript

// ❌ BAD
export default function Button() { }

// ✅ GOOD
export function Button() { }

Why: Named exports are more refactor-friendly and enable better tree-shaking.

typescript

// ❌ 错误示例
export default function Button() { }

// ✅ 正确示例
export function Button() { }

原因： 命名导出更便于重构，且支持更好的Tree Shaking。

❌ Don't: Inline Type Definitions

❌ 禁止：内联类型定义

typescript

// ❌ BAD
function UserCard({ user }: { user: { name: string; email: string } }) { }

// ✅ GOOD
interface User {
  name: string;
  email: string;
}

function UserCard({ user }: { user: User }) { }

Why: Reusability and discoverability.

undefined

typescript

// ❌ 错误示例
function UserCard({ user }: { user: { name: string; email: string } }) { }

// ✅ 正确示例
interface User {
  name: string;
  email: string;
}

function UserCard({ user }: { user: User }) { }

原因： 提升可复用性和可发现性。

undefined

Common Tasks

常见任务

Include shortcuts for frequent operations:

markdown

undefined

包含频繁操作的快捷方式：

markdown

undefined

Common Tasks

常见任务

Adding a New API Route

添加新API路由

Create
```
app/api/[route]/route.ts
```
Define HTTP method exports (GET, POST, etc.)
Validate input with Zod schema
Use try/catch for error handling
Return
```
Response
```
object

typescript

import { z } from 'zod';

const schema = z.object({
  name: z.string().min(1)
});

export async function POST(request: Request) {
  try {
    const body = await request.json();
    const data = schema.parse(body);

    // Process...

    return Response.json({ success: true });
  } catch (error) {
    if (error instanceof z.ZodError) {
      return Response.json(
        { error: error.errors },
        { status: 400 }
      );
    }
    return Response.json(
      { error: 'Internal error' },
      { status: 500 }
    );
  }
}

undefined

创建
```
app/api/[route]/route.ts
```
定义HTTP方法导出（GET、POST等）
使用Zod schema验证输入
使用try/catch处理错误
返回
```
Response
```
对象

typescript

import { z } from 'zod';

const schema = z.object({
  name: z.string().min(1)
});

export async function POST(request: Request) {
  try {
    const body = await request.json();
    const data = schema.parse(body);

    // 处理逻辑...

    return Response.json({ success: true });
  } catch (error) {
    if (error instanceof z.ZodError) {
      return Response.json(
        { error: error.errors },
        { status: 400 }
      );
    }
    return Response.json(
      { error: '内部错误' },
      { status: 500 }
    );
  }
}

undefined

Best Practices

最佳实践

Keep Rules Under 500 Lines

规则文件不超过500行

Split large rules into multiple, composable files
Each rule file should focus on one domain or concern
Reference other rule files when needed (e.g., "See
```
backend-api.mdc
```
for API patterns")
Why: Large files become unmanageable and harder for AI to process effectively

将大型规则拆分为多个可组合的文件
每个规则文件应聚焦一个领域或关注点
必要时引用其他规则文件（例如：“API模式请参见
```
backend-api.mdc
```
”）
原因： 大型文件难以维护，且AI处理效率更低

Split Into Composable Rules

拆分为可组合的规则

Break down by concern rather than creating one monolithic file:

.cursor/rules/
  ├── tech-stack.mdc          # Core technologies
  ├── typescript-patterns.mdc # Language-specific patterns
  ├── api-conventions.mdc     # API route standards
  ├── component-patterns.mdc  # React/UI patterns
  └── testing-standards.mdc   # Testing approaches

Why: Easier to maintain, update, and reuse across similar projects.

按关注点拆分，而非创建单一的巨型文件：

.cursor/rules/
  ├── tech-stack.mdc          # 核心技术
  ├── typescript-patterns.mdc # 语言特定模式
  ├── api-conventions.mdc     # API路由标准
  ├── component-patterns.mdc  # React/UI模式
  └── testing-standards.mdc   # 测试方法

原因： 更易于维护、更新，并能在相似项目中复用。

Provide Concrete Examples or Referenced Files

提供具体示例或参考文件

Instead of vague guidance, always include:

Complete, runnable code examples

References to actual project files:

See components/auth/LoginForm.tsx for example

Links to internal docs or design system
Specific file paths and line numbers when relevant

❌ BAD - Vague:

markdown

Use proper error handling in API routes.

✅ GOOD - Concrete:

markdown

API routes must use try/catch with typed errors. Example:
```typescript
// app/api/users/route.ts (lines 10-25)
export async function POST(request: Request) {
  try {
    const data = await request.json();
    return Response.json({ success: true });
  } catch (error) {
    return handleApiError(error); // See lib/errors.ts
  }
}

See

app/api/products/route.ts

for complete implementation.

undefined

避免模糊指导，务必包含：

完整可运行的代码示例
指向实际项目文件的参考：“示例请参见components/auth/LoginForm.tsx”
内部文档或设计系统的链接
相关的具体文件路径和行号

❌ 错误示例 - 模糊：

markdown

在API路由中使用正确的错误处理。

✅ 正确示例 - 具体：

markdown

API路由必须使用try/catch处理类型化错误。示例：
```typescript
// app/api/users/route.ts（第10-25行）
export async function POST(request: Request) {
  try {
    const data = await request.json();
    return Response.json({ success: true });
  } catch (error) {
    return handleApiError(error); // 参见lib/errors.ts
  }
}

完整实现请参见

app/api/products/route.ts

。

undefined

Write Rules Like Clear Internal Docs

像编写清晰的内部文档一样编写规则

Rules should read like technical documentation, not casual advice:

Be precise and unambiguous
Include the "why" behind decisions
Document exceptions to rules
Reference architecture decisions
Link to related rules or documentation

Think: "Could a new engineer understand this without asking questions?"

规则应像技术文档一样，而非随意建议：

精确且无歧义
包含决策背后的“原因”
记录规则的例外情况
引用架构决策
链接到相关规则或文档

思考： “新工程师无需提问就能理解这些内容吗？”

Reuse Rules When Repeating Prompts

重复提示时复用规则

If you find yourself giving the same instructions repeatedly in chat:

Document that pattern in
```
.cursor/rules/
```
Include the specific guidance you keep repeating
Add examples of correct implementation
Update existing rule files rather than creating new ones

Common scenarios to capture:

"Always use X pattern for Y"
"Don't forget to Z when doing W"
Corrections you make frequently
Patterns specific to your team/codebase

如果您发现自己在聊天中反复给出相同的指令：

将该模式记录到
```
.cursor/rules/
```
中
包含您反复提及的具体指导
添加正确实现的示例
更新现有规则文件，而非创建新文件

常见的记录场景：

“处理Y时始终使用X模式”
“做W时不要忘记Z”
您经常纠正的错误
团队/代码库特有的模式

Keep It Scannable

保持内容易于扫描

Use clear section headers
Bold important terms
Include code examples (not just prose)
Use tables for comparisons
Add table of contents for files over 200 lines

使用清晰的章节标题
对重要术语加粗
包含代码示例（而非仅文字描述）
使用表格进行对比
超过200行的文件添加目录

Update Regularly

定期更新

Review monthly or after major changes
Remove outdated patterns
Add new patterns as they emerge
Keep examples current with latest framework versions
Archive deprecated rules rather than deleting (for reference)

每月或重大变更后回顾
删除过时的模式
添加新出现的模式
保持示例与最新框架版本同步
归档已废弃的规则（而非删除，留作参考）

Test with AI

与AI一起测试规则

After creating rules, test them:

Ask AI: "Create a new API route following our conventions"
Ask AI: "Add error handling to this component"
Ask AI: "Refactor this to match our patterns"

Verify AI follows rules correctly. Update rules based on gaps found.

创建规则后进行测试：

询问AI：“按照我们的约定创建一个新的API路由”
询问AI：“为这个组件添加错误处理”
询问AI：“按照我们的模式重构这段代码”

验证AI是否正确遵循规则，根据发现的不足更新规则。

Real-World Example

真实示例

The PRPM registry

.cursor/rules

demonstrates:

Clear tech stack declaration (Fastify, TypeScript, PostgreSQL)
Specific TypeScript patterns
Fastify-specific conventions
Error handling standards
API route patterns
Database query patterns

PRPM注册中心的

.cursor/rules

展示了：

清晰的技术栈声明（Fastify、TypeScript、PostgreSQL）
具体的TypeScript模式
Fastify特定约定
错误处理标准
API路由模式
数据库查询模式

Checklist for New Cursor Rules

新Cursor规则检查清单

Helpful Prompts for Users

给用户的实用提示

When helping users create Cursor rules:

Discovery:

"What's your tech stack?"
"What patterns do you want AI to follow?"
"What mistakes does AI currently make?"

Refinement:

"Are there anti-patterns you want documented?"
"What are your most common coding tasks?"
"Do you have naming conventions?"

Validation:

"Let me test these rules by asking you to generate code..."
"Does this match your team's style?"

帮助用户创建Cursor规则时：

探索阶段：

“您的技术栈是什么？”
“您希望AI遵循哪些模式？”
“AI当前常犯哪些错误？”

优化阶段：

“有没有需要记录的反模式？”
“您最常见的编码任务是什么？”
“您有命名约定吗？”

验证阶段：

“让我通过要求您生成代码来测试这些规则...”
“这符合您团队的风格吗？”

Remember

请记住

Cursor rules are living documents - update as project evolves
Focus on decisions, not basics
Include runnable code examples, not descriptions
Test rules with AI to verify effectiveness
Keep it scannable - use headers, bold, lists

Goal: Help AI produce code that matches project conventions without constant correction.

Cursor规则是活文档 - 随项目发展而更新
聚焦决策，而非基础内容
包含可运行的代码示例，而非仅描述
与AI一起测试规则以验证有效性
保持内容易于扫描 - 使用标题、加粗、列表

目标： 帮助AI生成符合项目约定的代码，无需频繁纠正。