Codex项目规则怎么写：让它先读边界，再开始改文件

项目规则不是口号，要能约束一次真实修改

适合反复让Codex处理同一项目，又总要重申目录、格式、禁区和验收方式的人。

临时需求、一次性文案和当天才成立的决定，不应写进长期规则。规则失效后不清理，反而会让后续任务收到互相冲突的指令。

规则可以约束工作方式，但不能代替版本控制和权限边界。涉及生产环境、唯一原件和不可逆操作时，仍要单独要求Codex暂停确认。

写规则前先列清目录、命令和禁区

• 项目目录与主要文件说明
• 允许和禁止的操作清单
• 构建、测试与验收命令
• 建立一个测试副本或新目录，不直接操作唯一原件。
• 写下一句验收标准：Codex能在动手前准确说出作用范围、禁止项和验证命令，实际修改没有越过规则边界

先从项目现状提炼规则：源文件在哪里、哪些页面由脚本生成、真实验证命令是什么。脱离仓库实际结构编写的规则很难被正确执行。

从边界到验收，AGENTS.md这样写

先找一次真实的越界案例

回看最近一次返工：是改了生成文件、漏跑测试，还是碰了不该动的目录？规则应解决已经发生或高概率发生的问题，而不是堆抽象口号。

只留下跨任务仍然成立的要求

把目录职责、代码风格、安全禁区和完成标准写进去，不塞入只用一次的任务要求。

诸如“底部栏只能由公共生成器修改”适合放进项目规则；“今天把按钮改成蓝色”只属于当前任务。两类内容混在一起，规则很快就会失效。

把规则放到它真正控制的目录

确认规则需要覆盖整个项目还是某个子目录，避免局部要求意外影响无关文件。

根目录规则覆盖全项目，子目录规则补充局部要求。写完后列一遍每条规则的生效范围，防止教程目录的限制误伤其他页面。

先让Codex复述边界再动手

先让Codex复述将读取什么、修改什么、运行什么，不立即授权大范围编辑。

给一个低风险任务，让Codex先说出预计读取、修改和验证的文件。复述与规则不一致时，先修正规则或任务，不要边改边猜。

只有重复偏差才升级为长期规则

发现重复发生的误解时才补充一条具体规则，并删除互相冲突或已经失效的要求。

一次性的特殊情况留在任务说明中；同类偏差反复出现，再把它改成可执行的项目规则。新增规则时也要删除冲突或过期内容。

用一次新任务检查规则是否真生效

换一个相邻但不同的小任务，检查Codex是否主动遵守目录、禁区和验证命令。只有不靠临时提醒也能执行，规则才算写进项目。

一份最小项目规则示例

一个静态网站要求所有页面共用导航生成器、禁止手改生成HTML、完成后必须检查移动端溢出。把这三项写成项目规则后，后续新增页面不必每次重新解释。

可以先这样描述任务：

我正在处理“把长期稳定的项目边界、工作方式和验证命令整理成可维护的规则文件”。已有材料包括项目目录与主要文件说明、允许和禁止的操作清单、构建、测试与验收命令。请先不要扩大任务范围，也不要补造缺失信息。先完成“只写长期有效的规则”，输出可以人工检查的中间结果；我确认后，再继续“按作用范围放置”。最终请按照“Codex能在动手前准确说出作用范围、禁止项和验证命令，实际修改没有越过规则边界”列出验收结果和仍需人工确认的内容。

验证时不要告诉Codex应该复述什么，直接看它是否主动识别生成源、禁止项和检查命令。遗漏处才是规则真正需要补充的位置。

规则没生效、写太长怎么排查

规则写了很多，Codex仍然抓不住重点

把抽象口号改成可执行句子，例如具体目录、文件类型、命令和停止条件；重复或冲突的规则只保留一份。

规则写了“完成后检查”，却没写检查命令

把模糊要求改成项目中真实可运行的命令，并说明什么输出算通过。没有命令时，也要写明具体文件、页面和人工验收点。

根规则和子目录规则互相冲突

先按作用范围判断哪条更具体，再消除表述冲突。不能确定优先级时，应要求Codex暂停并报告，而不是自行选择一条执行。

规则问题要结合实际读取路径、修改差异和命令输出判断。一次只修正一条边界，再用小任务验证，才能知道是哪项规则起了作用。

让新任务验证这份规则

• Codex能在动手前准确说出作用范围、禁止项和验证命令，实际修改没有越过规则边界
• 长期规则与当前任务要求已经分开，没有把一次性需求永久化。
• 每条规则都能对应到具体目录、文件、命令或停止条件。
• 根目录与子目录规则的作用范围清楚且没有冲突。
• 新任务中Codex能主动复述并遵守规则，不依赖再次口头提醒。

项目结构或构建命令变化后，要同步回查规则。长期规则不是写完就结束，而是需要跟随真实工作方式一起维护。