我在codex上安装了鸭哥的上下文系统，不过我自己的codex中存在许多历史文件、历史项目，并且文件层级较乱，其中有.Codex隐藏文件夹、Codex文件夹和ChatGPT文件夹，这三个文件夹里都存放了与我的codex有关的文档，之前重来没有管理或整理过它们，说实话我没有技术编程背景所有看不太懂这些文件夹之间的关系，所以从来没有轻易移动或删除任何文件，这一次按照鸭哥的上下文系统后才发现这里面非常的混乱，毫无逻辑毫无分类，我应该怎么办呢？

Codex 这类工具的价值之一，是能调度本地文件和工具、并接受你灌注的上下文⁠1。所以这套系统放在哪里，判断标准不是“分类整齐”，而是 Codex 每次启动时能不能稳定读到它。通常做法是放在你实际用 Codex 干活的那个项目根目录，或 Codex 约定的配置位置；具体路径因版本而异，可以让 Codex 先只读地告诉你它默认会加载哪些文件，再对照放置。你之前那三个文件夹层级混乱，正好说明“按感觉分类”容易失效，按“谁读取、何时读取”来放更可靠。

立正在做主页时发现，guideline 越加越多，模型反而取平均、主线变弱；后来把材料分成“当前必须遵守的”和“需要时才读的参考”两类⁠2。鸭哥这套系统如果包含很多文档，不必全部塞进 Codex 每次都读的位置。可以先只放最核心的规则和当前项目说明，其余历史资料留在原处，需要时再让 Codex 去读。这样既避免上下文互相竞争，也符合他说的“想放到一起就放到一起，想分开就分开”的白盒控制思路⁠3。

可以先在一个小项目里放好这套系统，然后让 Codex 做一件依赖上下文的小事，比如按你的规则整理一份文件。观察它是否引用了你放的规则、有没有漏读或读错。如果它没读到，问题多半在位置或加载方式，而不是系统本身；如果读到了但输出跑偏，再回头精简内容。这比一次性整理所有历史文件更能帮你判断该放哪里。

出处 1 2

Codex 读取指令有层级：用户级配置对所有项目生效，项目根目录的 AGENTS.md 只对当前项目生效。所以“始终运行”的那份放用户级，比如 ~/.codex/AGENTS.md 这类全局位置；每个项目根目录再放一份自己的 AGENTS.md，写这个项目特有的规则、资料位置和验收标准。项目级会叠加在全局之上，等于全局给通用工作方式，项目给具体任务说明。立正提到过让 AI 去更新全局和本地项目的 AGENTS.md，说明他实际就是分这两层用⁠1。

README、docs、src、inputs、outputs、scratch、tests 这些是项目自己的内容，放在项目根目录下即可，由项目级 AGENTS.md 告诉 Codex 每类文件在哪、什么时候读。全局层只放跨项目通用的规则和索引，不塞具体资料。立正讲 context 架构时把记忆分成工作记忆、项目记忆、组织记忆三层，并强调按需加载、不一股脑塞进上下文窗口⁠2；项目资料属于项目记忆，全局只保留“怎么找、怎么加载”的规则。

你没有编程背景，最稳的做法是先只放全局那份，再在一个项目里放项目级 AGENTS.md，然后让 Codex 复述它读到了哪些规则、来自哪个文件。如果它只读到一份，说明路径或文件名不对；如果两份都读到，就说明分层生效了。这一步能验证“始终运行”是否真的成立，比先整理全部资料更重要。

出处 1 2

把鸭哥这套系统当成每次开工都要读的“工作方式说明”，放在用户级位置，让 Codex 在所有项目里都能读到；每个项目再放一份自己的 AGENTS.md 和 README、docs、src、inputs、outputs 等目录，只写这个项目特有的目标、约束和资料。这样全局层回答“怎么干活”，项目层回答“这次干什么”，两者是叠加关系，不是谁包含谁。立正讲 Codex 这类工具时提到，它和 Cursor 一样按项目隔离上下文，打开 A 项目只拿到 A 的上下文⁠1；所以项目资料留在项目里，全局层只放跨项目通用的部分。

如果某个项目的规则和全局默认冲突，就在该项目的 AGENTS.md 里写明覆盖，例如“本项目不用全局的提交规范，改用另一套”。这样全局层保持稳定，项目层按需调整，避免把全部资料复制到全局导致上下文膨胀。立正提到，上下文全塞到一起会很快占满窗口，模型把脑力都用来处理上下文，反而没法好好执行任务⁠1；所以全局层宜精简，项目资料按项目存放。

可以挑一个已有项目试：在项目根目录放一份简短的 AGENTS.md，写明本项目目标和资料位置，然后让 Codex 只读地说明它读到了哪些文件、哪些来自全局、哪些来自项目。观察它是否把项目资料和全局方法分开引用，就能判断分层是否生效。立正强调 AI 不是外挂也不是魔法，需要学会怎么用好它⁠2；分层是否有效，要靠实际读到的内容来验证，而不是靠文件夹名字。