长任务落到文件，规则写成地图
Codex 多出来的不是更会聊，是能把约定和进度写进项目文件，下次接着干。文件是交接物，聊天不是。
短改动靠五步就够。跨小时、跨会话的活，Codex 多出来的判断是：把约定和进度写进仓库，让下一班（人或 Agent）读文件接着干。官方说它在动手前会读项目说明；长任务实践把「持久的项目记忆」当作最重要的手法。codex-agents-md codex-long-horizon
读完你能回答：
- 项目说明为什么只能当地图，不能当百科全书？
- 长任务最少要落哪三类文件？
- 人还审什么，不审什么？
规则短，离代码近
项目说明放站得住的约定：测试怎么跑、什么时候必须问人、坏模式和安全路径。写短，坏模式说清楚。全局习惯放本机，仓库规矩放根目录，某服务的特例放在那棵树附近——近的覆盖远的。官方写过：空文件跳过，临时覆盖用单独的覆盖文件，不必删掉底稿。codex-agents-md
把所有话塞进一份说明，任务上下文会被挤掉，每条规则看起来一样重要，还无法验证有没有被遵守。OpenAI 用 Codex 做内部产品时，第一版巨型说明立刻失败，后来压成约百行的目录，指向分文件的文档。openai-harness 站内同一判断见 项目契约 和 上下文分层。
三类文件接住下一班
长任务最少落三类，名字可以换，职责不能混：
- 里程碑： 每一步要交出什么、用哪条命令验收、失败先修再前进。
- 执行说明： 当前怎么干、diff 要控制在能看完的范围。
- 状态记录： 做了什么、为什么这么定，人离开几小时回来还能读懂。
这是使用者侧的做法，不是再讲一遍如何做 Agent。机制见 长任务要有交接物和终态。
人审取舍，不审每一行
人仍然定目标、定约束、在偏离时改航，并审架构和产品取舍。不是每一行都盯。长任务的方向是少旁观、多带护栏地委派。下一篇是这种用法怎么翻车。