译者说明：译自 OpenAI 官方 Cookbook。原文是给工程团队写的，但它真正在讲的是一套「怎么让长期协作不走样」的制度，这一层对任何用 AI 干长活的人都成立。文件名与目录结构原样保留。
关于日期：Cookbook 是持续更新的仓库，页面上没有发布日期。本文的日期取自 OpenAI 官方 Cookbook 索引（
registry.yaml）里为这一篇登记的日期，也就是这份内容第一次被生产出来的时间。
那套目录
.
├── AGENTS.md # 这个仓库长期不变的规矩
├── GOALS.md # 要达成什么，什么算达成
├── PLANS.md # 路线图与阶段顺序
├── PROMPTS.md # 可复用的几个入口
└── harness/
├── build/ # 每个阶段一份规格
├── context/ # 每个阶段发现的重要事实
└── build-log.md # 进度与**验证证据**
看起来像是把简单的事复杂化了。但每一份文件都在挡一种具体的走样，下面逐个说。
每一份挡的是什么
AGENTS.md —— 挡「每次都要重讲一遍背景」。
放代码规范、测试标准、这个仓库特有的常识。它是每次开工前都会被读到的那份。
GOALS.md —— 挡「做着做着跑偏了」。
写清楚要什么、什么算成功、边界在哪、有什么技术约束。它刻意不写「怎么做」——那是另一份文件的事。
PLANS.md —— 挡「顺序乱了」。
阶段的先后和依赖关系，以这一份为准。
harness/build/ —— 挡「一个阶段范围失控」。
每个阶段一份，写清目标、验收标准、明确不做什么、以及怎么验证。
harness/context/ —— 挡「重要发现被忘掉」。
只在阶段真正开始之后才建，装的是那些会影响后续判断的决定、假设、约束和未解决的问题。
harness/build-log.md —— 挡「说做完了但其实没验证」。
这一份最要紧，下面单独讲。
全篇最值钱的那条规矩
原文关于日志的要求，翻译过来是这样：
只记那些会真正影响后续工作或判断的信息。 把「观察到的证据」和「声称的结论」分开。 绝不能把「计划要跑的命令」当成「已经验证通过」来记。
最后那半句是整套东西的核心。
这防的是一种很具体的失败：AI（或者人）说「测试应该会通过」，记下来的时候变成「测试通过」，再往后就成了既定事实——而实际上从来没有人跑过。
几道闸
原文列的几条安全设计，都很实在：
- 计划和实施分开批准，是两次
- 动手改之前，先跑一遍只读的检查
- 要的是实际观察到的测试结果，不是预测的结果
- 凭证、对外写入、提交、部署，各自单独批准——不能一次批完
- 遇到的限制和卡点必须留在日志里，不能只留成功的部分
一份东西只放在一个地方
原文给了一张归属表：
| 放哪 | 归它管 |
|---|---|
| 阶段规格 | 批准的范围、验收标准、计划的验证方式 |
| 阶段上下文 | 重要的发现、决定、约束、未决的事 |
| 构建日志 | 实际观察到的进度与证据 |
| 评审记录 | 详细意见与签字状态 |
一条信息只放一个地方，别处只放指过去的引用。
（站上有一篇讲这件事踩过的坑：东西还在不在服务器上，是唯一的判据。同一条原则的另一个面孔。）
它自己也说了「别过度」
这一点值得注意。原文明确写着：在仓库规模和风险不足以支撑这套流程的时候，不要硬上。 它主张的是「刚好够用的最小架子」。
这句话让整篇的可信度高了一截。 一份方法论如果不告诉你什么时候不该用它，那它多半没被真正用过。
对不写代码的人
把上面的文件名换掉，这套东西就是一份项目管理制度：
AGENTS.md→ 团队的工作规范GOALS.md→ 项目目标与验收标准PLANS.md→ 阶段计划build-log.md→ 项目日志，而且严格区分「计划」与「已验证」
最后一条是多数项目日志缺的那一样。 一份把计划和事实混在一起的日志，读起来一切顺利，直到某天有人去核对。