乐于分享
好东西不私藏

OpenAI怎么用Codex

OpenAI怎么用Codex
前几天 OpenAI 放了一份内部 Codex 使用手册出来。
很多人看完第一反应是,这么大厂,肯定有什么杀手级 Prompt 套路吧。
看完之后我有点意外。
OpenAI 的真实跑法,朴素到让人怀疑这是不是公关稿。任务切小、文档先对齐、AGENTS.md 当全局上下文、先出计划再写代码、用 Best of N 做方案比较。
这些东西,说实话任何一个写了一年代码的工程师都听过。
但我做企业 AI 落地这几年,越看越觉得,这些朴素的工程约束,恰恰是大模型真正能干活的核心原因。
今天就聊聊这个。

第一个反直觉的事,不要迷信大模型能干大事。

OpenAI 内部对 Codex 任务的颗粒度要求是,人类写一小时,或者几百行代码。
听起来是不是挺保守的?大模型这么猛,几千行代码不在话下吧。
但你真跑过就知道,任务越大,模型越容易跑偏。小任务,模型能聚焦,能保持上下文,能跑通测试,能交付一个可用的 PR。大任务,模型写到后面开始忘前面的约定,开始自己脑补业务逻辑,开始用一些看起来合理但跟代码库现有风格不一致的写法。
最后你自己 review 起来比从头写还累。
那怎么验证"一小时"这个标准真的是最优的?
人工 review。没有什么花活,就是工程师看模型给的产出,看它跑出来的代码跟你的预期差多少,跑偏多就要切小,跑偏少就可以稍微放大一点。没有什么银弹参数,就是靠经验迭代。
这事让我想起一个做运维的老哥跟我说的话,他说他以前觉得运维工作就是装机器配环境,后来才发现,运维的核心能力不是装得多快,是能在故障发生的第一时间判断出哪里出了问题。
大模型编程也是这个逻辑。任务颗粒度是核心变量,不是模型能力。

第二个反直觉的事,拒绝让 AI 瞎猜。

OpenAI 内部有个实践是在代码库根目录维护一个 AGENTS.md 文件,把命名规范、业务规则、已知坑点、依赖说明全写进去。
我自己在企业里也用类似的招。我的感受是,这个东西有用,但别神化它。
说有用,是因为它确实解决了一类问题。比如某个函数是历史遗留的,不能用某种写法;比如某个接口的入参有特殊格式要求;比如某个测试是 mock 出来的。这些东西不写下来,模型每次都猜错。
但 MD 写完之后,AI 有可能不一定完全按照它的说明文档来。
我说句实话,AGENTS.md 不是写完就高枕无忧的。模型对长上下文的理解有衰减,AGENTS.md 写得太长,模型读到后面就开始忘前面。写得太短,复杂业务逻辑又兜不住。
我的实操经验是,AGENTS.md 控制在几十条到一百条规则之间,每条都短到一行能说清楚。规则多了就拆专题文档。模型读一份核心的,再按需读专题,效果比让它读一个长文档好得多。

第三个反直觉的事,绝不直接喷代码。

OpenAI 内部明确写了大改动先用对话模式让 Codex 出实现计划,确认没坑了再让它写代码。
这个我深有体会。
我之前用 AI 写代码经常栽在一个地方:计划看起来没问题,写出来跟计划确实有一些细节上的出入。
有时候这个出入是无关紧要的,模型自己做了小调整,整体能跑。但有时候这个出入是致命的,模型在某个边界条件上用了你没想到的实现方式,单元测试都过了,线上炸了。
所以现在我养成了一个习惯。任何大改动,先让 AI 出计划,我用十分钟扫一眼,看它的方案跟我脑子里的预期差多少。差得多的,直接打回重做计划。差得少的,让它按计划去写。写完之后再对着计划做 code review。
这一套下来,多花的十分钟能省后面 debug 的两小时。
Best of N 也是这个逻辑。
OpenAI 内部会让复杂任务一次生成多个方案,再人工选或者合并。
我用下来的感受是,肯定是有提升的。但要看你怎么用。
不要让 AI 一次生成 5 个完整方案让你选,那是浪费 token。最好是让它先出方案大纲,3 个不一样思路的,你挑一个最有戏的,让它在这个方向上深入。这种"先选方向再深挖"的 Best of N,既控制了成本,又能拿到多种思路的对比。
企业 AI 落地走到今天,我越来越觉得一件事。
大模型落地早就过了拼提示词玄学的阶段。现在拼的全是这种反直觉的工程约束。
什么是玄学?某种"魔法 Prompt",号称能让模型能力提升 30%。
什么是工程约束?任务切小到什么粒度最稳,AGENTS.md 应该写多长,先出计划再写代码能减少多少返工,Best of N 怎么用最省 token。
这些东西,每一个都没有黑魔法,每一个都需要在项目里慢慢磨出来。
但恰恰是这些朴素到无聊的纪律,决定了你的 AI 编程是跑得通还是跑偏。
Codex 的手册里有一个核心范式我特别喜欢:不是 AI 写代码,而是人定义目标,AI 执行任务,人 review 结果。
这个范式的重点是分工。
AI 不是你的替代品,AI 是你的执行层。你是目标定义层和验收层。中间靠文档、计划、测试这些工程产物连接起来。
这套分工一旦跑顺了,你会发现,AI 编程这件事的瓶颈,从来不是模型能力,是工程纪律。
我们这两年一直在等 AI 变强。但真正让 AI 编程在公司里跑起来的,从来不是更强的模型,是更稳的工作流。
所以下次你看到某个大厂又发了什么 AI 编程新工具,别急着冲。先问问自己,我现在的工程约束够不够稳。任务切清楚了吗,文档写好了吗,code review 流程跑顺了吗。
这些事做好了,用现在的模型也能跑出让人惊讶的效率。
这些事没做好,给你最强的模型也是在烧钱。
以上,既然看到这里了,如果觉得不错,随手点个赞、在看、转发三连吧,如果想第一时间收到推送,也可以给我个星标⭐~感谢你的阅读,我们下次见哦~

相关学习资料