上一篇我说过，用 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 产生的代码，风格自然就统一了：
1 | - 统一使用 Composition API + <script setup> |
② 限制危险行为
AI 有时「好心办坏事」——觉得某个文件多余就删了，觉得某个配置没用就改了。
写进 Rule，直接禁止：
1 | NEVER delete any files without explicit user confirmation |
这类规则，用全大写的 NEVER、MUST、IMPORTANT 效果更好。AI 对强调词的权重更高。
③ 定义架构约束
你约好了模块划分，AI 不知道，随手就破坏了结构。
写进 Rule：
1 | 所有 API 请求封装在 src/api/ 目录下 |
④ 指定技术栈偏好
让 AI 写代码，它每次可能选不同的方案——这次用 fetch，下次用 axios；这次用 Vuex，下次用 Pinia。
写进 Rule，固定住：
1 | 默认使用 pnpm 作为包管理器 |
怎么写一个 Rule
直接看完整示例。这是一个 Vue3 + TypeScript 项目的 CLAUDE.md：
1 | # 项目规则 |
就这些。不复杂。
建好文件，放到项目根目录，以后每次对话 Claude Code 都自动读取并遵守。
嫌麻烦？让 AI 帮你生成第一版
上面这个模板，你完全可以自己从零写。
但有个更快的方式：在项目根目录执行一条命令，让 Claude Code 替你生成。
1 | claude init |
就这一行。
Claude Code 会扫描你的项目——读 package.json、看目录结构、识别用了哪些框架和工具——然后自动生成一个 CLAUDE.md，内容就是根据你项目实际情况定制的规则草稿。
我在一个 Vue 3 + Vite 的项目里跑了一次，生成的内容大概是这样：
1 | # Project Rules |
框架、目录、工具链，它都识别对了。
不是完美的，有些你项目特有的约定它猜不到。但作为第一版草稿，70% 的内容直接能用，剩下 30% 你自己补进去。
比从空白文件开始写，省力很多。
什么时候用 claude init？
新项目接手，还没有 CLAUDE.md 的时候，第一件事就跑这个命令。已有项目也可以用——生成后对比一下自己原来写的，看看有没有遗漏的地方。
进阶：按模块拆分规则
项目大了，所有规则堆在一个文件里会很乱，效果也会打折。
Claude Code 支持在 .claude/rules/ 目录下放多个规则文件：
1 | .claude/ |
每个文件专注一个领域。AI 在处理相关任务时，自动加载对应规则。
主 CLAUDE.md 保持简洁，子规则文件处理细节。这是大型项目的正确姿势。
注意事项
写 Rule 时容易踩的几个坑：
别写太长。
我后来才知道，Claude Code 的系统提示词本身就占了很大一块权重。你的 CLAUDE.md 最好控制在 150 行以内，超过这个范围，后面的规则效果会打折。
社区里流传的经验数字是：200 条指令是一个上限，超过之后 AI 开始「选择性忽略」。写精不写多。
强调词放在显眼位置。
NEVER、MUST、IMPORTANT、CRITICAL 这类词，AI 会特别注意。禁止类规则用 NEVER，必做类规则用 MUST。
同等重要的规则，放在文件靠前的位置，优先级更高。
写清楚触发条件，不只是规则本身。
光写「禁止删除文件」还不够，补上触发逻辑更有效：
1 | 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：哪些操作值得封装成快捷命令，哪些不值得。
欢迎感兴趣的朋友继续保持关注~