基础概念
先理解 Codex 的能力、边界和任务适配方式，再决定要不要让它执行。
为什么 Codex 值得考虑
当任务需要理解项目、修改真实文件、运行工具并验证结果时，Codex 比单纯对话更接近一套执行工作台。
从回答问题走向完成任务
普通聊天适合解释和构思；Codex 能围绕工作空间持续调查、修改、运行和检查，把建议落实为可审查的产物。
同一能力覆盖多个入口
你可以按工作习惯选择 CLI、桌面 App、Cloud / Web 或 IDE，不必为了使用核心能力改变整个工作环境。
适合真实而复杂的工作
跨文件修改、错误定位、测试验证、资料整理和重复流程都可以拆给它执行，人则保留目标、权限和最终验收。
先用现有账号与小任务试验
权益和额度以账号内显示为准。不要先根据营销比较购买或配置大量工具，先完成一个低风险闭环再判断价值。
能力与边界
完成本模块后：理解 Codex 和普通聊天 AI 的区别，并判断一件事情是否适合交给它。
01 Codex 不只是在聊天
普通聊天侧重回答问题；Codex 可以围绕一个工作空间读取文件、创建或修改内容、运行工具，并持续推进一个较完整的任务。
02 它擅长清楚且可检查的任务
整理资料、修改文案、创建页面、检查问题和执行重复步骤都很适合。任务有明确输入、完成标准，并且结果能由你检查时，成功率通常更高。
03 它不替你承担最终判断
涉及事实、隐私、金钱、发布、客户承诺和不可逆操作时，人仍需核验并决定。能力强不等于可以把责任一起交出去。
04 从协作而不是命令开始
先让它理解背景和计划，再允许执行；完成后查看真实变化和验证结果。好的体验来自持续对齐，而不是一句神奇提示词。
05 先选入口，再决定权限
快速问答、独立文件任务、代码项目和远程长任务需要的入口与权限不同。先判断任务是否需要真实文件和工具；如果只需要建议，就先保持只读，减少不必要的工作区访问。
06 先认识 Codex 的五种入口
Codex 不是单一软件，而是一组面向不同工作场景的入口：CLI 在终端中快速迭代；桌面 App 管理本地任务、Skills、插件和自动化；Cloud / Web 适合后台长任务与仓库协作；IDE 在编辑器上下文中做局部修改；ChatGPT 中的 Codex 适合从对话分派面向仓库的任务。它们共享核心能力，但上下文、交互方式和适用节奏不同。
07 根据工作动作选择入口
需要频繁查看命令输出、跑测试和修复代码时选 CLI；需要并行任务、可视化工作台、Skills 或电脑工具时选桌面 App；希望任务在后台持续运行或生成 PR 时选 Cloud / Web；正在编辑一个具体文件时选 IDE；已经在 ChatGPT 中讨论需求并准备连接仓库时，再考虑 ChatGPT 中的 Codex。不要因为某个入口功能最多，就把所有任务都搬过去。
08 按身份安排第一次学习顺序
开发者可以按 CodexGuide 的路径，从 CLI 建立“读取仓库—修改—运行命令—检查差异”的最小闭环，再学习桌面 App 与 Cloud。非技术用户更适合先用桌面 App 完成文件整理或页面修改，理解项目、任务和审批后，再决定是否需要 CLI。学习顺序应服务于真实任务，而不是追求把所有入口装齐。
09 理解入口背后的配置关系
AGENTS.md 为 CLI、桌面 App 和 Cloud 提供项目规则；config.toml 主要管理 CLI 与 IDE 的模型、审批和沙盒配置；Skills 把重复流程封装给 App、CLI 等入口使用；Worktrees 帮助桌面 App 隔离并行代码任务；Cloud Environments 描述云端运行环境；Sandbox 与 Approvals 则贯穿所有可执行入口。先理解关系，再修改配置。
10 建立入口选择的最小决策树
先问任务是否需要真实文件：不需要就留在普通聊天；需要时再问是否正在编辑代码、是否需要终端输出、是否要后台长时间运行、是否需要多任务与电脑工具。根据答案选择 IDE、CLI、Cloud 或桌面 App。最后确认工作范围、权限和验收方式，再开始执行。
查看实战模板与验收清单
判断任务是否适合 Codex
我想把下面这件事交给 Codex：
【任务】整理一份会议记录并生成待办清单
【输入】一份非敏感的会议文本
【风险】低，不涉及外部发送和删除
【验收】每项待办能在原文找到依据
请判断它是否适合，并告诉我还需要补充什么信息。完成检查
- 能说出 Codex 和普通聊天的区别
- 知道什么任务更适合交给它
- 知道哪些决定必须保留人工确认
- 会用小任务建立协作节奏
Codex 的当前形态
不要把 Codex 只理解为命令行编码助手，它正在发展为覆盖本地、编辑器和云端的任务执行系统。
产品变化看能力，不死记版本号
界面、默认模型、命令和账号权益会持续变化。教程重点关注项目、任务、工具、验证、Skills 与权限等稳定概念，具体版本以官方更新日志为准。
判断更新是否影响你
更新后用同一练习项目测试登录、文件读取、修改和验证链路。只有与当前任务相关的新能力才需要立即学习，不必追逐每个功能名称。
Codex 有什么用
它的价值不是多写一段回答，而是围绕真实工作空间持续完成任务。
理解与修改现有内容
读取项目结构、解释陌生文件、定位问题、修改代码或文档，并把变化落到实际文件中。
执行与验证工作
运行命令、测试和检查，比较修改前后的差异，记录失败原因与未验证项，让结果可以复查。
沉淀重复流程
把项目规则放进 AGENTS.md，把稳定流程做成 Skill，把长任务拆成可跟进的阶段，减少重复说明。
连接工作工具
在明确授权范围内使用浏览器、文档、仓库和其他插件；涉及外部发送、删除或敏感资料时仍由人决定。
适合哪些场景
优先选择输入明确、范围可限定、结果可验证、失败可恢复的任务。
场景一：看懂陌生项目
让 Codex 只读分析目录、入口、依赖与运行方式，并指出判断依据。适合接手项目、阅读代码和整理资料。
场景二：完成小型修改
修复一个明确问题、调整一处页面、补一组测试或整理一份文档。限定文件范围，并在交付前运行相应检查。
场景三：处理重复工作
批量分类、格式转换、生成固定报告或执行每日检查。先用小样本验证，再逐步扩大，不要一开始全自动。
暂时不适合直接执行
目标含糊、没有原始资料、无法验收，或涉及付款、生产环境、客户承诺与不可逆删除的任务，应先人工拆解和审批。
提供哪些工具与应用形式
不同入口没有绝对高下，选择最贴近当前工作动作的一种。
CLI
在终端里读取仓库、修改文件、运行命令和测试，适合希望看到完整执行过程的开发者。
桌面 App
用图形界面管理项目、任务、文件、Skills、插件和并行工作，适合多数新手与复杂本地协作。
Cloud / Web
连接仓库并在后台执行较长任务，适合团队协作、远程分析和生成可审查的变更。
IDE 与 ChatGPT
IDE 适合围绕当前代码边写边改；ChatGPT 中的 Codex 适合从已有对话分派仓库级任务。
安装
从官方入口完成安装与登录，并用最小权限和练习文件验证基础链路。
如何下载
先选适合自己的入口，再从 OpenAI 官方页面或可信应用商店下载。
普通新手：桌面 App
从 OpenAI 官方下载页选择当前系统版本。Windows 可通过官方入口进入 Microsoft Store，macOS 按官方安装包提示操作。不要从网盘、群文件或搜索广告下载所谓增强版。
开发者：CLI 或 IDE
CLI 和 IDE 的安装命令、系统要求可能更新，使用前查看官方文档；先验证 Node、Git 或编辑器版本是否满足要求，再选择一种入口安装，避免同时排查多个环境。
安装与首次使用
完成本模块后：通过 OpenAI 官方入口完成桌面应用安装、ChatGPT 账号登录、最小权限设置和第一次文件任务验收。
01 先选择入口：新手优先 Codex App
Codex 有桌面 App、IDE 插件、CLI 和云端等入口。第一次使用建议只安装 Codex App：它能直接管理任务、文件和项目，学习成本最低。CLI 是另一套终端入口，不等于桌面 App；只有明确需要命令行自动化时再安装。
02 Windows：从官方入口或 Microsoft Store 安装
优先从 OpenAI 官方 Codex App 页面进入 Windows 下载，或在 Microsoft Store 核对开发者为 OpenAI 后安装。等待系统完成下载，不要使用搜索结果里的来历不明安装包。若系统限制应用安装位置，先确保应用能正常安装到系统允许的位置。
03 macOS：下载安装并完成首次打开
从官方页面下载适合当前设备的版本，按系统提示移动到应用程序并打开。首次运行如果请求文件、自动化或辅助功能权限，只开启当前任务确实需要的权限；不建议为了省事一次开放整个磁盘。
04 官方账号登录：优先使用 Sign in with ChatGPT
打开 Codex 后，优先选择使用 ChatGPT 账号登录。登录页面、验证码和订阅确认都应由本人完成。能正常登录时，不需要额外安装模型切换工具，也不要把账号凭证交给任何第三方。
05 完成首次偏好设置
应用可能询问工作类型、个性化或基础偏好。它们用于优化体验，不会替你决定项目规则。新手可以按真实使用场景选择，也可以跳过不确定选项，后续再调整。
06 权限按任务逐项开启
文件、浏览器、电脑控制和网络访问是不同能力。只为当前任务开放确实需要的范围；遇到删除、覆盖、外部发送或安装软件时，先看清目标与影响再批准。不要为了省事直接开放整个用户目录。
07 版本变化以应用内提示和官方文档为准
界面名称、可用模型和账号权益可能随版本变化。教程截图与当前界面不一致时，先检查应用更新和 OpenAI 官方说明，不要通过不明安装包或修改系统安全设置来追求旧版界面。
08 建立第一个练习工作区
新建 codex-practice 文件夹，只放 README.md 和一份测试文本。打开这个文件夹后，先要求 Codex 只读检查并复述文件结构。这样能同时验证应用、账号、模型和文件读取权限。
09 运行第一条可验收任务
不要只问‘你是谁、你是什么模型’，因为回答无法证明文件能力。更可靠的测试是让它读取测试文件、生成一份新清单，再列出改动和验证方式。成功后亲自打开文件检查。
10 安装后常见问题的排查顺序
无法登录时先检查账号、网络和系统时间；看不到文件时检查打开的文件夹和系统权限；第三方模型不可用时检查供应商状态、Base URL、Key 和模型名；插件无法控制电脑时检查系统辅助功能权限。一次只改一个条件，避免反复重装。
11 确认你安装的是正确入口
桌面 App 适合可视化管理任务和文件；CLI 适合熟悉终端、需要脚本化操作的人；IDE 扩展适合在编辑器内处理代码。三者可以并存，但第一次使用只需选一个。不要因为教程展示了多个入口，就重复安装并在不同环境里排查同一个问题。
12 做一次权限基线检查
登录后先保持最小权限：只打开练习文件夹，不授予全磁盘访问，不放入密钥和真实客户资料。需要浏览器或电脑控制时，再为明确步骤单独开启。记录系统设置里开放了哪些权限、用途是什么，任务结束后关闭不再需要的权限。
13 用四层验收确认安装成功
第一层是账号能登录；第二层是能列出练习文件；第三层是经确认后能创建指定文件；第四层是能说明修改并让你亲自看到结果。任何一层失败都先停在该层排查。仅能聊天不代表文件能力正常，仅生成文件也不代表内容正确。
14 建立可重复的升级与排错路径
更新前记下当前版本和可用状态；更新后用同一练习任务复测。出现问题时依次检查官方服务状态、账号、应用版本、打开的项目、系统权限和网络。保留完整报错与复现步骤，最后才考虑清缓存或重装，避免把原始证据一起删掉。
查看实战模板与验收清单
安装完成后的验收任务
请先只读检查当前练习文件夹，不要修改文件。
1. 列出文件名，并说明你能否读取内容。
2. 复述 README.md 的主要信息。
3. 给出创建 first-task.md 的执行计划。
4. 等我确认后，再把 README.md 整理成三条行动清单写入 first-task.md。
5. 完成后列出修改文件、验证方式和仍不确定的地方。完成检查
- 确认安装包来自 OpenAI 官方入口或可信应用商店
- 能够区分 Codex App、CLI 和第三方模型切换工具
- 已使用本人 ChatGPT 账号完成登录
- 只开放当前练习任务需要的文件与系统权限
- Codex 能读取练习文件并按确认后的计划创建新文件
- 亲自检查了生成文件和修改范围
- 知道登录、应用版本和文件权限应该怎样分层排查
订阅 ChatGPT Plus / Pro
订阅资格、额度和可用功能会调整，购买前应以账号内方案页面为准。
先确认是否真的需要
先使用当前账号能访问的功能完成最小练习，再根据任务频率、并行需求和额度决定是否升级。不要把订阅当成学习 Codex 的前置考试。
只走账号内官方支付
在 ChatGPT 账号的方案或设置页面查看当前权益、价格、账单周期和取消方式。不要向第三方提供验证码、会话文件或代付登录。
在 CLI 中使用 Codex
适合需要频繁查看命令、测试和仓库状态的开发者。
从项目目录启动
先进入一个练习项目，再启动 Codex。首次使用完成本人账号登录，并先要求它只读解释目录、启动方式和测试命令，不要直接重构整个项目。
用最小命令闭环验收
让它修改一个明确文件、运行相关检查、展示差异并总结风险。CLI 能启动只证明安装成功，能完成并验证一个小改动才证明工作链路可用。
在桌面 App 中使用 Codex
适合希望同时查看任务、项目文件、修改内容和工具状态的人。
先打开练习文件夹
选择现有文件夹后，先查看文件树并让 Codex 复述项目。不要第一次就打开桌面或整个用户目录，也不要在没看计划前批准批量修改。
围绕同一项目持续协作
在一个任务里完成调查、修改与验证；目标改变或上下文过长时，总结现状再新开任务。并行任务使用隔离工作区，避免同时覆盖同一文件。
在 Cloud / Web 中使用 Codex
适合已连接仓库、希望任务在后台运行或生成可审查变更的场景。
先确认仓库与环境
只授权需要的仓库，检查默认分支、安装命令、测试方式和环境变量。敏感凭证通过受控环境配置，不写进任务说明或仓库文件。
先问懂没懂，再派任务
第一步让它解释项目入口、关键目录和验证方法；确认理解后再给范围明确的任务。完成后查看变更、日志、测试与未验证项，再决定是否创建或接受 PR。
在 IDE 中使用 Codex
适合在当前文件和代码选择范围内边写、边问、边修改。
从局部上下文开始
先让它解释当前文件或选中代码，再处理重构、报错、注释和测试。IDE 的优势是上下文靠近编辑位置，不代表它自动理解整个系统。
局部修改也要项目级验证
选中范围外的依赖和调用可能受影响。完成后查看完整差异，运行项目规定的类型检查或测试，不能只因为编辑器没有红线就认为任务完成。
运行
正确打开项目，完成一次从任务设计、只读调查、执行到验收的真实任务。
基础工具介绍：项目、任务、文件与上下文
完成本模块后：正确选择工作文件夹，让 Codex 理解任务范围，同时避免误读私人或重要文件。
01 理解工作范围
Codex 会围绕你选择的位置读取上下文。打开一个项目文件夹，相当于把这张工作桌交给它；桌外的内容不应该成为当前任务的一部分。
02 建立练习项目
新建 codex-practice 文件夹，放入 README.md、notes.txt 等简单文件。不要第一次就打开桌面、下载目录、整个用户目录或公司生产项目。
03 先让它复述
打开文件夹后先要求 Codex 列出结构、说明文件用途和它对项目的理解。确认无误前明确说“暂时不要修改”。
04 约定修改边界
正式开始前说清允许修改哪些文件、哪些文件只能读取，以及遇到删除、覆盖或密钥时必须暂停。
05 先确认项目是否可信
打开陌生项目时先保持只读，检查 AGENTS.md、项目配置、脚本和依赖安装命令。确认来源与影响前，不执行项目内脚本，也不授予网络、密钥或工作区外写入权限。
06 正确选择项目根目录
项目根目录应刚好覆盖本次需要协作的文件，并尽量包含 README、依赖清单、版本记录和项目规则。不要选单个深层文件夹导致 Codex 看不到必要配置，也不要直接选择桌面、文档或用户主目录。拿不准时，先创建项目副本或专用练习目录。
07 先让 Codex 建立只读地图
第一条指令要求它不要修改文件，只输出目录结构、关键入口、运行方式、测试方式和可能的敏感区域。让它说明每个判断来自哪个文件。你借此确认它是否找对项目、是否遗漏规则，也能在执行前发现大型生成目录和无关资料。
08 检查项目自己的规则与配置
重点查看 README、AGENTS.md、项目级配置、依赖脚本和环境变量示例。规则文件决定编码风格、验证命令和禁区；脚本可能安装依赖、访问网络或修改数据。陌生项目在信任来源前保持只读，不直接执行其中命令。
09 签署一次任务范围确认
执行前让 Codex列出允许读取的目录、允许修改的文件、需要运行的命令、明确禁止的动作和完成后的验证。范围变化时重新确认，不把最初对一个文件的授权自动扩展到整个项目。完成后用修改清单反向核对是否越界。
查看实战模板与验收清单
安全打开项目模板
请先只读检查当前文件夹：
1. 列出主要文件和用途。
2. 复述你理解的项目目标。
3. 指出可能包含敏感信息的文件。
4. 暂时不要修改、移动或删除任何内容。完成检查
- 项目范围足够小且明确
- Codex 能正确复述文件结构
- 敏感资料不在工作区
- 任何修改前都有明确边界
完成第一个任务
完成本模块后：完成一个从读取、计划、执行到验证的真实小任务，建立正确协作节奏。
01 选择低风险任务
第一个任务应在 20 分钟内完成、结果容易检查、出错也容易恢复。例如整理会议记录、润色 README 或把资料变成清单。
02 先要求计划
告诉 Codex 目标和交付形式，让它先读取资料并给出 3—5 步计划。计划不对时先修正理解，不要急着让它行动。
03 限定范围后执行
确认计划后，只允许它修改指定文件。执行过程中如果出现登录、外部发送、覆盖或删除，应停下来由你决定。
04 检查并做收尾
打开结果逐项验收，再让 Codex 总结修改内容、验证方式、仍不确定的地方和下一步。把有效指令保存下来。
05 完成报告必须包含证据
要求 Codex 列出实际修改文件、运行过的检查、未运行的检查和剩余风险。亲自打开产物并查看差异；只有结果与验收标准都对应上，任务才算完成。
06 为第一个任务设置成功条件
选择 20—40 分钟可完成、输入单一、输出可打开、失败可恢复的任务。提前写下三类标准：内容标准，例如每条待办有原文依据；范围标准，例如只创建一个文件；技术标准，例如文件能正常打开且格式正确。
07 先做只读调查，不急着生成
让 Codex 先列出它读取了什么、理解到什么、还缺什么，并引用关键依据。你要检查它有没有读错文件、把旧资料当最新版本，或对负责人和日期作出未经允许的推断。调查结果不可靠时，执行得越快返工越多。
08 把计划拆成可暂停的小步
计划应说明每一步的输入、产出、影响范围和验证方式。先完成结构，再填充内容，最后检查；每一步结束都能看见中间结果。遇到登录、安装、删除、覆盖、外部发送或范围扩张时设置人工确认点。
09 同时检查内容、文件与过程
内容检查事实、遗漏和语气；文件检查路径、格式和是否覆盖原稿；过程检查是否只改了允许范围、验证是否真实运行。三类证据缺一不可。即使最终页面看起来正常，也要确认没有隐藏的范围外修改。
10 用复盘决定下一次怎么做
记录本次最有效的指令、发生的误解、人工修改时间和未解决问题。如果错误来自任务说明，就改模板；来自资料质量，就改输入流程；来自工具限制，就缩小自动化范围。不要只保存漂亮结果而丢掉形成结果的方法。
查看实战模板与验收清单
第一次真实任务
请把 notes.txt 整理成 action-list.md。
要求：
- 只使用原文信息，不补充猜测。
- 输出事项、负责人、截止时间、待确认问题。
- 无法确认的信息写“待确认”。
先给我执行计划，等我确认后再创建文件。完成检查
- 任务范围清楚且低风险
- 执行前看过计划
- 只修改指定文件
- 结果已人工检查并保存模板
基础讲解：如何把任务说清楚
完成本模块后：写出 Codex 容易理解、能够执行并且可以验收的任务说明。
01 先写目标
目标描述最终变化，而不是空泛动作。不要只说“优化一下”，而要说“让第一次访问的用户在 10 秒内看懂产品用途”。
02 补充背景与输入
说明用户、场景、现有材料和相关文件。Codex 不知道你脑中的隐含背景，重要信息需要明确提供。
03 写清限制
标出不可修改的文件、必须保留的内容、语气、长度、技术条件和需要暂停确认的操作。
04 定义交付与验收
要求它用什么格式交付，并列出可检查标准。完成后让它报告改了什么、怎样验证、还有什么不确定。
05 把验收写成可观察证据
“更好看”“更专业”无法直接验收，应转换成可观察标准，例如指定视口无溢出、标题十秒内说明用途、测试命令通过、所有数字能回到来源。
查看实战模板与验收清单
六格任务说明
【目标】把首页介绍改得让新用户更容易理解。
【用户】第一次接触产品的非技术用户。
【输入】app/page.tsx 和现有品牌文案。
【限制】不改导航、不新增依赖、不删除用户已有内容。
【交付】修改页面，并列出文案调整。
【验收】页面能打开；标题说清用途；移动端不溢出。
先检查相关文件并复述计划，确认后再修改。完成检查
- 目标描述了最终结果
- 提供了必要背景和输入
- 明确了不能做什么
- 交付格式和验收标准可检查
任务执行与验证闭环
完成本模块后：看懂 Codex 的修改记录和检查结果，判断任务是真完成还是只生成了内容。
01 先看改了哪些文件
检查新增、修改和删除的文件清单。如果出现范围外文件，先暂停并询问原因，不要直接接受。
02 再看具体变化
逐段比较修改前后内容。重点关注被删除的信息、数字、链接、配置、依赖和看似顺手但未被要求的改动。
03 运行必要检查
页面任务要实际打开，代码任务要运行类型检查或测试，文档任务要检查结构、事实和链接。命令成功不代表用户体验一定正确。
04 要求完成报告
让 Codex 用简短清单说明修改、验证、未解决问题和风险。你应该能根据这份报告独立复查结果。
05 区分本次问题与既有问题
验证失败时先保存完整输出，并判断错误是否由本次修改引入。不要顺手修复所有旧警告；只处理当前目标直接相关的问题，把既有问题单独记录。
查看实战模板与验收清单
交付前检查指令
请在结束前做一次完整检查：
1. 列出所有新增、修改和删除的文件。
2. 说明每项修改对应哪个需求。
3. 运行适合本项目的验证。
4. 列出没有验证、仍不确定或需要我决定的事项。
不要把“已生成”写成“已验证”。完成检查
- 修改文件与需求一致
- 关键变化逐项看过
- 必要检查已经运行
- 未验证事项被明确列出
用手机远程跟进 Codex
手机更适合查看进度、补充方向和审批明确步骤，不适合盲批高风险操作。
桌面端先建立任务
在可信项目中启动任务，写清目标、范围和验收标准，确认电脑保持联网且任务入口支持远程跟进，再从同一账号的移动端查看。
手机端只做可判断的决定
查看最新摘要、修改文件和验证结果；看不清路径、命令影响或完整差异时不要批准，回到桌面检查后再继续。
用 AGENTS.md 固定项目规则
把重复说明变成项目内可追踪的工作约定，而不是每次聊天重新口述。
只写会影响执行的规则
说明项目入口、技术约束、测试命令、禁止修改区域、依赖策略和高风险确认点。规则要具体可执行，不要堆叠“写得优雅”之类无法检查的口号。
按目录逐层细化
根目录放全项目共识，子目录放局部命令和限制。修改规则后用一个小任务确认 Codex 是否正确读取，并随项目变化维护，避免规则与真实代码脱节。
查看新手 AGENTS.md 模板
# 项目说明
一句话说明项目用途与主要入口。
## 工作约定
- 修改前先说明计划和涉及文件
- 不修改范围外内容，不覆盖用户已有改动
- 新增依赖或删除文件前先确认
- 修改后运行项目已有检查，并报告未验证项
## 常用命令
- 开发：填写项目实际命令
- 检查：填写项目实际命令
- 测试：填写项目实际命令权限配置
区分审批与访问边界，保护敏感信息，并让每次重要修改都可恢复。
权限、安全与撤销
完成本模块后：识别高风险操作，保护敏感资料，并在修改不满意时安全恢复。
01 识别敏感信息
密码、验证码、API Key、身份证、客户隐私和未公开业务数据不应直接放进普通任务。示例资料先匿名化。
02 识别高风险动作
删除、覆盖、批量移动、安装系统软件、对外发送、支付和生产环境操作都应在执行前暂停，由人确认目标和影响。
03 建立恢复点
修改重要项目之前先备份或提交版本。大改动拆成小批次，每批检查后再继续，避免最后才发现无法回退。
04 安全撤销
先确认哪些变化来自本次任务，再仅恢复这些变化。不要为了撤销一处错误而覆盖用户在同一文件中的其他修改。
05 审批和沙盒是两道不同防线
审批决定某一步是否需要人确认，沙盒限制任务即使被执行时能访问的文件和网络范围。不要因为开启审批就默认环境安全，也不要因为在沙盒里就忽略高风险操作复核。
06 先做风险分级再授权
只读分析属于低风险；修改练习文件属于可恢复风险；安装依赖、访问网络和批量移动属于中风险；删除、覆盖、密钥、生产环境、付款和对外发布属于高风险。风险越高，目标解析、备份、人工确认和验证证据越要明确。
07 理解批准一次不等于永久授权
确认某条命令，只代表你理解并接受这一步的目标与影响，不代表后续相似命令都安全。批准前看清路径、参数、作用范围和恢复方式；包含通配符、递归操作、未展开变量或陌生脚本时，先要求 Codex 解析实际目标。
08 敏感信息采用最少暴露原则
能用假数据就不用真数据，能只给必要字段就不上传整份资料，能在本地完成就不复制到外部服务。密钥放在受控环境变量中，不写进提示词、截图、日志和版本库。发现泄露时，删除记录并不够，还要立即撤销或轮换凭证。
09 在修改前建立可验证恢复点
重要项目先确认 Git 状态或制作带时间的副本，记录用户已有的未提交修改。大改分批提交，每批对应一个目标。恢复时只撤销本次任务引入的变化，不能用整文件覆盖或强制重置误删用户同时进行的工作。
10 按证据执行安全撤销
先列出本次新增、修改和删除的文件，再查看具体差异，区分 Codex 改动和用户原有改动。选择最小恢复单元，撤销后重新运行原来的验证，并检查文件、页面和数据状态。无法确认来源时先备份当前状态，再请人决定。
查看实战模板与验收清单
高风险操作规则
执行以下操作前必须暂停并询问我：
- 删除、覆盖或批量移动文件
- 安装系统级软件或修改系统设置
- 使用账号、验证码、密钥或付款信息
- 向外部用户发送、发布或提交内容
每次修改前说明目标、影响范围和恢复方式。完成检查
- 敏感资料已移出工作区
- 高风险动作需要人工确认
- 重要修改前有恢复点
- 知道如何只撤销本次变化
接入第三方兼容模型
这是面向已有 API 使用经验者的可选方案，不属于 OpenAI 官方登录流程。
先核对兼容与责任边界
确认供应商、Base URL、模型标识、计费、限额、日志和数据留存规则。第三方服务的稳定性与隐私责任由相应供应商承担。
用独立密钥和匿名任务验证
密钥不写进对话、截图、代码或版本库。先用不含敏感信息的小任务测试读取、修改与错误处理；任何要求关闭安全防护的方案都应停止。
常见问题
用一套固定顺序定位登录、文件、任务和结果问题，而不是反复重装。
01 先判断问题在哪一层
把问题分成账号登录、应用启动、文件权限、任务理解和执行验证五层。先找最早失败的一层，后面的现象通常只是连锁反应。
02 缩小到最小案例
新建空文件夹和一份文本，测试能否读取。如果最小案例正常，问题多半在原项目权限、文件规模或规则；如果也失败，再检查应用和账号。
03 记录可复现步骤
保存完整报错、发生时间、操作步骤和已经尝试的方法。不要只说“不能用”，也不要在没有记录前同时修改多个设置。
04 按风险从低到高处理
先重试单个任务、重新打开项目、检查权限和网络，再考虑退出登录、更新或重装。处理后用同一最小案例复测。
05 先查服务状态，再重置本地环境
登录或模型突然不可用时，先查看官方状态、应用更新和账号范围；随后用空文件夹复现并保存完整错误。只有确认本地缓存或安装损坏后才重建。
查看排查模板与检查清单
问题发生在：登录 / 打开项目 / 读取文件 / 执行任务 / 验证结果
我看到的完整提示：
复现步骤：
最小练习文件夹是否正常：
已经尝试：
最近修改过的设置：
请先判断最可能的层级，再给从低风险到高风险的排查顺序。- 能指出问题属于哪一层
- 使用最小案例成功复现
- 完整记录错误与步骤
- 按顺序处理并重新验证
执行过程中卡住了？
加入免费交流群，交流 AI 学习、Codex 安装、任务设计、工作流和实际问题。
加入免费交流群