跳过主要内容
规则是自定义指令文件,为 Cline 提供有关您的编码偏好、标准和最佳实践的指南。当 Cline 执行任务时,这些指令会被添加到它的上下文。

什么是规则?

规则是存储在 .clinerules/ 目录中的简单 Markdown 文件,其中包含您团队的约定、偏好和指南。它们帮助 Cline 理解您的
  • 编码风格和约定
  • 首选库和框架
  • 架构模式
  • 测试策略
  • 文档标准
  • 沟通偏好
规则只是 .md 文件——无需复杂的配置!

快速示例

这是一个指导 TypeScript 开发的简单规则文件
# TypeScript Conventions

## Code Style
- Use 2-space indentation
- Prefer `const` over `let`
- Always use explicit return types for functions
- Use named exports instead of default exports

## Testing
- Write unit tests for all utility functions
- Use Vitest as the testing framework
- Aim for 80%+ code coverage

## Dependencies
- Prefer native TypeScript features over external libraries
- Use Zod for runtime type validation
- Use date-fns for date manipulation

创建规则

创建规则最简单的方法是使用 /newrule 命令
  1. 在与 Cline 对话时,输入 /newrule
  2. Cline 将分析您的对话和偏好
  3. 它会在 .clinerules/ 中创建一个命名恰当的 .md 文件
示例
/newrule

Based on our conversation, create a rule for React component structure

全局规则与工作区规则

工作区规则

位置: 仓库中的 .clinerules/范围: 特定于该项目用于: 项目特定的约定和模式

全局规则

位置: Documents/Cline/ 目录范围: 您所有的项目用于: 适用于任何地方的个人偏好

管理规则

切换规则

您可以启用或禁用单个规则文件
  1. 点击 Cline 界面中的规则图标
  2. 根据需要切换规则开/关
  3. 更改立即应用于新任务
禁用规则会将其从 Cline 的上下文中移除,但文件保持不变。您可以随时重新启用它。

企业远程规则

企业部署可以配置适用于所有团队成员的远程全局规则。这些规则通过您的基础设施配置进行管理,无法由单个开发人员关闭。有关远程规则的详细信息,请参阅自托管配置

兼容格式

Cline 还尊重来自其他 AI 编码工具的规则
文件/目录工具位置
.cursorrulesCursor工作区根目录(单个文件)
.cursor/rules/Cursor工作区目录(.mdc 文件)
.windsurfrulesWindsurf工作区根目录(单个文件)
AGENTS.md各种工作区根目录 + 递归搜索
AGENTS.md 行为: 只有当您的工作区根目录中存在一个顶级的 AGENTS.md 文件时,Cline 才会递归搜索嵌套的 AGENTS.md 文件。如果找到,所有 AGENTS.md 文件将与其相对路径作为标题组合在一起。
这些文件的功能与 .clinerules/ 文件相同,可以独立开启/关闭。

最佳实践

每个规则文件应专注于一个主题
  • typescript-conventions.md
  • react-component-structure.md
  • everything-about-our-codebase.md
规则基于实际的团队偏好,而非假设
  • ✅ “我们使用 React Query 进行服务器状态管理”
  • ❌ “使用最佳实践进行状态管理”
定期审查和更新规则
  • 采纳新技术时
  • 进行重大架构更改后
  • 团队约定演变时
太多规则可能会使 Cline 的上下文超负荷
  • 从 3-5 条基本规则开始
  • 仅在真正需要时添加更多
  • 及时移除过时的规则

规则文件示例

# API Design Standards

## REST Conventions
- Use plural nouns for endpoints (`/users`, not `/user`)
- Use HTTP methods semantically (GET, POST, PUT, DELETE)
- Return appropriate status codes

## Response Format
\`\`\`typescript
{
  data: T,
  error?: string,
  metadata?: {
    page: number,
    total: number
  }
}
\`\`\`

## Error Handling
- Always return error messages in `error` field
- Use 4xx for client errors, 5xx for server errors
- Include request ID in error responses
# Testing Requirements

## Test Organization
- Place tests next to source files (`Button.test.tsx`)
- Use `describe` blocks to group related tests
- Write descriptive test names

## Coverage Requirements
- Unit tests for all utility functions
- Integration tests for API endpoints
- E2E tests for critical user flows
- Minimum 80% coverage for new code

## Mocking Strategy
- Mock external API calls
- Use test fixtures for complex data
- Prefer dependency injection for testability

后续步骤