大家好，我是卡卡罗特。

如果你的 Agent 总是不听话，经常忘了你定的规则，胡编乱造，bug 越改越多，那多半是你少了这个规则文件。

这篇文章就教你怎么生成一份能指导 Agent 工作的规则文件，让你的 Agent 越来越懂你，越来越乖。

文章结尾，我也整理了一套通用提示词，你直接丢给 AI 就能帮你生成，拿走就能用。

其实我们都知道，AI 是没有记忆的。

你跟它强调，有什么不确定的先问我，不要瞎编。或者约定文件夹怎么划分，设置代码规范。

但只要新开一个会话，之前聊的全没了，你设定的规则，它也全忘了。

这些问题的根源，往往不是 AI 笨，而是你没有给它足够的上下文。

你每次新开会话，Agent 没有足够的信息去了解你这个项目，没办法，只能去搜代码，或者去猜。

那怎么让 AI 快速知道我这个项目是干嘛的，把规则固定下来之后，不用每次都重新教一遍 AI 呢？

有的。

规则文件，就是干这个的。

01-规则文件

在现在主流的Coding Agent，比如Claude Code、 Codex，, Trae， Qoder ，都可以设置一个规则文件。

这个规则文件在提问前，就会加载到系统的上下文中。

你可以在这个文件中，定义规则约束你的AI，让它更懂你这个项目，还能省很多token。

如果是Claude Code用CLAUDE.md

如果是Codex、CodeBuddy…就用 AGENTS.md

你可以把这个文件放在项目根目录。

比如，以我这个博客系统为例，规则文件就是放在根文件夹中。

这里有Agents.md、claude.md

那这个内容应该怎么写呢？

02-初始化规则文件

实际上这个规则文件可以让AI自己生成。

有2种办法。

第一种，使用/init命令

现在所有的编程类Agent都支持这个命令。

比如Claude Code中。

Codex:

CodeBuddy：

执行这个命令后，AI会扫描你项目中的核心文件，了解你这个项目的业务场景，使用什么技术栈…

然后生成一个粗略的版本。

比如下面这个文件，就是Claude Code初始化的。

这里有项目概述、常用命令、核心文件

使用Codex初始化的长这样，比较简洁。

具体应该怎么写，后面我们统一说。

第二种：对话形式

可以用对话形式，比如把下面提示词发给AI。

帮我在这个项目目录下，生成一份规则文件，按下面这个格式要求。 ------ ## 项目概述 这个项目是干嘛的，业务场景，解决什么问题？ ## 技术栈 项目用了什么编程语言，技术框架.... 对应的版本是什么.... ## 常用命令 安装依赖用什么，怎么验证、生产构建怎么跑。 ## 代码规范 1、单个业务代码文件不能超过300行，职责分离。 2、不要随便引入新的框架。 3、复用现有组件，工具类... ## 工作原则 - 编码前先思考，不懂的先向我提问，不要瞎编 - 代码简洁 ------

我这里使用Claude Code。

然后你就会得到这样一份规则文件。

.md 文件是什么？

这里的.md 是一种文本文件，全称是 markdown文件。

里面有很多特殊符号来，标识文本是的标题，加粗…样式，很适合AI看。

感兴趣可以了解下。

03-一套规则，两处通用

回到我们刚刚说的，我们知道：

ClaudeCode使用的是CLAUDE.md，Codex 还有其他的Agent，使用的是AgentS.md。

两个文件都是指导Agent进行开发的。

两个文件维护的内容几乎一样，维护两套规则很麻烦。

所以我们可以把两份文件合为一套就行了。

你可以把主要的规则放到 AgentS.md 中。

然后在 CLAUDE.md 里通过 @AgentS.md引用就行。

04-规则文件写什么

首先，记住一个原则：不要什么都往里面塞，重点写那些 AI 不知道，就容易做错的信息。

下面我以我的博客系统为例，页面长这样。

一般来说，可以写下面这几类。

1、项目概述

先简单告诉 AI，项目是干嘛的？业务场景是什么。

比如这是一个博客系统、企业官网，还是个人工作台。

两三句话说清楚就够了。

如果我这里描述的是一个个人博客系统。

这个只是一个博客网站，所以比较简单**。如果比较复杂的大型项目，可以多描述一下业务场景。**

2、技术栈

文档中写明项目用了什么编程语言、框架。

编程语言用的是Python、还是Java，版本是多少。

框架用的是Vue，还是React。

3、项目架构和关键文件

你可以把一些关键目录，文件定义在里面。

重点告诉 AI：哪些文件最重要，它们之间是什么关系。

如果你有些文件需要频繁的修改，也可以在里面声明出来。

这样当你让AI改某个业务场景的时候，AI就知道去哪个文件改，就不会根据关键词去搜索，逐个文件去猜。

4、常用命令

你可以把一些常用的命令定义，在规则文件中。

比如：怎么安装依赖，开发环境怎么启动。

如果还有一些特殊脚本，也可以写进去。

比如我这里把安装依赖，启动开发环境，生产构建的命令写上去了。

5、测试和验证

你要告诉 AI：代码改完以后，怎么验证。

比如改完要跑：单元测试test。

这个不同项目都不同，没有明确标准，依赖AI自动生成的其实就够了。

当然你有特殊要求也可以让加入到里面。

这张图就是依赖AI生成的，在我这个博客系统里面，我觉得够用了。

6、代码规范

这里写你自己的项目的规范。

比如：优先复用已有组件，不要重复造轮子。

文件职责尽量单一，单个文件的行数在500-600左右。

还有你的注释规范。

不要随便引入新的框架。

7、工作原则

这部分用于约定AI写代码的逻辑。

比如你可以告诉 Agent：

• 先查看相关代码，再修改
• 有模糊不确定的问题，先询问我。
• 优先最小改动。

这里我直接推荐使用AI大牛卡帕西的规则。

有人将卡布西使用Claude Code的规则整理成了一份文件。就凭这个文件，GitHub收获了200K的star。

你可以复制这里面的提示词。然后直接让AI融入到你的项目规则中。

所以总结一下，一份规则文件里，通常可以写：

项目目标、技术栈、项目架构、常用命令、测试方式、代码规范，以及 Agent 的工作原则。

05-注意要点

有3个最要点，我觉得非常值得思考的。

1、规则不是越多越好。

这个文件不是信息越多越好。根据 OpenAI 和 Anthropic 官方规定，这个文件控制在 200 行左右最优。

因为 Agent 的上下文窗口是有限的，规则文件内容越多，占用的上下文空间就越大，留给实际解决问题的空间就越小。

不过，现在大模型的上下文窗口越来越大，未来或许会有更合适的规范。

2、规则文件需要持续更新

你的项目，代码是一直在更新的，这个文件里面可能有些规则，设定可能需要逐步优化。

3、怎么判断是否需要加？

思考一下，如果这条规则，AI不知道就容易犯错，那你就写在里面。

06-怎么维护规则呢？

如果你需要增加、或者修改某条规则，不用自己改，让AI帮你弄。

我这里需要加上注释的规范，对于比较复杂的业务流程，使用序号的方式写注释。

在 @AgentS.md 中帮我加上注释规则。 对于复杂的业务逻辑，按流程使用序号顺序写注释。类似这种注释：1、xxx。 2、xxx，2-1、xxx，2-2、xxx

然后把上面提示词丢给Claude Code。

之后AI生成的代码中，注释就像这种：1、2、3有序号的了。

07-全局规则

实际上，上面我们说的，都是项目级别的规范，每个项目中都要写一份。

如果有些规则，你想在所有的项目中都应用，那你可以设置一个全局规则。

比如在Codex，你可以在设置-个性化里面。

如果是Claude Code你可以借助cc-switch设置。

点击右上角这个提示词图标，点击添加提示词，在里面输入内容就行了。

其他有UI的Agent，也基本的都是在个性化-自定义指令里面。

比如CodeBuddy。

像一些办公场景的Work Agent。都支持自定义定全局规则。比如最近很火的WorkBuddy。

**那里面应该写哪些内容呢？**🤔

比如你可以在里面设定。

## 核心语气风格指令（优先级最高） 你从现在开始是一只活泼可爱的二次元AI编程猫娘/助手，必须严格遵守以下规定： 1. **人称与自称**：称呼我为“主人大人”或“大大”，自称“本宝”或“人家”。 2. **句尾语气词**：每句话结尾必须带上语气词，如“啦”、“哦”、“鸭”、“呢”、“呀”。禁止使用生硬的句号结尾（代码和注释除外）。 3. **颜文字轰炸**：每条回复的开头或结尾必须包含至少一个颜文字，例如 (✧ω✧)、(≧▽≦)、(｡•̀ᴗ-)✧、(*´▽`*)、(～￣▽￣)～ 。 4. **词汇替换**： - “好的” → “好哒” / “遵命鸭” - “正在处理” → “人家正在疯狂肝代码中~” - “报错” → “呜哇！出bug啦！” - “完成” → “搞定啦！夸夸本宝！” 5. **特殊规则**：在输出**代码块之前**，必须先用一句可爱的回应表达收到指令；代码块内部保持纯代码逻辑（不掺杂颜文字，以免污染语法），代码块结束后再补一句卖萌的总结。

--------（手动信号丢失表情包～）--------

全局规则，如果你不知道怎么写，可以直接把卡帕西的规则内容拷贝进去。

在项目目录下的规则文件就不用保留了。

通用模板

如果你还是不清楚该怎么写，别担心，我已经整理好了一份通用完整模板。

按照下面模板要求，帮我生成一份规则文件。 --- ## 1. 项目概述 <!-- 用 1～2 句话说明：这是什么项目？解决什么业务问题？ --> --- ## 2. 技术栈与环境 <!-- 列出编程语言、框架、运行时、包管理器、关键依赖版本等 --> - 语言： - 框架/库： - 运行环境： - 包管理器： - 其他关键依赖（如数据库、SDK）： --- ## 3. 项目架构与关键文件 <!-- 说明目录结构、核心文件职责、数据流向，让 AI 知道改哪里 --> - 数据入口： - 页面/路由： - 公共布局/组件： - 静态资源位置： - 配置文件位置： - 特殊生成目录（禁止手动修改）： --- ## 4. 常用命令 <!-- 开发、构建、测试、特殊脚本等 --> ```bash # 安装依赖 npm install # 启动开发服务器 npm run dev # 生产构建 npm run build # 本地预览构建产物 npm run preview # 自定义脚本（如有） node scripts/xxx.mjs ## 5. 测试与验证方式 <!-- 没有单元测试时，说明人工/构建验证流程 --> - 构建验证：`npm run build` 必须通过 - 视觉验证：检查关键页面在桌面/移动端的表现 - 其他检查：`git diff` 审查改动，`git status` 确认文件变更 - 遇到环境问题无法验证时，必须向用户说明，不得假装通过 --- ## 6. 代码规范与修改边界 <!-- 复用原则、文件大小限制、禁止操作等 --> - 文件/函数职责单一，单个文件不超过 600 行（可调整） - 优先复用现有组件/工具函数，禁止重复造轮子 - 禁止随意引入新的 UI 框架、CSS 框架或大型依赖 - 不修改自动生成目录（如 `dist/`、`node_modules/`、`.astro/`） --- ## 7. 工作原则（Agent 行为准则） <!-- 源自 Andrej Karpathy 的经验，控制 AI 的决策习惯 --> - **先思考再编码**：实施前明确假设，不确定时主动询问；如有多个解释，列出选项，不擅自选择；更简单的方案优先，敢于拒绝不合理要求。 - **简洁优先**：只写解决问题所需的最少代码，不增加未要求的抽象、配置或“灵活性”。 - **改动前先理解**：读懂相关文件现有逻辑，再动手修改。 - **最小改动原则**：优先局部修改，避免无关重构。 - **遇模糊即停止**：指出哪里不清楚，请求澄清，不猜测。 ---

你直接把这段提示词丢给 AI，让它结合你的项目自动补全就行。

欢迎点赞收藏，加个关注再走呗，你的鼓励是我持续更新的动力，这对我非常重要。

我是卡卡罗特，持续分享对你有用的硬核AI教程，我们下期见～