如何使用 Codex：获得实际成果的 15 个技巧（2026）

发布于 2026年10月11日更新于 2026年10月11日作者：Codex 中文指南（翻译整理）

你让 AI 做一件事，收到的回答看起来有模有样，真正的工作却还没完成——这种情况并不少见。

Codex 改变了这种协作方式。它不只是建议你写什么代码或解释应该怎么做，还可以在项目中工作、编辑文件、运行命令、检查结果，并把可供你审查的改动交回来。

学会使用 Codex，并不意味着要写越来越长的提示词。从演示效果到真正有用的结果，关键在于：如何定义任务、提供什么上下文、授予哪些权限，以及怎样核验输出。

本文将介绍 15 个实用技巧，帮助你从凭感觉要求 AI 改代码、然后希望它能工作的“氛围编程”，转向一种可控、可验证且更安全的工作方式。

**译者说明：**本文根据 IA Operators 作者 Luiz Fernando Brazão 的英文文章翻译整理，原文发表于 2026 年 8 月 5 日。译文保留了原文的主要结构、15 条建议、示例、安全清单、FAQ 和官方参考链接；原站的商业服务推广、导航与页脚内容不属于正文，未纳入。原文注明的功能信息可能因套餐、操作系统、地区、工作区权限和应用版本而异；本站未对这些时效性描述逐项做独立核验。

本文内容

• Codex 是什么，适合做什么
• 开始前：选择使用 Codex 的入口
• 5 分钟开始使用 Codex
• 15 个实用技巧
• 实战示例
• 每个提示词都应带上的安全规则
• 使用 Codex 时的常见错误
• Codex 提示词模板
• 今天就能开始的检查清单
• 常见问题
• 官方参考资料

Codex 是什么，适合做什么

Codex 是 OpenAI 面向软件开发和技术工作的智能体。它可以编写和调试代码、运行测试与命令、审查改动、处理代码仓库；在你授予权限后，也可以操作本地文件夹。

原文将 OpenAI 的产品体验概括为三种主要用途：

体验	更适合的任务
Chat	提问、搜索、构思和对话式帮助
Work	研究、分析，以及文档、电子表格、演示文稿、报告或 Sites 等交付物
Codex	编程、终端、代码仓库、测试、技术改动和项目自动化

Codex 最初是编程智能体，能力已经扩展。在桌面应用中，它还可以使用 Skills、插件、浏览器、Computer Use、语音和其他工具，处理超出编写代码范围的应用操作流程。不过，如果你的目标只是制作一份没有实际技术环节的报告、演示文稿或电子表格，通常从 ChatGPT Work 开始更自然。

如果把 AI 开发工具看作一个光谱，Codex 位于更偏向执行的一端：它不只是给出建议，而是接收目标、规划步骤，并在你授权的工具中采取行动。

开始前：选择使用 Codex 的入口

Codex 可以通过多种入口使用：

• macOS 或 Windows 上的 ChatGPT 桌面应用；
• 开发环境扩展；
• 终端中的 Codex CLI；
• 受支持的云端环境；
• 通过移动应用远程访问某些会话。

选择哪种入口，取决于任务本身：

• 需要同时处理代码、本地文件、终端、浏览器和其他应用时，使用桌面应用。
• 希望在编辑器里检查改动时，使用 IDE 扩展。
• 偏好终端，或希望把 Codex 接入已有技术工作流时，使用 CLI。

本站也提供 Codex 桌面应用指南、Codex CLI 指南和 IDE 扩展指南。

5 分钟开始使用 Codex

如果你还没用过 Codex，可以按下面的最短路径完成一项可检查的任务：

1. 在你能使用的环境中打开 Codex：桌面应用、IDE 扩展、CLI 或云端。
2. 只选择要处理的文件夹或连接目标代码仓库，不要顺手开放其他项目。
3. 说明项目背景和事实来源：项目做什么、不同文件互相矛盾时以哪个为准、哪些文档是最新的。
4. 先交给它一个小而可验证的任务，并明确可检查的成功条件。
5. 批准任何改动前，先审阅计划、差异和测试结果。

一个适合作为起点的提示词：

我们正在维护一个 React 和 Node.js 应用。请修复用户双击后会创建两笔预约的 bug。不要修改界面设计或数据库架构。先分析原因并提交一份计划；在我批准计划前不要改动任何内容。

选择一个范围小、容易撤销、结果客观可验证的任务。这样你可以在几分钟内检查结果；如果方向不对，也能在造成后果前及时恢复。

接下来是 15 个实用技巧。

用 Codex 完成真正的工作：15 个实用技巧

1. 先判断任务应该交给 Codex 还是 Work

常见误区之一，是把所有 AI 相关的事都交给 Codex。

当任务需要实际技术操作时，Codex 最能发挥作用，例如：

• 修改代码仓库；
• 开发或修复功能；
• 运行测试；
• 分析日志；
• 迁移代码；
• 配置集成；
• 处理文件和开发工具；
• 用脚本自动化流程。

如果你想研究相机并制作对比表、准备销售演示文稿，或把几份材料整理成报告，通常可以先从 ChatGPT Work 开始。

可以用下面的规则快速判断：

• 主要产物是代码、技术配置或对系统采取的操作：使用 Codex。
• 主要产物是文档、分析、电子表格、演示文稿或报告：从 Work 开始。
• 只是想了解某件事或探索一个想法：使用 Chat。

选对工作入口，可以减少不必要的用量、错误和上下文切换。

2. 明确要交付什么，不要只说一个模糊愿望

像“把这个应用做得更好”这样的要求，留给 Codex 的解释空间太大。

它无法知道“更好”指的是提速、改设计、修复缺陷，还是重写架构。

一条可执行的任务说明至少应包含四项：

1. **上下文：**项目是什么，目前处于什么状态。
2. **目标：**你希望得到什么结果。
3. **约束：**哪些内容不能改变。
4. **成功标准：**怎样检查任务是否完成。

例如：

这个 React 应用用于预约管理。请修复用户双击时会创建重复预约的 bug。不要修改界面设计或数据库架构。当重复提交受到保护，且相关测试通过时，任务才算完成。

这样 Codex 得到的是一个有边界的问题和明确的成功条件。结果越容易验证，你就越不用猜它是否“看起来能用”。你也可以参考本站的 Codex 高质量提示词指南。

3. 提供恰当的上下文，并明确哪个文件才是准绳

Codex 可以读取与项目有关的文件夹、代码仓库和文档。但能看到更多信息，不代表它自然知道哪一份才正确。

请明确告诉它：

• 当前项目在哪个文件夹；
• 应该使用哪个分支；
• 需求写在哪里；
• 哪个文件定义业务规则；
• 哪些文档是最新的；
• 哪些文件只是历史资料或已经过时；
• 任务涉及哪些外部服务。

例如：

预约规则以 /docs/booking-rules.md 为准。/docs/old-flow.md 是历史资料，不要据此设计方案。修改代码前，请先列出需求与当前实现之间的冲突。

这样可以避免智能体悄悄替你调和互相矛盾的文档。在大型项目里，也值得维护一份长期有效的项目说明，记录架构、约定、开发命令、质量标准、安全规则和完成定义。不要让每次对话都从头摸索项目背景。

4. 重要改动先要计划，再允许执行

小修复可以直接开始；迁移、重构、基础设施变更，或会影响多个子系统的任务，应先要求 Codex 提交计划。

可以这样要求：

请分析问题并给出执行计划，列出受影响的文件、风险、依赖、回滚方案和验证方式。现在先不要修改任何内容。

审阅计划时，留意：

• 执行顺序是否合理；
• 是否发现了隐藏依赖；
• 是否有客观的验证方法；
• 是否准备了备份或恢复点；
• 改动范围是否超过解决问题所必需的范围。

要求计划并不是要给每件小事增加流程，而是在犯错代价较高时提高监督力度。

5. 只有在确实需要额外信息时才启用网页浏览

当你需要最新文档、近期 API 变更、库版本、技术规格、已知问题、当前价格或使用限制时，浏览网页会有帮助。

但每件事都打开浏览器会增加时间、用量，也可能带来低质量来源。可以这样约束：

优先使用项目文件和项目内文档。只有在缺少的信息可能已经变化，或需要核对官方文档时才进行网页浏览。浏览时说明要查什么、为什么需要查，以及使用了哪些来源。

也可以限制来源：

这项集成只使用服务提供方的官方文档。不要直接依据教程、论坛或旧答案实施，除非已经核实。

网页浏览不能代替对你已经提供的上下文进行推理。

6. 使用 Computer Use 时，只授予完成任务所需的权限

Codex 可以通过 Computer Use 操作应用：查看界面、点击、输入，以及使用缺少可靠 API 的工具。

这对测试界面、操作内部应用、检查注册流程、对比改动前后的视觉效果、处理旧系统，或自动化没有集成接口的工具很有用。

不过，操作界面本身也有风险：识错按钮、弹出意料之外的窗口，或界面布局变化，都可能触发你不希望发生的操作。因此应设置清楚的边界：

可以使用浏览器和测试应用。不要打开密码管理器、账单页面或个人账号。未经我授权，不要确认购买、发布、提交或删除操作。

处理文件时，可以这样要求：

只能在 /demo-project 文件夹内操作。不要移动、重命名或删除该文件夹之外的文件。删除文件前，先列出预览并等待我确认。

OpenAI 将 Computer Use 描述为通过自己的光标操作应用。权限越灵活，越需要限制作用范围，并按照操作风险安排监督。

7. 检查改动、运行测试，并要求证据

回答听起来很有说服力，并不能证明事情做对了。

Codex 修改项目后，要求它交代：改了什么、修改了哪些文件、相关差异、运行了哪些测试及结果、仍存在的问题、重要决策或假设，以及别人如何复现验证。

例如：

完成后用不超过 10 条要点总结，列出修改文件，运行相关测试，并说明我如何在本地复现验证结果。

遇到性能问题时，可以把目标写成可测量的指标：

将移动端 LCP 从 4.0 秒降到不高于 2.5 秒。在相同条件下测量改动前后，并附上 Lighthouse 结果。

这里有个容易弄反的概念：改善 LCP 意味着降低耗时，而不是提高耗时。

对于代码任务，较有力的证据通常包括自动化测试、干净的构建结果、lint、类型检查、基准测试、截图、日志和前后对比。

没有证据，你只能选择相信；有了证据，你才能进行审查。

8. 用语音协调进度，不用语音定义关键细节

在受支持的桌面应用中，ChatGPT Voice 可以与 Work 和 Codex 配合。你可以通过对话发起任务、询问进度、中断执行或协调工作。

语音很适合快速说明背景、审阅材料时记下想法、询问初步诊断、了解任务卡在哪里、协调多个工作线程，或要求汇报进展。

不过，重要细节最好用文字再次确认：路径、变量名、数量、域名、命令、验收标准、排除项、凭据和破坏性操作。

比较稳妥的节奏是：**用语音启动和引导，用文字授权和收尾。**这样既保留口头交流的速度，也不会丢失关键决策的精确性。

9. 根据任务在 Sol、Terra 和 Luna 之间选择

原文在 2026 年 8 月写道，Codex 提供 GPT-5.6 系列的三种主要模型：

• **Sol：**适合复杂、含糊或价值较高的工作。
• **Terra：**适合需要可靠推理和工具使用的日常任务。
• **Luna：**适合目标清晰、可重复、结构固定或批量较大的任务。

原文提到，拿不准时，官方建议先从 Sol 开始；Power 设置使用的是中等推理级别的 Sol。这并不意味着所有任务都要使用最大能力。

• **适合 Sol：**复杂架构、难复现的缺陷、迁移、深入技术研究、依赖众多的改动，以及有真实取舍的决策。
• **适合 Terra：**需求明确的功能、中等规模重构、代码分析、测试、技术文档和中等复杂度的自动化。
• **适合 Luna：**分类、提取、重复转换、机械式改动、结构化摘要，以及输出格式稳定的大批量任务。

选择能稳定产出可靠结果的最低推理级别。复杂任务可能需要更多推理，但也会增加用量和延迟。模型名称、可用范围和推荐设置可能随时间变化，请结合 Codex 模型文档确认当前信息。

10. 把重复流程沉淀成 Skills

Skills 是可复用的工作流程，用来教 ChatGPT 或 Codex 稳定完成某一类任务。一个 Skill 可以包含指令、示例、脚本、模板、质量标准、参考材料和固定步骤。

安装后，系统可以在相关任务中自动选用它；你也可以明确要求使用某个 Skill。

适合沉淀为 Skill 的流程包括：

• 按团队标准审查拉取请求；
• 准备软件发布；
• 执行无障碍检查；
• 把技术会议整理成任务；
• 检查 n8n 集成；
• 按模板生成文档；
• 分析生产日志；
• 按照设计系统搭建落地页。

不要把每条提示词都做成 Skill。若某个流程经常重复、具有明确标准、需要多人一致执行，或漏掉某一步会带来实际代价，才值得创建 Skill。

设计良好的 Skill，能把原本只存在于个人经验里的专业做法变成可复用流程。更多背景可见本站的技能与插件说明。

11. 自动操作界面之前，先找插件或集成

让 Codex 打开应用、到处点击之前，先检查是否已有插件、官方集成、API、MCP 服务器、专用 Skill 或命令行工具。

插件可以组合 Skills、应用、模板和集成，让 Codex 获得上下文并在受支持的工具中执行操作。原文提到 OpenAI 扩展了面向开发和生产力服务的插件目录。

建议按这个顺序寻找方案：

1. API 或官方集成；
2. 可信的插件或 MCP 服务器；
3. CLI；
4. 把 Computer Use 作为后备方式。

结构化集成通常比自动点击界面更可靠，尤其是流程需要重复运行时。选择自动化工具时也适用同一条标准：一个要运行上千次的流程，需要稳定的接口约定，而不是一个随时可能改变的屏幕。

如果没有合适的集成，再使用 Computer Use，并在每个关键步骤后检查；遇到不可逆操作时先确认。你也可以阅读本站的 MCP 指南和插件文档。

12. 为定时自动化定义可审计的输出

Codex 可以通过 Automations 执行周期性工作，例如：整理未分类的问题、分析 CI 失败、生成拉取请求摘要、检查过时文档、审查依赖、分析日志、继续长期任务，或跟进项目对话。

Automations 可以复用已有线程并保留上下文，之后继续推进工作。不要只安排一个动作，还要说明它必须交付什么：

每天早上检查过去 24 小时的生产错误。按可能原因分组，注明频率和影响，附上证据链接并建议优先级。不要修改任何生产环境内容。

请明确任务范围、频率、时间限制、信息来源、停止条件、输出格式、允许的操作和禁止的操作。

自动化如果执行了任务，却没有留下可验证的记录，很快就会变成一个黑箱。本站的定时任务文档介绍了相关功能。

13. 用 Goal 模式推进长期且可验证的目标

Goal 模式面向无法通过一次操作完成的工作。你可以设定一个长期目标和成功标准，让 Codex 持续推进。

它适合提高测试覆盖率、减少构建错误、完成迁移、保持文档同步、逐步改善某项指标，或关闭一份范围明确的问题清单。

目标必须有可观察的完成条件。

不好的目标：

把项目做得更好。

更有用的目标：

将项目中的 TypeScript 错误从 86 个降至 0 个。不要关闭规则，也不要把 any 当作通用修复手段。每完成一批改动就运行类型检查，并记录已解决的问题。

另一个例子：

将计费模块的测试覆盖率从 54% 提升到 80%，优先覆盖关键路径。不要为了提高覆盖率而编写无法验证实际行为的测试。

Goal 模式不会免除监督。智能体连续工作得越久，就越需要清楚的边界、检查点和验收标准。

14. 分清本地、远程和云端工作

理解这三者的差异，可以避免许多权限和预期方面的问题；具体行为也取决于你使用的 Codex 客户端。

• **本地工作：**Codex 访问你电脑上的文件夹或运行环境。适合处理本地文件、已安装的工具、特定开发环境、仅在本地网络运行的服务或桌面应用。只授予它必需的文件夹权限。
• **远程工作：**你可以从移动应用访问某些运行在受支持电脑上的 Codex 会话。要保持远程访问，宿主电脑必须开机、联网并运行 Codex。它适合查看进度、回答问题、批准操作，或继续电脑上开始的任务；这不等于 Codex 完全运行在手机上。
• **云端工作：**任务在托管的隔离环境里运行。适合处理代码仓库、并行运行任务，或委派不依赖你桌面环境的流程。

选择前可以问自己：

• 是否需要访问我电脑上的文件或程序？选本地。
• 是否需要通过另一台设备监督电脑上的会话？选远程。
• 是否可以在连接代码仓库的隔离环境中运行？选云端。

任务在哪里执行，决定了智能体能接触哪些数据和工具。本站还提供关于本地环境、云端环境和 Git Worktrees的说明。

15. 用可交付的结果收尾，不要只说“完成了”

Codex 的最后一条消息，应让其他人无需重读整个对话，也能知道发生了什么。

要求它提供收尾报告，包含最初目标、最终状态、修改文件、运行的测试、验证证据、尚存风险、已作出的决策、部署或继续工作的步骤，以及必要时的回滚说明。

可以复用这段提示词：

请用简短报告收尾。说明改了什么、没有改什么、如何验证、还存在哪些风险，以及其他人要继续处理时需要执行的准确步骤。

如果结果需要以可视形式分享，也可以使用 ChatGPT Sites 创建网页、轻量应用、仪表板或原型。Sites 在网页端的 Work，以及部分套餐、地区和工作区支持的桌面应用 Work 或 Codex 中可用。

不要自动发布敏感结果。先检查包含的文件、个人信息、密钥或秘密、访问权限、可见范围、域名和实际部署版本。

交付不只是结束执行，而是把结果留在可审查、可批准、可使用的状态。

实战示例

以下是一个用于演示的场景，不是真实客户案例；不包含指标、耗时或实测结果，只用于展示如何把前面的建议组合到同一项任务中。

**上下文：**一个使用 React 和 Node.js 的预约应用。业务规则保存在 /docs/booking-rules.md。用户连续点击确认按钮，系统就创建了两笔预约。

**任务：**修复重复预约问题，不要修改数据库架构或界面设计。

提示词：

请以 /docs/booking-rules.md 为唯一准绳。修复用户连续点击确认按钮会创建两笔预约的问题。你可以修改前端、API 和相关测试，但不要修改数据库架构或视觉设计。编辑之前，先提交计划，说明可能原因、受影响的文件和验证策略。

**预期改动范围：**确认按钮组件、API 中创建预约的处理逻辑，以及对应测试。

**验证方式：**前端与后端都具备重复提交保护；测试通过；并额外验证：带有相同幂等标识的两个请求不会创建第二笔预约。

**需要预先考虑的局限：**只在前端禁用按钮看起来可能足够，但另一个客户端仍然可以重复发送请求。真正起保护作用的应是服务端机制；浏览器端的保护主要改善用户体验。

每个提示词都应带上的安全规则

智能体越强，含糊指令可能造成的损失就越大。以下规则可以缩小风险范围：

• **最小权限：**只在获得授权的文件夹中工作。
• **破坏性操作先预览：**先列出将要删除或覆盖的内容，不要立刻执行。
• **明确确认：**未经书面确认，不要发布、购买、发送、删除或部署。
• **用量上限：**如果超过约定的时间、外部调用次数或成本上限，就停止。
• **不要把凭据写进提示词：**已有密钥管理方式、环境变量或托管凭据时，不要在对话中粘贴密码或令牌。
• **保留变更记录：**记录日期、操作、受影响文件和结果。
• **准备回滚：**触及生产环境前，先说明如何恢复到之前的状态。

安全不是任务结束后才加上的一次审查，而应该从定义任务时就纳入考虑。更多权限和审批方式可参阅本站的权限与安全指南。

使用 Codex 时的常见错误

• **提出要求，却不定义成功标准。**无法衡量结果时，智能体只能猜什么时候该停。
• **开放整台电脑的访问权限。**修改一个项目文件夹，并不需要获得全局权限。
• **明明有 API，却用 Computer Use。**相比结构化集成，自动点击往往更脆弱。
• **所有任务都选最强模型。**不必要的能力会增加用量和延迟，却不保证带来相称的提升。
• **不审查差异。**测试通过不代表改动正确、易维护，或符合业务要求。
• **浏览网页却不限制来源。**信息更新，不等于来源可靠。
• **安排定时任务却不要求报告。**自动化必须留下证据和记录。
• **混淆 Codex 和 ChatGPT Work。**二者有部分共同能力，但面向的主要产物不同。
• **给出互相矛盾的指令。**一边要求“自主执行”，一边要求“任何决定都先问我”，智能体无法判断哪条优先。
• **把“在我电脑上能运行”当作验证。**要定义运行环境、测试和可复现的条件。

Codex 提示词模板

可以重复使用下面的结构：

1. **上下文：**说明项目、当前状态和权威信息来源。
2. **目标：**写出具体需要的结果。
3. **范围：**说明允许修改哪些文件、系统或组件。
4. **排除项：**列明绝对不能触碰的内容。
5. **约束：**写清安全、兼容性、成本和允许使用的技术。
6. **计划：**说明是否需要先提交计划再执行。
7. **验证：**定义测试、指标或证据。
8. **交付：**指定最终结果的呈现格式。

完整示例

我们正在开发一个使用 React 和 Node.js 的预约管理应用。最新规则在 /docs/booking-rules.md。

请修复用户连续点击确认按钮会创建两笔预约的问题。

你可以修改前端、API 和与预约创建相关的测试。不要修改数据库架构或界面设计。

编辑前先提交一份简短计划，说明可能原因、受影响的文件和验证策略。

当且仅当：前端和后端都有重复提交保护、测试通过，并且相同标识的重复请求不会创建第二笔预约时，任务才算完成。

完成后请交付总结、修改文件、运行的测试以及尚存风险。

今天就能开始的检查清单

• 选一个真实且范围明确的任务。
• 判断它应该放在 Chat、Work 还是 Codex 中处理。
• 明确你要的交付物。
• 指定权威信息来源。
• 限制权限范围。
• 风险确实存在时，先要求计划。
• 定义检查结果的方法。
• 选择合适的模型。
• 审查改动和证据。
• 记录任务如何收尾。

不必一上来就做全面迁移，或安排一个替整家公司运行的自动化。从一项当前要花 30 到 60 分钟、有明确验证结果、并能在受控环境中运行的任务开始。

结语

学会使用 Codex，不是为了找到某句神奇提示词。

关键是把模糊要求转成可测试的目标，把全局权限收窄为最小访问，把“接受回答”变成“检查证据”，并从把 AI 当作助手，转向指挥它执行技术工作。

“氛围编程”适合探索想法和制作原型。但如果结果会影响客户、数据、生产环境或资金，你就需要更多保障：上下文、边界、测试和可追溯性。

Codex 可以编写代码、运行命令、处理代码仓库、操作工具，并在一段时间内持续推进任务。你的优势不只是能访问智能体，而是懂得如何围绕它设计一套可靠的工作系统。

从一个小结果开始。说清楚怎样才算完成。只开放必要权限。要求提供证据。然后再逐步提高自主程度。

常见问题

OpenAI Codex 是什么？

Codex 是 OpenAI 面向编程和技术工作的智能体。它可以编写和调试代码、运行命令与测试、审查改动、处理代码仓库，并根据当前环境和权限使用其他工具。

Codex 和 ChatGPT Work 有什么区别？

Codex 主要面向软件开发、终端、代码仓库和技术任务。ChatGPT Work 面向研究、分析，以及文档、电子表格、演示文稿、报告和 Sites 等交付物。

在 Codex 中应该使用哪个模型？

原文建议：复杂或含糊的问题使用 Sol；需要推理和工具的日常工作使用 Terra；目标清晰、重复且批量较大的任务使用 Luna。拿不准时，可以从 Sol 开始。模型可用性和推荐可能发生变化，请查看官方模型文档。

Codex 可以操作我的电脑吗？

在受支持的环境中，并且拥有相应权限时，Codex 可以通过 Computer Use 观察和操作应用。应限制访问范围，对敏感操作要求确认，并避免授予任务不需要的权限。

Codex 的 Goal 模式是什么？

Goal 模式让你为需要多轮推进的工作设定长期目标和成功标准。它最适合能通过测试、指标、状态或可验证交付物衡量进度的目标。

如何避免 Codex 删除文件或执行错误操作？

把访问权限限定在特定文件夹；破坏性操作前要求预览；使用备份或版本控制；删除、发布、部署或覆盖内容前要求明确确认。

离开电脑后，Codex 还能继续工作吗？

Codex 可以运行 Automations 和部分长期任务，具体方式取决于任务是在本地、远程还是云端执行。如果你是远程访问本地会话，宿主电脑必须保持开机、联网，并运行 Codex。

Codex 只适合开发者吗？

Codex 仍然主要面向软件和技术工作，但也可以借助代码、Skills、插件和 Computer Use 完成其他领域的任务。如果交付物不涉及实质性的技术工作，ChatGPT Work 通常更直接。

官方参考资料

• OpenAI：ChatGPT 中的 Codex
• OpenAI 帮助中心：ChatGPT Work 与 Codex
• OpenAI 开发者：Codex 推荐模型
• OpenAI 帮助中心：ChatGPT 中的 Skills
• OpenAI：介绍 Codex 桌面应用
• OpenAI：Codex 几乎无所不能
• OpenAI 帮助中心：创建和管理 ChatGPT Sites

**原文信息：**Luiz Fernando Brazão，How to use Codex: 15 tips for real results，IA Operators，2026 年 8 月 5 日。阅读英文原文。