我用 Codex 做研究后，总结出 6 条有用经验！

文章主旨：高效使用 Codex 的关键在于将其视为项目协作者，通过“读上下文→写计划→确认范围→小步实现→跑验证→总结结果”的结构化工作流，提前对齐需求、设定长期规则，避免无效探索和错误假设，从而提升代码生成与研究的可靠性。

关键要点：

• 第一步应让 Codex 先阅读项目结构，而非直接写代码，避免错误假设。
• AGENTS.md 适合写入长期工作规则（如“先阅读再修改”“最小改动”），而非临时任务说明。
• 复杂任务必须要求 Codex 先输出实现计划，明确步骤、影响范围和验证方式，待确认后再动手。
• 研究任务应让 Codex 先查证论文或 repo，输出核心 idea、关键模块、复现路径与风险点。
• 完成一个任务后，用 /new 开启新会话，防止旧假设干扰新任务。
• 每次完成后要求 Codex 输出修改文件列表、改动理由、验证结果及待人工确认项，避免盲目信任。

内容结构：

前言：推荐 Codex 工作流为：读上下文 → 写计划 → 确认范围 → 小步实现 → 跑验证 → 总结结果 → /new。作者将其视为项目协作者，总结出以下经验。

第一条：别一上来就让它写代码。 应先阅读项目，了解结构、入口、命令及不确定点，避免带着错误假设开始。

第二条：AGENTS.md 不要写成项目介绍。 应写入长期规则，如默认先阅读、修改前说明影响、最小改动、运行验证、中文说明（代码/命令保留英文）等。实验原则：实验服务于明确假设，避免低价值穷举。

第三条：复杂任务一定先 Plan。 要求 Codex 进入计划模式，输出要解决的问题、影响模块、拆解步骤、验证方式、易错点，确认后再实现。计划往往比代码本身更有价值。

第四条：研究任务要让它先查证，不要凭印象说。 要求 Codex 先阅读论文和官方 repo，输出核心 idea、关键公式/模块、实现一致性、最小复现路径及风险点。

第五条：做完一个任务就开新会话。 用一句话总结刚刚完成的任务、修改文件、状态和注意事项，然后 /new 开启新会话，减少“旧问题污染新任务”。

第六条：不要完全相信它说“完成了”。 要求输出修改了哪些文件、为什么改、运行了哪些验证、未验证项、需人工确认项。

总结： 真正让 Codex 稳定的，不是某句神奇 prompt，而是给它足够清楚的上下文、长期规则和验收标准。

文章总结： 本文提供了一套系统化、可落地的 Codex 使用方法论，强调“先对齐、再动手、勤验证、常总结”，将 AI 从代码生成工具转化为可靠的项目协作者，适合科研复现、课程项目、代码维护等场景。

敏捷宣言最误人

了解更多

Datawhale

查看原文：我用 Codex 做研究后，总结出 6 条有用经验！

文章来源：

Datawhale

扫码关注公众号