Codex 名字里带着“Code”，很容易让人把它当成代码生成器。

但在科研工作中，写代码只是其中一环。

阅读陌生代码库、核对论文方法、整理实验文件、记录验证结果，同样会消耗大量时间。这些杂货，也很适合让Codex来做。

这篇文章是我总结的一些经验。有些是反直觉的认知转变，有些是意料之外的用法。没有”你必定要学”的说教，只有”我试过了，这样的确 更省事”的记录。

一、先读再写：慢就是快

最初我用 Codex 的方式很粗暴：打开项目，劈头盖脸让它改。

翻车率大致一半。

后来养成了一个习惯：不管多着急，第一步永远是让它先读项目，先理解，先对齐。哪怕只是复现一篇论文里的方法，也让它先把 repo 结构和论文内容读一遍，出一个结构报告。

我目前的标准开场白是这样的：

暂时不要修改文件。

请先阅读项目说明和相关代码，并回答：
1. 项目的主要入口在哪里；
2. 哪些文件与当前任务直接相关；
3. 现有测试和运行命令是什么；
4. 你还缺少哪些信息；
5. 提议从哪一步开始。


这步看起来慢，实则省掉了后面大量的纠错时间。Codex 一开始就带着错误假设开干的破坏力，跟一个不懂项目的新同事直接上手改代码差不多。 
这个习惯后来被我延伸到了另外一个场景：  深度文献解析 。
以前读论文，最费时间的往往不是读完全文，而是把文章拆清楚。一篇论文用了什么数据、方法怎么设计的、每张图到底支撑哪个结论、这篇文章的创新点和局限分别在哪。如果只靠人工逐段整理，读完之后真正可复用的信息散落在笔记各处，写综述或设计实验时又得重新翻原文。 
我后来搭了一个固定流程。把一篇 PDF 扔进 Codex 项目文件夹，让它按五个模块出报告：文献信息与摘要、数据来源与分析方法、主要结果与证据链、图表逐图解释、创新性与局限性。每篇论文最终只生成一份 Markdown 文件。 
拿最近 Nature 上那篇 Computational design of metallohydrolases 来说。David Baker 组用计算设计做了金属水解酶。把 PDF 丢给 Codex 之后，它先提取了论文骨架：核心问题是”能不能从头设计具有金属催化活性的蛋白”，关键方法是 Rosetta 骨架设计加活性位点匹配。然后它把数据部分拆出来：训练集怎么构建的、设计流程分几步、每步用了什么筛选标准。接着把结果逐条对应到图表：Figure 2 展示的是设计结构跟天然结构的对比，Figure 4 是酶活测定数据。最后列出作者声明的局限性：某些设计的催化效率还远低于天然酶。 
以前读这样一篇论文要精读一两个小时，再做笔记。目前 Codex 先把骨架拆好，我只需要复核数据准确性和图表细节。二十分钟就够了。 
后来这成了我的固定用法。遇到需要深度理解的关键论文，先让 Codex 出结构报告，我再决定精读哪些部分。 

 二、AGENTS.md 不是写需求的，是写规则的 
刚用 Codex 的时候，我把 AGENTS.md 当成了”这次要做什么”的需求文档。每次新项目，往里塞一堆任务描述。 
完全用错了。 
AGENTS.md 真正适合放的是长期规则，不是临时需求。具体任务在对话里说就行，AGENTS.md 管的是”每次都该遵守的事”。 
我目前每个项目里固定放的规则： 
## 工作规则

- 修改前先说明影响范围
- 只处理与当前任务直接相关的文件
- 未经确认不要增加生产依赖
- 修改业务逻辑后运行对应验证
- 完成时列出修改文件和测试结果
- 说明用中文，代码和命令保持原格式无关文件


如果是论文复现类的项目，再加一条： 
## 实验规则

- 处理数据前确认输入格式、单位和缺失值
- 实验必须回答明确问题
- 方向已经显示无效时，先总结证据
- 不要为了补齐表格增加低价值实验


这条救过我许多次。Codex 有时候会执着于”把实验做完整”，但许多实验只是看起来完整，没有信息增益。规则挡在前面，token 和时间都省了。 
这个习惯扩展到另一个场景：  实验数据处理 。
我常常需要处理高通量分子性质预测的数据：几万个分子的 SMILES、实验值、不同来源的描述符，格式五花八门。以前是自己写 Python 脚本一个一个适配。后来我在 AGENTS.md 里加了一条：”处理数据前先确认格式和字段含义，列出假设，等我确认再批量处理。” 
然后直接把原始输出目录扔给 Codex。它会先扫一遍文件结构，识别格式，列出它的假设（列如”logP 这一列的缺失值我暂时用中位数填充，但需要你确认”），等我确认，再批量清洗、转换、画图。从原始输出到可用的 DataFrame 加趋势图，一条消息的事。 
以前这种事我得写一下午脚本。目前它写，我检查。 

 三、复杂任务先写计划：计划比代码更有价值 
这个经验是硬磕出来的。 
有次改一个蛋白-配体相互作用预测的机器学习流程，涉及特征工程、模型训练、超参数搜索和结果验证四个模块。我上来就让 Codex 改，结果改了东边西边崩，修了西边东边又出问题。 
最后让它停下来，出了一份计划。 
计划里它自己就指出了三个风险点。更关键的是，它列出的”会影响哪些模块”跟我脑子里想的不完全一样。有一个我漏掉的依赖关系，它在计划阶段就标记出来了。 
从那后来，涉及两个文件以上的任务，我必定先让它出计划。 
我目前的标准 prompt： 
先不要写代码。
请进入计划模式，帮我设计实现方案：
- 明确要解决的问题
- 列出受影响模块
- 拆成 3-7 个步骤
- 每步怎么验证
- 哪些地方最容易出错
- 等我确认后再开始。


许多时候，Codex 写代码前的计划比代码本身更有价值。计划错了改两句话，代码错了是连锁反应。 
这个思路反过来也成立：如果一个任务你脑子里已经有清晰的方案了，直接说就行，不用走计划流程。好钢用在刀刃上。 

 四、科研任务先查证，别让它凭印象说 
如果你让 Codex 复现一篇论文，不要说”帮我复现这篇”。 
它可能凭训练数据里的印象就开始写代码了。但论文和代码之间常常有出入。公式写的是 A，代码实现的是 B，或者论文省略了关键预处理步骤。 
更好的方式： 
请先核对论文和官方代码库，不要开始编程。

请分别列出：
- 论文中的核心方法和关键条件；
- 代码中的对应模块；
- 两者一致与不一致的地方；
- 最小复现路径；
- 当前无法确认的风险。


让它先做”文献调研 + 代码审查”，把不一致的地方提前标出来。对齐之后，再动手复现。 
这个”先查证”的原则，延伸到了另一类场景：  写周报和进度汇报 。
听起来不像科研工具该干的活，但实际很实用。到了周五，把这一周的聊天记录、提交记录、实验日志扔给 Codex，让它自己翻一遍，然后输出一份结构化的周报。不用你再回忆”这周到底干了啥”。 
我不是在偷懒。我是在把”回忆+整理+排版”这种机械劳动外包出去，把脑力留给真正需要判断的事。 

 五、做完就 /new，别让旧问题污染新任务 
长会话最大的隐患不是爆上下文，是积累旧假设。 
一个功能改完后来，继续在同一个会话里做新功能，Codex 可能会带着上一个任务里的判断继续思考。你改过又回退的代码、讨论过又放弃的方案、已经过时的前提，全残留在上下文里。 
我目前养成了一个固定动作：每完成一个独立任务，让 Codex 用一段话总结做了什么、改了哪些文件、当前状态、下一步注意事项。然后 /new，在新会话贴这段总结，再开始下一个任务。 
这个动作很小，但”旧问题污染新任务”的概率明显降了。 
同理，如果任务进行中突然想换方向或讨论方案，我也不会在原线程里聊。新开一个 side chat，讨论清楚了，把结论整理成执行指令发回主线程。Codex 支持 @ 引用其他对话，连复制粘贴都省了。 
主线程负责执行，side chat 负责思考。各管各的上下文。 

 六、不要完全信任它说”完成了” 
Codex 说”完成了”的时候，我目前的第一反应是：验证呢？ 
它有时候会跳过验证，或者跑了验证但没告知你跑了什么、哪部分没跑。不是它故意，是它的系统提示词里没写”必须汇报验证细节”。 
所以我加了一条强制要求。每个任务收尾时，让它输出： 
请给我： 


修改了哪些文件 


每个文件为什么改 


运行了哪些验证 


还有哪些没验证 


哪些地方需要我人工确认 


这五条让你在几分钟内就能判断：能不能信它说的”完成了”。大部分时候可以。偶尔你会发现，它的确   改对了，但有一处边界条件没测。你补一下就行。 

最后一条经验延伸到一个场景：  PPT 和海报生成 。
组会前赶 PPT 是每个研究生的必修课。一般的方式是开 PowerPoint 一张张拼，目前直接把论文、数据图和结构大纲扔给 Codex，说清楚需要几页、每页讲什么、用什么风格的图，它一口气生成全部内容。 
当然，生成的初稿不能直接用。格式要调，图要换，措辞要改。但它帮你把最耗时的”从零到一”跳过去了。剩下的调整，比从头做起快得多。 
还有一个让我意外的用法：  研究 Idea 的生成和筛选 。遇到一个新方向，我会先把 8-10 篇相关论文扔进一个项目，让 Codex 分别总结每篇的核心贡献和方法局限。总结完之后，让它基于这些文献之间的空白，生成 3-5 个可验证的研究想法，每个想法附上：


它来自哪些文献证据； 


准备验证什么假设； 


最小实验怎样设计； 


需要哪些数据和工具； 


哪些条件可能让想法不成立。 


。这些想法不必定靠谱，但它们提供了一张”可能值得做”的地图。我自己判断哪个方向有戏，再往下走。 
 总结 
回头看半年，Codex 帮我省下的时间，大头不在”写代码”，而在写代码之外的东西。 
文献调研、数据清洗、周报汇报、PPT 制作、方案设计、代码审查。这些事以前分布在不同的工具和流程里，目前一个人加一个终端窗口，大部分能串起来。 
六条经验总结成一段话：先读后写，先 Plan 再动手，规则放 AGENTS.md，需求在对话里说，科研任务先查证，做完就 /new，别说”完成了”就信。 
科研人使用 Codex，可以按下面的顺序推进： 
读材料
→ 确认任务范围
→ 写计划
→ 小步修改
→ 运行验证
→ 保存交接状态
→ 开启下一项任务


不是哪一句神奇 prompt 让它变强了。是你给了它清楚的上下文、长期规则和验收标准，它才从”能用的工具”变成了”靠得住的协作者”。 
如果觉得有用，随手点个赞、在看、转发三连吧，也方便更多朋友看到。如果想第一时间收到推送，也可以给我个星标。 
有什么好的想法或者意见，在评论区和我聊聊吧。