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

前置内容属性

PropertyTypeRequiredDescription
description
stringYesBrief description of the rule's purpose. Used by AI to decide relevance. Never use placeholders like
---
or empty strings.
globs
arrayNoFile patterns that trigger auto-attachment (e.g.,
["**/*.ts"]
). Leave empty or omit if not using Auto Attached type.
alwaysApply
booleanNoIf
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 TypeDescriptionWhen to Use
AlwaysAlways included in model contextCore project conventions, tech stack, universal patterns that apply everywhere
Auto AttachedIncluded when files matching
globs
pattern are referenced
File-type specific rules (e.g., React components, API routes, test files)
Agent RequestedAvailable to AI, which decides whether to include it based on
description
Contextual patterns, specialized workflows, optional conventions
ManualOnly 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

前置内容最佳实践

  1. 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
  2. Use globs strategically - Auto-attach to relevant file types:
    • React components:
      ["**/*.tsx", "**/*.jsx"]
    • API routes:
      ["**/api/**/*.ts", "**/routes/**/*.ts"]
    • Tests:
      ["**/*.test.ts", "**/*.spec.ts"]
  3. Avoid always applying everything - Use
    alwaysApply: true
    sparingly:
    • ✅ Good for: Tech stack, core conventions, project structure
    • ❌ Bad for: Framework-specific patterns, specialized workflows
  4. 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"
  1. Description是必填项 - AI会据此判断相关性,请务必具体:
    • ❌ 错误示例:
      后端代码
    • ✅ 正确示例:
      使用Zod的Fastify API路由模式、错误处理和验证
  2. 策略性使用globs - 自动附加到相关文件类型:
    • React组件:
      ["**/*.tsx", "**/*.jsx"]
    • API路由:
      ["**/api/**/*.ts", "**/routes/**/*.ts"]
    • 测试文件:
      ["**/*.test.ts", "**/*.spec.ts"]
  3. 避免全部规则始终应用 - 谨慎使用
    alwaysApply: true
    • ✅ 适用场景:技术栈、核心约定、项目结构
    • ❌ 不适用场景:框架特定模式、特定工作流
  4. 让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

任务名称

  1. Step one
  2. Step two [Code example]
  1. 步骤一
  2. 步骤二 [代码示例]

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路由

  1. Create
    app/api/[route]/route.ts
  2. Define HTTP method exports (GET, POST, etc.)
  3. Validate input with Zod schema
  4. Use try/catch for error handling
  5. 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
  1. 创建
    app/api/[route]/route.ts
  2. 定义HTTP方法导出(GET、POST等)
  3. 使用Zod schema验证输入
  4. 使用try/catch处理错误
  5. 返回
    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:
  1. Document that pattern in
    .cursor/rules/
  2. Include the specific guidance you keep repeating
  3. Add examples of correct implementation
  4. 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
如果您发现自己在聊天中反复给出相同的指令:
  1. 将该模式记录到
    .cursor/rules/
  2. 包含您反复提及的具体指导
  3. 添加正确实现的示例
  4. 更新现有规则文件,而非创建新文件
常见的记录场景:
  • “处理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:
  1. Ask AI: "Create a new API route following our conventions"
  2. Ask AI: "Add error handling to this component"
  3. Ask AI: "Refactor this to match our patterns"
Verify AI follows rules correctly. Update rules based on gaps found.
创建规则后进行测试:
  1. 询问AI:“按照我们的约定创建一个新的API路由”
  2. 询问AI:“为这个组件添加错误处理”
  3. 询问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规则检查清单

Project Context:
  • Tech stack clearly defined with versions
  • Key dependencies listed
  • Deployment platform specified
Code Style:
  • Component style specified (functional/class)
  • Export style (named/default)
  • File naming convention
  • Specific to project (not generic advice)
Patterns:
  • At least 3-5 code examples
  • Cover most common tasks
  • Include error handling pattern
  • Show project-specific conventions
Organization:
  • Logical section headers
  • Scannable (not wall of text)
  • Examples are complete and runnable
  • Anti-patterns included with rationale
Testing:
  • Tested with AI assistant
  • AI follows conventions correctly
  • Updated after catching mistakes
项目上下文:
  • 明确定义技术栈及版本
  • 列出核心依赖
  • 指定部署平台
代码风格:
  • 指定组件风格(函数式/类式)
  • 指定导出风格(命名/默认)
  • 指定文件命名约定
  • 内容针对项目(而非通用建议)
模式:
  • 至少包含3-5个代码示例
  • 覆盖大多数常见任务
  • 包含错误处理模式
  • 展示项目特定约定
组织方式:
  • 章节标题逻辑清晰
  • 内容易于扫描(而非大段文字)
  • 示例完整可运行
  • 包含反模式及理由
测试:
  • 已与AI助手测试
  • AI能正确遵循约定
  • 发现错误后已更新规则

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生成符合项目约定的代码,无需频繁纠正。