AI 编程助手规则配置
为 AI 编程助手提供项目上下文和编码规范，让它更好地理解你的项目。
这页适合作为“AI 编码规则沉淀入口”。真正有价值的不是把规则写得越长越好，而是让它稳定覆盖技术栈、目录边界、编码习惯、测试要求和交付标准。
推荐配置顺序
建议按这个顺序沉淀规则：
- 先写项目概述和技术栈
- 再写通用编码原则
- 再写按语言 / 框架拆分的细则
- 再写测试、提交、部署相关约束
- 最后再加项目特有的禁区和例外说明
先从最小可执行规则开始，比一开始堆一大份“没人会维护”的长文档更有效。
Cursor Rules
Cursor 支持项目级规则文件，放在 .cursor/rules/ 目录下。
目录结构
.cursor/
└── rules/
├── general.mdc # 通用规则
├── typescript.mdc # TypeScript 规范
├── vue.mdc # Vue 组件规范
└── testing.mdc # 测试规范
规则文件格式
---
description: TypeScript 编码规范
globs: **/*.ts, **/*.tsx
alwaysApply: false
---
# TypeScript 规范
- 使用 `type` 而非 `interface`（除非需要 extends）
- 优先使用 `const` 声明
- 函数参数超过 3 个时使用对象参数
- 所有导出函数必须有 JSDoc 注释
- 使用 `unknown` 而非 `any`
- 错误处理使用自定义 Error 类
## 命名规范
- 文件名：kebab-case（`user-service.ts`）
- 类型/接口：PascalCase（`UserProfile`）
- 函数/变量：camelCase（`getUserById`）
- 常量：UPPER_SNAKE_CASE（`MAX_RETRY_COUNT`）
- 布尔值：is/has/can 前缀（`isActive`）
常用规则模板
通用项目规则
---
description: 项目通用规则
alwaysApply: true
---
# 项目概述
这是一个使用 Nuxt 4 + TypeScript + UnoCSS 构建的知识库网站。
## 技术栈
- Nuxt 4（Vue 3 Composition API）
- TypeScript 5
- UnoCSS（Attributify 模式）
- Nuxt Content v3
- Cloudflare Pages 部署
## 编码原则
- 中文注释和文档
- Composition API + `<script setup>` 语法
- 优先使用 VueUse 组合式函数
- 最小化依赖，能用原生实现就不引入库
Git 提交规则
---
description: Git 提交规范
globs: .git/**
---
使用 Conventional Commits 格式：
- type(scope): 中文描述
- type: feat, fix, refactor, style, perf, test, docs, chore
- scope 可选，指明影响范围
- 描述使用中文，简洁明了
Kiro Steering
Kiro 使用 .kiro/steering/ 目录下的 Markdown 文件。
目录结构
.kiro/
└── steering/
├── project.md # 项目概述（始终包含）
├── coding.md # 编码规范（始终包含）
├── vue-rules.md # Vue 规范（匹配 .vue 文件时包含）
└── api-guide.md # API 规范（手动引用）
包含模式
---
inclusion: always
---
# 始终包含的规则
这些规则在每次对话中都会生效。
---
inclusion: fileMatch
fileMatchPattern: "**/*.vue"
---
# Vue 组件规范
仅在打开 .vue 文件时生效。
---
inclusion: manual
---
# API 设计指南
通过 #api-guide 手动引用。
引用外部文件
项目 API 规范请参考：#[[file:openapi.yaml]]
数据库 Schema：#[[file:prisma/schema.prisma]]
Claude Projects
Claude 的 Project Knowledge 功能。
项目指令（Project Instructions）
你是一位资深全栈开发者，帮助我维护一个 Nuxt 4 项目。
技术栈：Nuxt 4, TypeScript, UnoCSS, Cloudflare Workers
规范：
- 使用 Composition API + <script setup>
- 中文注释
- Conventional Commits 提交格式
- 优先使用 VueUse
回答风格：
- 直接给代码，少说废话
- 指出潜在问题
- 提供替代方案
上传项目文件
建议上传的文件：
package.json— 依赖信息tsconfig.json— TypeScript 配置nuxt.config.ts— 项目配置- 核心类型定义文件
- API Schema 文件
GitHub Copilot
项目级指令
.github/copilot-instructions.md：
# Copilot 指令
## 代码风格
- TypeScript strict 模式
- 使用 ESM import
- 函数式编程优先
- 避免 class，使用组合式函数
## 项目特定
- 使用 UnoCSS 而非 Tailwind
- 路由使用 Nuxt 文件系统路由
- 状态管理使用 useState composable
通用规则建议
不管用哪个 AI 工具，以下规则都值得配置：
# 输出规范
- 不要创建不必要的文档文件
- 代码修改后检查类型错误
- 保持最小化改动，不要过度工程化
- 新增功能要考虑已有代码风格
# 安全
- 不要硬编码密钥和密码
- 使用环境变量管理敏感信息
- 输入验证和错误处理
# 性能
- 避免不必要的重渲染
- 图片使用 WebP 格式
- 按需导入，避免全量引入
常见问题
规则写了很多，代理还是不听
高频原因通常包括：
- 规则层级混乱
- 规则互相冲突
- 没告诉它哪些规则始终生效
- 规则写得太抽象，没有可执行动作
应该按工具分别写，还是统一写一份
更稳的做法通常是：保留一份“项目主规则”，再根据不同工具补各自适配层，避免完全重复维护。
项目规则多久需要更新一次
只要技术栈、目录结构、测试策略或部署方式发生明显变化，就值得回头更新一次。
延伸阅读
参考链接
- Cursor Rules — Cursor 文档
- Kiro Steering — Kiro 文档
- Copilot Instructions — GitHub 文档
- Awesome Cursor Rules — 规则集合