我用 Codex 越久，越发现：真正决定协作质量的，不是那句话怎么写，而是你有没有给它一个靠谱的结构。
一开始我也觉得是模型的问题------为什么又理解偏了，为什么任务越做越大，为什么任务越来越难改的动。
后来我才意识到，问题不在 Codex，而在我：我一直把它当聊天框用，而不是当工作流用。这个认知的转变，比换多少 Prompt 都管用。
如果你也在折腾 Codex，我把这套还在持续打磨的 playbook 放到了 GitHub：HuiDBK/codex-playbook
你以为卡在 Prompt，其实卡在工作方式
大家最容易优化的，通常是模型选择、slash command 用法、Prompt 怎么写得更"高级"。这些都值得做，但它们不是最先该动的地方。
我最近遇到的真实问题，几乎都更底层：
-
任务边界没收住，一轮会话越聊越大
-
实现、审查、继续修改全混在一起
-
没有收口点，小需求最终变成长对话
这些问题有个共同点：不会在第一时间炸掉你，但会一点点吞掉你的注意力。等你反应过来，不是"代码写不出来"，而是"这轮协作已经不干净了"。
AGENTS.md：不是门牌，是地基
以前我对 AGENTS.md 的理解停留在"写点规则、显得规范"。现在我完全不这么看了。
它真正的价值，是把你每轮都要重新提醒一遍的东西，变成默认契约。但它不该越写越长------根规则保持短，展开说明放进对应文档，需要时再加载。
几条核心规则：
- 一轮只做一个小闭环：不顺手优化，不顺手重构，改完优先给改动摘要和验证结果
- 先找执行路径和最小改动面，再开始写：搞清楚怎么改之前，不要急着动手
这些规则没有一条看起来"高级"。但只要缺其中两三条，整个协作体验马上往下掉。
贴一份我目前探索的全局 AGENTS.md
md
## 范围控制
- 默认一轮会话只做一个小闭环。
- 先完成当前任务，不把"顺手优化"混入本轮。
- 不做未明确要求的重构，不改无关文件。
- 如果任务明显膨胀，先停下来说明原因，再继续。
## 执行方式
- 中等及以上任务，先复述目标、边界、方案和风险，再执行。
- 先找执行路径、相关文件和最小改动面，再开始修改。
- 优先复用现有模式，避免为了当前任务引入额外抽象。
- 需求不清且错误假设会造成明显返工时，先对齐，不硬做。
- 涉及较大行为变更、较大重构或高风险假设时，先对齐再改，不擅自推进。
- 不要只机械执行表面要求，要主动理解真正目标。
- 如果我给出的方案存在明显风险、局限或更优替代路径，要明确指出，并将"按要求执行"和"更优建议"分开表达。
## 输出方式
- 改完后优先给出：改动摘要、修改文件、验证结果、剩余风险。
- 默认简洁输出，不写长篇解释。
- 如果没法验证，直接说明，不模糊带过。
## Review
- 做 review 时，先看范围是否失控，再看行为、失败路径和测试缺口。三件事，彻底分开
以前我会把很多动作混在一起：边分析边改、边 review 边继续实现。表面流畅，实际容易失控。现在我把三件事硬拆开：
Plan：不是礼貌版开工，而是避免返工
如果执行路径还不清楚、改动可能跨模块、或者任务明显还没拆小，这时候最该做的不是"直接试试看"，而是先做 Plan。
Plan 阶段最重要的输出不是代码，而是三样东西：执行路径、最小改动面、主要风险。它解决的是别开错工。
审查：单独的一轮收口，不是暖场
只 review，不继续实现。重点看几件事：有没有改动越界、行为是否符合验收标准、失败路径有没有漏、测试是否只测了表面。它解决的是别带病交付。
多 agent：边界清楚时才加速，不是默认选项
很多人觉得任务一大，开几个 agent 就快了。真实情况通常相反------主问题没想清楚时，多 agent 只会把混乱复制好几份。只有主任务明确、子任务边界清楚且彼此独立时，并行才真的有意义。
一个简单的判断：
- 没想清楚怎么做 → 用 Plan
- 已有实现只想找问题 → 用审查
- 主任务明确、子任务可并行 → 再开多 agent
这条规则很朴素，但真的帮我省掉了大量无效对话。
验证会不会污染当前环境
这点以前我没太认真想过。默认让工具在当前工作区跑 build 和测试，看起来省事。但你只要多做几次，副作用就开始出现：缓存留下来了、临时文件留下来了、本来干净的工作区悄悄变脏了。
所以我现在的原则是：代码修改在当前工作区做，build 和实验性命令放到临时 worktree 或 /tmp 副本里跑。隔离成本明显过高时才例外。
一旦验证不再总是伴随"把现场弄乱"的代价，你会发现自己敢更频繁地验证------工作流整体也稳得多。
最后留下来的：小闭环
折腾到最后，我最认同的东西反而很朴素：不要把 Codex 当成一个可以一直聊下去的窗口，要把它放进一个稳定的小闭环。
我现在比较舒服的一轮，通常是这样的：
- 压缩目标：把任务压成一个明确的小目标，写清楚这轮不做什么、改哪些地方、怎么验收
- 先找路径：让它找执行路径和最小改动面，再开始实现
- 实现后看 diff：完成后立刻看改动范围，跑最小必要验证
- 单独审查，然后收口：做一轮独立审查，确认没有带病交付，然后结束这轮会话
这套东西一点都不性感，不像"神级 Prompt"那样让人兴奋，也不像"多 agent 并行"那样听起来很猛。
但真正让我效率稳定下来的，恰恰是这些不花哨的动作。
工欲善其事，必先利其器。我现在理解的"利其器"，不只是 Prompt 怎么写------而是规则、边界、验证、审查和收口这些结构有没有先搭起来。
这些东西一旦搭住，Codex 才是生产力；缺位了，它就只是一个"偶尔很好用、偶尔把你带偏"的聊天框。
注意：很多东西是和AI探讨出来的，更偏个人观点，也有很多需要改进与探索，大家参考即可，搭让自己用起来顺畅、懂你的 Agent 工具。
Github：github.com/HuiDBK/code...