我现在最推荐的 Codex 工作流是：
读上下文 → 写计划 → 确认范围 → 小步实现 → 跑验证 → 总结结果 → /new
如何有效使用，最近用 Codex 做了一些研究导向的代码工作，包括论文复现、读高质量 repo、整理实验逻辑、改课程项目里的功能。 我现在更愿意把它当成一个项目协作者。下面是总结出的一些使用经验：
第一条：别一上来就让它写代码
尤其是论文复现、课程项目、陌生 repo 这种场景，第一步应该是让它读项目。
可以直接这样说：
先不要修改代码。请先阅读这个项目，告诉我：1. 项目结构是什么2. 主要入口在哪里3. 训练/测试/运行命令分别是什么4. 哪些文件最可能和当前任务有关5. 你不确定的地方有哪些
这一步看起来慢，其实很省时间。很多翻车都是因为 Codex 一开始就带着错误假设开干，后面越改越复杂。
第二条：AGENTS.md 不要写成项目介绍
AGENTS.md 更适合写“长期规则”，不是写“这次我要你做什么”。比如：
## 工作规则- 默认先阅读相关代码和文档，再开始修改。- 修改前先说明影响范围。- 只做和当前任务相关的最小改动。- 提交前必须运行最小验证。- 说明用中文，代码、命令、文件名保持英文。- 不要修改无关文件。
如果是论文复现类项目，可以加一条：
# 实验原则实验必须服务于明确假设或决策。不要为了补齐表格而穷举低价值 ablation。
如果一个方向已经明显无效，先总结证据，再询问是否继续。
这个真的很重要。Codex 有时候会特别喜欢“把实验补完整”，但很多实验只是看起来完整，实际没有信息增益。
第三条：复杂任务一定先 Plan
我现在只要任务超过一个文件，都会先让它出计划。
先不要写代码。请进入计划模式，帮我设计实现方案：1. 明确这次要解决的问题2. 列出会影响哪些模块3. 拆成 3-7 个步骤4. 每一步怎么验证5. 哪些地方最容易出错等我确认后再开始实现
这样做的好处是，你能提前发现它有没有理解错需求。很多时候，Codex 写代码前的计划比代码本身更有价值。
第四条：研究任务要让它先查证，不要让它凭印象说
比如你让它复现一篇论文，或者解释一个开源 repo，不要直接问“帮我复现”。更好的方式是：
请先阅读论文和官方 repo，不要开始写代码。先输出：1. 论文核心 idea2. 关键公式/模块3. 官方实现和论文描述是否一致4. 复现最小路径5. 可能复现不出来的风险点
Codex 很适合做这种“读论文 + 看 repo + 整理实现路径”的工作。前提是你要明确告诉它：先读，先对齐，先列风险，再动手。
第五条：做完一个任务就开新会话
长会话很容易积累旧假设。尤其是一个功能改完以后，继续在同一个上下文里做新功能，Codex 可能会带着上一个任务的判断继续思考。
我的习惯是：
请用一句话总结刚完成的任务、修改过的文件、当前状态和下一步注意事项。然后 /new，在新会话里贴这个总结，再开始下一个任务。
这个动作很小，但会明显减少“旧问题污染新任务”。
第六条：不要完全相信它说“完成了”
我现在每次都会要求它最后输出：
请最后给我：
1. 修改了哪些文件2. 每个文件为什么改3. 运行了哪些验证4. 还有哪些没验证5. 哪些地方需要我人工确认
总结一下：真正让 Codex 稳定的，不是某一句神奇 prompt，而是你给它足够清楚的上下文、长期规则和验收标准。
