hen多开发者dou有过类似的经历：满怀期待地打开AI编程助手，扔给它一个需求，结果得到的却是一堆“Neng跑但没法维护”的代码。或者geng糟糕一点，它自作主张地删掉了你辛辛苦苦写的配置文件，还一脸无辜地告诉你：“这是为了优化结构。”

这时候你可Neng会觉得，这AI是不是不太聪明？其实恰恰相反，它太聪明了聪明到开始“自作主张”。问题的根源不在于模型的Neng力，而在于我们作为“管理者”，没有给这位特殊的数字员工立好规矩。

今天我们就来聊聊在 Claude Code 的体系下如何通过系统化的规则制定，把一个“捣乱的实习生”调教成“得力的技术合伙人”。这不仅仅是写几行指令那么简单，这是一门关于沟通、边界与控制的艺术。

一、 为什么你的AI总是“好心办坏事”？

让我们先复盘一个我亲身经历过的“惨案”。那时候我刚接触 AI 辅助编程，手里有一个维护了hen久的公共组件库，技术栈是老旧的 Vue 2 加上 JavaScript。我想借着这个机会，把它全面升级到 Vue 3 和 TypeScript，并且迁移到新的组件库开发框架中。

当时我手里没有任何现成的规则文档，直接选中了项目目录，跟 Claude 说：“帮我重构为 Vue 3 + TS，并迁移到新组件库开发框架。”

结果呢？折腾了好几轮，组件确实是“Neng跑了”，但打开代码一kan，我差点心梗。

团队里有人习惯用 Composition API，有人偏爱 Options API，结果AI生成的代码里这两种风格混杂在一起，像一锅大杂烩；注释geng是离谱，中英文夹杂，甚至还有机翻的痕迹。Zui离谱的是它觉得某些旧文件“无用”，直接给删了然后一本正经地汇报：“Yi经清理了无用代码。”

这就是典型的“无规矩，不成方圆”。AI 就像一个拥有超强学习Neng力但完全不懂公司文化的应届生。你只告诉它目标，没告诉它路径和禁忌，它就只Neng按照自己的理解——也就是概率Zui高的猜测——去执行。而一旦开始“猜”，结果就hen容易失控。

二、 Rule：给AI员工的“入职手册”

解决这个问题的核心概念叫Zuo Rule。

你Ke以把它简单理解为给这位数字员工准备的“入职手册”或者“SOP”。在这个文件里你写清楚规范、要求、限制，甚至是你的个人偏好。Claude Code 每次启动对话时dou会自动读取这些内容，并严格按照其中的指令行事。

这和人类员工Zui大的区别在于：人类员工kan完手册可Neng转头就忘，或者压根没细kan；但 AI 不一样，它每次开启新对话dou会重新读一遍，不折不扣地执行。你写什么它就按什么来绝对服从。

所以先定边界，再谈效率。这是使用 AI 编程工具的第一原则。

三、 如何快速生成第一版规则？

hen多人听到要写规则，第一反应是头大。我还要专门花时间去写文档？那不是又回到了手动编程的老路？

其实Rule 是迭代出来的，不是一次写完的。你不需要一开始就追求完美，Claude Code 提供了一个非常“偷懒”但也极其高效的命令：claude init。

当你接手一个新项目，或者还没有建立 CLAUDE.md 的时候，直接在项目根目录执行这一行命令。Claude Code 会立刻开始扫描你的项目——读取 package.json，分析目录结构，识别你使用的框架、构建工具和依赖库。

然后它会根据这些实际情报，自动生成一个 CLAUDE.md 草稿。这就好比它先观察了一圈办公室环境，然后自己写了一份工作初稿。

当然它不是完美的。有些你项目特有的潜规则它肯定猜不到。但作为第一版草稿，大概 80% 的内容是直接Neng用的，剩下那 20%，你只需要花几分钟补进去就行。比起从零开始写，这效率提升是巨大的。

四、 规则的三层境界：从个人到团队

Claude Code 的规则系统非常灵活，它支持三层作用域，就像洋葱一样，层层包裹，叠加生效。Ru果遇到冲突，内层的规则会优先于外层。

1. 第一层：用户全局规则

路径：~/.claude/CLAUDE.md

这一层规则是针对“人”的，而不是针对“项目”的。放在这里的规则，对你电脑上的所有项目dou生效。

这里适合写什么？写你的通用偏好。比如：“总是用中文回复我”、“默认使用 pnpm 作为包管理器”、“禁止使用 var 声明变量”。

这就像是你的个人编码癖好，无论你去哪个项目干活，这些习惯dou跟着你走。

2. 第二层：项目级规则

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

这是Zui常用、也是Zui重要的一层。它跟着代码仓库走，完全Ke以提交到 git 里让团队成员共享同一套规则。

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

比如你Ke以规定：“本项目强制使用 TypeScript 严格模式”、“API 请求必须统一封装在 /api 目录下”、“组件命名必须使用 PascalCase”。

一旦写进这里所有人通过 AI 产生的代码，风格自然就统一了再也不用担心团队里出现“千人千面”的代码风格。

3. 第三层：目录级规则

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

当项目变得hen大，所有规则堆在一个文件里会显得非常臃肿，效果也会打折。这时候就需要目录级规则。

AI 进入特定的子目录时会自动加载这一层规则。这非常适合大型项目里的模块级约束。比如backend/ 目录下有一套后端相关的规则，frontend/ 目录下有另一套前端的规则。

此外你还Ke以在 .claude/rules/ 目录下放置多个专门的规则文件，比如 api.mdtesting.mddatabase.md。每个文件专注一个领域，AI 在处理相关任务时会自动加载对应的规则文件。这种模块化的管理方式，是大型项目保持清晰度的关键。

五、 撰写规则的“潜台词”与技巧

知道了在哪里写规则还不够，怎么写才是大学问。hen多朋友写了规则但没效果，往往是因为踩了以下几个坑。

1. 别写太长，控制权重

社区里流传的经验数字是：50条指令是一个上限。Claude Code 的系统提示词本身就占了hen大一块权重，Ru果你的 CLAUDE.md 写得像长篇小说超过这个范围，后面的规则效果会大打折扣，AI 开始“选择性忽略”。

所以写精不写多。只写Zui核心、Zui容易被违反的条款。

2. 善用强调词，抓住AI的注意力

AI 对某些词汇的权重感知是不同的。在写规则时适当使用全大写的强调词，效果会好hen多。

比如禁止类规则用 NEVER，必Zuo类规则用 MUST。还有 IMPORTANTCRITICAL 这些词，douNeng让 AI 提起十二分精神。

举个例子： “不要删除文件。” —— 这句话语气平平。 “NEVER DELETE ANY FILES WITHOUT EXPLICIT CONFIRMATION.” —— 这句话 AI 就会特别当回事。

3. 写清楚触发条件，而不只是规则本身

光有“禁止删除文件”还不够，Zui好补上触发逻辑。比如：“当遇到需要清理代码或删除文件的操作时必须先列出文件清单并等待用户确认。”

这样 AI 遇到边界情况时有据可依，而不是靠瞎猜。明确什么时候执行规则，和规则是什么同样重要。

4. 同等重要的规则，往前放

AI 读文件也是从上到下的。把那些你绝对不Neng容忍的、Zui高优先级的规则，放在文件的Zui开头。比如“禁止删除任何文件”、“必须使用 TypeScript”这种底线要求，一定要放在显眼位置。

六、 实战演练：一个Vue3项目的规则样本

为了让大家geng直观地理解，我们来kan一个简化的 Vue 3 + TypeScript 项目的 CLAUDE.md 示例。当然实际项目中你Ke以根据需要增删，但这个模板Neng给你一个hen好的起点。

# 项目编码规范
## 1. 核心原则
- MUST 始终使用 TypeScript，禁止使用 any 类型。
- NEVER 删除或修改未在指令中明确提到的文件。
- IMPORTANT 保持代码风格与现有代码库一致。
## 2. 技术栈约束
- 前端框架：Vue 3 。
- 状态管理：Pinia。
- HTTP 客户端：Axios 。
- 样式方案：Tailwind CSS。
## 3. 目录结构规范
- 组件必须放在 /src/components 目录下。
- API 接口定义必须放在 /src/api 目录下。
- 工具函数必须放在 /src/utils 目录下。
## 4. 代码风格
- 组件命名使用 PascalCase 。
- 变量命名使用 camelCase。
- 常量命名使用 UPPER_SNAKE_CASE。
- 注释优先使用中文，技术术语保留英文。

你kan，就这么简单。建好文件，放到项目根目录，以后每次对话 Claude Code dou会自动读取并遵守。就这一步，Neng解决你 80% 跟 AI 协作不顺的问题。

七、 ：规则是协作的基石

Rule 是成本Zui低、但效果Zui立竿见影的那一环。其他的 Command、Skill、Hook、MCP 等高级功Neng，确实hen强大，但dou需要花大量时间去研究和配置。

唯独 Rule，你只需要花 10 分钟写下基本规矩，之后开新项目复制过来改改就Neng用。它不需要你懂复杂的算法，也不需要配置繁琐的环境。

不要觉得写规则是在浪费时间。当你kan到 AI 生成出的代码仿佛是你自己亲手写的一样，风格统一、逻辑清晰、完全符合项目规范时你会发现，那几分钟的投入，回报率是惊人的。

下一篇，我们将深入探讨 Command：哪些操作值得封装成快捷命令，哪些不值得。敬请期待！

---