昨天刚把 Codex 调教明白。
今天新开一个对话。
它又开始：
- 默认英文
- 动你不想它动的文件
- 回答像第一次见你
- 上次说过的规则，这次又忘了
大家默认的想法就是：
这模型也不强啊？
其实真正的问题根本不在模型。
不是 Codex 不够聪明。
是你没有考虑去维护管理它的长期记忆系统。
反复经历失忆，调试，在失忆的循环，是最拖累效率的事情！
真正让 Codex 变顺手的，不是每次临场补提示词。
而是给它搭一套长期上下文系统。
一、你以为自己在跟一个老友对话，其实它每次都在重新认识你
很多人现在用 Codex，状态都差不多：
- 每开一个新任务，又要重新说一遍偏好
- 稍不注意，它就开始做超出预期的操作
- 你以为上次已经讲清楚了，这次它还是照样忘
这就是最典型的“没有长期记忆”。
也就是说，你不是在和一个越来越懂你的老搭档协作。
你是在反复和一个失忆的高手重新磨合。
它能力可能很强。
但只要记不住你怎么工作、你最在意什么、你的默认边界是什么，它就永远不可能真的顺手。
很多模型和 Agent 默认都不带稳定的长期个性化记忆。
所以，你需要主动给 Agent 设定记忆系统，
把你的工作规则，沉淀成它能持续读取的东西。
二、真正让 Codex 变顺手的，是让他越来越了解你
这也是很多人最容易搞错的地方。
大家总觉得，想让 Codex 更好用，就要：
- 换更强模型
- 学更多提示词
- 找更复杂的工作流
这些当然有用。
但在真实使用里，真正拉开差距的，往往是另外两层：
AGENTS.mdMemories
前者解决的是：
它一开始就该怎么做。
后者解决的是：
它用久了以后，会不会越来越懂你。
个性化打开你的额外上下文
可以使用下面的模板，添加修改成你自己的个性化内容
# AGENTS.md
## 基础行为
- 默认使用中文回答，除非用户明确要求其他语言。
- 回答要简洁直接，避免不必要的铺垫和重复。
- 如果任务描述不清晰，先提问确认，再开始执行。
- 不要主动推测用户意图之外的需求，只做被要求的事。
## 安全边界
- 默认只读，不主动修改、删除任何文件，除非用户明确指示。
- 涉及不可逆操作（如删除、覆盖、调用外部 API 写入）前，必须先确认。
- 不在输出中打印任何密钥、Token 或敏感凭证。
## 工程规范
- 避免过度设计，只做任务明确要求或明显必要的改动，保持方案简洁。
- 不在未被要求的情况下添加功能、重构代码或进行额外优化。
- 不为未改动的代码添加注释、类型标注或文档字符串。
- 仅在逻辑不自明时添加注释。
- 不为不可能发生的场景添加错误处理或兜底逻辑。
- 不创建只使用一次的工具函数或抽象层。
- 确认无用的代码，直接删除，不留注释说明。
三、AGENTS.md：不仅仅是配置文件，是你的协作底线
很多人第一次看到 AGENTS.md，会把它当成普通说明文档。
但我现在更愿意把它理解成：
你和 Codex 长期合作的底层协议。
Codex 在开始工作前会读取它，而且支持两层：
- 全局层：
~/.codex/AGENTS.md - 项目层：项目目录里的
AGENTS.md
它最直接的作用，就是把那些你已经说烦了的话，提前写进去。
比如：
- 默认中文
- 回答简洁
- 危险操作先确认
- 不要过度设计
- 先给最小可行方案
这里有两个误解，必须先纠正
第一，没有 AGENTS.md，Codex 也不是一张白纸。
它仍然有系统指令、当前对话、工作目录、工具权限这些上下文。
缺的只是：
你主动沉淀进去的个人规则和项目规则。
第二，项目层也不是简单“覆盖全局”。
更准确的说法是：
Codex 会按顺序读取全局规则、项目根目录规则、子目录规则。
越靠近当前工作目录的规则，越晚进入上下文，所以通常优先级更高。
这更像规则叠加，不是传统配置文件那种机械覆盖。
四、真正好用的 AGENTS.md，不是写得多，而是写得准
很多人一上来就想写一份“大而全”的规则大全。
最后往往适得其反。
更稳的方式是分层。
全局层，写你这个人的长期偏好
最适合放这些：
- 默认语言
- 回答风格
- 安全边界
- 通用工程规范
- 默认工作习惯
比如我自己更在意的就是：
- 默认中文
- 先给结论
- 危险操作先确认
- 避免过度设计
- 先走最小可行方案
项目层，写这个项目的具体规则
最适合放这些：
- 项目结构
- 启动命令
- 测试命令
- 哪些目录别碰
- 什么算完成
例如这种就很实用：
# 项目规则
启动：
pnpm dev
测试：
pnpm test
禁止：
不要删除 assets 目录
完成标准：
运行通过 + 截图验证
五、Memories：决定它以后会不会越来越懂你
开启之后，Codex 会把一些稳定信息带到后续线程里，比如：
- 偏好
- 常用工作流
- 技术栈
- 项目约定
- 反复出现的坑点
下次不用重新解释，也知道你大概怎么工作、怎么判断、怎么做选择。
Codex 的记忆结构，你可以粗略理解成这样：
模型读取 → memory_summary → 关键词触发后读取 MEMORY → 如果信息还不够，再继续深入原始材料。
这套机制的意义，不是让它“什么都记住”。
而是让它在长期协作里，越来越接近你的工作方式。
但 Memories 也不是绝对真理
这一点特别重要。
很多人一听“记忆”，就容易自动脑补成“永久正确”。
其实不是。
它更像长期工作笔记。
会漂移。
会过期。
也可能带偏。
所以更稳的做法是定期：
- 清理失效偏好
- 删除旧项目信息
- 重写长期规则
- 修掉已经不适用的记忆
不要让 Agent 带着三个月前的你继续工作。
六、真正好用的，不是单点功能，而是一套长期上下文系统
很多人把这件事理解得太窄，只盯着 AGENTS.md 和 Memories。
但真正好用的长期上下文系统，通常至少有四层：
AGENTS.md：长期规则Memories：长期偏好和上下文- 项目文档：架构、模块、运行方式、业务背景
- Skills / 模板：可重复执行的流程
比如：
- 内容审核
- 发布前检查
- 日报生成
- repo 分析
- 固定工作流
这些一旦沉淀下来，Codex 才不是“每次重新配合一次”。
而是真的在慢慢接近你的工作方式。
七、记忆系统虽好，但是使用要克制！
值不值得配？值。
尤其适合你这种：
- 长期用 Codex 做内容系统
- 经常分析项目
- 会反复跑工作流
- 希望一套习惯能跨对话延续下去的人
但这套东西不是越多越好。
主要问题有几个：
- 规则太多会冲突
- 旧记忆可能过期
AGENTS.md太长会吃上下文- 规则写太死，Codex 会变保守
- 把“偏好”写成“绝对禁令”，反而会拖慢效率
所以关键不是写得越多越好。
而是：
写得准，写得轻，持续迭代。
八、会不会更耗额度？
会有一点，但通常可控。
因为 AGENTS.md 和 Memories 本质上都是额外上下文。
内容越长，输入 token 越多。
但如果你写得精简，它通常反而是省的。
因为真正浪费额度的，很多时候不是这几百字规则。
而是你每次都重新解释一遍。
所以更准确的结论是：
精简的 AGENTS.md + 适度的 Memories，通常是省额度的。
臃肿的规则 + 过量记忆，才会把上下文成本越堆越高。
#Codex #AGENTSmd #Memories #AI记忆系统 #AIAgent #上下文工程 #AI工作流 #MarkWave