以前我们用 AI,大多数时候还停在聊天框里。问一个问题,得到一段回答;让它改一段话,它给我一个版本;让它写代码,它吐出一段可以复制的东西。
很有用。但世界没有真的变化。
文件还要我自己建。
网页还要我自己打开。
图片还要我自己检查。
写完的文章还要我自己存到目录里。
现在用 Codex:查资料,写文章,做配图,生成 HTML,再把所有文件放到我指定的桌面目录。已经是一件很普通的事情。
Codex是什么
很多人会把它理解成“会写代码的 ChatGPT”,或者“更聪明的代码补全工具”。这个理解不算错,但只是很小的一部分。
Codex 的定位其实是 OpenAI 面向软件开发场景做的 coding agent。
这里的重点不是“coding”,而是“agent”。
它不是只给你补一段函数,也不是只回答一个报错问题。Open AI把 Codex 放在 ChatGPT、IDE、CLI、Cloud 这些不同入口里
App 更像一个独立工作台。你可以在里面把任务交给 Codex,让它围绕项目、文件、网页和工具去推进。
IDE extension 更贴近开发者日常写代码的场景。它可以直接进入编辑器上下文,理解当前文件、项目结构和修改范围。
CLI 则适合习惯终端的人。很多工程任务本来就发生在命令行里,比如跑测试、查日志、做迁移、执行脚本。
Cloud 面向更长、更并行的任务。你不一定要盯着本地电脑等它跑完,可以把任务放到云端环境里处理。
本质上是在把软件开发里的很多动作串起来:写代码、读代码、审查代码、调试问题、跑重复任务、操作浏览器和桌面应用。
换句话说,Codex 想做的不是一个更快的输入框。
它更像一个可以被派去完成开发任务的工作台,可以被派去执行任务的代理。
不要一上来就装 CLI
很多人看到 Codex,第一反应就是去找安装命令。
但后来发现,入口选错了,会把一个本来挺好用的工具,直接变成“折腾环境半小时,最后还没开始干活”。
Codex 现在大概有几种常见入口。
第一种是 Codex App。
它更像一个独立工作台。下载安装,登录账号,选择一个项目文件夹,然后就可以让它在本机项目里干活。对不想一开始碰命令行的人来说,这是最舒服的入口。
第二种是 IDE 扩展。
如果你每天都在 VS Code、Cursor、Windsurf 里写代码,那这个入口很自然。它在编辑器里工作,知道你当前项目是什么,也更容易和你平时的开发节奏接上。
第三种是 CLI。
也就是在终端里运行 codex。这个入口最适合习惯命令行的人。它很直接,也很强,但前提是你对终端、Node、Homebrew、权限、目录这些东西不陌生。
第四种是 Cloud。
它适合更长一点的任务,比如连接 GitHub 仓库、让 Codex 在云端跑一个修改,最后你再看 diff、建 PR。

如果是第一次用,我建议先从 App 或 IDE 扩展开始。
等你知道 Codex 到底能帮你做什么,再去折腾 CLI。
这和很多工具不一样。有些工具 CLI 是本体,图形界面只是壳。
但 Codex 的几个入口是面向不同工作习惯的,不必一上来就选最“工程师味”的那一个。
安装方式
因为我是 Mac 用户,而且已经习惯终端,可以直接装 CLI。
用 npm:
npm i -g @openai/codex或者用 Homebrew:
brew install codex装完以后,在项目目录里运行:
codex第一次运行会让你登录,可以用 ChatGPT 账号,也可以用 API key。
如果你本来就有 Node 环境,那 npm 方式很快。
如果你平时就用 Homebrew 管工具,那 brew 方式更顺手。
如果你是 Windows 用户,现在也不是完全不能用。
官方文档里已经写到 CLI 支持 macOS、Windows 和 Linux。Windows 上可以在 PowerShell 里原生运行,也可以在需要 Linux 环境的时候用 WSL2。
但我建议是:
如果只是想先体验,Windows 用户优先用 App 或 IDE 扩展。
别一上来就把 WSL、Node、代理、权限、路径全混在一起折腾。
AI 工具最怕的不是不会用,而是还没开始用,就被环境劝退了。
如何配置让它一直中文回复
Codex 默认不一定每次都按中文回复。
你可以在对话里说:
“后续请一直用中文回答。”
但这种方式不够稳定。
所以更优的方式是把它写进规则里。
比如在全局 Codex 配置目录里放一个 AGENTS.md,写上自己的使用偏好:
mkdir -p ~/.codexprintf 'Always respond in Chinese-simplified\n' > ~/.codex/AGENTS.md这是为了减少每次重复交代。同时我还会在里面补一些更实际的规则,比如:
“修改前先说明计划。”
“不要擅自改无关文件。”
“涉及删除、重置、线上配置时先征求确认。”
“输出时用中文,但代码和命令保持原样。”
这些规则越清楚,Codex 越像一个知道边界的助手。
你不写规则,它也能干活。但写了规则,它更少乱跑。
真正好用的地方,不是让它写一个函数
我现在最少让 Codex 做的事,反而是“帮我写一个函数”。因为这类事普通 AI 也能做。
Codex 真正舒服的地方,是那些需要在项目里来回穿梭的任务。比如接手一个陌生项目。我会让它先不要改代码,只梳理链路:
“帮我看一下这个项目的登录流程,从前端入口到后端鉴权,再到 token 写入,列出主要文件、关键函数和风险点。”
这类任务人做也不难,但很耗时间。Codex 可以先把地图画出来。我再沿着它给的路径去判断。
再比如线上报错。我不会直接问它:“为什么 500?”
我会说:“先看最近改动、相关路由、失败日志和测试结果。先列出三个可能原因,每个原因给验证办法。”

这就不再是问答了。这是排查。它先把范围缩小,人再做判断。
再比如 PR 审查。我不指望 Codex 替我做最终判断,但它很适合做第二双眼睛。
我会让它重点看权限、并发、异常回滚、边界条件和测试覆盖。
这比问一句“这段代码有没有问题”有效得多。因为你给它的是审查角度,不是让它泛泛评价。
Codex本质上是一个智能AI agent
以前很多 AI 工具只能听我描述。
我说页面白屏了。
它让我检查控制台。
我说按钮点不了。
它给我几段 CSS 建议。
问题是,真实前端问题经常不是一段代码能说清楚的。
它需要打开页面看。
需要点一下。
需要观察控制台。
需要确认是布局问题、事件问题、接口问题,还是状态没更新。
Codex 可以使用 Computer Use来操作你的电脑
它不只是读代码和跑命令,在一些场景里也可以使用浏览器或图形界面去完成任务。

这对前端、测试、运维都挺有用。
比如让它打开本地页面,复现一个按钮点击问题。
比如让它检查某个表单提交后有没有报错。
比如让它在浏览器里看页面是否真的渲染出来,而不是只根据代码猜。
能打开浏览器,意味着它更接近真实操作。
但要注意的是,他的能力越强,权限范围越大,代表着它越需要有规则去做限制,任务范围要写窄。
只打开哪个页面。
只检查哪个问题。
只允许读哪些信息。
不要让一个 agent 在边界不清楚的时候到处点。
给 Codex(AI) 的任务,把它写得像工作说明
以前我用 AI,喜欢丢一句话。
“帮我修一下这个 bug。”
后来发现,这种话对 agent 不够好。
因为它真的会去动手。你不说边界,它就只能自己猜边界。
所以使用上最好把任务写成四段:
目标是什么。
范围在哪里。
哪些地方不要动。
做完怎么验证。
比如:
“帮我排查登录接口偶发 500。范围只看 auth、user、session 相关文件。先不要改代码,先给排查结论。需要跑测试时先说明命令。最后给我一个最小修改方案。”
或者:
“帮我审查这个 PR。不要纠结格式,只看权限绕过、并发、失败回滚和测试缺口。输出按风险高低排序。”
这种写法看起来啰嗦。但对 Codex 很友好。因为它不是普通聊天框。它是在执行任务。
任务交代得越像真实工作说明,结果越稳。
夜雨聆风