claude rule介绍

antkang
13 阅读6分钟

AI 规则分层说明

安装与配置

安装 Claude Code

npm i anthropic-ai/claude-code

配置环境变量 用minimax举例

$env:ANTHROPIC_BASE_URL="https://api.minimaxi.com/anthropic"
$env:ANTHROPIC_AUTH_TOKEN="YOUR_API_TOKEN"
$env:ANTHROPIC_MODEL="MiniMax-M2.7"

设计目标

这套规则分层，核心不是介绍项目内容，而是明确 AI 规则应该放在哪里、什么时候生效、为什么这样分。

目标有两个：

  1. 把 每次都必须遵守的规则 收敛到全局层
  2. 把 仅在特定模块才需要的规则 下沉到目录层，减少无关内容占用上下文

分层原则

1. rules/ 根目录

rules/ 根目录下放的是 全局硬规则。
这类规则默认会进入上下文，属于 AI 在处理任何任务时都应该优先遵守的内容，因此必须保持精简，只保留真正跨模块、跨目录都成立的约束。

适合放在这一层的内容包括：

  • 核心工程原则
  • 修改边界
  • 架构层级约束
  • 全局命名规范
  • 通用开发规范
  • 所有目录都必须遵守的约束

这一层解决的是：

  • 什么是必须始终遵守的
  • 什么不能被破坏
  • 什么属于全局统一口径

2. monorepo 各目录下的规则

monorepo 中每个目录、每个 package，可以维护自己的局部规则。
这部分规则 不会默认常驻上下文，只有当 AI 实际进入对应目录、处理对应模块时，才按需加载。

适合放在这一层的内容包括：

  • 某个 package 独有的命名约定
  • 某个模块特有的实现约束
  • 局部目录下的开发规范
  • 某套系统专属的契约
  • 仅对当前子工程生效的规则

这一层解决的是：

  • 这个目录下应该怎么改
  • 这个模块有哪些局部约束
  • 这里的实现边界和特殊规则是什么

核心理解

可以把整套规则理解为两层：

  • 全局层：放“每次都必须遵守”的内容
  • 局部层：放“只有改到这里才需要遵守”的内容

也就是说：

  • rules/ 根目录负责统一性
  • 各子目录规则负责局部精度
  • 通过按需加载，控制上下文成本

关于上下文的准确表述

这里更准确的说法不是“子目录规则不会占上下文”，而是：

  • 根目录规则：高概率常驻上下文
  • 子目录规则：按需进入上下文
  • 只有当 AI 处理到对应模块时，相关规则才会被加载

所以真正的重点是 分层加载，不是绝对意义上的“占”或“不占”。

放置规则的判断标准

一条规则应该放在哪一层，不看它叫“命名规范”还是“开发规范”，只看一个标准：

这是全局约束，还是局部约束？

放在 rules/ 根目录

当这条规则满足以下条件时，应放在根目录：

  • 整个仓库都适用
  • 不管改哪个模块都必须遵守
  • 不读取这条规则就容易出现全局性错误

例如：

  • 统一命名规范
  • 通用工程原则
  • 跨包边界约束
  • 修改禁区

放在某个目录 / package 下

当这条规则满足以下条件时，应放在局部目录：

  • 只对某个模块生效
  • 离开该目录后就不再适用
  • 属于实现细节或局部契约

例如：

  • 某个 package 的文件组织约定
  • 某个系统的 schema 规则
  • 某个目录专属的样式约束
  • 某类组件的特殊写法

自定义 Skill 的补充定位

除了 rules 之外，还可以补充 自定义 skill，用于承载“规则之外的能力型流程”。

它更适合解决的问题不是“必须遵守什么”，而是“遇到某类任务时，应该按什么流程完成”。

适合做成 skill 的典型场景包括：

  • code review
  • commit message 生成
  • 变更总结
  • 发布前检查
  • 架构扫描
  • 测试补全建议
  • 文档整理
  • 重构任务拆解

rules 和 skill 的区别

rules 负责约束

rules 回答的是：

  • 能不能这样做
  • 应该改哪里
  • 什么绝对不能破坏
  • 需要遵守什么约束
skill 负责执行流程

skill 回答的是：

  • 这类任务通常怎么做
  • 先看什么，再看什么
  • 输出格式是什么
  • 检查步骤是什么

可以简单理解为：

  • rules = 约束
  • skill = 流程模板 / 能力封装

例子

code review skill

可以定义为固定流程：

  1. 先看改动范围
  2. 再看是否违反根规则和目录规则
  3. 再看是否有架构越层、命名漂移、重复实现、类型破坏
  4. 最后输出 review 结论，按严重度分级
commit skill

可以定义为固定流程：

  1. 先读取当前变更
  2. 提炼改动主题
  3. 判断属于 feat / fix / refactor / docs / test / chore
  4. 生成简洁且符合团队规范的 commit message

所以，规则定义边界，skill 提供动作能力。两者是互补关系，不是替代关系。

常用指令说明

除了 rules 和 skill，还可以补充一组常用指令，用于控制 AI 的工作方式与上下文管理。

/clear

清空当前对话上下文，重新开始。
适合在任务已经切换、旧上下文干扰当前判断时使用。

作用：

  • 丢弃当前对话积累的上下文
  • 让 AI 重新基于新输入理解任务
  • 避免旧任务残留影响新任务

/compact

压缩当前上下文，把长对话收敛成较短的有效摘要。
适合在对话已经很长，但仍想延续当前任务时使用。

作用：

  • 保留关键信息
  • 压缩冗余上下文
  • 降低上下文占用
  • 让后续对话更聚焦

/plan

让 AI 先给出执行计划，再开始具体修改。
适合在任务较大、改动范围不明确、需要先对齐方案时使用。

作用：

  • 先拆分任务
  • 明确改动范围
  • 提前暴露潜在风险
  • 避免直接动手后走偏

常见使用场景：

  • 架构调整
  • 大型重构
  • 多文件联动修改
  • 新功能接入设计

/resume

基于已有上下文或已有计划继续推进任务。
适合在中断后继续、或者已经讨论过方案后接着执行时使用。

作用：

  • 延续之前的任务状态
  • 不从头重新分析
  • 直接进入后续执行阶段

常见使用场景：

  • 上一次讨论到一半被打断
  • 已经有 plan，准备继续实现
  • 需要延续上轮结论继续往下做

推荐的整体理解方式

可以把整个体系理解成三层：

1. rules

定义 必须遵守的约束

2. skills

定义 高频任务的执行流程

3. commands

定义 如何控制上下文和工作模式

三者分工如下：

  • rules：约束边界
  • skills：沉淀能力
  • commands：控制过程

一句话总结

rules/ 根目录承载全局硬规则，默认进入上下文；
monorepo 各目录承载局部规则，按需加载，不常驻上下文；
skills 用来封装高频任务流程；
常用 commands 用来控制上下文和 AI 的执行方式。

avatar
文章
阅读
粉丝