Codex / 入门
Codex 概述
了解 Codex 如何作为软件工程智能体，在你写代码的各个入口里完成任务、修改文件并交付可审查结果。
Codex 是什么
Codex 是 OpenAI 面向软件工程的编码智能体，可以在本地和云端读取代码、编辑文件、运行命令、审查差异，并把结果交付为可验证的工程输出。
官方手册把 Codex 组织成多个 surface：CLI、IDE extension、Codex app、Codex web、GitHub、Slack、Linear、SDK 和自动化。它们共享同一类核心能力，但运行位置、权限边界和适用任务不同。
学习 Codex 时，不应只学“怎么让它写代码”，而要掌握执行模型：明确任务、加载项目规则、让它计划、控制权限、运行验证、审查 diff、沉淀复盘。
Codex 的入口
不同入口对应不同工作方式。CLI 适合本地仓库和真实命令；IDE 适合编辑器内审查；App/Web 适合任务管理和云端并行；SDK 适合把 Codex 嵌入产品或内部平台。
| 入口 | 适合场景 | 注意事项 |
|---|---|---|
| CLI | 本地修 bug、运行测试、脚本化执行。 | 受 sandbox 和 approval policy 约束。 |
| IDE extension | 在编辑器里引用文件、查看 diff、小步修改。 | 设置仍与 CLI 共享部分配置。 |
| App / Web | 管理任务、审查结果、远程/云端执行。 | 本地登录态和网络环境不同。 |
| GitHub / Slack / Linear | 从协作工具发起和跟踪任务。 | 需要保留人工审查和 CI。 |
| SDK | 构建内部 agent 平台或自动化。 | 必须设计权限、日志、超时和回滚。 |
学习原则
把 Codex 当成会执行工程动作的协作者。所有任务都要有目标、范围、限制、验证命令和可审查结果。
- 先读代码，再修改文件。
- 先计划，再执行。
- 先验证，再总结。
- 先审查 diff，再提交或部署。
完整使用要点
补充官方文档中容易被压缩遗漏的核心概念、操作顺序、权限边界和验证要求，方便中文学习者按页面完整学习。
官方结构补充
OpenAI Codex 文档的主线不是单一产品页，而是一套围绕“软件工程智能体”的使用体系。阅读顺序建议从概述开始，理解 Codex 如何跨 CLI、IDE、Web、App、GitHub、Slack、Linear 和 SDK 工作，再进入沙盒、权限、配置、AGENTS.md、MCP、Skills 与自动化。
- 入口层：决定任务在哪里发起，是否能访问本地仓库、浏览器登录态、远程云环境或团队协作上下文。
- 权限层：决定 Codex 可以读写哪些路径、是否能联网、什么时候需要人工或自动审批。
- 项目规则层：通过 AGENTS.md、配置、skills、hooks、MCP 把团队约定变成可复用上下文。
- 交付层：最终结果必须能被 diff、测试、构建、截图、PR 或发布记录验证。
因此 Codex 入门不应停在“让它写代码”。更可靠的学习目标是：能解释当前入口的权限边界，能把任务写成工程卡片，能读懂 Codex 的计划和命令输出，能在提交前审查改动和风险。
学习检查清单
把本页内容落到真实任务中，用入口、上下文、权限、验证和团队规则五个维度检查是否真正掌握。
学习检查清单
读完本页后，不要只记住概念名。你应该能把“Codex 概述”放回 Codex 的真实工程流程里：任务从哪里发起，系统会加载什么上下文，哪些动作需要审批，结果如何验证，失败时如何回退。
如果这是概念页面，要特别确认它如何影响真实任务：它改变上下文、权限、执行路径、验证方式，还是改变团队协作流程。
- 能用自己的话说明本页解决的具体问题，而不是只复述标题。
- 能写出一个最小示例任务，并标明目标、范围、禁止事项和验收标准。
- 能判断哪些信息应该放进当前提示，哪些应该沉淀到项目规则或配置里。
- 能说明哪些长期规则应该写进 AGENTS.md，哪些运行行为应该交给 config.toml、permission profile、skills 和 MCP。
- 能在任务完成后检查 diff、命令输出、测试结果、截图或 PR 说明，而不是只相信自然语言总结。
如果要把本页用于团队培训，可以让学员用 Codex 完成一个小任务：先只读解释，再提交计划，再执行最小改动，最后用真实验证命令和人工 diff 审查收尾。
Codex 实操注意事项
围绕本地环境、权限升级、远程入口、自动化失败和回滚补齐 Codex 使用中最容易被忽略的执行细节。
Codex 实操注意事项
这一页属于 Codex 的核心概念。学习时要把概念和真实执行联系起来：它会改变上下文、权限、任务拆分、验证路径，还是改变团队协作方式。
处理“Codex 概述”相关任务时，建议始终先确认当前 Git 状态和工作目录。Codex 可以很快完成修改，但它不会自动知道哪些未提交改动来自用户、哪些文件不能碰、哪些命令会影响生产环境。
- 本地任务优先使用低风险分支或工作树，完成后用 git diff 审查。
- 涉及安装依赖、联网、数据库、部署、push、删除、reset 时，先要求 Codex 解释影响再批准。
- 远程或协作入口生成的结果，也要回到 PR、CI、构建日志和测试证据中确认。
- 自动化任务要提前定义失败输出和退出条件，避免 Codex 在错误方向上反复尝试。
把 Codex 当成能执行命令的工程队友，而不是只会写文本的助手。越靠近真实系统，越需要明确边界、证据和回滚。