让 Codex 今天写代码、明天接着做，交接往往比启动任务更容易出错。上次只是点过提交，还是已经验证成功？“只能改项目目录”这个边界，下个任务有没有读到？
今天整理本地工作目录时，我把这些信息落到了三个位置：AGENTS.md、状态文件和执行日志。下面用一个持续维护的小工具项目说明怎么组织、怎么检查。这是一套可查看、可修订的任务交接约定，仍需要在恢复时核对实际状态。
一、AGENTS.md：放长期规则，指向需要读取的记录
如果使用 Codex，可以在项目根目录放一个 AGENTS.md。官方文档说明，Codex 会在开始工作时读取适用的 AGENTS.md；它有自己的发现范围和指令优先级。
我会让这个文件先回答四件事：这个项目要做什么、哪些地方可以改、什么算完成、开始工作时去哪里恢复状态。
可以从这段自己的项目约定开始：
项目目标：维护一个能实际运行的本地工具。
文件边界：只修改本项目目录，其他目录只读。
开始工作：先读 operations/state.json 和最近的 logs/ 记录。
结果核验：运行过的命令、结果及失败原因要留下记录。
结束工作：更新当前进度、未解决问题和下一步。
边界最好具体到路径和动作。“注意安全”“别乱改”很难判断是否执行到位；“只修改 D:/demo/project，项目外只读”更容易检查。这里的路径只是示例。
AGENTS.md 不需要变成聊天记录全集。已经结束的排查过程、过期的临时要求，放进日志更合适。规则越长，后续维护时越容易把旧信息继续当成要求。
二、state.json：写清现在停在哪儿
我另外建了一个状态文件，只保存恢复任务需要的信息。它可以是 JSON，也可以是简短的 Markdown；文件名和字段由项目自己约定。
下面是一个报告生成任务的示例，不是实际执行结果：
{
"updatedDate": "2026-10-22",
"completed": ["整理输入数据"],
"pending": ["生成报告", "核对输出"],
"unknown": ["上次远程提交是否成功"],
"nextAction": "先核对远程提交结果，避免重复提交"
}
这里我最看重的是 unknown。点过“提交”和提交成功，是两个状态。结果还不确定时，直接重新提交，可能造成重复发布、重复创建任务或重复扣费。
状态文件也有边界：它只是上次观察的记录。登录可能过期，文件可能被人修改，远程任务可能已经完成。恢复任务时，仍要重新核对关键状态。
还有一个容易误会的地方：state.json 不是 Codex 的内置记忆文件。工具不会因为它叫这个名字就自动读取；需要在项目规则中明确指向它，或者在启动任务时要求读取。
三、logs/：留证据，别只写“已完成”
日志不用很长。我会让每次工作至少留下这几项：
本次目标：
实际做了什么：
看到的结果或产物位置：
失败或结果未知的动作：
下次先做什么：
例如，“修复完成”很难帮助下次排查；写清修改了哪个文件、运行了什么验证、输出在哪里，就能少猜很多。
日志里也不要保存密码、Cookie、访问密钥或完整个人数据。需要记录授权问题时，保存错误类型和凭证名称通常就够了。
怎样检查这套结构是否能交接？
从项目目录开启一个新任务，让它先说明读取了哪些项目规则、当前进度依据是什么，再开始操作。
重点看三件事：是否读到了你指定的状态文件，是否把计划和实际结果分开，是否会先处理结果未知的动作。这个检查比问一句“你记住了吗”更具体。
对我来说，这套做法的价值是把项目交接落到了可以查看和修订的文件上。先从几条短规则、一份真实状态和一条执行日志开始，就已经能检查哪些信息还没有交接清楚。
参考资料：
创作说明：本文结合实际目录整理过程与官方文档，由 AI 辅助整理；示例路径、任务和数据均为说明用途。
版本说明：本文由作者根据自有原稿调整，核心内容此前已发表于本人知乎账号；本篇不参加要求首发或排除 AI 创作的活动。
