大家好，我是某白。

上篇配好了 AGENTS.md，Codex 终于不乱动你的项目了。不乱改、不假设、问清楚、验证完再说完成——这四条刹车装好之后，你才敢把大任务交给它。

规矩有了。下一步，让它在规矩里跑得又快又稳。

我把最近几个月用 Codex 做过的任务翻了一遍——处理实验数据、写分析脚本、出论文图表、整理文献笔记——筛出十条对我协助最大的技巧。不是为了凑数。每一条都对应一个我踩过的坑。

一、上下文先给够，别让它用猜的

AGENTS.md 管的是长期不变的工作习惯。但具体到一个任务，你要给的是这一次的上下文。

任务越模糊，Codex 自由发挥的空间越大，翻车的概率也越大。列如你只说”帮我分析这份数据”——它不知道你的数据长什么样、实验目的是什么、最终要给谁看。它只能猜。猜的默认方向一般是”做一个完整的数据分析报告”，但你可能只想要一个相关性矩阵。

怎么做？三条。

把数据文件的路径贴给它。把数据的前几行和列名列出来。告知它你要什么结论，而不是要什么操作。

举个例子。我有一份 CSV，记录了三组不同处理条件下小鼠的体重变化。如果我写”分析一下”，它可能会做描述统计、画箱线图、跑 t 检验——然后给出一个我根本不需要的 15 页报告。

但如果我写：这份数据有三列：group（A/B/C），day（0/7/14），weight_g。先做正态性检验，如果通过就用单因素方差分析比较三组在 day14 的体重差异。输出一张箱线图、一张均值折线图和一份统计摘要。验证方式：统计量和 scipy 算出来的一致，允许小数点后两位的浮点误差。

这样它就不会多干活，也不会漏掉你真正需要的东西。

二、Goal 模式：给目标，不给指令

Codex 的 Goal 模式和普通对话的区别在哪？普通对话是你让它做一步它做一步。Goal 是你告知它终点在哪，让它自己规划路线。

好 Goal 有三个要素：要什么结果、什么时候算完、怎么验证。

缺了验证的 Goal 就是个愿望。你写”帮我把这个分析做完”，它可能跑了一堆操作然后告知你完成了——但你打开一看，输出格式不对，统计方法用错了，图表标签是英文的。

我自己的习惯是，Goal 的描述至少包含这三行：

• 要产出什么：文件列表，格式要求

• 停止条件：通过什么检查

• 验证方式：用什么命令或标准来确认

列如一个数据处理 Goal：

处理 data/raw/ 下所有 CSV，清洗后输出到 data/clean/。停止条件：所有文件清洗完成且通过完整性检查。验证方式：每个清洗后文件的列数、行数和原始文件一致（允许删除缺失值），且 python check_integrity.py 全部通过。

Goal 跑的时候你可以关掉屏幕去干别的。回来之后看验证结果就行。通过的不用管，没通过的看 log。

如果不知道验证写什么，从最简单的开始：让它跑完后自己写一个验证脚本，告知你通过了哪些、失败了哪些。

三、Thread 拆细，别让一个会话扛所有事

刚用 Codex 的时候我犯过一个错：所有任务扔到同一个 Thread 里。结果上下文越滚越长，Thread 开始犯糊涂——忘了之前的约定、重复做已经做过的事、答非所问。

后来我改了习惯。一个 Thread 只做一件事。做完就归档。

列如一次完整的数据分析，我拆成三个 Thread：

• Thread 1：数据清洗。读原始文件，处理缺失值，统一格式，输出清洗后数据

• Thread 2：统计分析。读清洗后数据，做假设检验，输出统计结果

• Thread 3：可视化。读统计结果，画图，调样式，输出最终图表

拆开的好处是：每个 Thread 上下文干净，Codex 不会把前面任务的细节带到后面来。Thread 2 翻车了，不影响 Thread 3。改图表样式也不用重跑整个分析。

四、工具权限开到刚好，别给多余的

Codex 能做的事许多：读写文件、跑终端命令、访问网络、操作浏览器。但不是每个任务都需要全部权限。

我的规则很简单：任务需要什么开什么，不需要的关掉。分析本地数据就不开网络权限。只改代码就不开 Computer Use。尤其是跑不熟悉的脚本或者处理敏感数据的时候，关掉终端执行权限，先让它把方案写出来给你审，审完再开。

这一步花不了十秒钟，但能拦住许多意外。列如你让它”查一下这个包的最新文档”，它开了浏览器自己去搜——但你实则只是想让它看看已经下载到本地的文档。权限开大了，它就自己发挥去了。

五、让它先读，别急着让它动手

Codex 拿到一个任务之后，默认会直接进入”做”的状态。但许多时候你需要的，是它先告知你”我看到了什么”。

我目前几乎养成了习惯：任何涉及读取文件的任务，第一句话必定是”先读这个文件，告知我你看到了什么”。让它列出文件结构、数据维度、关键字段、潜在问题。等它确认完了，我再让它改。

这一步帮我看住了至少三次大坑。一次是它把一个 3GB 的 CSV 当成小文件直接读到内存里，机器卡了五分钟。一次是它把日期列的格式当成字符串而不是 datetime，后续分析全偏了。如果我先让它读再确认，这两次都不会发生。

科研数据处理里这个习惯尤其重大。你的数据可能有隐藏的编码问题、空行、特殊分隔符。Codex 默认会按”标准情况”去理解。但你让它先读一遍、汇报一遍，它才会注意到那些异常。

六、多试几遍，别信第一次的结果

同样的 Prompt，Codex 每次跑的路径可能不一样。第一次它可能选了一个偏复杂的方法，第二次简化了，第三次刚好。

我目前遇到重大任务，会同时开三个新 Thread，贴同样的上下文和需求，让它们各自跑一遍。然后对比输出：哪个结果最接近预期、哪个方法最稳定、哪个出错最少。选最好的那个作为正式方案。

这个过程多花一些 token，但省了返工的时间。对需要准确结果的科研分析来说，一次跑通不代表每次都跑通。

七、Side Panel + 浏览器 + Computer Use：手伸到代码之外

Codex 不只会写代码。它能做的事比你直觉里多一截。

Side Panel 被严重低估了。你让它生成一个 HTML 报表或者 PPT，它会直接在对话框旁边的面板渲染出来。你一边看一边说”这个表格太宽了””第三张图颜色太暗”，不用截图，不用切窗口。我做完数据分析之后常常让它直接在 Side Panel 里出一个交互式 HTML 报告，实验组和对照组的对比一目了然，改样式的同时就能看到效果。

浏览器插件适合查文档和爬数据。代码里用到的库出了新版本，让它打开官方文档看一眼变更日志，直接把受影响的部分标出来。需要从实验室管理系统批量下载数据文件的时候，告知它网址和操作步骤，它在浏览器里点完帮你存到本地——你看着就行。

Computer Use 处理那些只有图形界面的操作。有些实验室的管理系统还是纯网页表单，没有 API。填几十个样本的信息，手工要半天。让 Codex 打开页面，填表，提交，重复。你去喝杯咖啡。

八、Skills：把你的重复劳动变成自动化

用 Codex 一两个月之后，你会发现有些操作你在反复做。每次都开新 Thread，每次都要贴一样的上下文，每次都要踩差不多的坑。

Skills 就是用来消灭这些重复的。

Skill 不是一个提示词模板。它是带着踩坑记录和验证方式的工作流文件。Codex 加载一个 Skill 之后，不需要你重新交代背景，它就知道怎么做、怎么验证、什么坑不要踩。

怎么开始？最快的方式是让 Codex 自己帮你做。

打开 Codex 设置 → 个性化 → 记忆 → 启用记忆。这个功能会记录你在 Codex 里的操作模式。开了一段时间之后，发一句：

「查看我的记忆，找出我多次重复的工作流程，将它们转化为技能。」

Codex 会扫你的历史会话，把重复出现的操作模式提炼成 Skill。我第一次跑这句，它给我整出了三个：文献笔记整理、实验数据清洗管道、公众号文章排版。

如果你不想等记忆积累，也可以手动创建一个 Skill。在 Codex 里跟它说：我想创建一个 Skill，做的事情是 X，步骤如下 A → B → C，常见的坑是 Y。它会帮你生成 Skill 文件放到 ~/.codex/skills/ 目录下。

科研场景里，有三种东西特别适合做成 Skill：

• 数据清洗流水线。每次拿到新实验数据，都要走一遍：读文件、检查列名、处理缺失值、统一格式、输出清洗报告。做成 Skill 之后，下次把文件路径丢给它就完事。

• 实验日志格式化。每次跑完实验都要记录：日期、参数、结果摘要、异常情况。做成 Skill，给它原始数据，它按固定模板输出日志。

• 文献笔记整理。读一篇论文的 PDF，提取方法、结果、局限性，按固定格式存到你的笔记系统里。

Skill 写好之后不是死的。你每次用它，发现新的坑，就补进去。用久了它会越来越准。

九、Skill 跑偏了怎么修

Skill 本质上是一个 Markdown 文件，放在 ~/.codex/skills/ 目录下。跑偏了，三种修法。

打开文件直接改。如果你知道自己想加什么规则，直接编辑 SKILL.md，加一条”注意事项”就行。列如原来的数据清洗 Skill 没有处理日期格式，你加一句”日期列如果有 MM/DD/YYYY 和 YYYY-MM-DD 混用的，统一转成 ISO 格式”。

让 Codex 读了反馈后重写。跟它说”上次用这个 Skill 的时候，第 X 步出了问题，缘由是 Y。帮我把这个坑补进 Skill 里”。它会读完现有 Skill，把反馈整合进去。

版本管理：Skill 文件用 Git 管起来。每次大改之前 commit 一次，改坏了可以回退。这个习惯比想象中重大——Skill 是你工作流的代码，应该有版本记录。

更新还是新建？经验是：小调整（加一条规则、改一个参数）直接更新原 Skill。大逻辑变了（列如从 pandas 换到 polars），新建一个 Skill，保留旧的留着参考。

十、每半小时 checkpoint，别等崩了再后悔

长任务是 Codex 最危险的场景。不是由于它做不好，而是由于上下文会不知不觉堆到爆。

我跑过一个数据分析任务，从下午跑到晚上。中间一切正常。结果最后一次验证失败，Codex 开始反复修改同一个函数——改完跑测试，测试不过，再改，再跑。循环了七次之后上下文满了，整个 Thread 崩掉，前面的工作全丢。

从那之后我定了个规矩：长任务每半小时 checkpoint 一次。

具体操作很简单。让 Codex 每跑一段时间就做两件事：git commit 当前的修改，写一句进度摘要到 progress.md 。如果崩了，开新 Thread，让它读 progress.md 和最后一次 commit，接着来。

上下文太长的时候还有一个技巧：让 Codex 自己给自己写 handoff 文档。告知它”把当前进度、已完成的部分、下一步计划写成一个交接文档，存到 handoff.md”。然后开新 Thread，第一句就是”读 handoff.md，接着做”。

官方的 Memory 可以当快速回忆层用。但真正靠得住的还是你文件系统里的那些 .md 文件。它们不会被压缩、不会被遗忘、不会由于换 Thread 丢失。

长时间跑的 Goal，还有一个容易漏的东西：止损条件。

Goal 模式如果没有刹车，就像一个没有方向盘的车。方向偏了停不下来，只能看着它越跑越远。常见的翻车是同一个错误反复重试——改一次，报错，再改，再报错，循环。Token 烧了，时间没了，问题没解决。

我的 Goal 描述里都会带这么一句：“如果同一个错误重试三次还没解决，停下来把日志汇总给我。不要自己猜缘由继续改。”

另一个是审查点。长任务不是一口气从 A 跑到 Z。在关键的中间步骤设断点，等你确认了再往下走。“清洗完之后先列出各文件的异常值数量，我过一遍再进入统计环节。”这一分钟的审查，换接下来半小时不白跑。

最后

十条技巧讲完了。回头一看，它们实则都在讲同一件事：

Codex 是好用的，但不是“设完就不用管了”。你得给它规则，给它验证，给它止损条件。你用规则训练它，它才能配合你。

这个过程一开始会觉得麻烦——写 AGENTS.md、设审查点、做 checkpoint，都是额外的工作。但做了几次之后你会发现，这些“额外工作”省的，是你后面追着 AI 收拾残局的时间。

好用的 AI 搭档不是买来的，是驯出来的。

下一篇聊怎么把 Codex 接进真实的工作流里：MCP 连接外部工具、自动化定时任务、手机端随时接手。这些是让 Codex 从”干活”变成”不用管的自动运转”的最后一步。

如果觉得有用，随手点个赞、在看、转发三连吧，也方便更多朋友看到。如果想第一时间收到推送，也可以给我个星标。

有什么好的想法或者意见，在评论区和我聊聊吧。