三个月前，我第一次打开 Codex 的时候，主要把它当成代码助手：写几行 Python、改一个报错、解释一段脚本。
三个月后，我更愿意把它看成一个科研工作流助手。它不只是回答问题，而是可以帮我整理文献、处理文件、生成初稿、跑命令、记录经验，再把结果交给我复核。
真正让我明显提效的，也不是某一个神奇提示词，而是一组可重复的使用习惯。
这篇文章整理 6 个我现在仍在用的技巧。它们不追求夸张效果，也不承诺适合所有人；更准确地说，它们适合想把 Codex 用进日常科研流程的人。
先看这张总览图：它把 6 个技巧放到同一条科研辅助链路里。
先搭好工作流，再谈单个技巧；否则提效很容易只停留在感觉上。
先说结论：技巧不是越多越好，而是越稳定越好
Codex 最容易被低估的地方，不是能不能写代码，而是能不能和你的工作习惯长期配合。
如果每次都从零解释背景，它只能做一次性回答。如果你把研究背景、项目结构、常用工具、历史经验和检查清单都沉淀下来，它就更容易参与连续任务。
所以这 6 个技巧背后的共同逻辑是：让 Codex 少猜一点，让流程多记一点，让人最后多检查一点。
AI 工具可以加速科研流程，但不能替代研究判断。越接近结论、统计和投稿，越需要人工复核。
技巧一：用自定义指令记住项目背景
自定义指令最适合存放“每次都要重复说明”的背景。
比如你的研究方向、常用语言、常见数据格式、偏好的输出方式、代码注释风格，以及不希望它越界处理的内容。这样每次开始新对话时，Codex 都能先带着基本上下文理解任务。
我会把自定义指令控制在很短的范围内。一个可参考的写法是：
我是一名生物信息学研究者，主要处理单细胞组学和空间转录组学数据。常用 Python 和 R 做分析，用 Zotero 管理文献。回答时请先给结论，再给步骤；写代码时优先考虑可复现性，并用中文解释关键参数。
这类指令的价值在于减少沟通成本。
以前我让它写差异表达分析脚本，它可能先给一个很通用的模板。现在我会先告诉它项目背景、数据格式和预期输出，它更容易给出贴近项目的初稿。
下面这张图可以作为自定义指令的拆分模板。
越短越稳定，越具体越好用；建议控制在核心背景范围内。
技巧二：用 Agent 模式并行处理互不依赖的任务
Agent 模式适合目标明确、可检查、步骤相对清楚的任务。
它可以自己规划步骤、读取文件、运行命令、根据错误调整方案，再把结果交给你验收。真正好用的地方，是把“你等它做完一件事”的时间，变成“多个任务各自推进”的时间。
但并行有前提：任务之间不能互相依赖。
比如一个窗口整理文献摘要，一个窗口跑数据初筛，一个窗口润色论文的某个段落，这三件事可以并行。可如果论文段落要依赖数据分析结果，那就应该先做分析，再做写作。
我的经验是，并行任务要写清楚三件事：
- 目标是什么；
- 输入文件在哪里；
- 完成后怎么验收。
下面这张流程图提醒自己：并行不是越多越好，而是要能独立推进。
互不依赖才并行；需要前置结果的任务应当串行推进。
技巧三：用 MCP 连接外部工具，但只开放必要权限
MCP 可以把 Codex 和外部工具连接起来。
对科研工作来说，常见价值是让它读取文献库、访问项目文件、检查代码仓库、整理结果文件，或者在受控范围内辅助操作浏览器和数据库。
这里最重要的不是“能连多少工具”，而是“权限边界是否清楚”。
我会优先把 MCP 用在低风险、可复核的环节。比如读取 Zotero 里的候选文献、整理项目目录、生成引用清单、检查文件是否存在。涉及凭据、删除文件、改数据库、批量写入仓库时，一定要单独确认。
配置 MCP 时，不建议直接复制来路不明的包名、命令或脚本。更稳妥的做法是以官方文档或可信开源项目说明为准，并且只授权当前任务需要的目录和工具。
下面这张图把 MCP 的位置放得更清楚：它是受控连接层，不是无限权限入口。
只授权必要范围；凭据、写操作和删除操作必须单独复核。
技巧四：用模板快速启动新项目
科研项目里有大量重复初始化工作。
比如创建文件夹结构、准备 README、放置分析脚本模板、配置依赖文件、建立输出目录、写日志规范。手动做当然可以，但越熟悉的流程越容易漏小步骤。
我会为常见项目准备一个模板文件夹。
模板里不放真实数据，也不放敏感信息，只放标准结构、空白说明、示例配置和初始化脚本。新项目开始时，让 Codex 按模板复制结构，再替换项目名、路径和说明。
这样做的好处不是“省几分钟”，而是减少隐性错误。
比如项目名没有替换干净、输出目录没有创建、依赖版本没有记录，这些问题早期看起来很小，后面可能会影响复现和协作。
下面这张图把模板启动流程拆成 5 个检查点。
模板要定期维护；过期模板会把旧问题复制到新项目里。
技巧五：用对话历史沉淀知识库
对话历史不只是聊天记录，它可以变成知识库的原料。
每次完成一个重要任务后，我会让 Codex 帮我总结本次任务的关键内容：目标、输入、处理步骤、关键代码、遇到的问题、解决方式，以及下次可以复用的经验。
这些内容可以保存成 Markdown 文件，按项目、方法或问题类型归档。
下次遇到类似任务时，不需要重新问一遍。可以先让 Codex 搜索已有记录，再基于旧方案生成新版本。这样做比单纯依赖记忆更稳，也更方便复盘。
不过，知识库不能什么都存。
真实样本信息、个人信息、访问凭据、未核实的结论、审稿相关敏感内容，都应该删除或脱敏。能长期保存的，应该是方法、流程、踩坑记录和复核结论。
下面这张图展示了“任务完成后再沉淀”的循环。
知识库要去除隐私、凭据和未经核实的结论，再长期保存。
技巧六：用检查清单避免低级错误
科研工作里，最让人崩溃的往往不是难题，而是低级错误。
路径写错、样本分组表没更新、参考版本不一致、统计方法选错、结果文件没保存，这些问题都很常见。它们不是能力问题，而是注意力会波动。
我的做法是在每个项目根目录放一个 CHECKLIST.md。
这个文件不需要复杂，先写最容易出错的 5 到 10 项就够了。每次跑完分析、整理完结果或准备交付前，让 Codex 按清单逐项检查，并把不确定项列出来。
一个 RNA-seq 项目的清单可以包括：
- 原始数据路径是否正确；
- 参考基因组版本是否匹配；
- 样本分组信息是否完整；
- 多重假设检验是否做了 FDR 校正；
- 图表、表格和日志是否全部保存。
检查清单的价值会随着项目推进不断增加。
每犯一次新错误，就把它加入清单。下一次 Codex 检查时，它就能帮你把同类问题提前拦下来。
下面这张卡片可以作为清单的起点。
每犯一次新错误，就把它加入清单；清单会越来越像你的经验系统。
把 6 个技巧串成一条流程
单个技巧有用，但组合起来才更稳定。
我的实际流程通常是这样：
- 用自定义指令提供长期背景；
- 用模板启动项目结构；
- 用 MCP 连接必要工具；
- 用 Agent 拆分低风险任务；
- 用对话总结沉淀知识库；
- 用检查清单做最终验收。
这条流程的核心不是让 Codex “完全替你做科研”，而是把重复、琐碎、可复核的部分交给它，把判断、取舍和最终结论留给人。
下面这张总结图适合放在文章结尾前，帮助读者把 6 个技巧连起来。
先让系统更懂你，再让流程帮你少犯错。
总结
用了三个月之后，我最大的感受是：Codex 的价值不只在“会不会回答”，更在“能不能进入你的流程”。
自定义指令解决背景重复说明的问题，Agent 并行解决等待问题，MCP 解决工具割裂问题，模板解决重复初始化问题，知识库解决经验流失问题，检查清单解决低级错误问题。
这些技巧都不复杂，但它们有一个共同点：把一次性的对话，变成可复用的系统。
如果你也在用 Codex 做科研，不妨先从一个小项目开始。不要一上来就让它处理最高风险的任务，先让它帮你整理文件、生成初稿、建立清单，再逐步进入更复杂的流程。
有自己的 Codex 使用经验，也欢迎在评论区交流。尤其是文献管理、数据分析、论文写作和项目模板这几类场景，很值得互相借鉴。
