OpenAI Codex 使用教程

OpenAI Codex 使用教程p id 4DUV62MV 之前推过两篇 OpenAI Codex 相关 偏方法论 p p id 4DUV62N2 刚好这个周末 我的 Plus 额度也差不多耗光了 索性停下来 认真写一篇图文版入门 p

大家好,我是讯享网,很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



 

之前推过两篇 OpenAI Codex 相关,偏方法论

刚好这个周末,我的 Plus 额度也差不多耗光了,索性停下来,认真写一篇图文版入门。

如果你最近正准备试试 Codex,这篇可以帮你少走一些弯路。


不得不说 GPT-5.4 相比其他已经算量大管饱(时常给个额度翻倍惊喜),模型能力也是 Opus 级别



如果你第一次接触 Codex,我建议先从 App 入手,因为:

比 CLI 更直观

  • 比 IDE 插件更独立

  • 比 Web 更贴近本地开发

  • 线程、终端、diff、Git、worktree 这些能力都能在一个界面里看到

    这篇文章我只讲 App,不讲 CLI 和 IDE,目标是让你 10 分钟内知道:它能干什么、该怎么配、哪些设置最值得先改。

    多图预警,请准备好流量


    先弄清楚:Codex 其实有 4 个入口



    官方介绍,其实有 4 中用法,注意下图最下居中,它有网页端


    我理解:它们不是替代关系,而是同一套能力的不同入口。

    区别不在“谁更强”,而在“你平时在哪儿工作”。






    入口

    更像什么

    最适合的第一批用户

    App

    本地指挥台

    想并行跑任务、看 diff、切 worktree 的开发者

    CLI

    终端主线

    习惯命令行、想脚本化、想和现有 shell 工作流融合的人

    IDE extension

    编辑器内副驾驶

    长时间待在 VS Code、Cursor、Windsurf 里的人

    Web

    云端执行面板

    想把任务丢到后台、接 GitHub、跑云端任务的人

    安装之后界面如下


    它既不是 IDE,也不是 CLI,官方只管他叫 APP

    我更愿意把它理解成一个本地开发任务调度台,你可以在里面:

    给 agent 下任务

  • 跟踪线程

  • 看终端输出

  • 检查代码差异

  • 做 Git 操作

  • 在不同线程之间并行推进不同工作

    这一点,是它和普通聊天式 AI 工具最不一样的地方

    浮动弹出窗口:适合快速迭代

    右上角,它还有一种使用模式——支持快捷键唤出,悬浮于桌面

    这个设计我挺喜欢,它不会强迫你一直待在 App 主窗口里。

    你可以把线程挂在浏览器、编辑器、设计稿、预览页面附近,边看边提需求,适合快速来回迭代。

    如果你习惯一边看页面、一边让 agent 改代码,这个模式很好用。


    模型切换



    底部模型可以切换,还有思考深度,越高效果越好,速度越慢

    小任务、试探性任务:先用快一点的设置

  • 重构、复杂逻辑、长链路问题:再把思考深度拉高

    切换终端:这是 App 很核心的一部分

    右上角可以点击切换终端

    注意,它不是“整个 App 共用一个终端”,而是线程级别绑定的终端
    也就是说,每个线程都可以对应一个与当前项目或工作区绑定的内置终端

    这意味着你可以在不离开 App 的情况下直接:

    验证更改

  • 跑脚本

  • 看日志

  • 执行 Git 操作


    差异面板:一定要养成看的习惯



    创建终端右侧是差异面板,显示本地项目或工作树检查中的 Git 差异


    因为很多人第一次用 agent,最容易犯的一个问题就是:

    只看对话,不看改动。

    但真正决定结果好坏的,不是它说了什么,而是它到底改了哪些文件、删了什么、加了什么。

    所以我自己的使用习惯是:

    agent 改完

  • 先看 diff

  • 再决定是继续让它改,还是自己接管

    这样安全感会高很多

    内置 Git 工具

    Codex 应用程序直接在应用程序内提供常见的 Git 功能,可以直接从 Codex 提交、推送并为本地和工作树任务创建拉取请求。

    这件事的价值,不只是“方便”,而是上下文不断裂
    你不需要在“聊天—终端—Git 客户端—代码编辑器”之间频繁来回切


    线程:Codex App 的真正核心



    先看左侧工具栏,不同文件夹对应不同项目

    一个项目可以开 N 多个线程,不同线程做不同任务

    官方解释:线程是一个单一会话,你的提示加上后续的模型输出和工具调用。一个线程可以包含多个提示。例如,你的第一个提示可能要求 Codex 实现一个功能,而后续的提示可能要求它添加测试。当 Codex 正在积极处理线程时,该线程被称为“正在运行”。可以同时运行多个线程,但避免有两个线程修改相同的文件。也可以稍后通过使用另一个提示来继续线程。

    我自己的理解更简单:一个线程,就应该只做一件事。

    比如:

    一个线程实现功能

  • 一个线程补测试

  • 一个线程修 lint 或类型问题

  • 一个线程做重构

  • 一个线程只做代码审查和计划讨论

    这样做的好处非常明显:

    上下文更干净

  • diff 更容易看

  • 后续迁移到 worktree 或云线程也更顺

    不建议一个线程里同时混着做三四件事

    那样前面聊的是功能实现,后面又**测试、文档、部署问题,很快就会乱


    自动化:把重复任务交给后台



    自动化这里可以设置不同的定时任务,可以是抓取信息,可以是定时分析日志

    把一切重复、周期性的任务交给后台自动执行


    刚开始用 Codex,我建议先把线程、本地模式、diff、Git 这些基础链路跑顺,再来碰自动化

    技能

    技能就是 SKills ,这里大量是我自己创建的


    往下拉,也有官方推荐的 SKills


    点击新建 skills 时,它会自动跳转,默认使用 Skill Creator 创新,写清楚自己的需求就行了


    很多以前要靠 MCP 或手工配置解决的问题,已经可以被一部分 Skills 覆盖掉。

    不是说 MCP 没用了,而是对于很多普通用户来说,Skills 的上手门槛更低,路径也更短。

    如果你只是想快速补齐某类能力,先看看有没有现成 Skills,往往比从零折腾更省时间。

    设置-常规

    如果你第一次打开设置,不少人会有点懵

    因为选项挺多,看起来哪里都能改

    但我觉得真正值得优先关注的,不多

    然后进入设置-常规,建议打开运行时防止系统休眠

    Speed 我选了 Fast,优点是快,缺点是 2 倍消耗


    上图默认打开目标,可以设置成你熟悉的工具,甚至可以使用 antigravity


    跟进行为有两种模式,排队 or 引导,它正在运行任务时,引导模式允许在任务执行中注入新的指令,立即生效。排队则是新指令要等当前任务结束后才执行。


    设置-Appearance



    我没动,看个人习惯,默认就挺好,无不适感

    如果你没有特别强的界面偏好,这部分可以先放着,不是最优先该折腾的地方


    配置:Approval 和 Sandbox 决定了你有多“放手”



    它详细配置都在 config.toml 中

    Approval policy

  • Sandbox setting

    它们本质上决定了一个问题:你愿意给 agent 多大权限

    比如:

    不放心,就把 Approval 设得更严格,很多动作都手动确认

  • 不放心,就把 Sandbox 设成只读

  • 如果你已经很熟悉自己的环境和项目,再逐步放开权限

    我自己比较激进,基本会直接给高信任和 Full access


    设置-个性化:能锦上添花,但不是刚需



    它的个性化只有两个,一个是亲和,一个是务实


    上面自定义指令,我参考了这位大佬的配置


    实际感受还可以,缺点是更慢,消耗更多


    设置-MCP 服务器



    随着 Skills 逐渐补上很多能力,MCP 对普通用户来说,不再是刚需

    我没怎么搞,以前配置了很多,但现在 Skills 取代一大批,Playwright 肯定是必装


    设置-Git



    我多数都是选择本地模式


    设置-环境



    这里是对你添加的项目配置环境文件


    设置-工作树



    仅对你使用工作树模式时有效

    工作树主要作用:一个仓库,多个并行文件夹,各跑各的分支

    让多个 agents 能同时工作而不发生冲突


    回到操作页面,线程的运行模式有几种,前两者是本地执行

    本地:直接在当前项目目录中工作

  • 工作树:在 Git 工作树中隔离更改

  • 云端:在配置好的云端环境中远程运行

    本地模式可以迁移至工作树


    关于工作树,最详细的介绍:https://git-scm.com/docs/git-worktree

    云线程:适合把任务丢到远端跑

    云线程在隔离的环境中运行,Codex 会克隆你的仓库并检出它正在工作的分支。当你想并行运行工作或从另一台设备委派任务时,云线程很有用。要使用云线程与你的仓库,先将代码推送到 GitHub。


    关联之后就可以直接对你的 Github 仓库进行操作


    这类模式适合什么时候用?我的理解是两类场景:

    想并行委派任务

  • 想在另一台设备之外,把任务挂到云端执行

    如果你要让云线程操作你的仓库,先把代码推到 GitHub。

    Slash 命令

    对话框输入 / 可以调出可用命令,最常用的是 /plan

    这个命令很适合放在“真正开始改代码之前”

    简单说就是:

    先让 agent 和你对齐怎么做,再让它开始做。


    如果担心它找不准 skills 也可以手动用 / 指定


    上下文窗口



    线程中的所有信息都必须适应模型的不同上下文窗口

    Codex 会监控并报告剩余的空间,对于较长的任务,Codex 可能会通过总结相关信息并丢弃不太相关的细节来自动压缩上下文。通过重复压缩,Codex 可以在多个步骤上继续处理复杂任务。

    没有额度了,这一步无法截图展示了。

    国产模型支持

    不订阅 ChatGPT 也可以用 Codex

    修改两个地方

    ~/.codex/auth.json

    {

    "OPENAI_API_KEY": "sk-"







    }


    ~/.codex/config.toml

    model_provider = "" # 设置API供应商
    model = ""

    [model_providers.siliconflow]
    base_url = ""
    name = ""

    [projects."/Users/huhaiyang/Library/Mobile Documents/iCloud~md~obsidian/Documents/zhangAI/"]
    trust_level = "untrusted"



























    更多使用技巧

    建议多看看官方博客

    https://developers.openai.com/blog/topic/codex


    写的很浅,我本人也不算深度用户,后续大家感兴趣,我会再写一篇使用技巧

    小讯
    上一篇 2026-04-24 15:58
    下一篇 2026-04-24 15:56

    相关推荐

    版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容,请联系我们,一经查实,本站将立刻删除。
    如需转载请保留出处:https://51itzy.com/kjqy/275151.html