目标:用规则约束 AI 行为,统一团队代码规范
概述
规则(Rules)是告诉 AI "应该怎么做" 的指令。它们会:
- 影响 AI 的决策
- 约束代码生成风格
- 强制执行项目规范
- 减少重复说明
一套设计良好的规则,能让 AI 的输出质量提升数倍。
规则系统架构图
配置规则
在 opencode.json 中添加 rules 字段:
{
"rules": [
"使用 TypeScript 严格模式",
"所有函数必须包含 JSDoc 注释",
"API 路由统一返回 { success, data, error } 格式",
"数据库操作必须使用事务",
"优先使用 async/await 而非回调"
]
}每条规则是一个字符串,AI 会在每次回复前读取。
规则优先级流程
核心原则:后面的覆盖前面的(仅冲突时)。
规则类型
1. 代码风格规则
{
"rules": [
"使用 2 空格缩进",
"字符串使用单引号",
"最大行长度 100 字符",
"trailing comma: es5",
"末尾不留空行"
]
}2. 架构规则
{
"rules": [
"业务逻辑放在 services/ 目录",
"不要在组件中直接调用 API",
"使用 Repository 模式操作数据库",
"所有 API 响应经过统一错误处理中间件",
"前端状态管理使用 Zustand,不使用 Redux"
]
}3. 安全规则
{
"rules": [
"所有用户输入必须经过 Zod 校验",
"密码必须使用 bcrypt 哈希(cost ≥ 12)",
"JWT 密钥存储在环境变量,不硬编码",
"SQL 查询使用参数化防止注入",
"敏感操作需要二次确认"
]
}4. 测试规则
{
"rules": [
"新功能必须包含单元测试",
"测试覆盖率不低于 80%",
"使用 vitest 而非 jest",
"测试文件与源码同目录,后缀 .test.ts"
]
}高级:规则文件
对于复杂规则,可以创建 .rules 文件:
# 项目根目录
.rules
# 或
.opencode/rules.md内容示例:
# 项目规则
## TypeScript
- 启用 strict 模式
- 不使用 any 类型
- 接口名使用 I 前缀(如 IUser)
- 枚举使用 PascalCase
## React
- 使用函数组件 + Hooks
- Props 使用 interface 定义
- 事件处理函数以 handle 开头
- 自定义 Hook 以 use 开头
## API
- RESTful 风格
- 路由使用 kebab-case
- 响应格式: { success: boolean, data?: T, error?: string }
- HTTP 状态码语义正确(200/201/400/401/404/500)完整项目规则模板
模板:Node.js + Express + TypeScript 全栈项目
{
"$schema": "https://opencode.ai/config.json",
"model": "anthropic/claude-sonnet-4-5",
"rules": [
// ===== 语言与类型 =====
"使用 TypeScript 严格模式(strict: true)",
"不使用 any 类型,必要时使用 unknown + 类型守卫",
"所有函数参数和返回值必须显式标注类型",
// ===== 代码风格 =====
"使用 2 空格缩进",
"字符串使用单引号",
"最大行长度 100 字符",
"使用 trailing comma(ES5 风格)",
// ===== 项目结构 =====
"控制器放在 src/controllers/",
"路由放在 src/routes/",
"业务逻辑放在 src/services/",
"数据访问放在 src/repositories/",
"类型定义放在 src/types/",
"工具函数放在 src/utils/",
// ===== API 规范 =====
"所有 API 返回统一格式: { success: boolean, data?: T, error?: string }",
"路由使用 kebab-case,如 /api/user-profiles",
"HTTP 状态码语义正确",
// ===== 数据库 =====
"数据库操作使用 Prisma ORM",
"所有写操作使用事务",
"复杂查询使用 Prisma 的 include 和 select 优化",
// ===== 安全 =====
"使用 Zod 校验所有请求参数",
"密码使用 bcrypt 哈希(rounds: 12)",
"JWT 密钥从环境变量读取",
"敏感信息不记录到日志",
// ===== 错误处理 =====
"使用自定义 AppError 类",
"错误使用 winston 记录",
"不向客户端暴露内部错误详情",
// ===== 测试 =====
"新功能必须包含单元测试",
"使用 vitest + @vitest/coverage-v8",
"测试覆盖率不低于 80%"
],
"formatters": {
"*.ts": "prettier --write",
"*.json": "prettier --write"
}
}真实场景案例 ①:团队代码规范落地
某 15 人团队以前代码风格混乱,新人入职需要 2 周才能适应。引入 OpenCode 规则后,AI 生成的代码自动符合规范,Code Review 时间减少 60%,新人上手时间缩短到 3 天。
规则 vs AGENTS.md
| 维度 | 规则 (Rules) | AGENTS.md |
|---|---|---|
| 用途 | 约束行为 | 提供上下文 |
| 内容 | 应该怎么做 | 项目是什么 |
| 影响范围 | 所有回复 | 理解项目 |
| 示例 | "使用单引号" | "这是 Next.js 项目" |
| 格式 | 字符串数组 / Markdown 文件 | Markdown 文档 |
| 优先级 | 高(直接影响输出) | 中(辅助理解) |
| 更新频率 | 随规范调整 | 随项目演进 |
规则与 AGENTS.md 协作图
两者配合使用:
AGENTS.md— 让 AI 了解项目rules— 让 AI 按要求执行
协作示例
AGENTS.md:
# 项目概述
这是基于 Next.js 14 + Prisma + PostgreSQL 的电商平台。
## 技术栈
- 前端:Next.js App Router + Tailwind CSS + shadcn/ui
- 后端:Next.js API Routes
- 数据库:PostgreSQL + Prisma
- 认证:NextAuth.jsopencode.json rules:
{
"rules": [
"使用 Next.js App Router,不使用 Pages Router",
"UI 组件使用 shadcn/ui",
"数据库操作使用 Prisma",
"认证使用 NextAuth.js 的 session 策略"
]
}效果:AI 既知道项目用什么技术栈,又知道具体怎么做,输出质量大幅提升。
规则效果对比
无规则时
// AI 可能生成这样的代码
function getUser(id) {
return db.query('SELECT * FROM users WHERE id = ' + id);
}问题:
- ❌ 无类型注解
- ❌ SQL 注入风险
- ❌ 不使用 ORM
- ❌ 无错误处理
有规则时
// AI 生成符合规则的代码
import { prisma } from '@/lib/prisma';
/**
* 根据 ID 获取用户信息
* @param id - 用户 ID
* @returns 用户对象,不存在时返回 null
*/
async function getUser(id: string): Promise<User | null> {
try {
const user = await prisma.user.findUnique({
where: { id },
select: { id: true, email: true, name: true }
});
return user;
} catch (error) {
logger.error('Failed to get user', { id, error });
throw new AppError('USER_FETCH_FAILED', '获取用户信息失败');
}
}改进:
- ✅ TypeScript 严格类型
- ✅ 使用 Prisma ORM(防注入)
- ✅ JSDoc 注释
- ✅ 错误处理 + 日志
- ✅ 统一错误格式
真实场景案例 ②:规则驱动重构
某团队为遗留项目添加了规则:"所有新代码必须使用 Prisma,逐步替换原始 SQL"。3 个月后,AI 在新增功能时自动使用 Prisma,老代码在修改时也逐步被迁移,实现了平滑过渡。
避坑指南
❌ 规则过多
不要写几十条规则,AI 会"记不住"重点。
建议:最多 10-15 条核心规则。需要更多时,拆分到 .rules 文件。
❌ 规则冲突
{
"rules": [
"使用单引号",
"字符串使用双引号" // ❌ 冲突!
]
}✅ 规则具体
// ❌ 模糊
"写好代码"
// ✅ 具体
"所有公共函数添加 JSDoc 注释"
"函数长度不超过 50 行"
"嵌套深度不超过 3 层"✅ 规则可验证
// ❌ 主观
"代码要优雅"
// ✅ 可验证
"所有 API 响应经过 Zod 校验"
"测试覆盖率不低于 80%"FAQ
Q: 规则和 .rules 文件哪个优先级更高?
A:
.rules文件优先级高于opencode.json中的rules数组。如果两者冲突,以.rules文件为准。
Q: 规则对已有文件会生效吗?
A: 规则主要影响 AI 新生成的内容。对于已有文件,AI 在修改时会尽量遵循规则,但不会自动重构整个文件。
Q: 可以按目录设置不同规则吗?
A: 目前不支持目录级规则。建议按项目拆分,或在规则中明确说明不同目录的规范。
Q: AI 不遵守规则怎么办?
A: 1) 检查规则是否具体明确;2) 减少规则数量;3) 将最重要的规则放在前面;4) 在对话中直接提醒。
避坑清单 ⚠️
| 坑 | 后果 | 正确做法 |
|---|---|---|
| 规则超过 20 条 | AI 忽略部分规则 | 控制在 10-15 条,复杂规则放 .rules 文件 |
| 规则互相冲突 | AI 行为不可预期 | 定期审查,确保逻辑一致 |
| 规则过于抽象 | AI 无法执行 | 使用可验证、可量化的描述 |
| 忽视 AGENTS.md | AI 不了解项目背景 | 两者配合使用 |
| 规则从不更新 | 与项目实际脱节 | 随项目演进定期调整 |
| 团队没有统一规则 | 代码风格混乱 | 将 opencode.json 纳入版本控制 |
练习
- 为你的项目写 5-10 条核心规则
- 测试 AI 是否遵守规则(让它生成代码检查)
- 对比有/无规则的生成质量差异
- 创建一个
.rules文件,记录详细的架构约定
下一篇:12. MCP 服务器集成