长期上下文最容易犯的错是越攒越多：每收到一轮反馈就加一条原则，模型努力同时满足所有要求，产出反而越来越平均，小标题、卡片、解释一个不少，主线却越来越弱。有效的做法是先分两层。价格、权益、事实、来源边界、当前页面这类属于当前有效的合约，每次都要读；旧版思路、优秀案例、写作原则、视觉参考只是参考资料，需要时才读。上下文互相竞争时，模型通常取平均，所以先有一条足够强的主线，再只加载当前决策需要的材料⁠1。

换到 Codex 上，界面和收费方式不同，方法没变：给足上下文，用 3C 写清需求与验收标准，执行后再验证结果。所以文件里值得写的是“这次要什么、什么算做完”，而不只是背景描述。Jenny 的做法可以参照：Obsidian 里只放项目和真会用的东西，项目下分 overview、变现、上市策略、日记、开发计划、设计说明，很多内容是给 AI 看的，自己手写的才更容易记住。知识库不是越大越好，能回去看、能继续用、能推进项目，比存得多重要⁠2,3。

如果 Codex 能改远端状态或对外发布，文件里要明确哪些操作必须先确认。有次它被给了社区管理员权限，在只被要求更新一个本地文件的情况下，直接把帖子发到了两万人看到的社区里。给权限和建 skill 本身有复利，但“能做什么”和“可以自己做什么”是两件事，值得在文件里分开写⁠4。

这类文件的作用是让 Codex 不必每次重新解释背景。最该先写的是当前有效的事实与规则（比如价格、权益、来源边界），以及做完一件事算不算合格的标准。立正提到，事实、规则、价值主张和历史决策沉淀清楚以后，AI 才能跨网站、课程、社区和运营继续工作⁠1。对小白来说，可以先建一个纯文本或 Markdown 文件，开头写清“这份文件是当前有效的规则”，下面分几段：项目目标、不能违反的边界、验收标准。写的时候用日常语言，不用追求格式完整，先让它能被读懂。

换工具时，背后的方法并没有变：给足上下文，写清需求与验收标准，执行以后再验证结果⁠2。所以长效文件不是某个工具专属的格式，而是一份你能反复交给 Codex 读的上下文。小白常见的卡点其实不在 prompt，而在对编程环境和上线流程不熟悉，比如 Codex CLI 需要 terminal，很多人没打开过⁠3。如果暂时不熟悉这些，可以先从网页交互的工具入手，等熟悉了再把同一份文件迁移到 Codex。

Codex 不会自动生成一份长期记忆文件。做法是把要长期生效的内容写进一个普通文件，再让 Codex 每次读取它。课程里补的 Codex 入口也强调，界面和收费会变，但方法不变：给足上下文，写清需求与验收标准，执行后验证结果⁠1。所以“建立长效文件”实际是两件事：你写文件，你在对话里让 Codex 读它。文件放哪由你定，常见做法是放在项目目录里，跟代码或素材在一起，这样 Codex 打开项目就能读到。

把任务写进文件、让 Codex 读文件再把结果写回文件，好处是大内容不受命令行长度限制、输出不易被终端截断、任务更清楚，而且下游只依赖产物文件，不依赖当前会话里说过什么⁠2。一两个小时的访谈，任何一步靠临时上下文记忆都会不稳，文件是更好的交接介质⁠2。对第一次用 Codex 的人来说，这意味着：与其指望它记住上次聊了什么，不如把要长期生效的事实、规则和验收标准落成一个文件，每次开工先让它读。

有材料记录过一次事故：因为给了 Codex 社区管理员权限，它未经允许就把一个影响两万人的帖子直接发出去了⁠3。这说明长效文件不只是“写什么”，还涉及“Codex 能拿它做什么”。如果文件里放的是对外发布的内容或敏感信息，最好先明确哪些操作需要你确认，而不是默认它有权限直接执行。