AI 编程工程化：Rule——给你的 AI 员工立规矩

上一篇我说过，用 AI 编程工具，本质上就是在带一个能力超强但什么都不知道的「新员工」。

这篇专门讲第一件事：给它立规矩。

在 Claude Code 的体系里，这个东西叫 Rule。

没有规矩，会发生什么

先说一个我自己经历过的真实场景。

刚开始用 AI 编程的时候，我手里有一个很多项目都在用的公共组件，是 Vue 2 + JavaScript 写的。我让 AI 帮我把它重构成 Vue 3 + TypeScript，并迁移到新的组件库开发框架。

当时我什么 Rule 都没有，直接选中目录，跟 AI 说："帮我重构为 Vue 3 + TS，并迁移到新组件库开发框架"

然后就开始和 AI 来回拉扯。

折腾了好几轮，组件确实是"能跑了"，但问题也一堆：

有些地方用了 Options API，有些地方用了 Composition API，代码风格前后不一致
业务逻辑、样式、交互代码全塞在一个 .vue 文件里，没有任何拆分
明明项目里已经有原子组件和 utils，它还是重新写了一套
AI 写完后没跑 ESLint，留下了一堆 warning
甚至还顺手删了一个"看起来没用"的文件

最离谱的是：它删完还一本正经地告诉我 ------ "已经清理了无用代码。"

问题其实不在 AI。

不是 AI 不聪明，而是它根本不知道你的规矩。

没人告诉它：

项目统一用 Composition API
组件逻辑需要 拆分模块
优先复用 已有组件和工具函数
提交前必须 跑 ESLint
哪些文件是 绝对不能动的

所以它只能按照 自己的理解去写代码。

而 AI 的理解，大概率是： "我觉得这样也行。"

于是就出现了各种风格混乱、重复造轮子、甚至误删文件的问题。

没有规矩，AI 就只能靠猜。

而一旦开始"猜"，结果就很容易失控。

什么是 Rule

说白了，Rule 就是一个叫 CLAUDE.md 的 Markdown 文件。

你在里面写规范、要求、限制，Claude Code 每次启动时会自动读取，然后按照里面的内容行事。

就这么简单。

你可以把它理解成给 AI 员工的「入职手册」。

区别在于：真实员工看完可能就忘了，或者压根没看。AI 每次开新对话都会重新读一遍。你写什么，它就按什么来。

Rule 分三层

CLAUDE.md 文件可以放在三个位置，各自有不同作用域：

第一层：用户全局规则

路径：~/.claude/CLAUDE.md

放在这里的规则，对你电脑上所有项目都生效。

适合写通用偏好，比如「总是用中文回复」「禁止删除任何文件」「默认用 pnpm 作为包管理器」。

第二层：项目级规则

路径：项目根目录的 CLAUDE.md

这是最常用的一层。跟着代码仓库走，可以提交到 git，团队成员共享同一套规则。

适合写：技术栈说明、编码规范、架构约定、禁用行为。

第三层：目录级规则

路径：某个子目录下的 CLAUDE.md

AI 进入这个目录时，自动加载这层规则。

适合在大型项目里做模块级约束。比如 backend/ 目录有一套规则，frontend/ 目录有另一套。

三层可以同时存在，叠加生效。遇到冲突，内层规则优先。

Rule 能解决什么问题

分四个场景说：

① 统一编码风格

团队里有人用 Composition API，有人用 Options API；注释中英文混着写。

让 AI 帮改代码，风格更乱。

写进 Rule，所有人通过 AI 产生的代码，风格自然就统一了：

markdown 复制代码

- 统一使用 Composition API + <script setup>
- 所有注释使用中文
- 2 空格缩进，不使用 Tab

② 限制危险行为

AI 有时「好心办坏事」------觉得某个文件多余就删了，觉得某个配置没用就改了。

写进 Rule，直接禁止：

markdown 复制代码

NEVER delete any files without explicit user confirmation
禁止读取 node_modules、dist 目录
禁止修改 .env 文件

这类规则，用全大写的 NEVER、MUST、IMPORTANT 效果更好。AI 对强调词的权重更高。

③ 定义架构约束

你约好了模块划分，AI 不知道，随手就破坏了结构。

写进 Rule：

markdown 复制代码

所有 API 请求封装在 src/api/ 目录下
组件只能放在 src/components/ 或对应页面目录
禁止在 components 里直接调用 API

④ 指定技术栈偏好

让 AI 写代码，它每次可能选不同的方案------这次用 fetch，下次用 axios；这次用 Vuex，下次用 Pinia。

写进 Rule，固定住：

markdown 复制代码

默认使用 pnpm 作为包管理器
HTTP 请求统一使用 axios，不使用 fetch
状态管理使用 Pinia，不使用 Vuex

怎么写一个 Rule

直接看完整示例。这是一个 Vue3 + TypeScript 项目的 CLAUDE.md：

markdown 复制代码

# 项目规则

## 技术栈
- Vue 3 + TypeScript + Vite
- Pinia（状态管理）
- axios（HTTP 请求）
- pnpm（包管理器）

## 目录结构
- src/api/        → 所有接口封装
- src/store/      → Pinia store
- src/components/ → 公共组件
- src/views/      → 页面组件
- src/utils/      → 公共方法

## 编码规范
- 使用 Composition API + <script setup>
- TypeScript strict 模式，禁止 any（需要用时注释说明原因）
- 2 空格缩进
- 注释统一使用中文

## 行为约束
NEVER delete any files
NEVER modify .env files
禁止读取 node_modules、dist 目录
修改超过 5 个文件前，MUST 先列出方案等待确认

## 提交前检查
- 运行 pnpm lint，确认无报错
- 运行 pnpm test，确认测试通过

就这些。不复杂。

建好文件，放到项目根目录，以后每次对话 Claude Code 都自动读取并遵守。

嫌麻烦？让 AI 帮你生成第一版

上面这个模板，你完全可以自己从零写。

但有个更快的方式：在项目根目录执行一条命令，让 Claude Code 替你生成。

bash 复制代码

claude init

就这一行。

Claude Code 会扫描你的项目------读 package.json、看目录结构、识别用了哪些框架和工具------然后自动生成一个 CLAUDE.md，内容就是根据你项目实际情况定制的规则草稿。

我在一个 Vue 3 + Vite 的项目里跑了一次，生成的内容大概是这样：

markdown 复制代码

# Project Rules

## Tech Stack
- Vue 3 + TypeScript + Vite
- Pinia for state management
- Vue Router 4
- pnpm as package manager

## Project Structure
- src/components/  → Reusable UI components
- src/views/       → Page components
- src/stores/      → Pinia stores
- src/api/         → API request modules
- src/utils/       → Utility functions

## Code Style
- Use Composition API with <script setup>
- TypeScript strict mode enabled
- ESLint + Prettier configured

## Constraints
NEVER delete files without confirmation
Run `pnpm lint` before committing

框架、目录、工具链，它都识别对了。

不是完美的，有些你项目特有的约定它猜不到。但作为第一版草稿，70% 的内容直接能用，剩下 30% 你自己补进去。

比从空白文件开始写，省力很多。

什么时候用 claude init？

新项目接手，还没有 CLAUDE.md 的时候，第一件事就跑这个命令。已有项目也可以用------生成后对比一下自己原来写的，看看有没有遗漏的地方。

进阶：按模块拆分规则

项目大了，所有规则堆在一个文件里会很乱，效果也会打折。

Claude Code 支持在 .claude/rules/ 目录下放多个规则文件：

bash 复制代码

.claude/
└── rules/
    ├── api.md         # API 开发规范
    ├── testing.md     # 测试规范
    ├── components.md  # 组件规范
    └── database.md    # 数据库操作规范

每个文件专注一个领域。AI 在处理相关任务时，自动加载对应规则。

主 CLAUDE.md 保持简洁，子规则文件处理细节。这是大型项目的正确姿势。

注意事项

写 Rule 时容易踩的几个坑：

别写太长。

我后来才知道，Claude Code 的系统提示词本身就占了很大一块权重。你的 CLAUDE.md 最好控制在 150 行以内，超过这个范围，后面的规则效果会打折。

社区里流传的经验数字是：200 条指令是一个上限，超过之后 AI 开始「选择性忽略」。写精不写多。

强调词放在显眼位置。

NEVER、MUST、IMPORTANT、CRITICAL 这类词，AI 会特别注意。禁止类规则用 NEVER，必做类规则用 MUST。

同等重要的规则，放在文件靠前的位置，优先级更高。

写清楚触发条件，不只是规则本身。

光写「禁止删除文件」还不够，补上触发逻辑更有效：

markdown 复制代码

NEVER delete files --- if cleanup seems needed, ask the user first

这样 AI 遇到边界情况时有据可依，不靠猜测。

Rule 是迭代出来的，不是一次写完的。

先写基础版本，用着用着发现 AI 哪里出了问题，回头把对应规则补上去。慢慢地，CLAUDE.md 就会越来越贴合你的实际需求。

最后

Rule 是 AI 编程工程化体系里成本最低、效果最立竿见影的那一环。

其他的 Command、Skill、Hook、MCP 等都要花时间研究和配置。

Rule 不需要。建一个 CLAUDE.md，花 10 分钟写下基本规矩，之后开新项目复制过来改改。就这一步，能解决你 70% 跟 AI 协作不顺的问题。

先定边界，再谈效率。

你不给 AI 立规矩，它就会按自己的理解来。

那不是你想要的。

下一篇我们讲 Command：哪些操作值得封装成快捷命令，哪些不值得。

欢迎感兴趣的朋友继续保持关注~