AI 实践大家好，我是云途。
同一个项目做久以后，会出现一些每次都必须遵守的规则。例如正式版放在哪里、测试时不能连接哪个数据库、完成后要运行什么检查。
如果每次开新对话都重新解释，难免会漏掉。你可以把这些长期规则写进 AGENTS.md，Codex 进入项目后会先读取它。
AGENTS.md 不需要收录所有聊天记录。只写那些长期有效、会影响实际操作，而且能够检查的规则。
这节课要完成什么
- 理解 AGENTS.md 的作用范围；
- 选择应该长期保存的项目规则；
- 按目录层级组织全局与局部说明；
- 写出能执行、能验证、不过期的规则；
- 验证 Codex 是否真的读取并遵守。
AGENTS.md 解决什么问题
版本边界
哪个目录是正式真源、实验版、备份或归档。
工程方式
依赖装在哪里、使用哪些项目内脚本、哪些目录不可复制。
安全边界
生产数据库、凭据、部署和破坏性动作的规则。
验证要求
修改后必须运行哪些检查、哪些真实链路需要复核。
协作记录
重要结果需要更新哪个状态文件，交付报告包含什么。
规则会跟随目录层级生效
New-Yuntu-AGI/
├── AGENTS.md # 整个工作区规则
├── cn网站项目/
│ └── 正式官网/
│ └── AGENTS.md # 正式官网额外发布规则
└── 软件项目/
└── 桌面软件/
└── AGENTS.md # Electron 打包与平台规则根目录规则适用于整个工作区；更深目录可以补充更具体的说明。不要在多个层级复制同一段规则，避免更新一处后互相冲突。
哪些内容值得写进去
- 稳定存在的版本定义与绝对路径；
- 项目本地依赖和运行命令；
- 代码格式、测试与构建要求；
- 数据库、生产、备份和部署边界；
- 必须保留的品牌与业务事实；
- 修改前置步骤和交付记录位置。
临时任务目标、今天的进度、一次性截图反馈不适合长期规则，应放在任务提示词、计划或状态文件里。
避免写成口号和过度约束
【太空】
保持高质量，注意安全，写优雅代码。
【可执行】
- 修改前运行 `npm run lint`，记录原有失败。
- 依赖只安装在当前项目目录，禁止全局安装。
- 本地验收不得连接生产 MySQL。
- UI 修改后检查 390px 与 1440px，无页面级横向溢出。规则应尽量说明触发条件、动作、禁止项和验证。太细的视觉像素与易变按钮名称则放进设计系统或页面说明。
项目规则的基础模板
# 项目规则
## 项目与版本
- 当前真源：…
- 实验版：…
## 依赖与运行
- 只使用项目内依赖。
- 启动：`npm run dev`
## 修改边界
- 允许：…
- 禁止：…
## 数据与生产
- 本地测试库：…
- 不得直连生产。
## 验证
- `npm run lint`
- `npm test`
- 真实页面：…
## 交付
- 更新：工作区状态.md验证规则是否真正生效
可复制提示词
请先读取当前目录与上级目录适用的 AGENTS.md，不修改文件。报告：本轮项目真源、依赖安装规则、禁止连接的系统、修改前置步骤、必须运行的验证和需要更新的记录。每一项标注来自哪个文件和目录层级。发现冲突时列出冲突并停止，不要自行选择。
然后设计一个会触发规则的低风险任务。例如询问安装依赖，观察 Codex 是否选择项目内命令；不要为了测试规则而真的连接生产或执行破坏动作。
规则也需要维护
- 版本切换后更新真源路径；
- 脚本或数据库名变化后同步说明；
- 删除已经失效的历史约束；
- 把重复出现的新风险提升为规则；
- 定期检查局部 AGENTS.md 是否与根规则冲突；
- 不要把聊天记录不断追加成无人能读的长文。
视频录制与复习提纲
- 从重复解释中提取稳定规则；
- 演示根目录与子目录层级；
- 把三条口号改成可执行规则；
- 完成一份最小 AGENTS.md；
- 用只读提示验证 Codex读取结果；
- 演示版本变化后怎样维护。
新任务不用重新解释，规则才真正沉淀
- AGENTS.md 位于正确目录层级；
- 版本与路径指向真实真源；
- 依赖、数据和生产边界清楚；
- 验证命令来自项目实际脚本；
- 规则可以执行和检查；
- 我已经用只读任务验证 Codex读取结果。