很多人刚开始用 Codex 时，都会遇到一个问题：
它确实能写代码，但有时候写出来的风格不像我的项目。
比如你的项目用 pnpm，它却用了 npm；你们约定提交前要跑 lint，它忘了；你希望它少做大重构，它却顺手改了一堆无关文件。
这不是 Codex 不聪明，而是它还不知道你的团队习惯。
所以，想让 Codex 真正变成“懂项目的编码搭档”，第一步不是疯狂提 prompt，而是给它写清楚：这个项目有哪些规则。
在 Codex 里，最重要的规则通常有两类：
- 编码协作规则：写在
AGENTS.md - 命令权限规则：写在
.codex/rules/*.rules
这篇文章重点讲前者，也顺带解释后者什么时候用。
Codex 规则不是越多越好
很多人写规则时容易一上来就塞一大堆：
代码要优雅
不要出 bug
性能要好
遵守最佳实践
这些话看起来没错，但对 Codex 帮助不大。
好的 Codex 规则应该具体到“它下一步该怎么做”。
比如：
- 修改前先阅读相关模块，不要直接凭猜测改代码。
- 修改 JavaScript/TypeScript 文件后，运行 `pnpm lint`。
- 不要主动引入新的生产依赖，除非用户明确同意。
- 保持现有代码风格，不做无关重构。
你会发现，这些规则都很具体。
Codex 能知道什么时候该读文件，什么时候该跑测试，什么时候该停下来确认。
这才是有效规则。
最常用的是 AGENTS.md
根据 OpenAI 官方文档，Codex 会在开始工作前读取 AGENTS.md，用它获得项目额外说明和工作约定。
最简单的方式，是在项目根目录创建一个文件：
AGENTS.md
然后写入项目规则：
# AGENTS.md
## 项目约定
- 使用 `pnpm` 管理依赖，不要使用 `npm install`。
- 修改前端代码后，运行 `pnpm lint`。
- 修改核心业务逻辑后，补充或更新测试。
- 不要修改 `.env`、密钥、证书等敏感文件。
- 保持改动范围最小，不做无关格式化和重构。
这样每次 Codex 在这个仓库里工作时，就能先看到这些约定。
全局规则和项目规则要分开
Codex 的规则可以分层。
如果是你个人在所有项目里都希望遵守的习惯，可以写到全局文件：
~/.codex/AGENTS.md
Windows 用户可以理解成类似：
C:\Users\你的用户名\.codex\AGENTS.md
全局规则适合放个人偏好：
## 我的通用工作习惯
- 回答使用中文。
- 修改代码前先说明计划。
- 优先使用 `rg` 搜索文件和文本。
- 不要主动执行危险命令。
项目规则则放在仓库根目录：
你的项目/AGENTS.md
适合写项目专属内容：
## 当前项目规则
- 本项目使用 Vue 3 + TypeScript。
- 包管理器使用 `pnpm`。
- API 类型定义放在 `src/types/api.ts`。
- 组件样式遵循现有 Tailwind 写法。
- 提交前至少运行 `pnpm lint`。
这样做的好处是：个人习惯不会污染团队项目，项目规则也能随代码仓库一起共享。
子目录也可以有自己的规则
如果项目很大，比如有多个服务：
project/
AGENTS.md
services/
payment/
AGENTS.md
user/
AGENTS.md
你可以在不同目录写不同规则。
比如支付模块：
# services/payment/AGENTS.md
## 支付模块规则
- 修改支付逻辑时必须保持向后兼容。
- 不要修改金额精度处理方式，除非用户明确要求。
- 涉及退款、对账、签名校验时，需要补充测试。
- 不要打印完整银行卡号、Token 或签名密钥。
Codex 官方文档里提到，它会从项目根目录一路向当前工作目录读取规则，越靠近当前目录的规则越具体。
这对大型项目很有用。
根目录写通用规范，业务目录写特殊约束。Codex 进入不同模块时，就能拿到更贴近上下文的规则。
一份实用的 AGENTS.md 模板
你可以直接从这个模板开始改：
# AGENTS.md
## 项目概况
这是一个前端管理后台项目，主要技术栈为 React、TypeScript、Vite 和 pnpm。
## 开发规则
- 优先沿用现有目录结构和代码风格。
- 不要做无关重构，不要顺手格式化未修改文件。
- 新增功能时，优先复用已有组件和工具函数。
- 不要主动新增生产依赖，除非用户明确确认。
## 命令约定
- 安装依赖使用 `pnpm install`。
- 本地开发使用 `pnpm dev`。
- 修改代码后运行 `pnpm lint`。
- 涉及测试文件时运行 `pnpm test`。
## 安全边界
- 不要修改 `.env`、证书、密钥、生产配置文件。
- 不要提交真实 Token、密码、手机号、身份证号。
- 涉及权限、支付、登录逻辑时，必须说明风险点。
## 输出习惯
- 先简要说明修改思路，再动手改代码。
- 完成后说明改了哪些文件，以及是否运行了验证命令。
这份规则不追求“全”，而是覆盖最容易出问题的地方：包管理器、测试命令、依赖、安全、改动范围。
.rules 是另一种规则：管命令权限
注意，Codex 里还有一个叫 Rules 的配置，它和 AGENTS.md 不是一回事。
AGENTS.md 更像是“工作说明书”。
.rules 更像是“哪些命令可以放行，哪些命令必须询问”。
官方文档里说，Rules 用来控制 Codex 哪些命令可以在沙盒外运行；它目前仍属于实验性能力。
比如你希望 Codex 每次执行 GitHub PR 查看命令前都先询问，可以写：
~/.codex/rules/default.rules
内容示例：
prefix_rule(
pattern = ["gh", "pr", "view"],
decision = "prompt",
justification = "查看 PR 信息前需要确认",
match = [
"gh pr view 123",
],
)
常见 decision 有三种：
allow：允许执行prompt：每次询问forbidden：禁止执行
一般项目刚开始用 Codex，不必急着写 .rules。先把 AGENTS.md 写好，收益最大。
怎么判断规则写得好不好？
可以用 4 个问题检查：
- 这条规则是否能指导具体行为？
- Codex 是否知道什么时候该执行它？
- 它是否减少了真实项目风险？
- 它是否避免了过度限制？
比如这条就太虚：
- 写出高质量代码。
可以改成：
- 修改已有模块时，优先保持现有架构，不新增抽象层，除非重复逻辑超过 3 处。
这条就更清楚。
Codex 规则的核心，不是把 AI 管死，而是把团队最在意的边界提前说清楚。
结尾：规则写得好，Codex 才像队友
Codex 不是只靠一句 prompt 工作的工具。真正好用的 Codex 工作流，应该把项目规范沉淀到规则文件里。
这篇文章可以总结成三个关键点：
- 编码规则优先写
AGENTS.md，它是 Codex 理解项目约定的主要入口。 - 全局规则和项目规则要分开，个人习惯放
~/.codex/AGENTS.md，项目规范放仓库里的AGENTS.md。 .rules主要管命令权限，适合控制哪些命令允许、询问或禁止执行。
本文由 楸木 原创，转载请注明出处。