用 AGENTS.md 把运营规则写成 Codex 每次都读的文件
AGENTS.md 是 Codex 每次开工都会读的规则文件，从仓库根目录往下逐层拼接，越靠近当前目录的越优先，合并后默认上限 32 KiB。跨境团队该往里写的是指标口径、报告格式、判断阈值和禁止动作这些别人照着做也能做对的东西，不该写的是背景故事和空泛原则。写得好的 AGENTS.md 的副作用是你终于把流程写清楚了，这件事本身就值钱。
AGENTS.md 是 Codex 每次开工都会读的规则文件。作用很直接：让它按你们公司的标准干活，而不是按行业通用做法。
这里最常见的错误是把它写成公司介绍：我们是做什么的、我们的价值观是什么、我们希望你专业严谨。这些字它读了也用不上。
判断标准只有一条：写进去的每一条，都应该是"别人照着做也能做对"的东西。
两个层级：
~/.codex/ 目录下查找和合并的顺序是：
AGENTS.override.md，没有则读 AGENTS.md这个机制对跨境团队很实用：公司通用的规则写在上层，某个店铺或某个类目的特殊规则写在下层目录。走到那个目录干活时，下层的规则自动生效。
举个例子：
ops/
├── AGENTS.md 公司通用：报告语言、金额格式、禁止动作
├── amazon-us/
│ └── AGENTS.md 美国站：目标 ACoS、类目限制
└── shopify/
└── AGENTS.md 独立站：运费规则、退换货政策
在 amazon-us/ 里启动，它读到的是通用规则加美国站规则。
合并后的总大小默认上限是 32 KiB（配置项是 project_doc_max_bytes），到了上限就不再往下加。
这条限制的实际含义是：别把它写成大杂烩。
写太长有两个坏处，一个是可能被截断，另一个更现实——规则越多越稀释，真正重要的几条反而不突出。
超了怎么办？两个方向：
优先选第二个。规则本来就该分层，全公司都要遵守的和只有某个店铺才用的，混在一起本身就是问题。
用 /init 可以在当前目录生成一个骨架，然后按下面这个结构改。
# 运营规则
## 数据在哪
- 广告报表：`data/ads/`，文件名带日期
- 订单导出：`data/orders/`
- 库存和成本：`data/inventory/`
- 政策和话术：`kb/`
任何一份缺失时，说明缺什么，不要用估算值代替。
## 指标口径
- ACoS = 花费 ÷ 销售额
- 毛利 =（售价 − 成本 − 预估运费）÷ 售价
- 日均销量用中位数，不用平均数
- 算日均之前先剔除断货日和大促日
- 没有销售额的行，ACoS 记为无穷大，不要当成 0
## 判断阈值
- 目标 ACoS：30%
- 烧钱词：花费 ≥ 50 且订单为 0
- 高 ACoS 词：有订单但 ACoS > 45%
- 低毛利：毛利率低于 15%
- 断货风险：预计断货天数 < 备货周期
## 输出规范
- 报告用中文，写进 `reports/`，文件名带日期
- 金额保留两位小数，比率写成一位小数的百分比
- 结论写在最前面，明细放后面
- 每个数字要能说出来源，不能来源于推断
## 数据不足时怎么办
- 直接写「数据不足」，说明缺哪一份
- 不要为了凑出结论而估算
- 样本量不够时明确标注，结论标为仅供参考
## 禁止动作
- 不修改原始数据文件
- 不调用任何平台接口
- 不生成对客户的金额、时间或责任承诺
- 不直接修改线上 Listing、价格、库存
- 所有调整只写成建议，由人确认后执行
这份东西不长，但它把四件事定死了：数据在哪、按什么算、什么算异常、输出成什么样。有了它，同一份报表今天跑和下个月跑，结果口径是一致的。
上面那份里没有一句"要准确""要专业"。每一条要么是一个位置，要么是一个公式，要么是一个数字，要么是一个禁止项。
一条规则如果你没法判断它有没有被遵守，那它就不该写进去。
别把禁止事项混在正文里。它是最重要的一段，也是最需要一眼能找到的一段。
尤其是当你后面开始给 Codex 更大权限的时候，这一段就是最后一道业务保险——沙箱管技术边界，这段管业务边界。
不要一上来就设计一套理想流程。先把你现在实际怎么做的写下来，哪怕它不完美。
理由是：写现状你写得出来，写理想你写不准，而写不准的规则会让输出更差。
写 AGENTS.md 的过程里，多数团队会发现一件事：很多口径其实从来没定过。
同一个 ACoS，运营 A 算的是含广告外销售，运营 B 算的是只看广告订单；同一个"滞销"，有人说 30 天没动，有人说 60 天。平时没人对过，各写各的表，所以从来没暴露。
一旦要写成一份给机器执行的规则，就必须定下来。
这件事的价值不依赖 AI——就算你最后没用任何工具，把这些口径统一下来，团队的报表也终于能互相对得上了。
除了 AGENTS.md，每一层还可以放一个 AGENTS.override.md，它会被优先读取。
用途是「临时压过上层规则，但不动上层文件」。举几个跨境场景里的实际用法：
比起直接改 AGENTS.md，override 的好处是改动是局部的、可丢弃的。团队共用的规则文件保持干净，不会因为某次临时需求被改乱。
写完规则不等于它会照做。上线前建议做三件事验一下。
开一个会话，直接问它：按当前的规则，广告报表该怎么算、报告写成什么格式、哪些动作是禁止的。
如果它复述得和你写的对不上，说明规则写得不够明确，或者被上层规则覆盖了。这一步花不了两分钟，能省掉后面很多困惑。
把成本表抽掉一列，或者删掉几天的数据，然后让它跑毛利分析。
**正确的表现是它明确说「数据不足」，而不是给出一个看起来正常的结果。**如果它凑了个结论出来，说明「数据不足时怎么办」这段没写到位，或者写了但不够硬。
这一条特别值得测，因为真实工作里数据缺失是常态，而这种错误最难发现——报告看起来完全正常。
让它做一件规则里明确禁止的事，比如「帮我把这个 Listing 直接改到线上」。
它应该拒绝并说明原因。如果它照做了，说明禁止动作那一段没起作用，得回去改写法。
**写成了公司介绍。**前面说过，但值得再提一次，因为这是最常见的。它读了「我们追求品质」用不上。
**规则之间互相矛盾。**上层写「报告用中文」，下层写「report in English」，两条都在，结果不确定。合并是逐层拼接的，所以改下层规则时要想一下上层写了什么。
把一次性的要求写进去。「这次帮我看一下 3 月的数据」这种属于对话内容，不该进规则文件。规则文件里放的应该是每次都成立的东西。
**忘了更新。**平台政策改了、目标 ACoS 调了、退换货规则变了，规则文件没跟着改，它就会一直用旧标准。建议把「检查规则文件」放进你的月度复盘清单。
再强调一次这两个文件的分工，因为经常被混：
AGENTS.md：按什么标准干活。业务资产，该进版本库，团队共享config.toml：允许它干到什么程度。安全设置，权限相关把权限写进 AGENTS.md 没有意义——它是给模型读的文字，不是系统级约束。反过来把业务口径写进 config.toml 也不对，那里没有放它的地方。
规则写好之后，就可以让流程自己跑了。下一篇讲 codex exec：怎么把广告诊断变成一条不用人盯着的命令，以及非交互模式下沙箱该配哪一档。
作者
大阪烧鸟
大阪烧鸟，关注 AI 在跨境电商运营中的实际应用、Shopify 独立站与日本商业观察，偏爱把复杂问题拆成可执行的方法。
