夜雨聆风项目来源
最近一段时间，我使用 Codex 的频率越来越高。
最开始我对它的理解很简单：这不就是一个放在终端里的 ChatGPT 吗？区别可能只是它能看文件、能改代码、能运行命令，权限比网页端更大一点。
但真正使用了一段时间后，我发现这个理解是不准确的。
Codex 不是一个更会聊天的 AI，也不是一个单纯帮你写代码的工具。它更像是一个“执行型助手”，适合接手那些目标明确、路径清楚、文件很多、需要反复测试和修改的任务。
它的优势不在于替代人做所有判断，而在于当你已经把事情想明白以后，它可以极大地放大你的执行能力。
这也是我这段时间最大的体会：「Codex 用得好不好，关键不在于 Codex 本身有多聪明，而在于你有没有把任务拆成它能够执行的形式。」
一、Codex 适合做执行性任务，计划越详尽越好
目前我对 Codex 的定位比较明确： 它非常适合做执行性任务，但不适合让它完全从零开始替你决定一个项目应该怎么做。
比如安装软件、整理文件、批量处理数据、修改项目代码、生成脚本、跑测试、修复报错、批量下载文献、读取本地文件、筛选材料等，这些任务交给 Codex 是非常合适的。
但如果你直接给它一句很笼统的话，比如：
帮我把这个项目做好。
或者：
帮我写一篇高质量论文。
它通常也会开始做，但做出来的东西大概率会比较平庸，甚至可能跑偏。
原因很简单，Codex 虽然能执行，但它并不知道你真正想要的“好”是什么。对它来说，只要任务能够完成，文件能够生成，代码能够运行，它就会倾向于认为事情已经结束。
但对人来说，一个项目真正重要的往往不是“有没有做完”，而是：
这个方案是不是符合研究目的； 这个结果是不是能支撑文章结论； 这个实现方式是不是稳健； 这个文件结构后续是不是方便维护； 这个结果会不会有假阳性、假阴性或解释不清的问题。
这些东西如果一开始不写清楚，Codex 很难自动替你补全。
所以我现在使用 Codex 前，最重要的一步不是让它立刻开始执行，而是先制定一个尽量详细的计划。这个计划可以是agent.md、plan.md、protocol.md或者其他名字，核心是让它成为后续执行任务的根本依据。
一个好的计划至少应该写清楚几件事：
这次任务的目标是什么； 输入文件在哪里； 输出文件应该放在哪里； 每一步要做什么； 哪些事情可以自动执行，哪些事情必须先汇报； 最终如何验收结果； 出错时应该如何处理； 不允许它做哪些事情。
我现在越来越觉得，使用 Codex 的过程其实很像带一个执行力很强但需要明确管理的学生。你不能只说“你去把这个做了”，而要告诉它“做成什么样算合格，什么情况需要停下来问我，什么情况可以自己修”。
计划越详尽，Codex 的表现就越稳定。 计划越模糊，它就越容易进入一种“看似努力，实际跑偏”的状态。
二、搭建 ChatGPT-Codex 工作流，而不是只使用单个工具
我现在比较推荐的一种方式是：「ChatGPT 做决策和计划，Codex 做执行和汇报。」
这其实是两个工具能力差异决定的。
ChatGPT 更适合用来做总体判断。比如判断一个研究方案是否合理、一个论文结构是否成立、一个实验设计是否有逻辑漏洞、一个软件功能应该如何拆解、一个任务应该按什么优先级推进。
Codex 更适合在本地环境里执行具体任务。比如它能看到你的目录结构，能读取文件，能修改代码，能运行命令，能根据报错继续修复，也能把结果整理成文件。
所以我现在不会把所有事情都丢给 Codex，而是让它们形成一个工作流：
先在 ChatGPT 里讨论任务目标； 让 ChatGPT 形成详细执行计划； 把计划保存为 Markdown 文件； 交给 Codex 阅读； Codex 根据本地环境提出执行层面的疑问； 再把 Codex 的疑问交给 ChatGPT 修订计划； 最后由 Codex 按计划执行； 执行完后再生成汇报文件； 人来审核结果和关键判断。
这个流程看起来好像比直接让 Codex 干活更麻烦，但实际使用下来，它能减少大量返工。
尤其是做复杂任务时，最怕的不是 AI 干得慢，而是它很快地把事情干偏了。 如果一开始方向错了，它执行得越快，后面返工越痛苦。
在这个工作流里，我强烈建议 ChatGPT 和 Codex 之间都尽量用 Markdown 文件交流。
不要只靠终端里一段一段复制粘贴，也不要只在对话框里口头描述。最好让 ChatGPT 生成一个完整的plan.md，让 Codex 执行后生成一个report.md。如果中间有疑问，就让 Codex 生成questions.md，再把这个文件交给 ChatGPT 修改计划。
这样做有几个好处。
第一，信息不会丢。 复杂任务一旦经过几轮交流，如果只靠聊天记录，很容易忘掉前面定过什么规则。
第二，方便自己修改。 AI 生成的计划不一定完全符合你的想法，但 Markdown 文件很好改。你可以直接在里面补充一两句话，再交给 Codex 执行。
第三，方便追责。 如果结果不对，可以回头看计划里到底有没有写清楚。如果计划没写清楚，那就是计划问题；如果计划写清楚了 Codex 仍然做错，那就是执行问题。
第四，方便复用。 很多任务不是只做一次。一个好的agent.md后面可以反复复用，每次只改输入文件和输出路径。
所以我的一个经验是：「不要把 Codex 当成聊天对象，而要把它当成一个能读项目文档并执行项目文档的本地 agent。」
这个心态一变，使用效果会差很多。
三、善用 Codex 的 Plan 模式，但不要迷信 Plan 模式
Codex 里面有一个比较有用的功能，就是计划模式。一般可以通过shift + tab进入。
这个模式的作用是让 Codex 在真正执行前，先把它理解到的任务翻译成自己的计划。也就是说，你给它一个任务后，不是让它立刻动手，而是让它先告诉你：
它准备怎么做； 它会先看哪些文件； 它会修改哪些内容； 它认为可能有什么风险； 它最后会如何验证结果。
这个功能对中小型任务非常有用。
比如你让它修改一个网页展示逻辑、整理一批脚本、检查一个项目结构、修复一个报错、添加一个小功能，这时候进入 Plan 模式往往能明显提高执行质量。
因为 Codex 自己先梳理一遍任务后，它会更清楚接下来该做什么。你也能在执行前发现它有没有理解错。
但 Plan 模式也有一个限制： 如果 ChatGPT 给出的计划本身非常长、非常细、包含大量背景逻辑和执行要求，这时候就不一定适合让 Codex 再用 Plan 模式重写一遍。
因为 Codex 自己生成的计划通常会更短，更偏执行摘要。它可能会把一些你原本写得很细的约束压缩掉，甚至忽略掉一些很关键的边界条件。
所以我现在一般这样使用：
如果任务不大，我会让 Codex 进入 Plan 模式，先翻译成它自己的执行计划，再开始做。 如果任务很大，ChatGPT 已经给了一个长篇的agent.md，我通常不会让 Codex 重写整个计划，而是让它先阅读计划，然后只输出“执行前疑问”和“风险点”。
也就是说，Plan 模式不是万能的。 它适合让 Codex 对短任务建立执行框架，但不适合替代一个已经写得很完整的长计划。
一个比较实用的提示词是：
请先阅读当前目录下的 plan.md，不要立即执行。
先输出你对任务的理解、准备执行的步骤、可能存在的风险点，以及你需要我确认的问题。
在我确认之前，不要修改任何文件。
这个提示词的价值很大。
因为它把 Codex 从“马上开始干活”的状态，拉回到“先理解任务”的状态。很多问题只要在执行前多问一轮，就能避免后面一大堆返工。
四、让 ChatGPT 和 Codex 多交流几轮，不要急着执行
Codex 和 ChatGPT 之间其实有一个很重要的差异： 它们掌握的信息不一样，视角也不一样。
ChatGPT 更像一个站在项目外部做规划的人。它知道更多背景知识，也更适合判断什么方案有创新性，什么论证更稳，什么结构更适合写论文，什么结果更适合展示。
Codex 更像一个站在项目内部做执行的人。它能看到实际文件，知道路径是否存在，知道代码能不能跑，知道依赖有没有装，知道某个方案在本地环境里是否麻烦，知道执行过程中会不会遇到具体问题。
这两个视角是互补的。
所以我现在不会让 ChatGPT 写完计划后，直接让 Codex 执行。更好的方式是让 Codex 先审阅计划，尤其是让它从执行角度提出问题。
我自己试过几次，这一步非常有价值。
Codex 经常会对 ChatGPT 或其他 AI 给出的计划产生很多疑问，比如：
某个文件路径是否真实存在； 某个输入数据是否已经准备好； 某一步是否会覆盖旧结果； 某个软件是否已经安装； 某个输出格式是否需要统一； 某些任务是否应该先小规模测试再全量执行； 某些指标是否缺少计算依据； 某些修改是否会影响旧功能。
这些疑问通常不是找茬，而是非常合理的执行层面考虑。
这时候不要觉得麻烦，也不要急着说“你别问了，直接做”。 相反，应该把这些问题整理出来，再交给 ChatGPT 修改计划。
修改后的计划质量往往会明显提高。
这里面有一个很有意思的现象： 如果让 Codex 自己从零开始制定方案，它通常会比较保守，甚至会使用一些过时或平庸的方法。它更像是根据已有文件和常见做法往前推，不太容易主动提出特别有创造性的方案。
但如果 ChatGPT 先给出一个较高层次的计划，再让 Codex 从执行角度挑问题，两者结合起来效果会更好。
一个负责方向，一个负责落地。 一个负责想得远一点，一个负责看得细一点。
这比单独使用任何一个工具都稳。
五、文件越多，Codex 的优势越明显
我这段时间感受很深的一点是： 文件越多的任务，Codex 的优势越大。
比如找文献、下载文献、整理 PDF、读取论文内容、筛选目标、生成汇总表、建立文件夹结构、按规则重命名文件、把结果整理成 Markdown 报告，这类任务交给网页端 ChatGPT 会非常痛苦。
因为网页端最大的问题是： 它没有你的本地文件系统。
你要自己下载论文，自己上传文件，自己整理文件名，自己把结果复制出来。如果文件很多，这个过程本身就会让人崩溃。
但 Codex 不一样。
如果本地环境配置好了，它可以直接在目录里批量处理文件。比如把文献下载到指定文件夹，用已有脚本读取 PDF，用 skills 或其他工具提取论文内容，再根据你的筛选标准生成结果。
这种任务本质上不是单纯的“问答”，而是“本地文件工程”。 网页端再聪明，也很难舒服地完成。 Codex 的优势就在这里。
当然，这也有一个前提： 你最好给 Codex 安装一些适合自己工作流的 skills。
比如论文读取、PDF 处理、Markdown 整理、科研绘图、表格处理、代码检查、项目结构分析等。如果没有这些能力，它也能做，但会更笨重，需要绕很多路。
我现在越来越觉得，Codex 的真正价值不是“单次回答质量比 ChatGPT 更高”，而是它能接入你的本地工作环境，把 AI 能力变成连续的工程执行能力。
这对于科研工作尤其重要。
科研项目里真正耗人的地方，很多时候不是想一个理论，而是围绕这个理论做大量脏活累活：
找文献； 下文献； 看文献； 整理证据； 对比结果； 改文件； 跑脚本； 处理报错； 生成图表； 统一格式； 写汇报； 再根据汇报继续改。
这些事情如果全靠人手动做，会非常消耗时间。 如果交给 Codex，只要计划足够清楚，它能帮你把大量中间环节自动化。
六、人不是被替代了，而是变成了项目负责人
使用 Codex 后，一个很明显的变化是： 我并没有变轻松，反而有时候更累。
这听起来有点矛盾。
按理说 AI 帮我做了这么多事，我应该更轻松才对。但实际感受并不是这样。
原因在于，Codex 提高了执行速度，也就提高了项目推进速度。以前一个人一天只能推进一个任务，现在可能同时推进三个任务、四个任务。以前很多事因为太麻烦就暂时不做了，现在 Codex 能做，于是这些事情都变成了“可以做”。
结果就是，人从一个亲自干活的人，变成了一个同时管理多个任务的人。
你不一定要亲自写每一行代码，也不一定要亲自整理每一个文件，但你必须不断判断：
这个任务是否值得做； 这个结果是否可信； 这个方向是否应该继续； 这个错误是否会影响结论； 这个文件是否可以进入正式结果； 这个汇报是否遗漏了关键信息； 这个计划是否需要修改。
换句话说，人从执行者变成了项目负责人。
这也是为什么我不认为 Codex 会让人完全不用思考。恰恰相反，它会把人的思考位置往上推。
以前你可能主要思考“这一步怎么做”。 现在你更多要思考“为什么要做这一步”“做到什么程度算够”“做出来的东西能不能用”。
这也是一个很大的变化。
七、我目前总结出的使用原则
如果要把这段时间的经验总结成几句话，我大概会这样写：
第一，Codex 适合执行，不适合完全替你做判断。 越是目标明确、步骤清楚、文件繁多的任务，越适合交给 Codex。
第二，任务开始前一定要写计划。 计划里要有目标、路径、输入、输出、限制、验收标准和出错处理方式。
第三，ChatGPT 和 Codex 应该分工。 ChatGPT 更适合做顶层设计和方案判断，Codex 更适合在本地执行、测试、修改和汇报。
第四，中间文件非常重要。 尽量用 Markdown 作为 ChatGPT 和 Codex 之间的交流媒介，不要只靠聊天记录。
第五，执行前多交流几轮。 Codex 从执行角度提出的问题，很多时候能显著提高计划质量。
第六，Plan 模式很好用，但要看任务大小。 短任务可以让 Codex 自己先生成计划，长任务则最好让它阅读既有计划并提出疑问，而不是压缩重写。
第七，文件型任务优先考虑 Codex。 只要涉及大量本地文件、论文、代码、脚本、图片、表格，Codex 的优势通常会比网页端明显得多。
写在最后
这段时间使用 Codex 后，我对 AI 工具的理解发生了一个变化。
以前我会更关注某个模型“会不会回答”“回答得聪不聪明”。 现在我更关注的是：它能不能进入真实工作流。
真正有用的 AI，不只是能在对话框里给出一个漂亮答案，而是能参与一个持续推进的项目。它能读文件、改文件、运行命令、生成报告、根据反馈继续修复，最后把一个复杂任务往前推进一大截。
但这并不意味着人可以完全放手。
相反，越强的执行工具，越需要人有更清晰的判断。 因为它执行得太快了，如果方向错了，它会很快把错误放大。 如果计划不清楚，它会很快生成一堆看似完整但实际上不符合需求的东西。 如果人不审核，它也可能把一些不可靠的结果包装得非常像真的。
所以我现在对 Codex 的态度是： 它不是一个可以完全替代人的工具，而是一个非常强的执行放大器。
你想清楚了，它能帮你做得很快。 你没想清楚，它也能很快帮你把混乱扩大。
这大概也是目前 AI agent 工具最真实的状态： 它们已经足够强，强到可以改变很多人的工作方式； 但它们还没有强到可以让人完全退出判断环节。
人仍然是那个制定目标、判断方向、审核结果的人。 Codex 则是那个执行力极强、能连续工作、但需要被正确管理的助手。
用好了，它会让你觉得自己像多了一个项目组。 用不好，它会让你觉得自己多了一个特别能干但经常需要返工的实习生。
而真正的关键，也许不是“AI 能不能完成任务”，而是我们能不能学会把任务交给 AI。