经常用 Codex 后，我发现 AGENTS.md 只该管一件事

让 Codex 少走弯路：一份全局 AGENTS.md 的取舍

Codex GPT-5.6、Claude Fable 这一代模型变强后，我反而开始删 Prompt。

以前总怕 AI 理解错。

恨不得把"先看什么、再搜什么、怎么改、最后怎么回复"，一条条写进全局 AGENTS.md。

结果呢？

规则越来越长，模型却经常被过期的项目细节、互相打架的要求拖住。

说白了，模型已经能自己判断很多执行细节。你再把每一步写死，等于让它一边解决问题，一边翻一本过期操作手册。

现在我最常给 AI 的，反而只有两样东西：目标 ，以及一份能落地的技术方案。

全局 AGENTS.md 呢？

我只让它管一件事：边界。

不是 Prompt 越短越好，是别替模型做它会做的事

先说清楚。

我不是说"Prompt 越短越厉害"。

一个模糊的目标，丢给再强的模型，也只会得到一堆看起来很努力的猜测。

该说清的，还是要说清。

比如你要改什么功能、技术方案准备怎么走、不能碰哪些文件、最后怎么验收。

这些不是束缚。

这是把施工图交给 AI。

但"先读哪个目录""每一步都要先问我""只许用某一个命令"这类规则，一旦只对某个项目成立，就不该常驻在全局 AGENTS.md 里。

项目换了，规则可能就错了。

模型能力越强，越应该把两件事分开：

• 目标和技术方案，跟着当前任务走；
• 安全边界和协作习惯，放进全局规则里。

这才是我这次改造的核心。

全局规则，到底该留下什么？

我最后只保留四类内容。

第一类，是协作习惯。

比如默认用中文、表达直接一点、事实和判断要分开。它们不随项目变化，放全局最合适。

第二类，是目标驱动。

除非我明确说只要分析或方案，否则 AI 应该推进到一个可以交付、可以验证的结果，而不是做完一半停下来问"要不要继续"。

第三类，是真实性和验证。

不知道就说不知道；可能变了就去核验；改过代码就做和风险相称的检查。

第四类，是安全边界。

这个最重要。

AI 可以主动做事，但不能主动把你的工作区清空。

项目命令、目录结构、依赖版本、业务术语和临时故障补丁，我都不放这里。

它们该去项目根目录的 AGENTS.md，或者某一个只在特定任务触发的 Skill。

强制限制则更不能只靠文字提醒。

该用权限、沙箱、CI、Hook 的地方，还是要交给工具。

一条规则该放哪？问自己三个问题

我以前写 AGENTS.md，最大的毛病就是舍不得删。

看到一条"挺有用"的经验，就想记进去。

后来才发现，问题不是这条经验有没有用，而是它应该由谁记住。

现在我会先问三个问题。

第一，它换个项目还成立吗？

还成立，才有资格放全局。

比如"高风险删除先确认""别编造验证结果"，换什么仓库都成立。

第二，它是不是只在一类任务里出现？

写文章、接口联调、发版检查，这些都有一套固定流程，应该做成 Skill。需要的时候再加载，不需要时别占着全局 context。

第三，它能不能只靠模型自觉？

不能。

像禁止强制推送、限制生产写入、保护密钥，这些该交给权限、沙箱、CI 或 Hook。文字规则负责提醒，工具规则负责拦住。

翻译成人话就是：

• 每个项目都成立的原则，放全局 AGENTS.md；
• 只属于某个仓库的事实，放项目根目录的 AGENTS.md；
• 只在某个动作触发的步骤，放 Skill；
• 绝不能出错的红线，交给工具强制执行。

比如 Android 项目里的索引工具、Gradle 命令、模块划分，确实好用，但它们不是所有项目的常识。

给它们加"只在 Android 项目命中时启用"的条件，或者直接下放到项目里，才不会让一个前端仓库也背着 Android 的说明书。

这一层分工做完，AGENTS.md 才会轻下来。

这是我这次改造后的全局版本

下面这份，是我基于上面的思路整理出的可公开版本。

重点看"文件系统安全"这一段。

以前我以为 AI 的风险，是它做得不够快。

现在越来越觉得，风险是它做得太快，而且替你做了你根本没授权的事。

Global AGENTS.md

这里记录的是我跨项目都要用的协作习惯、行动边界和收尾方式。
系统要求、用户本次任务，以及离目标文件更近的项目规则，优先级更高。

## 协作与目标

- 没有特别说明时，用中文沟通；另有语言要求时跟随用户。
- 用清楚、可执行的说法回答，并把事实、判断和未知之处区分开,不要一味讨好我。
- 围绕任务目标和验收结果做判断，不照着固定流程生搬硬套。
- 本次技术方案、命令、目录和技术栈，听当前项目的说明。

## 执行与验证

- 动手前，先看和目标直接相关的项目说明、代码、测试与文档。
- 能沿用已有脚本、依赖和工程约定时，不另起一套。
- 改动控制在解决问题所必需的范围内，不顺手清理或猜测性重构。
- API、命令、路径、配置、运行结果和验证结论都不能凭空补全。
- 改完要做与风险匹配的检查；做不了就说明原因和还剩什么不确定性。

## 文件系统安全

- 工作区内正常修改可直接执行；递归、批量、目录、未跟踪文件或未明确涉及的删除，必须先确认。
- 跨工作区修改仅限用户明确指定的目标；删除、递归移动或覆盖前，展示真实绝对路径、影响数量和相关 Git 状态。
- 禁止递归删除 `/`、`$HOME`、`~/.codex` 及系统目录；不得借助环境变量、符号链接或挂载点绕过边界。
- `rm -rf`、`git clean`、`git reset --hard`、`find -delete`、`xargs rm` 和通配符删除，只有用户明确提出并确认目标后才能执行。
- 不得为通过构建或测试擅自删除文件，也不得削弱沙箱、审批或权限配置。

## 必须先确认的边界

- 删除重要数据、不可逆迁移、重写 Git 历史、强制推送。
- 生产部署、生产写入、公开发布。
- 权限、凭证、DNS、计费或付费资源变更。
- 明显扩大范围，或改变关键行为、兼容性和架构的高风险选择。

这一份不长。

但它解决的不是某一次开发的问题，而是每一次让 AI 干活时最容易踩的坑。

如果你是 Android 开发者，或者有自己常用的 IDE 索引工具，可以在项目规则里加一个"满足某些条件才启用"的小节。

别把它塞进所有项目都加载的全局文件。

我现在最常用的组合：目标 + 技术方案

全局 AGENTS.md 定边界。

具体任务怎么推进，我现在更常用的是这四行：

目标：这次要解决什么，最后交付什么。
技术方案：准备改哪些模块，按什么路径实现。
验收：怎么证明它真的完成了。
边界：哪些文件、行为或外部操作不能碰。

这就像出门开车。

AGENTS.md 是交通规则：红灯别闯，不能把车开到人行道上。

技术方案才是导航：今天去哪，走哪条路，到了怎么确认。

两份东西混在一起，导航会越来越厚，交通规则也会越来越乱。

拆开以后，反而省心。

每次新任务，我只需要把目标和方案说清；AI 再去读当前项目真正相关的规则、代码和文档。

人负责定方向和边界，AI 负责把方案推进到底。

放到哪里？最简单的办法，是直接丢给 AI

我把个人全局规则维护在 ~/.codex/AGENTS.md，项目特有规则则放在项目根目录的 AGENTS.md。

不同客户端和项目的加载方式可能不同，第一次别靠记忆猜。

先让 AI 读取它当前加载了哪些规则文件，再决定改哪里。

其实最简单的方法，就是把你旧的配置和下面这段话一起丢给 AI：

请读取我现有的全局 AGENTS.md。

目标：把它精简成跨项目长期有效的协作规则。
保留：协作偏好、目标驱动、真实性、验证标准、文件系统安全。
移出：项目命令、单一技术栈、临时故障补丁和具体业务细节。

请先输出三样东西：
1. 建议删除、保留、下放到项目 AGENTS 或 Skill 的内容；
2. 一份完整的新版本；
3. 与原文件的差异摘要。

不要直接覆盖原文件。等我确认后再修改。

让 AI 先分类，再改文件。

这一步很值。

因为最容易出问题的，从来不是它不会写，而是你不知道它准备删什么。

最后说两句

好的 AGENTS.md，不替 AI 思考。

它只确保 AI 思考时，不会跑偏，也不会越界。

模型变强以后，我们不需要再把它训练成一个只会照流程办事的实习生。

把目标说清，把技术方案给到，把危险边界划好。

剩下的，让它去做。

全局规则解决的是：让 AI 在你的项目里稳定推进，又不越界。

经常用 Codex 的人，还会碰到另一件事：重置信号什么时候出现，很多时候得自己去 X 上翻动态。

我做的「徐公 AI 雷达」，主要盯着 Tibo 是否在 X（Twitter）发出 Codex 重置相关信号。它会把值得留意的公开信号及时捞出来。

如果你经常用 Codex，可以关注一下。少刷几次动态，在该关注的时候看到它就够了。