AI 总乱改代码？一个规则文件帮你搞定（附完整提示词）

核心命题：Agent 瞎编、乱改、bug 越改越多，根源往往不是模型笨，而是你没有给它足够的上下文。
解法一句话：在项目根目录放一份规则文件，让它在每次提问前自动加载进上下文。 文末附可直接复制的通用提示词模板。

如果你的 Agent 总是不听话，经常忘了你定的规则，胡编乱造，bug 越改越多，那多半是你少了这个规则文件。这篇文章讲怎么生成一份能指导 Agent 工作的规则文件，让你的 Agent 越来越懂你、越来越乖。

---

一、为什么需要规则文件

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

你跟它强调「有什么不确定的先问我，不要瞎编」，或者约定文件夹怎么划分、设置代码规范；但只要新开一个会话，之前聊的全没了，你设定的规则它也全忘了。

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

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

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

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

---

二、规则文件是什么

现在主流的 Coding Agent，比如 Claude Code、Codex、Trae、Qoder，都可以设置一个规则文件。这个规则文件在提问前就会加载到系统的上下文中。你可以在这个文件中定义规则约束你的 AI，让它更懂你这个项目，还能省很多 token。

Agent	规则文件名
Claude Code	CLAUDE.md
Codex、CodeBuddy 等	AGENTS.md

文件放在项目根目录即可。以本文示例的博客系统为例，规则文件就放在根文件夹中：

根目录里同时有 AGENTS.md 和 claude.md。那这个内容应该怎么写呢？

---

三、初始化规则文件的两种方式

实际上这个规则文件可以让 AI 自己生成，有 2 种办法。

方式一：使用 /init 命令

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

Claude Code 中：

Codex：

CodeBuddy：

执行这个命令后，AI 会扫描你项目中的核心文件，了解你这个项目的业务场景、使用什么技术栈，然后生成一个粗略的版本。

比如下面这个文件，就是 Claude Code 初始化的，里面有项目概述、常用命令、核心文件：

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

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

方式二：对话形式

可以用对话形式，把下面这段提示词发给 AI：

帮我在这个项目目录下，生成一份规则文件，按下面这个格式要求。
---
## 项目概述
这个项目是干嘛的，业务场景，解决什么问题？

## 技术栈
项目用了什么编程语言，技术框架....
对应的版本是什么....

## 常用命令
安装依赖用什么，怎么验证、生产构建怎么跑。

## 代码规范
1、单个业务代码文件不能超过300行，职责分离。
2、不要随便引入新的框架。
3、复用现有组件，工具类...

## 工作原则
- 编码前先思考，不懂的先向我提问，不要瞎编
- 代码简洁
---

这里使用 Claude Code 发送：

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

补充：.md 文件是什么

这里的 .md 是一种文本文件，全称是 markdown 文件。里面有很多特殊符号来标识文本的标题、加粗等样式，很适合 AI 看。感兴趣可以了解下。

---

四、一套规则，两处通用

回到刚刚说的：Claude Code 使用的是 CLAUDE.md，Codex 还有其他的 Agent 使用的是 AGENTS.md。两个文件都是指导 Agent 进行开发的，维护的内容几乎一样，维护两套规则很麻烦。

所以我们可以把两份文件合为一套： 把主要的规则放到 AGENTS.md 中，然后在 CLAUDE.md 里通过 @AGENTS.md 引用就行。

---

五、规则文件应该写什么

首先记住一个原则：不要什么都往里面塞，重点写那些「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 大牛卡帕西（Andrej Karpathy）的规则。有人将卡帕西使用 Claude Code 的规则整理成了一份文件，就凭这个文件，GitHub 收获了 200K 的 star。

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

配图所示仓库为 GitHub 上的 multica-ai/andrej-karpathy-skills（Public，约 201.7K star），可取用文件包括 CLAUDE.md、CURSOR.md、EXAMPLES.md、README.zh.md 与 skills/karpathy-guidelines 等。原文只给了仓库与 CLAUDE.md 开头部分的截图，全文需到该仓库自取。

小结

一份规则文件里，通常可以写：项目目标、技术栈、项目架构、常用命令、测试方式、代码规范，以及 Agent 的工作原则。

---

六、三个注意要点

有 3 个要点非常值得思考。

1、规则不是越多越好。 这个文件不是信息越多越好。根据 OpenAI 和 Anthropic 官方规定，这个文件控制在 200 行左右最优。因为 Agent 的上下文窗口是有限的，规则文件内容越多，占用的上下文空间就越大，留给实际解决问题的空间就越小。不过，现在大模型的上下文窗口越来越大，未来或许会有更合适的规范。

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

3、怎么判断是否需要加？ 思考一下：如果这条规则 AI 不知道就容易犯错，那你就写在里面。

---

七、怎么维护规则

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

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

在 @AgentS.md 中帮我加上注释规则。

对于复杂的业务逻辑，按流程使用序号顺序写注释。类似这种注释：1、xxx。 2、xxx，2-1、xxx，2-2、xxx

注：@AgentS.md 为原文写法，即 AGENTS.md。

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

之后 AI 生成的代码中，注释就变成 1、2、3 带序号的形式了：

---

八、全局规则

实际上，上面说的都是项目级别的规范，每个项目中都要写一份。如果有些规则你想在所有项目中都应用，那你可以设置一个全局规则。

Agent	全局规则设置入口
Codex	设置 - 个性化
Claude Code	借助 cc-switch：点击右上角提示词图标 → 添加提示词 → 输入内容
CodeBuddy	个性化 - 自定义指令
WorkBuddy 等办公 Work Agent	支持自定义全局规则

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

如果是 Claude Code，你可以借助 cc-switch 设置。点击右上角这个提示词图标，点击添加提示词，在里面输入内容就行了：

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

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

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

比如你可以在里面设定语气风格。原文给了一份可直接复制的示例（「核心语气风格指令」），逐字如下：

## 核心语气风格指令（优先级最高）
你从现在开始是一只活泼可爱的二次元AI编程猫娘/助手，必须严格遵守以下规定：

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

全局规则如果你不知道怎么写，可以直接把卡帕西的规则内容拷贝进去。这样一来，项目目录下的规则文件就不用保留了。

---

九、通用完整模板

如果还是不清楚该怎么写，别担心，下面是一份通用完整模板。把这段提示词丢给 AI，让它结合你的项目自动补全就行：

按照下面模板要求，帮我生成一份规则文件。
---
## 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 的决策习惯 -->
- **先思考再编码**：实施前明确假设，不确定时主动询问；如有多个解释，列出选项，不擅自选择；更简单的方案优先，敢于拒绝不合理要求。
- **简洁优先**：只写解决问题所需的最少代码，不增加未要求的抽象、配置或“灵活性”。
- **改动前先理解**：读懂相关文件现有逻辑，再动手修改。
- **最小改动原则**：优先局部修改，避免无关重构。
- **遇模糊即停止**：指出哪里不清楚，请求澄清，不猜测。
---

注：模板中第 4 节内嵌的 bash 代码块在原文里未闭合，此处按原文原样保留。

---

参考

• 原文出处：微信公众号「卡卡罗特AI」，《AI总乱改代码？一个规则文件帮你搞定！99%的人都没设置！附完整提示词》，2026-08-15，https://mp.weixin.qq.com/s/xtaAmEjjCa_5r5hv-j1h5A
• 卡帕西规则仓库：https://github.com/multica-ai/andrej-karpathy-skills