让 Codex 越用越聪明：用一套长期规则积累项目经验 - AI

很多人在使用 Codex 时，会遇到一个明显的问题：

同样的错误反复出现，同样的项目规范需要重复说明，每次开始新任务，都像重新认识一个陌生的助手。

想解决这个问题，单靠一句“记住我的习惯”并不够。更有效的方法，是通过一段初始化提示词，为 Codex 建立一套长期工作规则，让它主动记录经验、复盘问题，并在新项目开始前读取这些规则。

QQ20260725-224050

这套方法的核心，是让 Codex 自动创建并持续维护三个文档：

全局工作台
全局复盘日志
新项目 SOP

它们共同组成一套可持续积累的项目知识库。

一、为什么要建立长期工作规则？

Codex 很擅长执行当前任务，但它并不会天然理解你的全部开发习惯。

例如，你可能希望它：

修改代码前先理解项目结构；
尽量只改动必要文件；
不要随意重构无关代码；
每次修改后说明改了什么；
遇到错误时记录原因和解决办法；
创建新项目时使用统一目录和命名方式。

如果每次都重新输入这些要求，不仅麻烦，也容易遗漏。

因此，更合理的做法不是不断追加临时提示词，而是建立一套固定文档，让 Codex 在工作前主动读取，在工作后持续更新。

二、三个核心文档分别做什么？

1. 全局工作台

全局工作台相当于 Codex 的“工作说明书”。

它主要用于规定 Codex 的通用行为，例如：

开始任务前需要检查哪些内容；
修改代码时应遵守什么原则；
哪些文件可以修改，哪些文件不要轻易触碰；
项目文档分别放在哪里；
不同规则文件之间如何配合；
完成任务后需要输出哪些说明。

全局工作台还可以作为整个规则体系的目录，帮助 Codex快速找到其他文档。

简单来说，它解决的是：

Codex 应该按照什么方式工作。

2. 全局复盘日志

全局复盘日志用于记录实际工作中出现过的问题。

可以写入的内容包括：

曾经修改错误的文件；
因不了解项目结构导致的问题；
重复出现的命令错误；
构建、测试或部署失败的原因；
用户已经明确否定过的方案；
已经验证有效的解决方法；
今后遇到类似问题时应如何处理。

复盘日志不是普通的操作记录，而是一份可复用的经验库。

每完成一个重要任务，Codex 都可以检查：

这次是否出现了错误；
错误为什么发生；
下次如何避免；
有没有可以复用的方法。

这样做的意义在于，同一个坑尽量只踩一次。

3. 新项目 SOP

新项目 SOP 用来规定创建新项目时的标准流程。

例如可以要求：

每个项目必须使用独立文件夹；
项目名称采用统一格式；
创建 README、任务记录和状态文档；
开发前先确认技术栈和目录结构；
不在桌面或临时目录随意堆放文件；
初始化 Git 仓库并配置忽略文件；
重要操作前先备份；
完成初始搭建后记录项目状态。

它解决的是：

新项目应该按照什么顺序开始。

有了这份 SOP，即使同时管理多个项目，也能尽量保持目录、文档和操作方式一致。

三、把规则写入 Agent.md

三个文档创建完成后，还需要在项目的核心规则文件中加入一条最高优先级指令。

常见文件名可能是：

1
2
3


AGENTS.md
Agent.md
agents.md

具体名称需要根据 Codex 当前使用的规则机制和项目结构决定。

可以在其中写入类似规则：

执行任何新项目或重要任务之前，必须先阅读全局工作台、全局复盘日志和新项目 SOP。确认理解相关规则后，再开始分析、修改或创建文件。

这一步非常重要。

如果只是创建文档，却没有要求 Codex 在任务开始前主动读取，那么这些文档很容易变成无人使用的资料。

真正有效的机制应该是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


开始任务
  ↓
读取全局规则
  ↓
查看历史复盘
  ↓
按照 SOP 执行
  ↓
完成任务
  ↓
记录新的经验

这样才能形成完整闭环。

四、它为什么会“越用越聪明”？

这里所说的“越用越聪明”，并不是让 Codex 自动升级模型，也不是增加账户额度。

它真正改变的是工作上下文。

随着任务不断增加，复盘日志里会逐渐积累：

你常用的技术栈；
你不喜欢的代码风格；
你习惯的目录结构；
项目中容易出错的位置；
已经尝试过但失败的方案；
更适合你的操作流程；
不同项目之间可以复用的经验。

当 Codex 每次工作前都读取这些信息，它就能减少重复试错，也更容易按照你的习惯完成任务。

从实际体验上看，它会表现得越来越稳定，也越来越像一个熟悉你项目的长期协作者。

五、这套机制需要注意什么？

虽然长期规则很有用，但并不是文档越多越好。

首先，规则要保持简洁。过多重复、冲突或已经失效的内容，反而会干扰 Codex 的判断。

其次，复盘日志要记录结论，而不是堆积完整聊天内容。建议重点保留：

问题是什么；
原因是什么；
最终如何解决；
下次应该怎么做。

最后，重要规则仍然应该保存在项目文件中，而不是完全依赖模型自身的临时上下文。文件更容易检查、修改、同步和备份，也适合在多台电脑或团队成员之间共享。

总结

想让 Codex 更懂你的项目，关键并不是不断寻找更长、更复杂的提示词，而是建立一套可以持续维护的工作机制。

通过全局工作台统一行为规则，通过全局复盘日志沉淀经验，再通过新项目 SOP 规范项目初始化流程，最后将“任务开始前必须阅读这些文档”写入 AGENTS.md，就能形成一个不断积累和复用经验的闭环。

它不会让 Codex 的模型能力发生变化，但能明显减少重复沟通、无关修改和重复踩坑。

真正让 Codex 越用越顺手的，不是一段神奇提示词，而是一套能够长期执行、持续复盘、不断更新的项目规则体系。