与 AI 编程智能体的第一次合作，应该是一场可控的实验，而不是盲目的冒险。给 Codex 指派一个规模小、可回退的任务，仔细观察它的每一步操作，并在任何内容到达生产环境之前及时停下。本文将带你完整走一遍首次使用周期：阅读仓库规则、建立干净的起始状态、请求一个有边界的改动、审查 diff、运行你已有的检查，并在需要时干净地回滚。命令执行、沙箱、审批提示等能力因产品形态、套餐、模型和管理员策略而异，具体的设置细节请以官方快速入门文档为准。想先了解背景，可以从我们的 Codex 概览 读起。
选择一个容易回退的任务
并非所有任务都适合作为第一次尝试。选一个同时满足以下条件的任务：
- 只涉及一两个文件，最好只影响一个行为单元
- 正确性显而易见：修复拼写错误、重命名、澄清 docstring、补一个缺失的测试
- 所在仓库已有测试，或至少有可以运行的构建
- 不需要新增依赖、不改 schema、不涉及密钥、不需要部署
好的例子：修复拼错的函数名、把含糊的注释写得更严谨、为已经正常工作的行为补一个测试。糟糕的例子：任何涉及认证、计费、基础设施，或缺乏测试覆盖的文件。如果一位完全陌生的新成员在无人监督下做这件事都会让你犹豫，那就把这个任务留到以后的会话。
先读规则，再建立干净的基线
大多数仓库会在 README、贡献指南，或类似 AGENTS.md 的智能体指令文件(如果项目提供的话)中写明自己的约定。先读这些内容，Codex 才会从项目的真实规范出发，而不是靠猜测。
然后确认仓库处于已知良好的状态，再让 Codex 写任何东西：
git status
git switch main
git pull
git switch -c codex-first-task
pytest # 或 npm test、go test ./...、mvn test —— 用这个仓库实际使用的命令如果基线本来就失败，先修复或记录下来；否则你无法区分 Codex 的改动和原有问题。绝不运行自己不认识的命令——先查 README 或 CI 配置，找到项目真正的测试命令。
只请求一个有边界的改动
模糊的提示词只会产生模糊的 diff。把任务、范围、禁区、验证方式都写清楚。可以套用这个模板：
任务:把整个仓库中拼写错误的函数 `recieve_user_input` 重命名为 `receive_user_input`。
范围:
- 更新函数定义和所有调用点。
- 不要改变行为、格式或任何无关文件。
- 不要安装依赖,也不要修改配置。
验证:
- 运行现有的测试套件,并报告结果。
- 用两三句话总结 diff。那些“不要”条款并不是摆设：它们把改动圈定起来，让 diff 保持在小到可以审查的规模。想了解更多模式——范围圈定、验证条款、后续追问——请阅读我们的 为 Codex 写出更好的提示词 指南，并把措辞建议与官方提示词文档相互印证。
运行新东西之前，先审查 diff
Codex 完成后，先读 diff,再决定是否接受或在此基础上继续：
git diff --stat # 哪些文件改了,各改了多少
git diff # 具体改动内容逐项过一遍这份清单：
- diff 里只出现你预期的文件
- 没有密钥、令牌或
.env文件 - 改动与请求一致——没有顺手夹带的重构
- 没有未经你要求的依赖、构建或 CI 改动
- 相关的命名、注释和文档同步更新到位
如果有不对的地方，用 git restore path/to/file 丢弃该文件的改动，再用更收紧的措辞重新提示。如果 diff 干净，就进入检查这一步。
运行现有的检查
相信项目自身的检查，而不是智能体的总结。用建立基线时的同一条测试命令，再加上项目的 linter 或构建(如果有的话)。把结果与基线对比：原来通过的测试应该继续通过，任何新出现的失败都应能追溯到你所请求的那项改动——而不是别的原因。视配置而定，Codex 可能会声称已经运行过测试；即便如此，也要独立验证，因为执行权限和沙箱机制因环境设置而异。同时，仔细阅读任何被修改过的测试：为了让有问题的行为通过而改写测试，是 AI 生成改动中一种典型的失败模式。
在部署之前停下，并清楚如何回滚
对于第一次任务，做到本地提交即可停下。有意识地暂存，让自己看清将要保留的内容：
git add -p # 暂存时逐块审查
git commit -m "Rename recieve_user_input to receive_user_input"在没有以全新的眼光复查已提交的结果之前，不要推送、不要创建 Pull Request,也不要部署。回滚路径，按从轻到重排列：
- 未提交的改动:
git restore .直接丢弃(对未提交的内容，这一步不可逆) - 一个糟糕的本地提交:
git revert HEAD;或在只有你自己使用的分支上用git reset --hard HEAD~1 - 分支已经无法挽救:
git switch main && git branch -D codex-first-task,然后从头再来
由于工作被隔离在独立分支上，最坏的结果只是删掉一个分支——而不是去修复一个共享仓库。
首次运行常见问题排查
| 现象 | 可能原因 | 首先尝试 |
|---|---|---|
| Codex 看不到预期的文件 | 工作目录不对，或仓库没有打开 | 确认智能体是在仓库根目录运行的，然后重新说明路径 |
| 改动之后测试失败 | 基线本来就失败 | 在干净的检出上重跑测试，并对比失败项 |
| diff 中包含无关文件 | 提示词范围太宽 | 还原无关文件，用明确的范围限制重新提示 |
| 智能体暂停并请求批准命令 | 审批或沙箱设置要求确认 | 批准这一条命令，或按官方文档调整设置 |
| 输出不符合项目约定 | 智能体看不到仓库规则 | 把贡献指南或指令文件指给它，然后重跑 |
局限性、隐私与安全边界
AI 编程智能体擅长有边界、可验证的修改，而在缺乏反馈信号的任务上并不可靠——大型重构、模糊的需求、没有测试覆盖的系统。要逐行审查；智能体的总结不能替代 diff。隐私与安全方面：绝不要在提示词中粘贴凭证、API 密钥或客户数据，并且让一切密钥完全不进入仓库。提示词和代码如何被处理，取决于适用的服务条款以及你的账户或组织的数据控制设置；管理员可能按套餐和地区进行不同配置。在受管环境中，把智能体接入任何仓库之前，请先确认内部政策。
常见问题(FAQ)
什么样的任务才算”低风险”?
单文件范围、正确性显而易见、已有测试覆盖、不新增依赖，并且没有任何通往生产环境的路径。如果一个失误会被你的测试套件发现，并能用 git restore 撤销，那它就符合标准。
Codex 说测试通过了，我该相信吗？
不要——要亲自验证。在改动后的代码上运行项目自己的测试命令，并与之前记录的基线对比。执行环境因设置而异，独立验证才是唯一可靠的办法。
如何撤销 Codex 做过的所有改动？
未提交的改动:git restore .。有问题的本地提交:git revert HEAD,或在你的私有分支上用 git reset --hard。最坏的情况是删掉工作分支；默认分支不受影响，因为你从一开始就隔离了工作。
在哪里能找到最新的官方说明？
设置和快速入门步骤、提示词指南、代码审查实践，请以官方文档为准。功能和默认值会随时间变化，也可能因账户、套餐和管理员策略而不同，所以官方文档的优先级高于任何文章——包括本文。