chatgpt + codex 程序员实用指南

面向程序员和技术团队，介绍 ChatGPT、ChatGPT Work、Codex 桌面端、Codex CLI、IDE 扩展和 Codex Cloud 的区别、用法与协作方式。
本文依据 OpenAI 官方文档重新整理，最后核对日期：2026-08-06。产品处于持续更新中，账号套餐、组织策略和灰度发布可能导致界面略有不同。

目录

• 1. 先建立正确的产品地图
• 2. 如何选择：一张表看懂
• 3. ChatGPT Chat：快速交流与思考
• 4. ChatGPT Work：完成较长的多步骤工作
• 5. ChatGPT 的 Web、桌面和移动端
• 6. Codex 的产品形态
• 7. Codex CLI 入门与常用命令
• 8. Codex 桌面 App 工作流
• 9. Codex IDE 扩展
• 10. Codex Cloud
• 11. 提示词写法与实用模板
• 12. AGENTS.md、配置和长期规则
• 13. Skills、Plugins、MCP、Hooks 与自动化
• 14. 权限、沙箱与安全
• 15. 程序员端到端实战
• 16. 常见误区
• 17. 速查清单
• 18. 官方资料

1. 先建立正确的产品地图

1.1 ChatGPT 不再只有“聊天”一种工作方式

按照当前官方产品结构，ChatGPT 中最需要区分的是三种体验：

官方的简化选择方式是：

• 想问问题、搜索或讨论想法，选 Chat。
• 想完成研究、分析或制作一份成品，选 Work。
• 想读写代码仓库、运行命令和测试，选 Codex。

这三个名称描述的是“工作体验”，Web、桌面 App、移动 App、CLI 和 IDE 则是访问这些能力的“产品表面”。二者不要混为一谈。

1.2 ChatGPT 与 Codex 的根本差别

ChatGPT 更偏向通用知识工作：理解问题、组织信息、研究、沟通和制作内容。

Codex 是软件工程代理：它围绕真实开发环境工作，能够检查仓库、编辑文件、运行本机或云端命令、执行测试、检查 diff，并把结果交给开发者审阅。

可以把它们类比为：

ChatGPT Chat  = 技术顾问 / 结对讨论者
ChatGPT Work  = 能持续执行多步骤知识工作的项目助理
Codex         = 能进入开发环境动手工作的工程代理

1.3 OpenAI API 是另一类产品

ChatGPT 和 Codex 是开发者直接使用的成品工具。OpenAI API 则用于把模型能力集成进你自己的程序、服务或产品。

例如：

• 用 ChatGPT 讨论客服机器人的需求；
• 用 Codex 在仓库中实现客服系统；
• 用 OpenAI API 为最终客服产品提供模型能力。

ChatGPT 订阅、Codex 使用权限和 API 计费/凭据不是一回事。登录 ChatGPT 不代表你的服务端程序自动拥有 API Key。

2. 如何选择：一张表看懂

2.1 一个实用决策树

任务主要是修改真实代码仓库吗？
├─ 否
│  ├─ 只是问答、搜索、讨论？ → Chat
│  └─ 需要多步骤执行或正式产物？ → Work
└─ 是
   ├─ 正在编辑器里做聚焦修改？ → IDE 扩展
   ├─ 偏爱终端或需要脚本/CI？ → CLI
   ├─ 需要可视化管理、审查和本机工具？ → 桌面 Codex
   └─ 需要后台、隔离环境或并行任务？ → Codex Cloud

3. ChatGPT Chat：快速交流与思考

3.1 适合做什么

• 学习语言、框架、协议和算法；
• 解释代码片段、错误堆栈和日志；
• 讨论架构方案；
• 生成伪代码、SQL 草稿或测试思路；
• 快速搜索最新资料；
• 头脑风暴产品需求和边界情况；
• 改写技术文档、邮件和 PR 描述。

示例：

我熟悉 Java、线程池和 CompletableFuture，但不了解 Go 的 goroutine。
请用我熟悉的概念解释 goroutine、channel 和 context，
然后给一个“并发请求三个服务，超时后取消”的最小例子。
最后指出这种类比在哪些地方不准确。

告诉 ChatGPT 你已经掌握什么，比单纯说“通俗解释”更容易获得合适的答案。

3.2 适合调试，但要提供证据

一个有效的调试请求应包括：

• 完整错误信息和堆栈；
• 相关代码；
• 运行环境和版本；
• 预期行为与实际行为；
• 最小复现步骤；
• 已经尝试过什么。

这是一个 Java 21、Spring Boot 3.4 应用。
预期：事务提交后发送领域事件。
实际：偶尔查不到刚写入的数据，堆栈如下……

请先列出最可能的三个根因，按概率排序；
再给出逐个排除的最小实验。现在不要重写代码。

当问题依赖整个仓库、构建系统或真实运行环境时，应切换到 Codex。

3.3 Web 搜索与深度研究

会变化的信息必须联网核对，例如：

• 当前软件版本和 API；
• 云服务规格和价格；
• 安全公告与 CVE；
• 法律、政策和行业标准；
• 最新模型或产品能力。

请联网核对 React 当前官方文档对 Server Components 的建议。
只使用 React 官方站点和官方博客，给出链接。
如果不同版本的页面结论不同，请明确区分。

• 普通搜索适合快速查一个事实。
• 深度研究适合多来源、较长链路、需要研究计划和引用报告的问题。

深度研究可以使用公开网页、上传文件和已连接的数据源。开始前可以检查和修改研究计划，执行中也可以调整方向。

4. ChatGPT Work：完成较长的多步骤工作

4.1 Work 和 Chat 的区别

Chat 以交流为中心；Work 以“完成一个明确结果”为中心。

适合 Work 的任务：

• 调研并输出一份有依据的技术选型报告；
• 分析日志、表格或多份文档；
• 制作文档、演示文稿、电子表格或 PDF；
• 创建可交互的 Site、仪表盘或项目跟踪器；
• 使用插件从多个系统收集上下文；
• 运行计划任务或监控变化。

示例：

分析我上传的三个月 CI 数据，识别最常见的失败类型和耗时瓶颈。
输出：
1. 一份管理层可读的两页摘要；
2. 按仓库、测试类型和责任团队拆分的表格；
3. 三项优先改进建议及预期收益；
4. 数据不足或推断不确定的地方。
不要修改源文件。

4.2 Work 的使用原则

给 Work 的请求应明确：

• 最终交付物是什么；
• 可以使用哪些文件、网站和插件；
• 目标读者是谁；
• 格式、长度和风格；
• 需要遵循的标准；
• 完成前如何自查。

基于附件中的架构图、事故复盘和监控导出，制作一份 10 页以内的技术复盘 PPT。
读者是后端工程师和 SRE。
必须区分事实与推断，引用数据来源，包含时间线、根因、放大因素、行动项和负责人。
使用简洁工程风格，不要编造缺失指标。

4.3 Work 与 Codex 怎么协作

一个常见流程是：

1. 用 Work 汇总需求、用户反馈和业务资料，形成 PRD 或技术任务书。
2. 将任务书放入代码仓库。
3. 用 Codex 读取任务书，调查代码并实现。
4. 用 Work 根据最终变更制作发布说明、培训材料或报告。

Work 可以生成代码片段，但“需要在真实仓库中可靠修改和验证”时，应交给 Codex。

5. ChatGPT 的 Web、桌面和移动端

5.1 ChatGPT Web

访问 chatgpt.com 即可使用。Web 端适合：

• 快速使用 Chat 或 Work；
• 使用上传文件、Projects、Skills 和 Plugins；
• 调研、分析和制作可下载产物；
• 跨设备访问云端聊天；
• 不需要直接访问本机仓库或桌面应用的任务。

Web 端的 Work 在云端运行，不能直接读取你电脑上的任意本地文件。需要通过上传、项目文件或连接器提供上下文。

5.2 ChatGPT 桌面 App

当前 Windows 和 macOS 桌面 App 把主要体验集中在一起：

ChatGPT
├─ Chat
└─ Work

Codex
└─ 软件开发专用视图

桌面 App 的优势：

• 可打开本地文件夹和项目；
• 在授权后使用本地文件、浏览器和桌面应用；
• 同时管理多个聊天和长任务；
• 创建和检查文档、表格、图片等产物；
• 在 Codex 视图中使用仓库、终端和开发工具；
• 使用计划任务；
• Work 或 Codex 在符合账号条件时可使用语音协调任务。

注意：Chat/Work 的历史记录与 Codex 历史是分开的。切换顶部入口时，要确认自己当前位于哪种体验。

5.3 ChatGPT 移动端

移动端适合：

• 使用 Chat 进行快速问答；
• 使用云端 Work；
• 继续在其他设备开始的云端 Work；
• 查看和回应需要你介入的任务；
• 通过 Remote 访问部分受支持的桌面 Codex 聊天。

当前官方说明中，完整 Codex 不能像 Chat 或 Work 一样直接在移动端选择。移动端的 Remote 更像远程跟进入口，不等同于完整本地开发环境。

5.4 Projects

Project 会把相关聊天、文件和项目指令放在一起，适合持续性工作。

例如为某个后端系统建立 Project：

项目背景：内部订单系统，Java 21、Spring Boot、PostgreSQL。
默认使用中文解释，代码与标识符使用英文。
架构建议必须说明兼容性、数据库迁移、可观测性和回滚。
涉及版本的事实必须核对官方文档。

Project 适合知识和资料上下文；仓库的构建命令、代码规范和测试要求更适合写入 AGENTS.md。

6. Codex 的产品形态

Codex 的不同形态使用相同的工程思路，但交互位置和最擅长的场景不同。

6.1 这些形态并不是互斥的

可以在 IDE 中开始调查，在任务变大时委派到 Cloud；也可以从 CLI 查看云任务，再回桌面 App 审查结果。

推荐组合：

• 个人快速开发：IDE + CLI；
• 多仓库和多任务：桌面 App + worktree；
• 长任务和团队委派：Cloud + GitHub；
• CI 自动检查：codex exec 或 GitHub Action；
• 技术负责人：桌面 App 管理任务，IDE 做精细修订，Cloud 做并行探索。

7. Codex CLI 入门与常用命令

7.1 安装

使用 npm：

npm install -g @openai/codex

macOS/Linux 可使用官方安装脚本：

curl -fsSL https://chatgpt.com/codex/install.sh | sh

检查版本：

codex --version

进入项目根目录再启动：

cd /path/to/project
codex

首次运行会要求登录，可按界面选择 ChatGPT 登录或当前版本提供的其他认证方式。

7.2 第一次使用

先让 Codex 只读了解项目：

介绍这个项目的业务目标、入口、主要模块、数据流、启动方式和测试命令。
引用关键文件路径。只分析，不修改文件。

再交给它一个小而明确的任务：

为用户注册接口增加 email 格式校验。
沿用现有错误结构，不添加新依赖。
先检查现有校验方式，然后做最小改动，补充测试并运行相关检查。
最后报告修改文件、测试结果和剩余风险。

7.3 常用斜杠命令

实际命令以当前版本中输入 / 后显示的列表为准。

7.4 常用 CLI 示例

带初始任务启动：

codex "解释当前项目的鉴权流程，只分析，不修改"

指定工作目录：

codex -C /path/to/project "分析最近失败的测试"

附加图片：

codex -i error.png "根据截图修复前端布局问题并验证"

只读运行：

codex --sandbox read-only "审查鉴权设计，列出具体风险"

允许写当前工作区，越界时请求批准：

codex --sandbox workspace-write --ask-for-approval on-request

本地代码审查：

codex review

非交互执行：

codex exec "运行相关测试，分析失败原因，并输出 Markdown 摘要"

查看当前版本准确参数：

codex --help
codex exec --help
codex review --help

7.5 CLI 最适合的场景

• 习惯终端优先的开发；
• 需要直接使用本机编译器、测试工具和脚本；
• 提交前做本地审查；
• 编写可重复的非交互流程；
• 从终端委派和跟进 Cloud 工作。

8. Codex 桌面 App 工作流

8.1 为什么选择桌面 Codex

桌面 App 更像代理任务的控制台：

• 按项目组织多个任务；
• 在一个界面中查看进度、命令和文件；
• 使用 diff 面板逐行审阅；
• 打开集成终端；
• 管理长期任务和通知；
• 通过 Git worktree 隔离并行任务；
• 使用 Browser、Computer Use、Skills、Plugins 和 MCP；
• 创建计划任务。

8.2 Local、worktree 和 Cloud

如果两个任务会修改同一批文件，不要让它们同时在同一个本地工作区运行。使用独立 worktree 或 Cloud 环境。

8.3 推荐流程

1. 打开仓库，检查当前分支与 Git 状态。
2. 让 Codex 读取 AGENTS.md 和相关代码。
3. 复杂任务先使用 /plan。
4. 确认计划后再实现。
5. 要求运行测试、lint 和类型检查。
6. 打开 diff 面板逐文件查看。
7. 对具体代码行直接提出反馈。
8. 使用 /review 再检查一遍。
9. 人工确认后才提交、推送或创建 PR。

示例：

先进入计划模式。把订单导出从同步接口改为异步任务。
调查当前 API、数据库迁移、任务系统、权限和前端调用。
计划必须覆盖旧客户端兼容、幂等、重试、状态查询、测试、监控和回滚。
在我确认计划之前不要改代码。

9. Codex IDE 扩展

IDE 扩展的核心优势是“上下文已经在编辑器里”。它可以利用：

• 当前打开的文件；
• 选中的代码；
• 当前项目；
• 最近的相关聊天。

9.1 适合的任务

• 解释当前文件或函数；
• 对选中代码做聚焦重构；
• 生成或补充相邻测试；
• 在代码旁审查变更；
• 快速迭代一个小功能；
• 任务变大后转交 Cloud。

示例：选中一个重试函数后输入：

检查选中实现是否存在指数退避计算、最大重试次数或取消传播问题。
先解释风险，再做最小修改并补充对应测试。

9.2 不要依赖“它应该知道我在看哪里”

虽然 IDE 能自动提供编辑器上下文，但仍应说明：

• 你要达到的行为；
• 哪些兼容性不能破坏；
• 相关但未打开的模块；
• 测试和完成标准。

大范围跨模块改造更适合桌面 Codex、CLI 计划模式或 Cloud。

10. Codex Cloud

Codex Cloud 在隔离的云环境中运行编码任务，可以从专门的 Codex 云端入口、CLI 或集成工具发起。

10.1 适合什么

• 任务需要长时间后台运行；
• 同时尝试多个实现方向；
• 不希望占用本机；
• 需要标准化、可复现的依赖环境；
• 从 GitHub、Linear 或 Slack 委派工作；
• 不在开发电脑旁，但需要启动或审阅任务。

10.2 基本流程

1. 使用 ChatGPT 账号登录 Codex Cloud。
2. 连接 GitHub，并限制可访问仓库。
3. 为仓库配置环境、依赖、变量和初始化步骤。
4. 发起任务并观察日志，或让它后台执行。
5. 审查摘要和 diff。
6. 继续追问修改，确认后再创建 PR。

10.3 Cloud 不是“自动正确”

远程运行不会减少工程审查责任。必须检查：

• 环境与生产/本地是否一致；
• 依赖安装和网络权限；
• Secret 的使用范围；
• 测试是否真正执行；
• diff 是否包含无关改动；
• PR 是否需要额外人工验证。

11. 提示词写法与实用模板

11.1 四段式任务描述

官方最佳实践建议任务至少包含：目标、上下文、约束和完成标准。

目标：修复重复支付回调导致订单状态回退的问题。

上下文：重点检查 src/payment/webhook.ts、订单状态机和现有支付测试。
典型事件顺序是 PAID → REFUNDED → 迟到的 PAID 回调。

约束：不能改变外部 API；状态转换必须单调；不增加数据库表；沿用当前日志格式。

完成标准：先用测试复现，实施最小修复，运行相关测试和类型检查。
最后报告根因、修改文件、测试结果和未解决风险。

11.2 六个高频技巧

1. 指定范围：哪些目录相关，哪些不要动。
2. 说明完成标准：测试、性能、兼容和输出格式。
3. 复杂任务先计划：先调查，暂不修改。
4. 要求证据：报告实际运行的命令和结果。
5. 小步实现：按可独立验证的垂直切片推进。
6. 要求自审：实现后检查 diff、边界和回归风险。

11.3 模板：理解陌生项目

快速熟悉这个仓库，只读取和分析。
说明业务目标、入口、模块关系、主要数据流、启动方式和测试方法。
引用关键文件路径；不确定的地方明确标注，不要猜测。

11.4 模板：实现功能

实现 [功能]。
相关模块：[文件或目录]。
必须保持：[接口、兼容性、架构约束]。
禁止：[不能修改的内容]。
先检查现有模式，再做最小改动，补测试并运行验证。

11.5 模板：修复缺陷

复现并修复以下问题：[现象、日志、步骤]。
先定位根因并用测试复现，再修改生产代码。
不要通过删除断言、吞掉异常或禁用检查让测试通过。
最后说明根因、修复原理、测试结果和潜在回归范围。

11.6 模板：代码审查

审查当前未提交改动，不修改代码。
重点检查正确性、安全、并发、性能和兼容性。
只报告可操作且有证据的问题，按严重程度排序，引用文件和行。
如果没有明确缺陷，也要说明测试或验证上的剩余风险。

11.7 模板：技术调研

调研 [主题]，目标读者是 [角色]。
只使用 [允许的来源]，标注信息日期并给出链接。
比较 [候选方案] 的功能、复杂度、成本、风险和适用边界。
把事实、推断和建议分开，最后给出推荐和验证计划。

12. AGENTS.md、配置和长期规则

12.1 AGENTS.md

AGENTS.md 是写给编码代理的仓库说明。适合存放：

• 仓库结构和关键目录；
• 安装、构建、测试和 lint 命令；
• 代码风格与架构约束；
• PR 和审查要求；
• 禁止事项；
• 完成任务前的验证步骤。

示例：

# Repository guidance

## Layout
- `apps/api`: FastAPI service
- `apps/web`: React frontend
- `packages/shared`: shared types and utilities

## Commands
- Install: `pnpm install`
- Unit tests: `pnpm test`
- Type check: `pnpm typecheck`
- Lint: `pnpm lint`

## Conventions
- Use TypeScript strict mode.
- Reuse existing components before adding dependencies.
- Public API changes require compatibility notes.
- Schema changes require forward and rollback migrations.

## Verification
- Run tests closest to the changed code first.
- Before completion, run typecheck and lint for affected packages.
- Report checks that could not be run and why.

## Do not
- Do not edit generated files manually.
- Do not commit secrets or `.env` files.
- Do not change CI or deployment files unless requested.

层级规则：

• ~/.codex/AGENTS.md：个人全局偏好；
• 仓库根目录：团队通用规则；
• 子目录：该子树的局部规则，更靠近目标文件的说明优先。

使用 /init 可以生成初稿，但要人工校对。短小、准确、可执行的文件比堆满口号的长文更有效。

12.2 config.toml

常见配置层：

• 个人配置：~/.codex/config.toml；
• 项目配置：.codex/config.toml；
• 命令行临时覆盖：-c key=value。

配置可控制模型、推理强度、沙箱、审批、网络、MCP、Hooks 和功能开关等。字段会随版本演进，修改前查看当前官方配置参考。

12.3 规则应该放在哪里

13. Skills、Plugins、MCP、Hooks 与自动化

13.1 Skills

Skill 把一套可重复的方法封装为说明、模板、参考文件和脚本。

适合：

• 固定清单做 PR 审查；
• 生成发布说明；
• 标准化事故分析；
• 执行团队迁移流程；
• 按统一模板生成文档。

当你反复复制同一提示词，或不断纠正同一流程时，就值得做成 Skill。

13.2 Plugins

Plugin 是可安装能力包，可以包含 Skills、工具、MCP 连接器、Hooks 和其他资源。

例如一个 GitHub Plugin 可以让 ChatGPT/Codex 按授权范围读取 Issue、检查 PR 或执行明确的写操作。

13.3 MCP

MCP 用于连接外部工具和实时数据。适合：

• GitHub Issue/PR；
• 内部知识库；
• 项目管理系统；
• 数据库或监控平台；
• 经授权的组织文档。

CLI 添加远程服务的常见形式：

codex mcp add <name> --url <server-url>

从一两个真正消除手工操作的连接开始，不要一次接入所有系统。写操作和删除操作应有更严格的权限。

13.4 Hooks

Hook 用于在工具调用、命令执行或文件编辑前后实施可重复的机械规则。例如：

• 禁止修改特定路径；
• 执行命令前做策略检查；
• 编辑后运行格式化或审计；
• 记录关键工具调用。

需要“提醒模型遵守”用 AGENTS.md；需要“无论模型怎么想都机械执行”才考虑 Hook。

13.5 Scheduled Tasks / Automations

适合稳定、重复、输出容易审查的流程：

• 汇总近期提交；
• 归类 CI 失败；
• 起草发布说明；
• 扫描潜在缺陷；
• 生成站会摘要；
• 监控依赖、Issue 或文档变化。

先手动把流程跑稳定，再调度。可以把 Skill 看作“怎么做”，把计划任务看作“何时做”。

14. 权限、沙箱与安全

14.1 沙箱与审批是两个层次

• 沙箱：Codex 技术上可以访问和修改什么。
• 审批策略：什么操作必须暂停并获得用户允许。

常见沙箱：

默认本地模式通常限制写入工作区，并限制命令网络访问。访问工作区外路径或网络时可能请求批准。

14.2 批准前检查什么

1. 具体命令是什么；
2. 为什么必须越过当前限制；
3. 精确读写或删除哪些路径；
4. 是否会访问网络、上传代码或读取凭据；
5. 能否使用更小权限完成；
6. 操作失败后能否恢复。

14.3 安全底线

• 不在提示词或源码中粘贴 API Key、私钥和生产凭据；
• 不让未知脚本直接获得高权限；
• 删除、迁移、发布前建立可恢复点；
• 合并 PR、部署、发消息和生产写入应由人确认；
• 使用 Git 提交、分支或 worktree 隔离改动；
• 审查第三方网页、Issue 和 README 中可能存在的提示注入；
• AI 生成代码仍要测试、代码审查和安全扫描；
• 只为 Cloud 或插件开放任务确实需要的仓库和系统。

15. 程序员端到端实战

假设需求是“为博客系统增加草稿自动保存”。

第一步：Chat 澄清需求

帮我把“草稿自动保存”变成可实现的需求。
请逐项询问保存频率、并发冲突、离线行为、权限、保留策略和兼容性。
最后输出验收标准和异常场景，不写代码。

第二步：Work 形成正式任务书

根据刚才确认的需求和上传的现有 API 文档，制作一份工程任务书。
包括目标、非目标、接口草案、数据模型、用户流程、异常场景、验收标准和上线检查表。
事实缺失处标记为“待确认”，不要编造。

第三步：Codex 计划

把任务书放入仓库后：

阅读 docs/draft-autosave.md，调查文章 API、数据库迁移和前端状态管理。
使用计划模式，给出最小实现方案、涉及文件、迁移、兼容性、测试和回滚。
先不要修改代码。

第四步：按垂直切片实现

按确认后的计划先实现后端保存接口和测试，暂不修改前端。
保持现有 API 兼容，不引入新框架。
运行相关单元测试、集成测试和类型检查。

再实现前端：

实现前端自动保存。处理请求乱序、重复提交、网络断开和页面退出。
沿用现有通知组件，补充测试，不改变发布流程。

第五步：审查

审查当前改动，重点检查旧客户端兼容、并发覆盖、越权保存、请求风暴、数据丢失和迁移回滚。
只报告有证据且可操作的问题，不修改文件。

第六步：用 Work 制作交付材料

根据任务书、最终 diff 摘要和测试结果，生成发布说明和客服 FAQ。
区分用户可见变化、内部实现和已知限制。

第七步：人工验收

• diff 与需求一致；
• 没有无关重构；
• 测试确实执行；
• 权限、安全、日志和监控合理；
• 数据迁移可执行、可回滚；
• 文档和发布说明已更新；
• PR 描述清楚；
• 仍有风险时明确记录，而不是默认为已解决。

16. 常见误区

误区 1：把 Chat、Work 和 Codex 当成同一种聊天窗口

改进：按任务结果选择体验。快速交流用 Chat，成品交付用 Work，仓库开发用 Codex。

误区 2：一句“帮我写完”就期待生产级代码

改进：提供目标、上下文、约束和完成标准。

误区 3：复杂任务直接开写

改进：先 /plan，确认影响面、迁移、测试和回滚。

误区 4：只读最终总结，不看 diff 和日志

改进：把 Codex 结果视为同事提交的待审变更。

误区 5：为省事开放全部权限

改进：从只读或工作区写入开始，只为明确需要授权越界操作。

误区 6：把长期规则复制到每个提示词

改进：仓库规范放 AGENTS.md，个人默认放配置，重复流程做 Skill。

误区 7：多个代理同时改同一工作区

改进：使用独立 worktree、分支或 Cloud 环境。

误区 8：让模型凭记忆回答版本问题

改进：要求联网、使用官方来源并注明核对日期。

误区 9：流程还不稳定就自动化

改进：先手动跑通和做成 Skill，再创建计划任务。

17. 速查清单

开始前

• 选择了正确体验：Chat、Work 或 Codex；
• Codex 形态适合任务：桌面、CLI、IDE 或 Cloud；
• 工作目录、仓库和分支正确；
• Git 状态清楚并有恢复点；
• 提供了关键文件、日志和需求；
• 写明禁止修改的范围；
• 权限与风险匹配。

完成前

• 检查全部 diff；
• 运行相关测试；
• 运行必要的 lint、格式化和类型检查；
• 没有密钥、隐私数据或调试残留；
• 没有无关的大范围重构；
• 兼容、迁移和回滚已考虑；
• 未运行的验证项已明确说明；
• 外部副作用由人确认。

团队沉淀

• 重复规则是否应加入 AGENTS.md；
• 重复流程是否应做成 Skill；
• 外部上下文是否适合 Plugin/MCP；
• 机械约束是否需要 Hook；
• 稳定流程是否适合计划任务；
• 多任务是否使用 worktree 或 Cloud 隔离。

18. 官方资料

以下资料均为 OpenAI 官方页面：

• ChatGPT Work 与 Codex 的区别
• ChatGPT Web
• ChatGPT 桌面 App
• ChatGPT Projects
• ChatGPT 深度研究
• Codex CLI
• Codex IDE 扩展
• Codex Cloud
• Codex 开发者命令参考
• Codex 最佳实践
• Codex 权限、审批与安全
• Skills 与 Plugins
• Codex 开源仓库

如果只记住一句话：Chat 用来快速交流，Work 用来完成多步骤成品，Codex 用来进入开发环境交付可验证的软件变更。