Codex 不好用多数时候不是模型问题而是这 4 个使用姿势错了如果你也有过这种感觉大概率不是你一个人的问题。同样都是让 Codex 帮忙改代码、查仓库、跑命令有时候它很好用像一下子就懂了你的意思有时候又特别别扭改动飘、理解偏、结果总和预期差一截。很多人第一反应是是不是模型不够聪明或者是工具不好用。但我自己连续用了一段时间之后慢慢发现一件事很多时候不是 Codex 不行而是我们的使用姿势有问题。尤其是已经装过、用过一点、也确实成功过几次的人最容易卡在这个阶段。不是完全不会用而是“会一点但总觉得用不顺”。这篇文章我不讲安装也不讲太重的 MCP 编排只想把我自己最常踩、也最容易让 Codex 变得不好用的 4 个问题讲清楚。你看完不一定立刻变成重度玩家但至少会从“会用一点”往“用得顺很多”走一截。如果你还没装过最短的上手路径其实很简单npmi-gopenai/codex codex第一次启动时按官方说明用 ChatGPT 账户或者 API Key 登录就行。但真正的问题从来都不是“装没装上”而是“装上以后到底怎么用才不至于总觉得它忽好忽坏”。这篇文章我就只讲这个。目标也不高不是把你一下拉到中级而是把你从“会装、会问”带到“知道怎么用得顺一点”。1. 第一个误区一上来就让它直接写功能这是最常见的一个坑。很多人第一次打开 Codex或者即使已经用了几次还是很容易上来就丢一句帮我把这个报错修掉。或者帮我改一下这个列表页感觉哪里不太对。看起来很正常但这类问法的问题是你脑子里已经有了完整上下文Codex 没有。它不知道这个仓库的入口在哪不知道测试怎么跑不知道你现在想要的是“先出方案”还是“直接动手”也不知道你能接受多大范围的改动。结果它只能自己脑补。只要一脑补结果就容易漂。更稳的起手方式不是“直接让它写”而是先让它理解。我现在更常用的第一轮问法是这种先不要改代码。先帮我做三件事 1. 找出这个报错最可能是从哪一层抛出来的。 2. 告诉我相关文件和调用链路分别在哪里。 3. 说一下如果要改最小改动会落在哪几个文件。如果你懒得分条甚至可以更短一点先别动手改先帮我定位这个问题大概率出在哪一层再告诉我你准备从哪里下手。你会发现只是多了“先别动手改”这几个字整个协作体验就完全不一样了。因为这一步本质上是在做一件很重要的事先校验它对上下文的理解再决定要不要让它进入下一步。很多人觉得 Codex 不稳定其实第一刀就切错了。不是它不能改而是你不该让它在还没形成项目地图的时候就直接下手。2. 第二个误区一句模糊需求直接扔过去默认它自己会拆轻度用户还有一个很典型的问题就是把一整团需求原封不动扔给 Codex然后希望它自己拆得很好。比如这种问法这个列表页有点怪你帮我优化一下。或者这个接口请求写得不太顺你帮我整理一下。问题不是它完全做不了而是这种需求对人来说都偏抽象对 agent 来说就更抽象了。我后来比较有用的一个小习惯是强迫自己把任务拆成四步理解 - 定位 - 小改 - 验证什么意思就是不要让 Codex 一口气吃掉整件事而是让它先一步一步过。比如同样是改列表页我现在更愿意这样问先不要直接改页面。 先帮我定位这个列表页对应的组件、数据请求和状态处理分别在哪。 然后告诉我你觉得最可能影响体验的两个点是什么。 等我确认后你只改其中一个点不要顺手改别的。 改完后告诉我影响了哪些文件我该怎么验证。这里真正重要的不是字多而是边界清楚。再比如“整理接口调用”这种事错误问法通常是帮我整理这个模块里的接口调用。更好的问法可以是先找出这个模块里最容易重复的请求逻辑在哪。 不要直接重构先告诉我现在最乱的是哪一段。 然后只挑一处重复最明显的地方给我一个最小改动方案。 如果要改先说你准备动哪些文件再动手。你会发现Codex 不是不会做事而是你不能默认它替你完成“任务拆解”这一步。对简单任务它有时会猜对但只要任务稍微复杂一点自己不拆结果就很容易歪。所以如果你已经用过 Codex但总觉得它“有时很好有时很乱”先别急着怪模型。先回头看一下你是不是经常把一整团模糊需求直接扔过去了。3. 第三个误区每次都像重新开机不给它长期规则这个问题在项目稍微复杂一点之后会特别明显。你会发现每次开一个新会话都要重新说一遍我们这个项目用pnpm改前端要跑哪些校验哪些目录不要乱碰不要顺手加生产依赖改完先汇报不要直接大面积执行一次两次还行次数多了就很烦。而且更麻烦的是你今天记得说明天不一定记得说。你不说Codex 就只能按自己的默认策略来。这也是为什么我越来越觉得AGENTS.md不是一个“可有可无的小功能”而是从“会用”到“用得顺”的分水岭。按 OpenAI 官方文档的说明Codex 在干活前会先读取AGENTS.md。它不只是看一个文件而是会叠加读取全局规则和项目规则从项目根目录到你当前目录的路径上越靠近当前目录的规则越具体。这件事的现实意义特别直接你终于不用每次都重新讲一遍工作规矩了。如果你现在还没有这个文件我建议先别写得太复杂先上一个我觉得大多数项目都能直接用的最小版本# AGENTS.md - 这个仓库统一用 pnpm不要切回 npm - 前端代码改完后先跑一次 pnpm test - deploy/ 下面的东西不要动除非我明确提到 - 如果要加新依赖先告诉我为什么要加 - 准备改多个文件之前先把改动范围说清楚这几行看起来很普通但它解决的是“每次都得重新提醒一遍”的问题。以前你可能会觉得“我明明已经说过不要乱改部署文件了怎么它还是改了”很多时候不是它故意乱来而是那句话只存在于你上一次会话里没有变成长期规则。如果某个子目录还有特殊要求你也可以在更靠近那个目录的位置再放一层更具体的规则。这样它在那个局部区域工作时会自动带上更细的约束。所以AGENTS.md最有价值的地方不是写得多漂亮而是把你那些本来就会反复说的话沉淀下来。我现在的体感是很多人以为自己缺的是 prompt 技巧但真实项目里先把AGENTS.md写出来收益通常更直接。因为 prompt 只是你这一次怎么问AGENTS.md才是你们以后默认怎么合作。4. 第四个误区把它当成一次性全自动完成器这也是很多轻度用户很容易踩的坑。表面上看大家是在追求效率本质上是默认 Codex 应该“一次性自己全做完而且还不能出错”。但只要你真的在项目里用过几次就会发现这是不现实的。尤其是在你还没完全摸清它的节奏之前最稳的方式从来不是一下把权力全放出去而是先让它在你能控住的范围里工作。OpenAI 官方文档里把这件事做成了明确能力也就是approval modes。简单理解就是你可以按自己的安全感和任务风险来决定哪些动作先让我看哪些动作可以先执行。这背后的思路其实特别朴素你对仓库越不熟越不该一上来就全自动任务越模糊越不该一上来就全自动改动面越大越要先看它怎么想再决定放不放权所以我现在更推荐的做法是先让它说方案再让它解释准备改哪些文件再让它说明可能风险你确认节奏没问题再让它继续比如可以直接这么说先不要直接执行。 先告诉我你准备怎么改、会影响哪些文件、有哪些风险。 我确认以后你再继续。或者更明确一点这次任务先按保守方式来。 你先给方案和改动范围不要直接做大面积修改。 如果需要运行命令或者改多个文件先告诉我原因。这类问法听起来好像“慢了一点”但真实体验通常反而更稳。因为你不是在和一个搜索框对话而是在和一个会读、会改、会执行的 agent 协作。只要它具备执行能力预期管理就一定比“花式提问”更重要。顺着这个逻辑再说一下 MCP。MCP 很重要这点我不否认。它能让 Codex 接更多工具和上下文后面你真想把工作流再往前推基本绕不过去。但如果你现在还处在“经常觉得 Codex 没达到预期”的阶段那你最优先该补的通常不是 MCP而是前面这几件更基础的协作姿势。因为说到底很多人不是输在“工具接得不够多”而是输在起手太急任务太糊规则太少放权太快而且当你真的开始高频用 Codex 之后接下来冒出来的问题往往就不只是“怎么提问更稳”了。对轻度用户来说前面这些使用姿势已经够用了但对每天都在用的人来说后面的现实问题会越来越明显。比如账号本身的获取和支付就不一定顺手地区可用性、支付方式、持续成本这些事情很快就会从“偶尔麻烦一下”变成“天天都要面对”。尤其是你不只是偶尔试一试而是真的把 Codex 当生产力工具在用的时候官方链路未必总是最省心。有人会卡在账号和支付环节有人会卡在使用环境有人则是用量一上来之后发现长期成本比自己预期高很多。我自己后来也是在这个阶段才慢慢意识到前面的使用姿势是一层问题后面的账号、成本和接口链路其实是另一层问题。前者决定你能不能把 Codex 用顺后者决定你能不能长期把这套工作流用下去。在账号这块我也是折腾了好久踩了不少坑后来就没有继续把精力都花在账号、支付和链路折腾上而是改用 modelapi01.com 这种更偏 AI 编程场景的 API 中转方案。对我这种每天深度使用 Codex 的人来说至少不用再反复处理账号和环境上的麻烦也不需要为了高频使用去硬扛官方链路的成本压力更重要的是Claude Code、Codex、Gemini 这类工具后面要统一接进同一套接口时会省事很多把省下来的时间用在真正项目开发上。5. 如果你明天还准备继续用 Codex那先把这几件事改掉如果你看到这里只想带走最有用的部分我建议别急着学更多新功能先把下面这几个习惯改掉。第一别再一上来就让 Codex 直接写功能。先让它把仓库、入口、命令和约定讲清楚再进入真正任务。第二别再把一整团需求直接扔过去。你自己先拆一下哪怕只是拆成“先定位、再小改、再验证”结果都会稳很多。第三别每次都靠临时提醒。那些你本来就会反复说的话尽快放进AGENTS.md省得每次重新开机。第四别默认它应该一次性全自动做完。先让它说方案、讲改动范围、讲风险再决定要不要继续放权。我自己现在回头看Codex 真正开始变得顺手不是因为我突然学会了什么很高级的技巧而是我终于不再把它当成一个“会写代码的聊天框”而是把它当成一个需要协作规则的工程助手。很多时候模型没有你想的那么笨只是你给它的工作姿势还停留在“随手问一嘴”的阶段。