openai教程:如何使用codex编程

很多人第一次用 Codex 写代码，卡的地方不是不会装，而是不知道让它干什么、干完怎么看对不对。这篇按一天的活来排：先把环境和第一句指令跑通，再挑几个典型任务练手，最后给你一套看结果、查报错、控制节奏的做法。全程不写死数字，遇到要看价格和额度的，都告诉你去站内哪一页翻当时的数字。

第一次上手 Codex，卡住的地方基本不是安装，而是「不知道让它干什么、干完怎么判断对不对」。这篇按一天的活来排：先把环境和一个最小任务跑通，再挑几类最常见的编程任务练手，最后给你一套看结果、查报错、控制节奏的做法。

全文不写死任何数字。涉及价格、额度、限速、模型对比的，一律到站内对应页面核对当时的情况——这些数字变动频繁，写死在教程里第二天就过期了。

第一天只做三件事：把工具跑起来、让它改对一个小文件、看懂它到底动了哪里

1. 确认能跑通先确认客户端版本和登录状态正常，再用一个git clone出来的玩具仓库试跑，别一上来就对着主项目动手。
2. 发出第一句指令不要写「帮我优化代码」。改成「读一下这个文件，先用一句话说明它做什么，然后只改这个函数的某个具体行为，不要动其他文件」。
3. 验收改动改完先看它列出的文件清单和diff，确认只落在你指定的范围，再决定跑不跑测试。

跑不通的时候，先分清是客户端没配好、登录态失效，还是额度或限速问题——这三类处理方式完全不同。配置类的坑去 与 对照着查，别在一个方向上死磕。

日常最常用的四类任务：补函数、写测试、读老代码、按报错修

• 补函数时把「不要动哪些文件、不要引入新依赖」写进指令，比事后回滚省事。
• 写测试先让它读现有测试文件，学会你的断言风格和fixture用法再动手。
• 读老代码让它先产出说明文档和可疑点清单，你确认之后才进入修改环节。
• 按报错修时把完整堆栈、复现命令、最近一次改动一起贴，缺一样它就容易猜。

结构化输出的写法（比如要求它返回固定字段、固定格式）可以参考 ；报错类问题的排查顺序另有一篇 讲得比较细，遇到连不上、被拒绝的情况先去那里过一遍。

验收与收手：怎么判断这次改动能不能留、什么时候必须自己接手

• diff是否只落在预期文件，有没有顺手改无关代码。
• 依赖文件有没有变，有没有偷偷加包。
• 测试是否真的跑过、跑的是不是相关用例。
• 改动会不会影响别人正在用的接口或数据结构。

这四条里有任意一条过不了，就别提交。给它设定轮次上限也很重要，比如「最多改两轮，改不好就停下来说明原因」——跑飞的典型征兆是反复改同一个文件却不再提供新信息，这时候继续对话只是浪费额度。护栏的具体思路见 。

涉及数据迁移、删数据、改鉴权、动生产配置的任务，不要让AI直接执行，让它出方案、列风险，落手由你来做。另外建议每次任务记一行：指令原文、改了哪些文件、结果如何。记几次之后你会清楚自己哪类描述最容易返工。

哪些情况不适合用 Codex，以及怎么退回手工

Codex适合把已经想清楚的事做快，不适合替你想清楚。

如果它给的方案让你觉得绕，别急着和它争论，换成「先给两个更简单的备选方案，说明各自的代价」再挑，通常一轮就能拉回来。不确定团队允许把哪些内容发出去时，先去 看看有哪些本地或自建的替代方案。