《Getting the most out of Codex》动手打了所有 Prompt 大师的脸

最近 OpenAI 在开发者网站发了一篇文章叫《Getting the most out of Codex》。翻译过来就是“怎么把 Codex 用出花来”。你可能会想这不就是又一篇 Prompt 教程吗。告诉你十个万能提示词模板然后标题写“让 AI 效率提升 1000%”评论区全是“已收藏下次一定看”。不是。这篇文章压根没教你怎么写 Prompt。它甚至暗示了一件很反直觉的事 —— 你的 Codex 不好用问题可能不在 AI。你以为是 Prompt 不行其实是仓库在拖后腿先讲个场景。你打开 Codex输入帮我修一下这个 xxxx 的 bug。它改了三行代码确实把 bug 修了。但同时把隔壁模块的接口改了还顺手升级了一个你不打算动的依赖。你血压上来了。你开始怀疑是不是我 Prompt 写得不够好是不是要加“请谨慎修改”这种话不是。你让一个人修水管如果没告诉他总闸在哪、墙里有没有电线、楼下邻居会不会漏水——他能干好才见鬼了。Codex 也是同一个道理。它差的那点东西不是推理能力是工作条件。这就是 OpenAI 这篇文章真正想说的Codex 的上限不取决于你单次 Prompt 写得多漂亮而取决于你的仓库有没有给它一个可执行的工程环境。坏 Prompt 与好工程环境的对比这句话值钱。我们拆开说。Prompt 不是咒语别念了过去一年半整个 AI 社区都在造一个神话只要 Prompt 写得好AI 什么都能干。于是涌现出一批 Prompt 大师卖课、卖模板、卖“提示词工程”认证。离谱。Prompt 这个词翻译成中文是“提示词”听起来特别像一句口诀。好像你念对了AI 就开悟了。但 OpenAI 这篇文章从头到尾没教你怎么“念口诀”。它反复强调的是一个结构1. 你要什么目标2. 相关的代码在哪、业务逻辑是什么上下文3. 什么不能碰约束4. 怎么才算做完了完成标准这四件事缺一不可。Codex 任务合同四要素但大多数人只说了第一件事。剩下的全靠 AI 猜。猜对了惊喜。猜错了骂一句 AI 垃圾。这跟你把实习生关小黑屋里、不给任务说明书、不让他问问题、完了骂他能力差有什么区别模糊 Prompt 让 Codex 猜需求写清楚的 Prompt 让 Codex 执行工单。你缺的不是更华丽的措辞是一个稳定的任务结构。第三次犯的错不该还留在聊天框里Codex 有个很容易被忽视的功能叫 AGENTS.md。简单说你在项目根目录放一个 Markdown 文件里面写好这个仓库怎么构建、怎么跑测试、哪些目录不能改、用什么包管理器、PR 要怎么写。然后每次 Codex 进入这个仓库它都会先读一遍。这个东西有多重要呢我给你算一笔账。你第一次告诉 Codex“别用 npm用 pnpm”。它记住了。第二次换了个会话你又得说一遍。第三次你烦了。但你还是说了。第四次你忘了说。它用 npm 装了一堆包把 lock 文件搞乱了。你骂它蠢。但真正蠢的是“一件事说了三次还没写进规则”这件事本身。重复三次的提示词不该继续留在聊天框里。它应该进 AGENTS.md成为仓库的一部分。重复规则进入 AGENTS.mdAGENTS.md 的价值不在于“文档做得好”而在于把一次性经验变成长期资产。你今天调教 Codex 花的时间明天、后天、下个月团队成员都能复用。这才是从“个人技巧”到“团队能力”的第一步。你的配置决定了 Codex 是员工还是野人大部分人的 Codex 是裸奔的。沙箱没开、审批没配、MCP 也没接。AI 进了仓库权限全开爱干什么干什么。你怕不怕说实话第一次看 Codex 自动删文件的时候我心脏停了一拍。但 OpenAI 的解决思路不是“收紧一切”。它给你的是一套控制面——•沙箱画一块施工区。AI 只能在这块区域里读文件、改文件。出了这个范围碰都不能碰。•审批策略某些命令自动跑某些命令必须先弹窗让你确认。比如删文件、连网络、访问数据库。•推理强度简单任务用快模式省钱省时间复杂重构切深度模式虽然慢但靠谱。•WorktreeGit 的独立工作区。你可以同时让一个 Codex 修 bug、另一个 Codex 写测试、第三个做重构每人一个独立目录互不打架。Codex 配置控制面这不是束缚。配置不是为了束缚 Codex而是为了让它能放心工作。你把边界划清楚AI 才敢在边界里大胆冲。边界模糊的时候它要么畏手畏脚要么胡乱越界。两种结果你都不想要。Codex 最危险的一句话“我已经做完了”AI 编程最让人心里发毛的时刻不是报错。是它自信满满地告诉你“搞定了”然后你一看——改了 300 行代码完全不管测试能不能跑类型检查全红还把另一个模块的接口给改了。它真的觉得自己搞定了。因为它没有验证意识。对它来说“写了代码”就等于“完成了任务”。但我们都知道写完代码和交付代码之间还隔着测试、lint、类型检查、code review、人工确认。OpenAI 这篇文章的价值在于它告诉你一件很重要的事不要让 AI 自己判断“做没做完”。让工程系统来判断。具体怎么做让 Codex 写完代码后自己跑一遍测试。测试挂了让它看报错日志自己修。修完再跑。跑过了让它自己看 diff确认改动范围没有越界。最后再走 PR 流程让人类 review。这叫什么闭环。一个健康的 Codex 流程不是“AI 写代码人检查”。而是“AI 写代码、跑测试、看 diff、修失败、再跑测试、再给人看”。Codex 工程闭环每一步失败输出都变成下一轮的输入。让 Codex 可靠的不是它说话多谨慎而是它逃不过测试和编译器。这是我用 Codex 一年来最重要的认知低阶用法是让 AI 吐代码你凭感觉复制。高阶用法是让 AI 进入你的工程流水线让测试、lint、类型检查、review 和审批一起约束它。AI 的价值是更快地跑完工程流程。MCP、Skills、Automations这三样东西决定了你是不是在用“玩具”前面说的是怎么让单次任务靠谱。但如果你想让 Codex 从一个“聊一下”的工具变成团队基础设施还有三个东西绕不开。MCP、Skills、Automations。三个东西很容易搞混。我用一句话说清楚•MCP让 Codex 能连外部工具。浏览器、数据库、GitHub、日历、内部系统——接上之后AI 能干的事指数级增长。•Skills把重复任务封装成可复用的流程。比如“从一段会议纪要生成 PR 标题”“把 API 变更同步成文档”——一次写好以后直接触发。•Automations定时任务。每天早上汇总未处理的 issue每周检查依赖升级风险每半小时回去跟进上次没做完的线程。这三样合起来Codex 就不只是一个“你问一句它答一句”的东西了。MCP 给 Codex 手和眼睛。Skills 给它工作方法。Automations 给它时间表。三样都配齐你拥有的不是一个助手而是一个能运行的工程代理系统。如果你现在打开 Codex先干这五件事我知道看完这篇文章你可能觉得搞这么复杂我还是回去手写代码吧。别! 不需要一步到位。真正有效的第一步是把最容易重复、最容易出错、最容易验证的部分先标准化。五件事按顺序来第一花 10 分钟写一个 AGENTS.md。不要写长篇大论。就写项目结构长什么样、怎么安装、怎么跑测试、怎么跑 lint、哪些目录是自动生成的不准改。这 10 分钟未来会省你 100 个小时。第二每一次给 Codex 任务都用同一个模板。目标、上下文、约束、完成标准。这四个字段缺一个都不发。养成习惯比写多华丽都重要。第三把检查命令写清楚让它自己跑。你的项目有测试吗有类型检查吗有 lint 吗如果有告诉 Codex 命令是什么让它改完代码自己跑一遍。不要让 AI 在黑暗里写代码。第四重复三次以上的操作封装成 Skill。每次发版都要写 release note每次都让你整理调研资料每次都让 Codex 先搜仓库再改这些都不该靠记忆。写一个 Skill 文件放仓库里。下次直接用。第五开权限之前先想明白边界。MCP 能连数据库能连浏览器能连你的 GitHub 账号。但连上之前问自己一句这个任务真的需要全权限吗能不能先只给只读能不能先连测试环境最小权限。这是用 MCP 的唯一铁律。最后说一句掏心窝子的很多人问我为什么我用 Codex 感觉时灵时不灵我以前也会回答“换个 Prompt 试试”, “试试别的模型”。但我现在越来越确定一个答案Codex 好不好用的天花板从来不在模型本身而在你的工程系统有没有准备好接待一个 AI 同事。你不会让一个新入职的同事不看文档直接上手干。你不会让他没跑测试就合并代码。你不会把生产数据库密码贴在墙上。那你凭什么给 AI 通着权限、不写规则、不加验证然后指望它每次都精准命中OpenAI 这篇文章最狠的地方不是教会你什么新技巧。而是逼你面对一个事实——真正会用 Codex 的团队不是在训练模型。他们是在训练自己的工程系统。你的仓库越来越会“接住 AI”而不是让 AI 自己瞎摸索。这个差别决定你是在玩一个酷炫的聊天框还是在建一条可靠的工程流水线。共勉。参考来源- OpenAI Developers, Getting the most out of Codex- OpenAI Developers, Prompting Codex- OpenAI Developers, AGENTS.md- OpenAI Developers, Codex MCP/Skills/Automations/Worktrees 相关文档