夜雨聆风我是sillyrabbit，喜欢AI知识分享，用AIGC做创意视觉的搞怪兔子。
Silly，but it works.
Silly Rabbit 以前习惯用 Codex CLI。操作很直观：cd 进项目目录，运行 codex，当前文件夹就是工作区，AGENTS.md 放在根目录就行，清清楚楚。
后来开始用 Codex App，反而有点不适应。Project 是什么？Thread 又是什么？Worker 怎么开？上下文为什么老是爆掉、压缩老是卡死？
折腾了一段时间之后，本兔子逐渐理解了：这不全是产品问题，更多是 AI Agent 的上下文机制本身有结构性限制。Codex App 和 Codex CLI 的心智模型也不一样。搞清楚这两件事，很多坑就能避开。
以下是Silly折腾出来的一套工作流，供参考。
✅先理解问题本质：杯子和水
每一个对话，都像一个有限的杯子。
你和 Codex 聊的内容、它读取的文件、它输出的代码，都是往这个杯子里倒水。任务越复杂、对话越长，水就越多，杯子就越满。
压缩上下文（compact），相当于把水浓缩——体积小了，但可能丢细节，也可能在浓缩过程中卡住。
所以，更可靠的办法，不是寄希望于杯子更大、压缩更聪明，而是：把水存到杯子外面——也就是存到项目文件里。（这个弯本兔转了一会儿才绕过来。）
说清楚一点：不是模型没有记忆，而是模型不适合被当成可靠的长期项目记忆。当前对话里的上下文它确实能看到，但一旦对话变长、压缩发生、或者你换了对话，这些"记忆"就靠不住了。
真正可靠的记忆，是文件。
✅Codex CLI 和 Codex App，心智模型不一样
用 CLI 时，逻辑是"目录优先"：你在哪个目录运行 codex，那里就是工作区。
用 App 时，逻辑是"Project / Thread 优先"：
Project：绑定到你电脑上某个真实的文件夹，是长期项目的容器
Project Thread：在这个项目里开的对话，能访问项目文件夹，适合长期做项目
Standalone Thread：临时开的独立对话，不一定绑定真实项目，更像随手问问
简单说：Project Thread = 在项目里干活；Standalone Thread = 随手开的临时聊天。
如果你想让 Codex 管理真实项目、维护 AGENTS.md、更新日志文件，建议先在 App 里创建一个 Project，并绑定真实项目文件夹，不要在 Standalone Thread 里长期做项目。否则文件读写关系会很混乱。
✅第一层：给 Codex 建一本"工作手册"
文件名：AGENTS.md
这是 Codex 每次开工前会读取的文件。把稳定的规则写进去，以后就不用每次重新交代。
适合写进去的内容：
项目结构说明（哪个文件夹放什么）
代码规范（用什么框架、命名风格、不允许的操作）
构建和测试命令（比如
npm run test怎么跑）协作约定（不随意修改无关文件、不跳过测试、有疑问先问）
每轮工作结束后，必须更新
LOG.md和STATUS.md（这条很关键）
注意：AGENTS.md 适合放稳定规则，不适合放当前任务进度。任务进度放在后面说的几个文件里。
✅第二层：用文件代替对话记忆
Silly Rabbit 的项目里，一般会维护这样一套文件：
各自的职责：
PLAN.md：这次要做什么，分几个阶段，每个阶段的目标和范围LOG.md：每轮对话或 Worker 完成后，记录做了什么、改了哪些文件、测试结果如何STATUS.md：现在做到第几步、谁在执行、下一步是什么、有没有阻塞
为什么这样做有效？
哪怕对话变长、压缩效果不理想、换了模型或者换了对话，新的 Thread 只要读这几个文件，就能快速接手。损失的只是上一次对话的"聊天记录"，而不是整个项目的状态。
✅第三层：大活拆开，主对话只做"导演"
不太理想的做法是：一个对话里，从需求讨论到设计、实现、调试、测试、修复，全走一遍。对话越来越重，最后要么压缩、要么爆掉。
更可行的做法，是把角色拆开：
主对话负责：
理解需求
制定计划并写入
PLAN.md拆分任务，分配给 Worker
收集阶段总结
做最终 review
Worker 负责：
执行某一个阶段
只改明确范围内的文件
跑测试
更新
LOG.md/STATUS.md汇报改动、测试结果和风险点
这样主对话保持"轻量"，Worker 处理具体执行，任务边界清楚，互不干扰。
一个小提醒：Worker 不是越多越好。多个 Worker 同时改同一块代码，很容易互相冲突。更适合拆成边界清晰、互不重叠的任务。
✅如何在 Codex App 里开启子 Worker
有两种方式，都不复杂：
方式一：在主对话里直接描述
方式二：在同一个 Project 里手动新建一个 Thread
这个新 Thread 就充当手动 Worker。给它的开场提示词可以是：
关键不是有没有某个按钮，而是工作边界要说清楚。Worker 最好知道：做哪个阶段、允许改哪些文件、完成标准是什么、结果写回哪个日志。
✅第四层：上下文快爆时，怎么应急
按严重程度来：
如果平时日志维护得好，即使换对话，损失也会小很多。这就是第二层文件系统很关键的原因——它是整套方法的兜底机制。
✅第五层（进阶）：用状态机的思路管理项目
普通用法是：我盯着 Agent 干活。
更系统的用法是：我盯着任务状态流转。
任务不只活在某个聊天窗口里，而是有明确的生命周期：
每个任务最好都有：
当前状态
下一步动作
完成标准
阻塞原因（如果有）
产出证据（PR 链接、测试结果、日志截图）
OpenAI 在 2026 年 4 月 27 日发布的开源项目 Symphony，就是这个思路的完整实现——用 Linear 任务看板作为"状态机"，每个 ticket 自动分配一个 Agent 去执行，Agent 崩了自动重启，人只负责 review 结果。据 OpenAI 官方介绍，这种工作流让内部团队的合并 PR 数量在数周内有明显提升。
对普通用户来说，不需要部署复杂系统，只要让 STATUS.md 持续记录任务状态，就已经是在用状态机思维辅助 Agent 工作了。
✅行动清单
如果你想从今天开始调整，可以按这个顺序来：
在 Codex App 里创建一个 Project，绑定真实项目文件夹
在项目根目录建
AGENTS.md，写入项目规范和"每轮更新日志"的约定建
PLAN.md、LOG.md、STATUS.md，开始任何大任务前先填写计划做大任务时，主 Thread 写计划、分配任务，另开 Thread 或启动 Worker 执行
感觉对话变重时，及时
/compact，或 Fork 到干净节点继续对话换了、模型换了，让新 Thread 先读文件，再开工
信息存文件，对话只指挥，大活拆小块，状态随时存。
这不一定是使用 Codex App 的唯一方式，但在本兔的实践里，是目前最稳的一种。
