Codex 生产力提升实战：8个让你事半功倍的隐藏技巧
我用 Codex 也有一段时间了。最初只是让它帮忙改代码、写文档、跑命令，觉得挺方便。后来慢慢察觉，同一款工具，不同人用出来的效果天差地别。
拉开差距的，往往是一些“用着用着才悟出来”的技巧。这些技巧藏在你踩过的坑里，藏在你零碎的操作记录里，官方文档和教程反而很少提及。
这篇就是把这段时间零碎记录下来的心得、踩过的坑、吐槽完想通的东西整理一下，算是一份“用了一阵子以后回头看，早知道这些就好了”的汇总。
善用免费工具探路，让 Codex 专注核心任务
这是我最看重的使用习惯。
我现在一般让 Codex 负责写代码，然后用豆包、元宝这类免费 AI 单独开一条项目开发对话。遇到不懂的直接问豆包，需要一步步操作的事情也复制进去，让它手把手教我。
这样做的好处是双重的：不污染 Codex 的对话上下文，也不浪费宝贵的 Token 额度。
Codex 的 Token 是要花钱的，或者说额度是有限的。用它来问“这个命令怎么用”“这条报错是什么意思”，纯属浪费资源。这些简单的事，免费工具完全能胜任。
把 Codex 的额度留给它真正擅长的地方：写代码、做方案、梳理项目、处理复杂任务。基础的知识问答和操作指导，通通交给免费工具。
这条思路用顺手以后，你会发现自己的产出效率有明显跃升。记住，要把它的能力用在最该用的地方。
长内容提供文件路径，避免直接粘贴对话
碰到报错日志、大段代码、长文档，很多人的第一反应是复制粘贴到对话里让 AI 自己找答案。
千万别这么做。
把一万行日志粘进对话，这些内容就会永久占据你的上下文空间，每多一轮对话都要重新“读”一遍。更聪明的做法是把文件路径发给 AI，让它自己按需检索信息，只将相关内容拉入上下文。
记住这句话：最便宜的 Token，是那些根本没进入上下文的 Token。
掌握启动服务等基础操作，减少不必要的 Token 消耗
以前我连启动个本地服务都要交给 AI，觉得“反正它能干”。后来发现这样做有两个坏处：一是浪费 Token，二是自己对项目越来越陌生。
现在的习惯是：启动服务、Git 提交推送、简单的文件操作，这些全都手动完成。一来不浪费 Token，二来自己也有参与感，慢慢也会更熟悉这些东西。
Git 提交我更建议手动操作。用小乌龟点几下鼠标就行，不用每次都让 AI 帮你执行一次 Git，白花花的 Token 还容易污染上下文。而且手动提交时你会注意敏感信息不要提交、node_modules 不要提交，这些 AI 有时候并不会帮你把关。
AI 生成的前端代码，务必在浏览器中实际验证
这是我自己踩过无数坑后总结出来的铁律。
AI 写前端特别容易“脑补成功”。它改完代码，跟你说“已经搞定了”，你看着代码好像没毛病。结果打开页面一看，布局错乱，按钮挤在一起，文字溢出。
所以做网页类任务时，一定要让 Codex 最后用浏览器验证。不管它说自己改得多完美，用 Browser Use 打开实际页面看一眼。没装这个插件的，建议装一个。
这个习惯让我省掉了无数次返工。
当 AI 陷入死角时，主动为其提供新思路
大模型也会钻牛角尖。
碰到一个问题，它调来调去就是搞不定，你不要一直让它“再想想办法”。它已经没有新思路了，你再怎么催也没用。
这时候你要做两件事：
第一，帮它想个新方向重新尝试。把你对问题的理解、你猜测的原因告诉它，让它沿着你的思路去试。大模型最怕的是没有方向，你给它一个明确的方向，它往往就能打开局面。
第二，如果还是摆不平，就换工具或者换模型。同一个问题，Codex 解不了的，可能Claude Code 可以。Claude Code 解不了的，可能 Cursor 可以。不要在一棵树上吊死。
这个道理我也是花了很长时间才想通的。以前总觉得“这个工具这么强，肯定能搞定”，结果在一个问题上耗了两小时。后来换了个思路，十分钟就解决了。
把错误固化成规则，而不是指望 AI 道歉
AI 最擅长的就是态度好。你骂它，它不生气。你指出问题，它马上承认。你让它重写，它立刻重写。
但它的听话往往只在当前这次有效。只要你没把这个错误固化下来，下一次它照样可能重蹈覆辙。
所以我们要换个思路。不要老想着让 AI“认识到错误”，而是让 AI“没有机会再犯这个错”。
怎么做？两种方式：一两句话能讲清楚的，直接写成规则放进 AGENTS.md 文件里。比如之前我让 AI 查 Codex 的资料，它跑去网上搜了一大堆，明明我项目文件夹里就有完整的 Codex 教程。于是我在 AGENTS.md 里加了一条：有关 Codex 教学的内容，优先搜索当前文件夹里的资料。就这么一句，它保证下次不会再犯。
一两句话说不清的东西，就写成 skill。skill 本质上是把你认为正确的工作流程固化下来。比如你让 AI 用 Figma 画图，如果没有固定流程，它上来就乱画，你改一次它改好了，下次又变回老样子。写成 skill 固定流程，它就能按步骤来。
但 skill 也别整太多。搞多了绝对出问题，要么浪费 Token，要么你的 AI 越用越迟钝。
不要一上手就规划大而全
这是我在 AI 编程里最大的教训。
你让 AI 一次性做一个大而全的东西，它确实做得出来。但你拿到手一看，每个地方都差了那么一点，你想让它改，甚至都不知道怎么组织语言去描述。因为你当初设想得不够细，很多细节是在做的过程中才慢慢浮现的。
正确做法是先做最小 MVP，能跑就行。然后你去用、去体验、去发现问题，再一个功能一个功能往上叠加。这样每一步你都知道自己确切的修改方向，AI 也清楚目标。
改好之后，如果对 AI 做的 UI 不满意，可以把前端截图发给 gpt-image-2 让它重新设计，设计好后再交回 Codex 进行优化。这个方法特别好用，比用语言描述“这里好看一点”“那里大一点”有效得多。
判断推理档位的依据是“返工成本”
Codex 有低、中、高、超高四个推理档位。大多数人直接用默认的中档就好，不用纠结。
什么时候该调？看“返工成本”。如果 Codex 做错了，你自己看一眼就能修，那用低档或中档。如果做错了可能会埋下一个 Bug、误导读者、破坏原有架构，那就换高档或超高。
一个复杂问题用低档反复折腾五次，不一定比高档一次性做透更省。小事让它快做，大事让它慢慢想。该省时节省，该花时大方。
总结
用 Codex 久了以后，我觉得真正拉开差距的，不是谁的提示词写得好，而是谁更清楚什么时候该让模型跑腿，什么时候该让模型认真思考，什么时候该自己上手操作。
工具越强，越要学会合理分配。
以上这些技巧，都是我从自己的碎片记录里翻出来的。有的来自踩坑后的顿悟，有的是吐槽完才想通的，有的是用了很久才意识到的。希望对你有用。