---

前言

适用对象：希望 Codex 越用越懂项目，又不想让规则、记忆和历史对话互相污染的个人与团队。
核心观点：上下文不是一个大仓库。不同信息的权威性、寿命和复用范围不同，必须进入不同载体。

“让 AI 记住更多”听起来总是正确，但它很容易产生反效果。项目规则、个人偏好、历史事实、操作步骤和当前聊天如果全部放在同一处，结果往往不是更聪明，而是更难判断：哪条必须执行，哪条只是建议；哪条仍然有效，哪条已经过期；哪条适用于整个团队，哪条只属于某个人。

Codex 当前提供了多种上下文机制：AGENTS.md、项目文档、Skills、Memories，以及当前任务中的对话与附件。它们并不是同一功能的不同入口，而是五种不同层级。本文给出一套可直接采用的分层方法，并重点解释冲突处理、隐私边界与维护策略。

版本与可用性边界：Memories 的开关、生成与召回行为，Skills 的触发方式，以及 AGENTS.md 的加载范围可能随客户端、工作区策略和产品版本变化。Memory 是辅助召回，不应承载唯一的安全、权限或合规要求；任何动态能力都要以当前官方说明和实际运行验证为准。

一、先建立三个判断维度

任何一条信息进入 Codex 上下文前，先回答三个问题。

1. 权威性：不遵守会怎样

• 强制：违反就会造成错误、风险或团队不一致；
• 参考：通常有帮助，但应允许结合当前事实修正；
• 临时：只为本次判断服务，任务结束后可以丢弃。

2. 寿命：它多久会变化

• 长期稳定：工程原则、目录边界、审批规则；
• 项目周期：架构状态、业务口径、里程碑决定；
• 短期有效：当前报错、临时测试数据、一次会议的待确认判断。

3. 复用范围：谁需要它

• 所有项目；
• 某个代码库或目录；
• 某类任务；
• 某位使用者；
• 仅当前任务。

这三个维度比“重要不重要”更有用。一条很重要但只对当前事故有效的日志，不应该写进全局 AGENTS.md；一个经常使用的写作偏好，也不一定有资格成为团队强制规则。

二、五种载体各自承担什么责任

载体	最适合承载	权威性	典型寿命	不适合承载
AGENTS.md	必须遵守的工作规则、目录边界、验证命令	高	中长期	大段背景、个人猜测、实时状态
项目文档	架构事实、业务口径、决策理由、运行手册	中高	项目周期	每次任务都重复的操作步骤
Skills	可复用的方法、模板、脚本和验收流程	中高	中长期	某项目当前进度、隐含权限
Memories	个人偏好、重复背景、可被重新核对的经验	中低	可变	唯一安全规则、唯一事实源
当前任务	临时证据、即时目标、未确认假设	视证据而定	短期	未来必须稳定召回的规则

最简单的记忆口诀是：

规则进 AGENTS，事实进文档，方法进 Skill，偏好进 Memory，临时证据留在任务。

这不是绝对法律，但可以解决大部分混乱。

三、AGENTS.md：稳定且可审计的规则层

官方文档说明，Codex 在开始工作前会查找并读取 AGENTS.md。指令可以分层：个人或全局层提供通用规则，项目层提供代码库规则，更深目录可以进一步收窄。每次运行会组装一条指令链，因此项目内更具体的指导能够覆盖更一般的指导。

适合写入 AGENTS.md 的内容：

• 仓库使用什么包管理器、测试命令和格式化工具；
• 哪些目录允许修改，哪些生成文件不能手改；
• 认证、隐私、数据迁移等变更必须经过什么审查；
• 对现有用户改动的保护规则；
• 提交前必须执行哪些验证；
• 团队约定的代码风格和交付格式；
• 某个子目录特有的技术约束。

不适合写入的内容：

• “今天先修登录页”之类短期任务；
• 尚未证实的排障猜测；
• 完整会议转写和大量历史记录；
• 会快速变化的版本号清单；
• 真实密钥、客户数据或生产凭据；
• 只对某个人有意义的表达偏好。

一份好的 AGENTS.md 应短、硬、可执行。比如“注意测试”过于模糊；“修改 apps/api 后运行指定测试与类型检查，并在交付中列出失败项”更容易执行和验收。

AGENTS.md 能提高模型遵循规则的一致性，却不是权限系统，也不是确定性安全边界。凡是不可绕过的要求，仍应由平台与文件权限、Hook、CI、组织策略或人工审批落实；不能把“已经写进 AGENTS.md”当成“已经被强制执行”。

还要避免把 AGENTS.md 写成百科全书。文件越长，冲突与过期规则越难发现。架构说明应链接到正式文档，具体流程可以交给 Skill，AGENTS.md 只保留入口和不可违反的约束。

四、项目文档：事实、决定与理由层

项目文档是上下文体系的“事实账本”。它回答的是“系统现在如何工作”和“为什么这样决定”，而不是规定 Codex 每次必须按哪几步操作。

建议至少维护四类文档：

1. 系统地图：模块边界、数据流、外部依赖、关键入口；
2. 决策记录：选择 A 而不是 B 的原因、日期、参与者、替代条件；
3. 运行手册：部署、故障处理、恢复和常见问题；
4. 任务 handoff：当前目标、已完成、验证结果、未解决风险、下一步。

文档最重要的不是格式，而是状态标记。每个关键结论最好带有：生效日期、适用范围、证据来源、是否已被替代。否则 AI 看到两份互相冲突的文档，只能猜哪个更新。

对于长任务，不建议把所有原始聊天永久保存为唯一知识源。原始对话里混有假设、纠错、重复和过期命令。更好的做法是把经确认的结果提炼为 handoff，再保留必要来源链接。这样既降低上下文成本，也减少未来把讨论过程误当事实的风险。

五、Skills：可复用的方法层

Skill 解决的是“遇到这一类任务，应该怎么做”。它可以包含指令、参考资料和可选脚本，适用于桌面端、CLI 和 IDE。官方采用渐进披露：Codex 先看到技能的名称、描述和路径，只有在匹配任务时才读取完整内容。这意味着 Skill 的描述必须准确，否则可能该触发时不触发，或在无关任务中错误触发。

一个健壮的 Skill 通常包含：

• 明确触发条件和不适用范围；
• 输入要求与缺失信息处理；
• 分阶段步骤，而不是一大段散文；
• 每阶段成功标准和验证方式；
• 风险操作的审批点；
• 失败后的退出、回滚或升级路径；
• 必要模板、示例与反例；
• 可重复执行的脚本，但不嵌入凭据。

例如，“制作图文博客”可以做成 Skill：先核实主题与来源，再规划文章结构，生成原创插图，写 Markdown，检查图片路径、链接、篇幅和敏感信息，最后做视觉抽查。这个方法可以用于多个主题，不应夹带某一篇文章的临时结论。

Skill 与 AGENTS.md 的边界可以这样判断：

• 不管做什么任务都必须遵守，放 AGENTS.md；
• 只有执行某类工作时才需要，放 Skill；
• 只是描述项目现状，放项目文档。

六、Memories：有帮助，但不能当宪法

官方 Memories 文档明确区分了本地 Codex 客户端的本地记忆与 ChatGPT Web 的记忆系统。桌面、CLI 和 IDE 的本地客户端使用本地记忆存储；本地记忆默认关闭，数据位于用户目录下的 Codex 记忆位置。桌面端还存在 Chronicle 相关体验，而 CLI 与 IDE 主要使用主机上的本地记忆存储。

Memory 适合记住：

• 你偏好的交付格式与表达风格；
• 经常使用的非敏感目录或工具习惯；
• 多个任务反复出现的背景；
• 已经被你多次确认的工作偏好；
• 可在使用前重新核对的经验判断。

不应只靠 Memory 记住：

• 生产操作前必须审批；
• 哪些客户数据禁止外送；
• 某个仓库的唯一构建命令；
• 当前系统架构的权威版本；
• 任何密钥、口令或私人数据；
• 法律、合规或权限边界。

原因很直接：Memory 是召回辅助，不是强制执行层。官方也指出，记忆生成通常在后台发生，短会话或活跃会话可能跳过，接近额度限制时也可能不生成。即使记忆字段会尝试清除敏感信息，用户仍应在分享前检查本地数据。

因此，Memory 的正确定位是“减少重复解释”，而不是“替代正式规则”。如果某件事忘一次就会造成严重后果，它就不该只存在于记忆里。

七、当前任务：证据与推理的临时工作台

当前任务最适合承载高密度、短寿命的信息：报错日志、截图、测试输出、一次性需求、刚发现的事实、尚待验证的假设。它的优势是上下文近、交互快，缺点是容易被压缩、归档或被后续消息覆盖。

任务中应显式区分三类内容：

• 事实：有文件、命令输出或权威来源支持；
• 推断：基于事实的暂时解释；
• 决定：由人确认、将影响后续工作的选择。

阶段结束时，只把已确认的决定和仍有效的事实提炼出去。失败尝试若对未来有价值，可以记录“尝试了什么、为何失败、在什么条件下可重试”，而不是复制整个推理过程。

八、冲突时谁优先

分层之后仍会发生冲突，但必须先判断冲突属于哪一种。指令与授权冲突决定“允许做什么”，事实与证据冲突决定“现在究竟是什么情况”。两者不能放在同一条优先级列表里，否则一份更新的日志可能被误用来绕过权限，一条高权威规则也可能被误当成事实证明。

1. 指令与授权冲突：先守边界，再谈执行

建议按下面的治理顺序处理，而不是宣称它是所有客户端内部实现的固定优先级：

1. 平台安全边界、组织政策和法律合规要求；
2. 已获授权的当前用户目标与确认范围；
3. 当前目录实际生效、且由项目治理认可的 AGENTS.md 约束；
4. 被明确触发的 Skill 流程与人工确认的阶段决定；
5. Memory 中的偏好和历史经验。

当前请求只能在已有授权内调整目标，不能因为“用户现在这么说”就默默越过组织策略、客户数据边界或仓库强制规则。若用户请求与项目约束冲突，应展示双方内容、来源和影响，请有权的人决定是修改请求、批准例外还是正式更新规则。Skill 描述的是方法，不自动获得扩大权限的能力；Memory 更不能覆盖任何强制边界。

2. 事实与证据冲突：比较新鲜度、范围和可复核性

事实判断不按“谁的级别高”机械覆盖，而应比较：证据是否直接、时间是否更新、适用范围是否一致、来源是否可复核。当前代码和静态配置只能说明所检查版本的实现状态；命令输出只说明被测环境在特定时间的观察结果。若结论涉及生产实际行为，还要核对已部署版本、运行时配置、网关或基础设施以及监控证据。上述证据都不必然证明“系统本来就应该这样”；带日期和状态的架构决定可以说明预期，却可能已经落后于实现。遇到冲突时，应同时保留“当前观察”和“目标规范”，再判断是文档过期、实现回归、环境差异还是取证不足。

例如，项目文档写“接口只读”，当前路由却接受写请求。代码证据足以触发调查，但不能凭此宣布写权限已获批准。反过来，规则写着必须验证租户隔离，某次测试通过也不代表可以删除这条规则。事实证据用于修正认知，授权规则用于限制行动，两条线最终都要能追到来源。

若 Memory 与当前明确请求不同，通常应采用本次已确认意图，并考虑修正或删除旧记忆；但涉及安全、权限或合规时仍回到正式规则和授权流程，而不是让新请求直接覆盖。

冲突处理最忌讳“默默选择”。对重要差异，应说明：冲突的两条内容、各自来源和日期、当前采用哪一条、为什么、是否需要更新长期载体。

九、控制上下文成本：不是越多越好

上下文过多会产生三类成本：模型要在更多材料中找重点，旧信息更容易与新信息冲突，人也更难审计 AI 到底依据了什么。优化目标应从“最大化输入”改成“最小充分上下文”。

可以采用四步压缩法：

1. 去重：同一规则只保留一个权威版本，其余位置改为链接；
2. 分层：强制规则、项目事实、方法和临时证据分开；
3. 索引：长文档先提供目录、摘要和适用范围；
4. 过期处理：替代旧结论时标记 superseded 或归档，不让两个版本并列生效。

还可以要求 Codex 在重要交付中附一份“依据清单”：本次读取了哪些规则、用了哪些项目文档、哪些信息来自当前验证、哪些只是推断。这比要求它输出更长的思考过程更可审计。

十、隐私与数据边界

上下文资产越完整，泄露面也越大。至少遵守以下规则：

• 不把 .env、私钥、访问令牌、密码和带口令连接串写入任何长期载体；
• 客户数据、邮箱、手机号、支付信息等只在明确授权的最小范围内处理；
• 共享 Skill 和 AGENTS.md 前扫描本机路径、内部域名与身份信息；
• 会议纪要提炼结论时，删除与任务无关的个人信息；
• Memory 在导出、迁移或分享前人工检查；
• 外部审查只发送完成判断所必需的脱敏材料；
• 需要真实值才能判断的问题，不应伪装成“已审查通过”，而应标记上下文不足。

尤其要注意：把敏感值替换成占位符可以保护数据，但如果值的格式、权限或作用域会影响安全结论，脱敏后审查者可能无法判断。此时正确结论是需要更多本地验证，而不是强行给出确定答案。

十一、案例：把混乱的“万能提示词”迁移成分层体系

假设一个团队有一份两万字提示词，混合了代码风格、部署说明、历史故障、写作偏好、测试命令和当前迭代任务。迁移可以分五步。

第一步：逐条标注

为每一段标注权威性、寿命、复用范围和敏感等级。无法判断来源的内容先放“待核对”，不要直接迁移。

第二步：抽取硬规则

把目录边界、验证命令、审批要求和用户改动保护规则写入对应层级的 AGENTS.md。每条规则尽量能被观察或验证。

第三步：重建事实文档

架构、业务口径和故障经验进入正式文档。补上日期、证据和状态。相互矛盾的历史说法由负责人裁决。

第四步：封装重复方法

把发布检查、文档生产、浏览器验收等高频流程拆成 Skills。先用真实任务手动跑通，再加入脚本与自动验证。

第五步：清理个人与临时内容

稳定个人偏好可进入 Memory；当前迭代的任务说明留在当前任务或 handoff。最后删除万能提示词，避免它继续成为隐藏的旧权威源。

迁移完成后的衡量标准不是文件变多，而是任何成员都能回答：一条信息为什么在这里、谁负责更新、冲突时听谁的、过期后怎么处理。

十二、常见失败模式

1. 把 Memory 当唯一知识库

召回不等于强制，生成也不是实时保证。重要规则必须落到可审计文件。

2. 全局 AGENTS.md 管得过细

某个项目的特殊命令污染所有项目。通用规则留全局，项目规则放仓库，目录差异放更深层。

3. Skill 同时保存流程和项目状态

复用 Skill 时携带旧项目结论。把状态移回文档或 handoff。

4. 文档有多个“最新版”

文件名加日期仍可能冲突。需要明确当前入口、替代关系和负责人。

5. 原始对话未经提炼直接入库

讨论中的错误假设被未来 AI 当作事实。只沉淀确认结论、证据与必要失败路径。

6. 为节省 Token 删除来源

过度摘要让结论无法复核。压缩正文可以，但保留权威来源链接、日期和关键证据位置。

7. 不清理过期上下文

上下文体系需要维护预算。建议每月检查高权威规则，每个里程碑整理项目事实，每季度审视 Skills 与 Memory。

十三、快速决策树

遇到一条新信息时，可以按顺序判断：

1. 不遵守是否会带来明确风险？是，则考虑 AGENTS.md、Hook 或正式政策；
2. 它描述项目当前状态或决定吗？是，则进入项目文档；
3. 它是一套可跨任务复用的方法吗？是，则进入 Skill；
4. 它主要是个人偏好或重复背景吗？是，则可考虑 Memory；
5. 它只服务当前判断吗？是，则留在当前任务；
6. 它包含敏感信息吗？是，则先最小化、脱敏或不持久化；
7. 它是否已有权威版本？是，则更新原位置，不要创建第二个真相源。

十四、设计一次任务的上下文装载顺序

分层存储之后，还要解决“本次到底装载什么”。如果每次仍把五层全部展开，分层只改变了文件位置，没有降低上下文负担。更合理的装载顺序是从最小必需集合开始，再按问题逐步取证。

第一步读取强制规则，只提取与当前目录和任务类型相关的约束；第二步读取目标与完成标准，确认本次不做的范围；第三步打开项目地图和最近 handoff，恢复当前状态；第四步根据任务类型选择 Skill；第五步只在遇到具体判断时查询更深文档、Memory 或历史证据。

这个过程可以形成一份简短的“上下文清单”：

本次目标：要交付的结果和完成条件。
强制规则：实际命中的 AGENTS.md 层级与关键条目。
当前事实：使用的项目文档、日期与状态。
执行方法：触发的 Skill 及其版本。
临时证据：本次读取的日志、截图、命令输出。
未采用内容：过期文档、冲突记忆或范围外资料。

清单的作用不是增加形式，而是让人快速发现装载错误。若一个前端样式任务加载了生产数据库运行手册，说明选择过宽；若认证改动没有加载权限模型，说明关键事实缺失。

任务结束时执行相反动作：临时证据默认丢弃，确认决定进入项目文档，可复用步骤反馈给 Skill，新的强制规则经过人工批准后进入 AGENTS.md，稳定个人偏好才考虑 Memory。不要让 AI 自动把所有输出升级为长期知识，否则错误和噪声会获得不应有的权威。

还应定期做“冷启动测试”：让一个没有参与过历史讨论的新任务，只依靠正式规则、文档和 handoff 复述当前状态与下一步。若无法做到，说明关键上下文仍藏在人的记忆或旧聊天里。

十五、团队治理：谁有权改变哪一层

上下文系统必须有所有者。没有所有者的文件最终会变成“大家都以为别人会更新”的旧资料。

建议建立轻量责任分工：

• 全局 AGENTS.md 由工程负责人或工作流负责人审批；
• 仓库规则由代码库维护者负责，并通过代码评审变更；
• 架构与业务事实由对应领域负责人确认；
• Skills 由实际使用者维护，但安全脚本和外部工具接入需要额外审查；
• Memory 由个人管理，不作为团队政策来源；
• 任务 handoff 由当前执行者在交接前核对。

高权威层的变更应比低权威层更严格。修改全局安全规则可能影响所有项目，需要说明原因、影响范围、迁移方式和回滚方法；修改当前任务的一条临时假设则可以快速进行，但不能悄悄写回长期文档。

可以为每一层设维护周期：强制规则在每次相关事故和季度评审时检查；项目文档在里程碑和架构变化时更新；Skills 在连续出现同类返工时修订；Memory 在召回冲突或分享设备前清理；handoff 在每个阶段结束时生成。

判断体系是否健康，可以观察四个结果：新成员恢复项目的时间、AI 重复询问背景的次数、因旧规则导致的返工、重要决定能否追到来源。文件数量、记忆条数和 Skill 数量都不是目标。

最后，要保留删除机制。一条规则长期不再命中、一份 Skill 没有真实使用者、一段记忆反复与当前事实冲突，就应归档或删除。上下文资产和代码一样会产生维护成本；不敢删除的知识库，最终会让所有内容都失去可信度。

跨团队共享时，建议只共享经过确认的最小层。另一个团队可能需要通用 Skill 和接口契约，却不需要个人 Memory、原始会议记录或完整故障日志。分享包应附适用范围、更新时间、敏感信息处理和已知缺口。接收方先把它当作待验证输入，再与自己的规则和代码事实核对，不能因为来源是内部文档就默认永远正确。

当项目结束时，也要执行上下文退役：保留最终决定、运行手册和高价值失败案例，删除临时账号、合成数据、重复附件与无用任务状态。这样，未来召回的是项目真正留下的知识，而不是结束时无人整理的工作现场。

十六、维护检查清单

• 全局规则与项目规则已分开；
• AGENTS.md 中每条要求都清晰、稳定、可执行；
• 架构事实和业务口径有日期、来源、状态；
• 已被替代的文档明确归档或标记；
• Skills 只承载可复用方法，不夹带项目当前状态；
• Skill 描述足够准确，能正确触发和避开无关任务；
• Memory 不承担唯一的安全、权限或合规规则；
• 当前任务中的事实、推断、决定可以区分；
• 指令授权冲突与事实证据冲突分开处理；
• 阶段结束有简短 handoff，而不是只留原始对话；
• 重要结论保留可核对来源；
• 长上下文已去重，并有明确权威入口；
• 敏感信息未进入可共享的规则、Skill 或记忆；
• 冲突时会显式说明，不会静默选边；
• 已设定月度或里程碑清理节奏。

结语

高质量上下文体系不是让 Codex 知道一切，而是让它在正确时刻得到最小、可靠、可审计的信息。AGENTS.md 负责必须遵守的规则，项目文档负责当前事实与决定，Skills 负责可复用方法，Memories 负责低风险召回，当前任务负责即时证据。

当这五层边界清楚后，团队会得到两个直接收益：一是减少每次从头解释，二是出现错误时能够追到信息来源。后者比“记得更多”更重要，因为一个无法解释依据的 AI，即使偶尔给出正确答案，也很难进入真正的生产流程。

---

感谢各位大佬支持！！！
互三啦！！！