creating-cursor-rules-skill
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseCreating Cursor Rules
创建Cursor规则
You are an expert at creating effective files that help AI assistants understand project conventions and produce better code.
.cursor/rules您是创建高效文件的专家,这类文件能帮助AI助手理解项目约定并生成更优质的代码。
.cursor/rulesWhen to Apply This Skill
何时应用此技能
Use when:
- User is starting a new project and needs setup
.cursor/rules - 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
undefinedTech 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
undefinedRule 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 |
|---|---|---|---|
| string | Yes | Brief description of the rule's purpose. Used by AI to decide relevance. Never use placeholders like |
| array | No | File patterns that trigger auto-attachment (e.g., |
| boolean | No | If |
| 属性 | 类型 | 必填 | 描述 |
|---|---|---|---|
| 字符串 | 是 | 规则用途的简要说明,AI会据此判断相关性。禁止使用 |
| 数组 | 否 | 触发自动附加的文件模式(例如 |
| 布尔值 | 否 | 如果为 |
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 | 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 | Contextual patterns, specialized workflows, optional conventions |
| Manual | Only included when explicitly mentioned using | Rarely-used patterns, experimental conventions, legacy documentation |
通过Cursor中的类型下拉菜单控制规则的应用方式:
| 规则类型 | 描述 | 使用场景 |
|---|---|---|
| Always(始终应用) | 始终包含在模型上下文环境中 | 核心项目约定、技术栈、全局通用模式 |
| Auto Attached(自动附加) | 当引用匹配 | 特定文件类型的规则(例如React组件、API路由、测试文件) |
| Agent Requested(AI主动调用) | 可供AI使用,AI会根据 | 上下文相关的模式、特定工作流、可选约定 |
| Manual(手动应用) | 仅当使用 | 极少使用的模式、实验性约定、遗留文档 |
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
- ❌ Bad:
-
Use globs strategically - Auto-attach to relevant file types:
- React components:
["**/*.tsx", "**/*.jsx"] - API routes:
["**/api/**/*.ts", "**/routes/**/*.ts"] - Tests:
["**/*.test.ts", "**/*.spec.ts"]
- React components:
-
Avoid always applying everything - Usesparingly:
alwaysApply: true- ✅ 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"]
- React组件:
-
避免全部规则始终应用 - 谨慎使用:
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
undefinedmarkdown
undefinedTech 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
undefinedmarkdown
undefinedCode 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
undefined3. Common Patterns
3. 通用模式
Always include code examples, not just descriptions:
markdown
undefined务必包含代码示例,而非仅文字描述:
markdown
undefinedPatterns
模式
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
});
}
}undefinedtypescript
// 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
});
}
}undefinedWhat 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
undefinedProject 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[测试方法及模式示例]
undefinedExample Sections
示例章节
Tech Stack Section
技术栈章节
markdown
undefinedmarkdown
undefinedTech 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:
- for server state
@tanstack/react-query - for date manipulation (not moment.js)
date-fns - +
clsxfor conditional classestailwind-merge
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 - 用于日期处理(禁止使用moment.js)
date-fns - +
clsx用于条件类名tailwind-merge
undefinedAnti-Patterns Section
反模式章节
markdown
undefinedmarkdown
undefinedAnti-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.
undefinedtypescript
// ❌ 错误示例
function UserCard({ user }: { user: { name: string; email: string } }) { }
// ✅ 正确示例
interface User {
name: string;
email: string;
}
function UserCard({ user }: { user: User }) { }原因: 提升可复用性和可发现性。
undefinedCommon Tasks
常见任务
Include shortcuts for frequent operations:
markdown
undefined包含频繁操作的快捷方式:
markdown
undefinedCommon 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 object
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);
// 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 }
);
}
}undefinedBest 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 for API patterns")
backend-api.mdc - 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 approachesWhy: 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 for complete implementation.
app/api/products/route.tsundefined避免模糊指导,务必包含:
- 完整可运行的代码示例
- 指向实际项目文件的参考:“示例请参见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.tsundefinedWrite 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 demonstrates:
.cursor/rules- 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生成符合项目约定的代码,无需频繁纠正。